RHEL Administrator Scenarios, Interview Questions and Capstone

Anil Jalela · Published Sep 3, 2026 · 7 min read

A professional assessment should reveal how an administrator thinks when evidence is incomplete and change has consequences. Memorizing a command is not enough. A strong answer states assumptions, identifies the responsible layer, protects access and data, selects a bounded action and defines proof. This capstone joins the course into one small service with deliberate failures and a recovery record.

Define the capstone service and failure budget

Build one RHEL 9 or 10 VM providing an internal HTTPS status page and a restricted shared-data path. Use named administration, a dedicated service identity, LVM-backed data, NetworkManager, firewalld, SELinux enforcing, systemd, journald/rsyslog and an SSH recovery path. Keep the service isolated from real customer data and public networks.

The assessment includes injected failures in configuration, permissions, capacity, DNS or dependency state. Every failure must be reversible and authorized. The evaluator scores diagnosis and evidence, not how quickly the learner restarts or disables controls.

Capstone control record

Operating sequence

1. Write the architecture, data classification, recovery objective and expected ports.
2. Build from verified media/repositories and capture the initial baseline.
3. Create named and service identities with narrow sudo and filesystem access.
4. Create LVM-backed XFS data and persistent UUID mount.
5. Configure network, DNS, firewall, SELinux and HTTPS service.
6. Add monitoring evidence, persistent/remote logs and a tested backup.
7. Inject three approved failures one at a time and diagnose from symptoms.
8. Restore service/data, run positive and negative tests and write the final review.

Commands and expected evidence

cat /etc/redhat-release
systemctl --failed
findmnt --verify
pvs; vgs; lvs
nmcli connection show --active
ip route
ss -lntup
firewall-cmd --get-active-zones
firewall-cmd --list-all
getenforce
ausearch -m AVC -ts recent
journalctl -p warning..alert -b --no-pager
dnf history info last
curl --fail --show-error --resolve status.lab.example:443:192.0.2.20 https://status.lab.example/

• Replace documentation names/addresses only inside the isolated lab.
• The command set is an evidence index, not a script to run without interpreting each result.
• The HTTPS test should validate the lab CA/host identity; do not use -k as acceptance.
• Preserve failure evidence before repair and reset one injection before introducing the next.

Evidence and acceptance criteria

Worked operating scenario

The evaluator changes the custom web root label and removes one route while leaving the service process active. The learner sees an active unit but a failed client request. They test name resolution, route selection, listener, firewall and AVC evidence, correct the route through NetworkManager and restore the documented SELinux label.

They do not disable SELinux, flush the firewall or reboot. Final tests prove the intended client succeeds, an unapproved source remains denied and the configuration survives reboot.

Practical how-to cases

systemctl status httpd --no-pager
journalctl -u httpd -b --no-pager
httpd -t
ss -lntp | grep ':80'
getenforce
sudo ausearch -m AVC -ts recent
curl -v http://127.0.0.1/

systemctl --failed
journalctl -b -p warning..alert --no-pager
findmnt --verify
lsblk -f
blkid
systemctl status local-fs.target

nmcli connection show --active
ip -brief address
ip route
sshd -t
ss -lntp | grep ':22'
firewall-cmd --get-active-zones
journalctl -u sshd -n 50

date -u --iso-8601=seconds
hostnamectl
dnf check-update || test $? -eq 100
findmnt --verify
systemctl --failed
ss -lntup
getenforce
firewall-cmd --get-active-zones
journalctl -p warning..alert -b --no-pager

Independent practice tasks

1. Complete a timed identity, package, storage and network configuration exercise.
2. Repair five injected faults while preserving a causal incident log.
3. Perform and document a file restore plus one service recovery.
4. Present a capstone handoff containing build, monitoring, backup, rollback and open-risk evidence.

For this lesson on RHEL Administrator Capstone, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: injecting failures on production or shared infrastructure is not a training exercise. Use disposable isolated systems.
• Unsafe: disabling firewall/SELinux or granting world write to pass the capstone fails the security and diagnosis gates.
• Unsafe: storing passwords, subscription credentials or private keys in the submitted evidence package creates a new incident.

Rewritten knowledge checks

Guided lab and acceptance test

1. Create the architecture and acceptance matrix before provisioning.
2. Build and harden the isolated service using lessons 1 through 19.
3. Have a reviewer select three bounded failure cards without revealing the responsible layer.
4. Record hypothesis, evidence and decision before every change.
5. Restore a backup to a separate target and compare checksums/application behavior.
6. Deliver a final operations pack with no secrets and remove all lab resources.

Primary references

• RHEL 10 security hardening
• RHEL 10 documentation
• RHEL 9 documentation