CS AO common mistakes
CS AO · Understand the traps and how to avoid them.
Treating the exam as a Linux-only test and skipping Windows and macOS administration concepts, so questions on service management (systemd units vs. Windows services vs. launchd), event logs, and registry or plist configuration become guesswork.
Most candidates come from a single-OS background and study only what they use daily, but the exam is deliberately cross-platform and tests whether you understand the underlying administration model rather than one tool's syntax.
What to do instead
Build a comparison table for each core task (start/stop a service, schedule a job, read logs, set environment variables, manage startup items) across Linux, Windows, and macOS. Practice the equivalent command for each and note where the model differs (declarative unit files vs. service control manager vs. launchd plists).
Answering installation questions with the 'default next-next-next' path, ignoring partitioning scheme choice, filesystem selection, boot mode (UEFI vs. legacy BIOS), and whether the scenario calls for a minimal or full install.
Candidates memorize that installation works but not why a given layout is chosen, so they miss scenario questions that hinge on matching the install configuration to the stated purpose, hardware, or compliance requirement.
What to do instead
For each install scenario, write down the decision points before the steps: disk layout and redundancy, filesystem, boot mode, network configuration at install time, and post-install baseline. Practice unattended/automated installs so you can explain what each answer file setting actually controls.
Confusing authentication with authorization and answering access questions with the wrong control, for example granting a user a role when the real fix is a file-system permission, ACL, or sudo policy change.
The concepts are taught together and the vocabulary overlaps, so candidates pick the first plausible control instead of tracing where the actual decision is enforced (directory service, local account database, file ACL, or privilege escalation policy).
What to do instead
For every access scenario, identify the enforcement point first, then the mechanism. Practice reading effective permissions (group nesting, deny precedence, inherited ACLs, sudoers ordering) and predicting the resulting access before checking it with tooling.
Treating storage as a single layer, so answers mix up partitioning, logical volume management, RAID, and filesystem-level features, or forget that mount configuration must persist across reboots.
Modern storage stacks several abstraction layers and the exam tests whether you know which layer a symptom belongs to; candidates also routinely test a mount manually and never verify it survives a reboot.
What to do instead
Draw the stack from physical disk to mount point and label which tool manages each layer. Practice resizing, extending, and repairing across layers, and always validate persistent mount configuration by checking the fstab/automount equivalent and rebooting a test system.
Diagnosing connectivity by pinging only, then declaring the network healthy or broken without checking name resolution, routing, listening sockets, and firewall rules in a deliberate order.
Ping is the first tool learned and gives a fast binary answer, but it tests only one layer and is often blocked; candidates then misattribute a DNS, routing, or firewall problem to the link itself.
What to do instead
Adopt a fixed layered checklist: interface and link state, IP configuration, local route table, gateway reachability, name resolution, remote port reachability, then application response. Practice running the checklist on deliberately broken lab hosts so each failure produces a recognizable signature.
Hardening by checklist without understanding the trade-off, giving answers that disable a service or tighten a setting while breaking the workload the scenario says must keep running.
Candidates memorize 'disable this, restrict that' from hardening guides and forget that the exam scenarios include a stated business function that must remain available.
What to do instead
For each hardening control, state what it protects against, what it breaks, and how to verify the workload still functions. Practice applying a baseline (least privilege, patching, service minimization, logging, encryption in transit and at rest) to a running service and documenting the exceptions.
Confusing monitoring with alerting and backup with archive, so answers propose dashboards where thresholds and escalation are needed, or retention copies where point-in-time restore is needed.
The terms are used loosely in day-to-day work; the exam tests the operational purpose of each capability and whether you can match the tool to the recovery objective.
What to do instead
Map each capability to its purpose: metrics for trend and capacity, logs for investigation, alerts for action with defined thresholds and owners, backups for restore within an RPO/RTO, archives for retention. Practice stating the recovery objective before choosing the mechanism.
Jumping to a fix before establishing a symptom timeline, so the answer changes several things at once and never isolates the cause or verifies the result.
Production pressure rewards fast action, and candidates carry that habit into scenario questions that explicitly reward methodical isolation and confirmation.
What to do instead
Use a repeatable loop: gather the exact symptom and scope, check recent changes, form one hypothesis, test it with the least invasive action, verify, then document. Practice on injected faults where only one change at a time is permitted until the cause is proven.
Ignoring the scenario's stated constraints (budget, uptime window, legacy dependency, regulatory requirement) and answering with the technically ideal but contextually wrong option.
Candidates focus on the technical facts and skim the framing sentences, but many items are designed so that two answers are technically valid and only one fits the constraints.
What to do instead
Before evaluating options, extract the constraints into a short list and eliminate any answer that violates one. Practice re-reading the stem after choosing to confirm the selection satisfies every stated condition.
Skipping hands-on verification of command syntax and output, so answers describe the right intent with the wrong flags, wrong paths, or a misread exit status.
Reading documentation feels sufficient, but recall of exact options and output interpretation decays without practice, and the exam includes items where a single flag changes the outcome.
What to do instead
Build a lab covering the exam's core tasks and run each command until you can predict the output and exit code. Keep a personal cheat sheet of flags you got wrong, and re-test those specific commands weekly rather than re-reading general material.