CTLA common mistakes
CTLA · Understand the traps and how to avoid them.
When a service fails to start, the candidate edits the unit file or reinstalls the package before reading the journal, then declares the service 'fixed' after a restart that only masked the error.
Candidates trained on desktop Linux reach for the GUI or a reinstall reflex. On the exam, the deliberate fault is usually a bad ExecStart path, a missing User, or a dependency ordering issue, and journalctl -u -b shows it in one line. Skipping that step wastes the time budget and produces a guess instead of a diagnosis.
What to do instead
Adopt a fixed triage order: systemctl status , then journalctl -u -b --no-pager, then systemctl cat to see the effective unit and drop-ins, then systemd-analyze verify. Only after those four steps touch configuration. Practice this sequence until it is automatic.
The candidate writes a shell script that works interactively but fails under cron or systemd because it relies on the interactive PATH, the current working directory, or an unexported variable.
Interactive shells source profile files that set PATH and aliases; cron and systemd start with a minimal environment and a different working directory. Candidates test only in their own shell, so the script passes locally and fails in the scheduled context the exam describes.
What to do instead
Start every operational script with an explicit interpreter line, set PATH explicitly, cd to an absolute directory or use absolute paths throughout, and export every variable the script depends on. Test with env -i /bin/bash script.sh to simulate the cron environment before declaring it correct.
The candidate uses chmod 777 to resolve a permission denial, or changes ownership recursively across a whole tree, instead of identifying which specific access check is failing.
Permission errors present as a single denied operation, and 777 makes the symptom disappear, so it feels like a fix. Candidates also forget that directory execute permission, SELinux context, and ACLs can each deny access independently of the classic rwx bits.
What to do instead
Diagnose with namei -l /path/to/file to see permissions on every path component, then ls -Z for SELinux context and getfacl for ACLs. Grant the narrowest permission that satisfies the requirement, and state in your answer why that permission is sufficient.
The candidate configures an IP address and default gateway but never verifies name resolution, then reports the host as 'networked' when a ping by address works and everything by name fails.
Address-level connectivity and name resolution are separate layers, and candidates conflate 'the link is up' with 'the host can reach services'. The exam scenario typically has working L3 reachability and a broken resolver or search domain.
What to do instead
Verify in layers: ip addr and ip route for L2/L3, ping by address, then getent hosts and resolvectl query for resolution, then ss -tulpn to confirm the listener. Report which layer failed rather than a blanket 'network problem'.
The candidate treats a full filesystem as a capacity problem and adds space, when the actual cause is deleted-but-open files or inode exhaustion.
df reports the block usage, but a process holding a deleted file keeps blocks allocated and invisible to du, and a filesystem can be out of inodes while showing free space. Candidates who only run df and du miss both cases.
What to do instead
Always check df -h and df -i together. If df shows full but du does not account for it, run lsof +L1 or lsof | grep deleted to find the process holding unlinked files, and restart or truncate that process. State both checks in your answer.
The candidate answers a hardening question by listing tools (install a firewall, enable SELinux) without stating the enforcing mode, the default policy, or how the change is persisted across reboot.
Hardening questions test whether you understand the effective state, not whether you know a package name. A firewall rule added at runtime with firewall-cmd and never made permanent, or an SELinux mode changed with setenforce and never written to config, reverts on reboot and fails the requirement.
What to do instead
For every hardening change, state the runtime command, the persistence step, and the verification command. For firewalld that is firewall-cmd --add-service=... then --permanent then --reload then --list-all. For SELinux, edit /etc/selinux/config and confirm with getenforce and sestatus.
The candidate describes a backup as verified because the job exited zero, without ever testing a restore or checking that the archive is readable.
Backup tools report success when the write completed, not when the data is recoverable. Candidates equate exit status with integrity and skip the restore step, which is precisely the operational-procedure point the question is testing.
What to do instead
Include a restore test in every backup answer: list the archive contents, restore to a scratch directory, and compare checksums or file counts. For tar use tar -tf to list and tar -tvf to inspect; for databases run a test restore into a throwaway instance.
The candidate kills a runaway process with kill -9 as the first action, or kills the parent shell instead of the specific child, and then cannot explain why cleanup did not run.
SIGKILL cannot be caught, so the process never flushes buffers, removes lock files, or closes sockets cleanly. Candidates reach for -9 because it always works, then misdiagnose the stale lock or orphaned child as a separate fault.
What to do instead
Escalate signals in order: SIGTERM first, wait, confirm with ps, then SIGKILL only if the process is unresponsive. Identify the exact PID with pgrep -af or ps -eo pid,ppid,cmd before signalling, and check for child processes with pstree -p.
The candidate confuses a virtual machine's guest-level configuration with the host's, or assumes a cloud instance's firewall is the only one in play, ignoring the provider's security group or the host's hypervisor network.
Virtualization and cloud questions layer controls: guest OS firewall, hypervisor virtual switch, and provider security group all filter traffic. Candidates troubleshoot at one layer only and conclude the port is open when an outer layer is dropping it.
What to do instead
Enumerate the layers explicitly in your answer: guest firewall (firewalld/ufw/nftables), virtual network or bridge configuration on the host, and the cloud security group or network ACL. Test from outside the guest to distinguish a guest-local block from an upstream one.
The candidate jumps to a fix in a troubleshooting scenario without first establishing a baseline or reproducing the fault, and writes an answer that describes a remedy for a symptom that was never confirmed.
Exam troubleshooting items reward a documented method: gather symptoms, form a hypothesis, test it, then remediate. Candidates under time pressure pattern-match the scenario to a familiar fault and skip confirmation, which loses method marks even when the guess is right.
What to do instead
Structure every troubleshooting answer as: observed symptom, evidence collected (exact commands and their output), hypothesis, test that confirmed or eliminated it, remediation, and verification. Name the commands you would run at each step rather than describing them abstractly.