Linux System Administration Fundamentals Questions

Core Linux administration knowledge and hands on operational skills required to install, configure, and maintain Linux systems. Covers user and group management, file permissions and ownership, process management and signals, package management across distributions, the boot process and runlevels or targets, basic systemd service control, filesystem navigation and basic disk management, common system configuration files, shell and command line proficiency, and differences between major enterprise and community distributions. Candidates should demonstrate practical troubleshooting of routine issues, patching and updates, and an ability to perform day to day administration tasks reliably.

HardTechnical

54 practiced

Your organization plans to modernize legacy stateful Linux services currently running on VMs. As a Systems Administrator, compare using containers (Docker/Podman + Kubernetes) versus VMs for these services. Cover operational trade-offs: security isolation, resource utilization, persistent storage patterns, networking, migration steps, backup and restore strategies, and an actionable migration plan for stateful workloads.

HardTechnical

26 practiced

An Ansible playbook accidentally pushed an SSH configuration change to a group of hosts that prevents new logins, leaving only the existing session. As the Systems Administrator, describe recovery steps to regain access to the hosts, how to test and rollout Ansible changes safely in the future (e.g., canary hosts, --check, serial), and propose safeguards such as automated rollback jobs and configuration drift detection.

Sample Answer

**Situation & immediate goal**I would regain access quickly and safely, preserving existing sessions, then remediate the SSH config and harden deployment practice.

**Recovery steps (priority)**- Use existing open sessions to add a safe backdoor: create a new authorized_key or enable a temporary user with sudo and known key.

bash

# on an active session
  mkdir -p ~/.ssh && echo "ssh-rsa AAA... mykey" >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys

- If no active session on some hosts, use out-of-band access (IPMI/console, cloud serial console, provider rescue mode) to revert /etc/ssh/sshd_config and restart sshd:

bash

systemctl restart sshd

- Revert the pushed change in version control (Git) and mark the bad playbook commit.

**Testing & safer rollout**- Use pull-request CI that lints and validates YAML, tests templates with molecule and serverspec.- Deploy to a canary group (1–2 hosts) first. Use ansible-playbook --check for dry-run, then:

bash

ansible-playbook site.yml --limit canary --diff
  ansible-playbook site.yml --limit canary --serial 1

- Use --serial and pause/approval between batches. Monitor logs, SSH connectivity, and health checks before proceeding.

**Automated safeguards**- Automated rollback job: after successful change, snapshot config or create checkpoint; if health checks fail within window, run rollback playbook automatically.- Configuration drift detection: run regular ansible-runner audits or use tools (OSConfig, osquery, Chef InSpec) to alert on unexpected sshd_config diffs.- GitOps: enforce changes only from reviewed commits; CI gates deployments.- Access safety net: ensure at least one management user/key and emergency console access are tested and documented.

**Post-incident**- Root cause analysis, update playbook to validate SSH rules (ensure PermitRootLogin/AllowUsers/Match blocks safe), add automated dry-run and canary steps to pipeline, and run a tabletop to improve runbooks.

MediumTechnical

29 practiced

Design a robust scheduled backup that runs /usr/local/bin/backup.sh daily at 03:00 as root. Requirements: ensure only one instance runs at a time, capture stdout/stderr to rotating logs, and provide a systemd-timer alternative to cron. Provide a safe cron entry using flock and a sample systemd service and timer unit pair that implements the same behavior.

HardSystem Design

29 practiced

Design a highly available NFS solution to serve home directories for ~500 users with low latency and automatic failover between two datacenters. Consider consistent file locking, metadata consistency, split-brain prevention, client mount strategies (autofs/systemd), and backup. Outline architecture options (e.g., Ganesha+Ceph, DRBD+Pacemaker+NFS, clustered filesystem), pros/cons, and steps to implement and test failover.

Sample Answer

**Clarify requirements**- 500 users, low latency, active service in one DC with automatic failover to second DC, POSIX locks, consistent metadata, avoid split-brain, seamless mounts, regular backup.

**Architecture options (summary + pros/cons)**1. Ganesha NFS + Ceph (RADOS/GANESHA) - Pros: True shared backend, multi-site with Ceph RBD/CRUSH, strong concurrency, no kernel NFS limits, scalable. - Cons: Operational complexity, Ceph tuning for latency, cross-DC replication requires RADOS Gateway or multi-site planning.2. DRBD + Pacemaker + NFS (active/passive) - Pros: Simpler, familiar Linux stack, synchronous DRBD can ensure identical blocks, predictable failover via Pacemaker. - Cons: Single active node (higher latency if DC far), split-brain risk if network partitions, limited scale.3. Clustered filesystem (OCFS2/GlusterFS/DRBD+GFS2) - Pros: Shared-disk semantics (GFS2) or scale-out (Gluster), multiple active servers possible. - Cons: GFS2 needs shared SAN; Gluster needs careful tuning for metadata-heavy workloads.

**Recommended choice**- For 500 users with strong POSIX semantics: Ganesha + Ceph (if team can operate Ceph). If not, DRBD+Pacemaker+NFS active/passive is pragmatic.

**Key design details**- Consistent file locking: Use NFSv4 delegations + Ganesha supports locks via FSAL; with DRBD+NFS ensure ldiskfs and kernel locking on active node.- Metadata consistency: Centralized metadata backend (CephFS) or clustered FS avoids stale metadata.- Split-brain prevention: For DRBD+Pacemaker use fencing (STONITH over IPMI), quorum on cluster, strict timeouts; Ceph uses monitors and quorum.- Client mount strategy: Use autofs or systemd.automount with NFSv4, mount options: vers=4.2, proto=tcp, timeo/soft settings, noac for critical dirs if needed. autofs reduces mount storms and handles failover faster.- Backup: Periodic snapshots (Ceph snapshots; LVM snapshots if DRBD), external backup to object store (S3), user-level backups (rsnapshot), test restores regularly.

