August 20, 2026
12 min read
Table of Contents
By Kokil Thapa | Last reviewed: August 2026
Hiring managers ask Linux interview questions for DevOps not to test memorised definitions, but to verify you can diagnose production failures under pressure. Theoretical knowledge of the kernel is useful, but practical competence with systemd, permissions, networking stacks, and log analysis separates operators who keep systems running from those who only pass certification exams. This guide covers the exact topics I use when evaluating candidates and the answers that demonstrate real operational maturity.
Quick answer: Effective Linux interview questions for DevOps assess practical troubleshooting across four domains: boot and service management (systemd), file permissions and ownership, network diagnostics (ss, ip, nftables), and resource analysis (strace, perf). Strong answers cite specific commands, config paths, and production trade-offs rather than abstract theory.
What Core Linux Interview Questions for DevOps Reveal Operational Competence?
The most telling Linux interview questions for DevOps probe your mental model of how the operating system actually works when things break. When I evaluate engineers for DevOps automation roles, I skip trivia about kernel versions and focus on scenarios that mirror real incidents. A candidate who can explain the difference between a hard link and a soft link is fine; a candidate who can trace why a Laravel queue worker silently fails after deployment because of a stale PID file or incorrect group ownership on the storage directory is someone I want on my team.
Operational competence shows up in three ways during technical interviews. First, the candidate names specific tools and their modern replacements (ss over netstat, journalctl over raw log grepping). Second, they describe verification steps, not just fix steps. Third, they acknowledge trade-offs: disabling SELinux might restore service immediately, but it creates a security debt that must be tracked. If you are preparing for interviews or building your own assessment rubric, structure questions around these observable behaviours rather than rote recall.
Why scenario-based questions beat definition recall
Definition questions have a ceiling. Anyone can memorise that "inode is a data structure storing metadata." Scenario questions have no ceiling because they reveal depth. Ask instead: "A developer reports that file.txt exists and has 644 permissions, but their PHP application gets 'Permission denied'. Walk me through your diagnosis." A junior answer checks ls -l. A senior answer checks parent directory execute bits, SELinux/AppArmor context, filesystem mount options (noexec, ro), open file descriptor limits, and whether the web server process runs under a different user namespace. That diagnostic tree is what you actually need on a Tuesday night when the payment gateway callback is failing.
How Do You Explain the Linux Boot Process and Systemd Service Management?
Understanding the boot sequence is foundational Linux interview questions for DevOps territory because every service reliability issue traces back to how and when that service starts. In 2026, systemd is universal on server-class distributions (Ubuntu 22.04/24.04 LTS, RHEL/Rocky 9, Debian 12). Candidates who still describe SysVinit runlevels as current practice are signalling outdated experience.
The boot sequence you must articulate
- Firmware (UEFI/BIOS): POST executes, locates bootloader via EFI variables or MBR. UEFI systems load
/boot/efi/EFI/ubuntu/grubx64.efi; legacy BIOS loads stage1 from MBR. - Bootloader (GRUB2): Presents menu, loads kernel (
vmlinuz) and initramfs into memory. Kernel command line parameters (root=,quiet,splash) are visible viacat /proc/cmdline. - Initramfs: Temporary root filesystem mounts real root device, handles LUKS decryption, LVM activation, RAID assembly. Failures here produce dracut/initramfs emergency shells.
- Kernel init:
/sbin/init(symlinked to systemd) starts as PID 1. Default target determined bysystemctl get-default(usuallymulti-user.targetfor servers). - Systemd unit activation: Units activate based on dependency graph (
Wants=,Requires=,After=). Parallel startup where dependencies allow. Journal captures all output.
Systemd questions that reveal real experience
Expect questions like: "Your Nginx service fails to start after reboot but works fine with manual systemctl start nginx. Diagnose." The answer involves checking journalctl -u nginx -b for boot-time errors, verifying After=network-online.target (not just network.target), confirming the unit file isn't masked (systemctl is-enabled nginx), and checking whether a configuration test directive (ExecStartPre=/usr/sbin/nginx -t) is failing silently due to missing certificate files that haven't been provisioned yet by an ACME client.
<!-- Common diagnostic commands for systemd issues -->
# Check why a unit failed at last boot
journalctl -u php8.3-fpm.service -b --no-pager -n 50
# View full unit file including drop-ins
systemctl cat laravel-queue-worker.service
# Verify dependency ordering
systemd-analyze critical-chain laravel-queue-worker.service
# Check if unit is masked or overridden
systemctl status laravel-queue-worker.service
ls -la /etc/systemd/system/laravel-queue-worker.service.d/
# Reload daemon after editing unit files
sudo systemctl daemon-reload
sudo systemctl restart laravel-queue-worker.serviceOn production Laravel applications I maintain, queue workers are managed as templated systemd units (laravel-queue@.service) so multiple workers can run with identical configuration. Interviewers value candidates who know this pattern because it demonstrates infrastructure-as-code thinking applied to OS-level services.
How Do File Permissions, Ownership, and ACLs Actually Work in Production?
Permission questions appear in virtually every set of Linux interview questions for DevOps because misconfigured permissions cause more silent application failures than almost any other category. The basics (rwx, owner/group/other) are table stakes. What matters is understanding edge cases that break deployments.
Beyond chmod 777: permission models that survive production
When a candidate suggests chmod 777 as a solution, that's an immediate signal of inexperience. Production systems use precise permission models. For a typical Laravel application deployed with Deployer on Ubuntu 24.04, the correct setup looks like this:
# Application files owned by deploy user, readable by www-data group
sudo chown -R deploy:www-data /var/www/app/current/storage
sudo find /var/www/app/current/storage -type d -exec chmod 2775 {} \;
sudo find /var/www/app/current/storage -type f -exec chmod 0664 {} \;
# Setgid bit (2xxx) ensures new files inherit www-data group
# This prevents permission drift when deploy user creates cache/logs
# Verify effective permissions including ACLs
getfacl /var/www/app/current/storage/logs/laravel.log
# Fix umask for deployment scripts to prevent future drift
echo "umask 0002" >> /home/deploy/.bashrcThe setgid bit on directories is the detail that separates working deployments from ones that break after the next release. Without it, files created by the deploy user during php artisan cache:clear won't be writable by www-data (PHP-FPM), causing 500 errors until manually fixed. I've seen this exact issue take down client portals during peak traffic because the CI pipeline ran cache warmup as the wrong user.
ACLs: when POSIX permissions aren't enough
Standard POSIX permissions handle owner/group/other. When you need granular access (e.g., a monitoring agent needs read access to logs without being in the www-data group), use POSIX ACLs:
# Grant readonly access to monitoring user without changing group
setfacl -m u:monitoring:r-- /var/www/app/current/storage/logs/laravel.log
# Make ACL persistent for new files (default ACL)
setfacl -d -m u:monitoring:r-- /var/www/app/current/storage/logs/
# Audit current ACL state
getfacl /var/www/app/current/storage/logs/Interviewers may ask when to use ACLs versus groups. The practical answer: use groups for broad, stable access patterns (web server, deploy user). Use ACLs for exceptional, temporary, or cross-cutting access that shouldn't pollute group membership. ACLs add complexity; don't introduce them without documenting why.
Which Network Diagnostic Commands Replace Deprecated Tools in 2026?
Network troubleshooting dominates Linux interview questions for DevOps because connectivity failures are the most common production incident category. Tools have evolved significantly; using deprecated commands signals stale knowledge.
| Deprecated Tool | Modern Replacement | Key Advantage | Example Command |
|---|---|---|---|
netstat | ss | Faster (netlink vs /proc parsing), richer socket state info | ss -tulnp | grep :443 |
ifconfig | ip addr | Supports modern features (VLANs, bridges, namespaces) | ip -br addr show |
route | ip route | Policy routing, multiple tables, IPv6 native | ip route get 8.8.8.8 |
iptables | nftables / nft | Unified IPv4/IPv6, sets/maps, better performance | nft list ruleset |
arp | ip neigh | Consistent syntax, neighbour state visibility | ip neigh show dev eth0 |
host / nslookup | dig / resolvectl | DNSSEC validation, systemd-resolved integration | dig +trace example.com |
Diagnostic workflow for "application can't reach database"
This scenario appears constantly in interviews and real incidents. Follow this ordered checklist:
- DNS resolution:
dig db.internal.example.com— verify A/AAAA record matches expected IP. Check/etc/resolv.confand systemd-resolved status (resolvectl status). - Routing:
ip route get 10.0.5.20— confirm packet takes expected interface. Wrong route = VLAN/subnet misconfiguration. - Connectivity:
nc -zv 10.0.5.20 5432— TCP handshake succeeds? Timeout = firewall/security group. Refused = service not listening. - Socket state:
ss -tnp | grep 5432— check for TIME_WAIT accumulation, half-open connections, or unexpected source ports. - Firewall:
nft list rulesetorufw status verbose— verify INPUT/OUTPUT chains allow the connection. Don't forget egress rules. - Application layer:
PGCONNECT_TIMEOUT=5 psql -h db.internal.example.com -U app_user— isolate network from auth/config issues.
Candidates who jump straight to "check the firewall" miss the three preceding layers where problems actually live. On a recent legal-tech portal deployment, the database connection failed because systemd-resolved was caching a stale DNS entry after a failover; resolvectl flush-caches resolved it in seconds, but only after methodically ruling out routing and socket issues.
How Do You Debug Resource Exhaustion and Performance Issues Under Load?
Performance debugging questions separate senior candidates from mid-level ones in Linux interview questions for DevOps assessments. Anyone can read top output; seniors correlate metrics across subsystems to identify root causes.
The diagnostic toolkit for resource issues
When CPU, memory, or I/O saturation hits production, follow this escalation path:
- Triage with
vmstat 1: Sample every second. Watchr(run queue),b(blocked on I/O),si/so(swap activity). Highb+ swap = memory pressure causing I/O thrashing, not CPU problem. - Identify offenders with
pidstat -urd 1: Per-process CPU, memory, and I/O delta. More useful thantopfor spotting brief spikes. - Trace syscalls with
strace -p PID -c: Count syscall frequency and time. Reveals tight loops, excessive fsync, or blocking reads. Attach briefly in production; detach with Ctrl+C to see summary. - Profile with
perf toporperf record: Kernel + userspace function-level hotspots. Requireslinux-tools-genericand oftenkernel.perf_event_paranoid=1sysctl adjustment. - Check cgroup limits:
systemctl show -p MemoryMax,MemoryCurrent UNIT. Containerised workloads often hit cgroup OOM before host memory is exhausted.dmesg | grep -i oomconfirms kills.
# Real-world diagnostic session for high load average
vmstat 1 5 # Is load CPU or I/O bound?
pidstat -urd 1 5 # Which processes contribute?
iotop -aoP # Confirm I/O culprit (needs CAP_SYS_ADMIN)
strace -p 12345 -c -e trace=file,write # Syscall profile
cat /sys/fs/cgroup/system.slice/php8.3-fpm.service/memory.current
cat /sys/fs/cgroup/system.slice/php8.3-fpm.service/memory.maxOn a WooCommerce store handling flash sales, I once diagnosed checkout timeouts that appeared CPU-related (top showed 95% CPU) but were actually caused by Redis connection pool exhaustion forcing synchronous fallback to MySQL. ss -tnp | grep 6379 revealed thousands of TIME_WAIT sockets; tuning tcp_tw_reuse and increasing Redis maxclients resolved it. The lesson: never trust a single metric. Correlate across network, application, and OS layers.
OOM killer forensics
When processes disappear unexpectedly, check dmesg -T | grep -i "oom\|killed". The OOM killer selects victims by oom_score, influenced by oom_score_adj (-1000 to 1000). Database processes should have negative adjustments; batch jobs positive. Document these settings in your deployment playbook — they're invisible until something dies at 3 AM.
Conclusion: Preparing for Linux Interview Questions for DevOps That Actually Matter
The most valuable Linux interview questions for DevOps test your ability to navigate uncertainty, not recite man pages. Build hands-on experience by breaking things safely: spin up VMs, misconfigure systemd units intentionally, corrupt DNS caches, exhaust file descriptors, then practice systematic recovery. Read journalctl daily even when nothing is wrong to build pattern recognition. Maintain a personal runbook of incidents you've resolved with exact commands and timestamps.
If you're hiring and need help designing practical assessments, or if you're a founder evaluating whether your current infrastructure team has the depth your growth demands, reach out to discuss your DevOps and Linux operations needs. For developers building their careers in Nepal's growing tech sector, understanding these Linux fundamentals directly impacts your readiness for senior roles — explore more on high-demand tech positions and compensation or review CI/CD pipeline expertise expectations to align your preparation with market requirements. Real competence comes from production scars, not certificates. Go break something (safely) and fix it.
Frequently Asked Questions
Interviewers prioritize troubleshooting over memorization. Expect questions on strace, lsof, ss, journalctl, and awk. You must demonstrate diagnosing high load, network latency, or permission errors on Ubuntu 22/24 servers using these tools in real scenarios rather than reciting man page definitions.
Processes have isolated memory space while threads share memory within a process. In DevOps contexts, relate this to PHP-FPM workers versus Node.js event loops. Explain how thread contention causes CPU spikes differently than process spawning overhead, and mention debugging tools like htop or perf that visualize both resource types during production incidents.
Candidates frequently fail when explaining sticky bits, ACLs, or umask defaults beyond basic chmod. Interviewers ask about www-data ownership conflicts after deployments or why sudo is needed for specific log rotations. On my projects using Deployer 7, incorrect shared directory permissions cause silent failures that only surface during zero-downtime symlink swaps.
Focus on unit file structure, dependency ordering, and restart policies rather than legacy init scripts. Explain how to create custom services for Laravel queue workers or Node.js apps with proper environment loading. Mention journalctl filtering and systemctl status debugging, as interviewers want proof you can manage services reliably without GUI tools on headless Ubuntu servers.
Understand TCP handshake states, DNS resolution flow, and firewall rule precedence in nftables or UFW. Be ready to diagnose connection timeouts using ss -tunapl or tracepath. In Nepal infrastructure where NAT and ISP routing add complexity, practical experience troubleshooting eSewa webhook callbacks or API connectivity matters more than theoretical OSI model recitations.
Be honest about your actual exposure. If you use Docker Compose for staging but not K8s in production, say so. Explain cgroups and namespaces fundamentals that underpin all containers. Interviewers value candidates who understand Linux primitives over those who claim orchestration mastery they cannot demonstrate during hands-on troubleshooting exercises.
Expect scenarios involving LVM resizing, inode exhaustion, or RAID degradation. Know how to check disk health with smartctl and monitor I/O wait with iostat. On legal-tech portals handling document uploads, I have diagnosed full partitions caused by unrotated logs or orphaned temp files that application monitoring missed entirely until users reported upload failures.
Reference specific configurations: disabling root SSH, configuring fail2ban jails, setting appropriate file immutability with chattr, and auditing with auditd. Mention CIS benchmarks as a framework but emphasize practical trade-offs. For Nepal-based clients, balancing security with operational simplicity matters because small teams cannot maintain complex SELinux policies without dedicated staff.
Seniors discuss kernel parameters like vm.swappiness, net.core.somaxconn, and fs.inotify.max_user_watches in context of actual problems. Juniors list tools without explaining when to adjust them. Describe a real incident where default limits caused queue worker crashes or database connection exhaustion, and how you validated improvements with measurable metrics afterward.
Demonstrate Bash proficiency for automation and glue code, but acknowledge Python or Go for complex logic. Show understanding of error handling, idempotency, and logging in scripts. On production deployments, I write Bash for Deployer hooks but avoid embedding business logic there. Interviewers probe whether you know when shell scripting becomes unmaintainable technical debt.
Beyond grep and tail, expect questions on structured logging, log rotation strategies, and centralized aggregation. Explain how to correlate timestamps across multiple services during incident response. Mention practical constraints like disk space management on budget VPS hosting common in Nepal, where retaining thirty days of verbose logs requires deliberate retention policies rather than default configurations.
Describe runner isolation, artifact caching, and secret management on self-hosted agents. Explain how GitLab CI jobs interact with target servers via SSH keys and Deployer. Address common pitfalls like stale cron paths after symlink releases or PHP version mismatches between build and runtime environments. Real deployment troubleshooting experience outweighs theoretical pipeline architecture diagrams.
Articulate RPO/RTO definitions tied to actual backup mechanisms like mysqldump, pg_dump, or rsync snapshots. Discuss verification testing because untested backups are worthless. On client projects, I implement nightly automated dumps with offsite replication and quarterly restore drills. Interviewers want evidence you treat recovery as an engineered process, not an afterthought configured once during setup.
Explain apt pinning, repository priorities, and safe upgrade strategies for production servers. Discuss handling held packages during security patches and resolving library conflicts without breaking running services. Mention specific experiences upgrading PHP versions across Laravel applications where extension compatibility required careful staging validation before touching production systems serving real customer traffic.
Mid-level positions typically range Rs 80,000 to Rs 150,000 monthly (~USD 600-1,100). Senior roles with proven production experience reach Rs 200,000+ (~USD 1,500+). Remote international contracts pay significantly higher but require stronger communication skills and timezone flexibility. Rates vary based on company size, tech stack complexity, and whether the role includes on-call responsibilities or infrastructure ownership.
