LTF12 common mistakes
LTF12 · Understand the traps and how to avoid them.
Beginning to type commands before reading the full task statement, including resource names, constraints, and the required end state.
Time pressure and pattern recognition encourage candidates to jump to a familiar command sequence after seeing only the first line of a task.
What to do instead
Read the task twice. Underline required names, paths, namespaces, and acceptance checks. Restate the end state in one sentence, then list the commands needed before touching the system.
Treating a zero exit code or a successful command as proof that the task is complete, without running an independent verification step.
Candidates associate command success with outcome success and skip checking service behaviour, connectivity, permissions, or persisted configuration.
What to do instead
Define the verification command before making changes. After the change, test the actual user-visible outcome, inspect logs or status, and confirm the configuration survives a reload or restart where relevant.
Spending too long on one difficult item while leaving easier items untouched until the final minutes.
Sunk-cost thinking and perfectionism make candidates keep debugging a single failure instead of protecting overall score.
What to do instead
Set a per-task time budget. If the budget expires, record the current state, mark the item for return, and move to the next task. Return only after all items have at least a partial solution.
Applying changes in the wrong context, namespace, user account, directory, or target host because the current environment was never confirmed.
Default contexts and inherited shell settings are easy to assume, especially when tasks switch between multiple environments.
What to do instead
Make the first command of every task a context check. Explicitly set the target context, namespace, user, or host, and verify that the resource being edited is the one named in the task.
Editing a live configuration file without a backup, syntax check, or rollback command, then breaking a component that had been working.
Urgency leads candidates to modify production-like files directly and assume they can remember the original contents.
What to do instead
Copy the file with a timestamped suffix before editing. Validate syntax with the tool's check mode, reload rather than restart when possible, and keep the exact rollback command ready.
Guessing at the cause of a failure instead of reading the first relevant error from logs, status output, or events.
Unfamiliar error messages feel slower to read than trying another command, so candidates iterate blindly.
What to do instead
Triage in order: service status, recent journal entries, application logs, and platform events. Read the earliest causal error, fix that, and re-check before changing anything else.
Configuring a change only at runtime and never writing it to persistent configuration or enabling it for future starts.
The immediate test passes, so candidates do not consider reboot, reload, or reconnection behaviour.
What to do instead
Identify the persistent configuration source, make the change there, enable the relevant unit or service, and verify by restarting or reloading the component before finishing.
Overcomplicating a task with custom scripts, extra packages, or unnecessary architecture when a native tool or minimal change would satisfy the requirement.
Candidates try to demonstrate depth or distrust simple built-in mechanisms, adding failure points and consuming time.
What to do instead
Choose the simplest native mechanism that meets the stated requirement. Add complexity only when the task explicitly demands it, and remove unnecessary dependencies before verification.
Avoiding built-in documentation, help output, and manual pages because of a belief that consulting them looks inexperienced or wastes time.
Memorization anxiety and exam pressure make candidates rely on recall even when authoritative syntax is available locally.
What to do instead
Practice using command help, manual pages, and offline documentation during preparation. In the exam, consult them immediately for exact flags or syntax rather than guessing repeatedly.
Finishing with temporary files, test artifacts, or altered defaults left in place, so the environment no longer matches the required clean end state.
Attention is focused on the last task, and cleanup is not treated as part of the deliverable.
What to do instead
Reserve final minutes to remove temporary files, stop test services, restore unrelated defaults, and re-run the acceptance check for each completed task.