**Implementation steps**1. Provision storage cluster (Ceph mons/osds) or two DRBD nodes with fencing mechanism.2. Deploy NFS servers: Ganesha fronting CephFS or kernel NFS on active DRBD node.3. Configure cluster manager (Pacemaker/Corosync) for DRBD or Ceph monitors for Ceph.4. Implement fencing, STONITH, quorum policies.5. Configure exports, NFSv4 domain, idmap, Kerberos if required.6. Client rollout: configure autofs/systemd unit, ensure mount options and failover scripts.

**Testing & verification**- Simulate failover: graceful stop of active NFS, verify mounts remount and users keep sessions.- Simulate abrupt failure: kill node, validate Pacemaker promotes DRBD secondary and exports come online.- Network partition: validate fencing prevents split-brain and check data converges after heal.- Locking tests: run concurrent file edits and lock/unlock scenarios, verify no data corruption.- Performance & latency tests: measure with fio and many small-file ops.- Backup restore test: restore sample home directories and validate permissions/locks.

**Operational best-practices**- Monitor OSDs, DRBD sync, Pacemaker health, NFS export stats.- Automate failover runbooks, regular DR drills.- Limit active/passive failovers during business hours; schedule maintenance windows for major changes.

HardSystem Design

34 practiced

Design and implement a private package repository for Debian (apt) and RHEL (yum) to distribute internal packages. Requirements: GPG-signed packages, authenticated access for internal users, CI pipeline integration to publish builds, and optional caching at edge sites. Outline tools (e.g., aptly, reprepro, createrepo), signing process, nginx hosting with TLS and auth, and CI steps to publish and verify packages.

Sample Answer

**Clarify requirements**- Private apt (Debian/Ubuntu) + yum/dnf (RHEL/CentOS) repos- GPG-signed packages and metadata, authenticated access (internal users), CI integration, optional edge caching

**High-level architecture**- Central build/publish cluster (CI runners + repo manager)- Storage: object store (S3-compatible) or on-prem NFS- Front-end: nginx with TLS + client auth (mTLS or HTTP basic + LDAP/SSO)- Edge caching: redistributable HTTP cache nodes or mirror proxies (apt-cacher-ng, squid), rsync-based mirrors for yum

**Tools**- Debian: aptly or reprepro (I recommend aptly for snapshot/publish)- RHEL: createrepo_c + yum-signature tools (rpm --addsign)- Signing: GPG (dedicated subkey on HSM or secure keyserver), rpm GPG key for RPMs- CI: GitLab CI / Jenkins / GitHub Actions with runners having signing keys in HSM or sealed vault (HashiCorp Vault)

**Signing & verification process**- Build job creates .deb/.rpm artifacts- Use non-exportable GPG key (HSM or Vault-transient agent) to: - Debian: aptly repo add + aptly publish; sign Release with GPG - RPM: rpm --addsign package.rpm; regenerate repodata with createrepo_c --update- Publish signed metadata to storage

Example publish step (Debian):

bash

# add package and sign repository
aptly repo add myrepo ./artifacts/*.deb
aptly publish update -gpg-key="repo@example.com" myrepo

RPM sign example:

bash

rpm --addsign package.rpm
createrepo_c -v /srv/repos/rhel
gpg --detach-sign --armor repodata/repomd.xml

**nginx hosting & auth**- Serve repo from nginx with TLS (Let's Encrypt/internal CA). Enforce: - mTLS for strong auth OR - HTTP basic backed by LDAP/SSO + IP allow list- Protect metadata endpoints; enable gzip, caching headers, and range requests for apt.

nginx snippet:

nginx

ssl_certificate /etc/ssl/certs/repo.crt;
ssl_certificate_key /etc/ssl/private/repo.key;
auth_basic "Protected";
auth_basic_user_file /etc/nginx/.htpasswd;
location /repo/ { proxy_pass http://storage_backend/; }

**CI pipeline**- Stages: build -> test -> sign -> publish -> smoke-test- Signing stage fetches key via Vault agent or uses HSM plugin- Publish pushes to object store and triggers repository update (aptly publish or createrepo_c)- Smoke test: client VM pulls package, verifies GPG signature and installs package

CI pseudosteps:- Build artifacts- Run unit/integration tests in container- Request short-lived signing token from Vault- Sign artifacts and update repo metadata- Invalidate CDN/edge caches or trigger mirror sync- Run automated apt-get/yum install on test instances

**Edge caching & mirrors**- apt: use apt-cacher-ng at edge sites to cache debs and metadata- yum: use nginx+proxy_cache or local mirror via rsync from central object store- Scheduled rsync or object-store lifecycle + cache-control headers

**Security & ops**- Store signing keys in HSM/Vault; log all signing requests; rotate keys periodically- Monitor repo integrity (automated gpg verification of Release/repomd)- Backup storage and test restore; implement access audit via LDAP/SSO logs

**Trade-offs**- Aptly gives snapshots and atomic publishes; reprepro lighter-weight- HSM adds cost but improves key safety; Vault with transit is cheaper but needs strong ops

This design provides secure, CI-driven publication of signed packages with authenticated access and scalable edge caching.

Unlock Full Question Bank

Get access to hundreds of Linux System Administration Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.