Linux Interview Prep: 60 Key Questions and Answers
These 60 Linux questions cover filesystem behavior, processes, storage, networking, security, shell scripting, and controlled troubleshooting. Use a disposable virtual machine or authorized lab for commands that change system state.
Questions are original study examples, not questions from a live hiring assessment. Adapt your examples to your own work and verify tool behavior using an authorized practice environment.
Linux is the kernel. A distribution combines it with system utilities, libraries, an installer or package manager, and defaults. Commands and service conventions may differ by distribution and version.
pwd displays the shell's current directory. Use it before file operations so that a relative path has an unambiguous meaning, especially in scripts or a recovery session.
ls -l displays long-format metadata, including mode and ownership; ls -a includes names beginning with a dot. These commands do not reveal every security or filesystem attribute.
find traverses directories and can filter by name, type, size, or time. Quote patterns and restrict the starting directory to avoid unexpectedly expensive searches.
grep searches matching lines. Use explicit directories and safe patterns, and avoid accidentally exposing secrets through logs or command history during an interview demonstration.
A symbolic link stores a path to another file or directory and can point across filesystems. A hard link is another directory entry for the same inode and generally must remain on its filesystem.
Inodes identify filesystem objects and hold metadata about files. A file's name lives in directory entries, so multiple hard links can refer to one inode.
The digits represent owner, group, and other permissions using read=4, write=2, execute=1. Mode 640 allows owner read/write, group read, and no permissions for others, subject to other access controls.
chmod changes permission mode bits, while chown changes file ownership. Both require appropriate privileges; changing permissions recursively without a plan can expose data or break services.
The umask removes default permission bits when new files and directories are created. It helps define safe defaults but does not replace access control lists or service-specific permissions.
Use top, ps, or a supported monitoring tool. Correlate the process with its service and workload before terminating it; a high CPU reading alone does not prove a malfunction.
A process has a distinct execution environment, while threads within it can share memory and resources. Scheduling and isolation details vary by implementation and runtime.
A PID identifies a running process within its PID namespace. PIDs can be reused, so for auditing or automation pair the identifier with process start time or a service-level identity.
The kill command sends a signal, typically SIGTERM by default. Applications may handle it to close cleanly; SIGKILL is a last resort because it bypasses application cleanup.
On systemd-based distributions, it reports a unit's active state and recent diagnostic context. Use journalctl and the unit definition when status alone does not explain a restart or failure.
On a systemd host, systemctl enable configures startup dependencies for a unit. Enabling and starting are distinct operations; confirm the unit's actual state after changes.
A process that has exited but whose parent has not collected its status can remain as a zombie. It no longer executes normal workload but still occupies a process-table entry.
Cron runs scheduled commands according to configured time expressions. Check which user's environment and time zone apply, because environment variables and file paths often differ from interactive shells.
Systemd timers integrate with systemd units, logging, and dependencies. Cron may be simpler for routine schedules. Choose based on distribution support, observability, and operational ownership.
Review unit status, journal entries for the relevant boot or time range, configuration changes, resource pressure, and dependency failures. Form a hypothesis before restarting repeatedly.
df -h shows filesystem capacity and use. Compare with df -i for inode exhaustion, since a filesystem can run out of inodes even when free blocks remain.
du sums disk usage for files and directories within a path. df reports allocation at the filesystem level. Differences can arise from deleted but still open files, permissions, snapshots, and filesystem overhead.
lsblk shows block devices and relationships. Confirm device names and mount points before making changes; writing to the wrong block device can irreversibly destroy data.
It is a directory through which a mounted filesystem becomes accessible. The mount table and filesystem configuration determine which storage is presented at that location.
It declares filesystem mounts and options that may be used at boot. An incorrect entry can block startup or expose data, so test changes and retain a recovery plan.
Logical Volume Manager provides a layer between physical storage and logical volumes, allowing controlled resizing and allocation. Filesystem resizing and backups are separate concerns.
Tools such as apt, dnf, or zypper resolve dependencies and install packages from configured repositories. Commands, repositories, and package names differ across distributions and supported releases.
Use the distribution's package metadata or query command to inspect version, origin, dependencies, and signature policy. Avoid downloading unverified packages from arbitrary websites.
A new kernel can alter driver compatibility or require a reboot. Plan maintenance, verify recovery kernels, and ensure important services are healthy after restarting.
Take a verified backup, inventory partitions and mounts, understand the boot arrangement, and test the procedure on nonproduction storage. Partitioning is not a safe improvisation exercise.
ip address lists interface addresses; ip link shows link state. Container and network namespace boundaries may affect what appears, so inspect the correct namespace.
ip route displays routes in the current namespace. Evaluate the most specific matching route and any policy-routing rules when diagnosing unexpected traffic paths.
Ping commonly tests ICMP reachability, which may be filtered. A service check verifies the target port, protocol, and expected application response; success or failure of one does not prove the other.
ss -lntup can show sockets and associated processes when permissions allow. Interpret bind addresses carefully: localhost-only listeners differ from sockets exposed on all interfaces.
resolvectl, dig, or host can inspect resolver behavior or answers depending on installed tools. Test against the system resolver and an authoritative source when split-horizon DNS is possible.
curl can show status and response headers and verify certificate negotiation by default. Avoid insecure certificate-bypass flags as a normal troubleshooting technique.
A socket means an application is bound to an address and port. Host or network firewalls decide which traffic can reach it; a listening service is not proof of external accessibility.
Compare observations across hops and endpoints, examine interface counters, and account for ICMP rate limiting. A trace alone does not prove data traffic is dropping at the same rate.
Clock synchronization may be disabled, blocked, or misconfigured. Check timedatectl or the installed time service and investigate drift, time zone, and authentication effects.
Record affected clients, protocol, time windows, routes, name resolution, interface errors, and application logs. Collect a controlled reproduction before changing multiple settings simultaneously.
A user identifies an account, while groups help assign shared file and system permissions. Effective access may also depend on ACLs, roles, service configuration, and security modules.
sudo runs an authorized command with another identity, commonly root, under configured policy. Prefer narrowly granted commands and audit logging over shared root credentials.
id displays the effective and real identities and group memberships relevant to the process. Compare it with the service account and file ownership when diagnosing access failures.
Access control lists can grant more granular permissions than basic owner/group/other mode bits. Use getfacl or setfacl where supported, and inspect inheritance on directories before changing them.
A private key can authenticate to remote systems; exposing it can compromise accounts. Protect key storage, use passphrases and approved hardware or agents, and revoke compromised keys promptly.
SELinux applies mandatory access control rules based on security contexts and policy. Disabling it to fix an error can hide a real policy mismatch; examine denials and correct the legitimate access path.
They constrain programs with mandatory access control rules, commonly by paths and capabilities. Review active profiles and denied operations rather than assuming a standard Unix permission change is sufficient.
A service should receive only the permissions, network access, and data it needs. This limits accidental damage and narrows the impact if the process is compromised.
Review the distribution's journal or authentication logs with proper permissions, correlate timestamps and accounts, and safeguard sensitive data. Avoid publishing raw logs that disclose tokens or personal identifiers.
Do not hardcode passwords or tokens in a repository or command history. Use approved secret stores, restrictive service permissions, and injection mechanisms that reduce exposure in process listings and logs.
Commands generally return zero for success and nonzero for failure, although tools define the exact codes. Scripts should check relevant failures and provide meaningful diagnostics.
Quoting prevents unintended word splitting and pathname expansion in many contexts. It is especially important for filenames containing spaces or wildcard characters.
It connects one command's output stream to another command's input. Check how exit statuses are handled and whether sensitive data could leak into logs when composing pipelines.
Validate input, quote variables, use explicit paths, handle errors, log meaningful outcomes, and test against disposable data. Strict-mode options can help but need thought about expected failures.
Shell variables belong to the shell context; exported environment variables can be inherited by child processes. They can be useful for configuration but are not secure storage for all secrets.
Establish an exact selection rule, produce a dry-run listing, review retention requirements, and log what will be removed. Never test destructive automation on the only copy of user data.
Identify which filesystem is full, review growth in logs and caches, look for deleted open files, and assess retention policies. Avoid deleting unfamiliar system files as a quick fix.
Perform a controlled restoration to an isolated environment and compare expected files and application behavior. A completed backup job or matching file size alone does not prove recoverability.
Start with impact and stabilization, establish a timeline, preserve evidence, communicate with incident owners, and make controlled changes with a rollback path. Document root causes only after evidence supports them.
Describe a reproducible lab: configure a nonproduction service, inspect its logs and permissions, diagnose a simulated failure, and explain your recovery steps. Show judgment about data loss and authorization, not just command recall.
Consult issuer and project-maintained documentation, not leaked or memorized answer sets: Linux manual-pages project.
Practice commands on a disposable machine, describe expected output and failure modes, and document the safest next action before altering files, service permissions, or storage.