LFCA common mistakes
LFCA · Understand the traps and how to avoid them.
Treating every absolute path as if it starts at the root of the current filesystem, so candidates answer that /home/alice/report.txt is always on the root partition and miss that a separate /home mount changes which filesystem the file lives on.
Candidates memorise 'a path starting with / is absolute' and stop there, never connecting the mount table to path resolution. The exam phrases questions around df, mount, and where data physically resides, and the mental shortcut produces a confident wrong answer.
What to do instead
Before answering any path question, ask which mount point the path falls under. Practise reading output of findmnt, mount, and df -h alongside lsblk, and trace a path component by component: /home/alice/report.txt resolves to the /home mount if one exists, otherwise to /. Draw the tree with mount points marked and state the backing device for each branch.
Confusing file permissions with directory permissions: candidates say a user with read permission on a file can read it even when the containing directory lacks execute (search) permission, or claim write on a directory lets you edit a file's contents.
rwx on files and rwx on directories are tested separately but look identical in ls -l output. Candidates learn the file semantics first and apply them uniformly, forgetting that directory x controls traversal and directory w controls creating, renaming, and deleting entries, not editing file content.
What to do instead
Build a two-column table: for files, r=read content, w=modify content, x=execute; for directories, r=list names, w=create/delete/rename entries, x=traverse and stat entries. Then walk concrete scenarios: can bob read /data/report if /data is mode 700 owned by alice? No, because traversal fails before the file mode is consulted. Answer permission questions by evaluating each path component's x bit first.
Assuming a process started with sudo runs entirely as root, so candidates say a script launched via sudo can write to a root-owned file even if the script itself drops privileges, or they expect environment variables like HOME and PATH to remain the invoking user's.
sudo is taught as 'run as root' without covering the environment reset, the difference between sudo and sudo -i, or setuid semantics. Exam items probe effective versus real UID and why PATH-dependent commands behave differently under sudo.
What to do instead
Learn the mechanics: sudo sets real and effective UID to the target user for the command, resets most environment variables (HOME, PATH, USER) unless -E or env_keep applies, and sudo -i starts a login shell. Practise id versus sudo id, sudo -l to inspect allowed commands, and inspecting /proc//status for Uid and Gid lines. When a question mentions a command failing only under sudo, suspect PATH or HOME first.
Memorising systemd unit file locations and commands as a single blob, so candidates answer that enabling a service starts it immediately, or that a unit placed in /etc/systemd/system is active without daemon-reload.
systemctl start, enable, and daemon-reload are learned together in tutorials and blur into one action. Candidates also miss that unit search paths have precedence, with /etc overriding /usr/lib, and that a changed unit file is not re-read until reloaded.
What to do instead
Separate the verbs: start/stop act on the running state now; enable/disable control whether it starts at boot by creating symlinks; daemon-reload re-reads unit files from disk. Practise writing a minimal unit with [Unit], [Service], ExecStart, and [Install] WantedBy=multi-user.target, placing it in /etc/systemd/system, running daemon-reload, then enable --now. Check status and journalctl -u to confirm behaviour rather than assuming.
Treating package managers as interchangeable, so candidates answer that apt install and dnf install both resolve dependencies from the same repository metadata, or that removing a package with rm from /usr/bin is a supported uninstall.
The commands look similar and candidates generalise from one distribution. Exam items test the package database concept, why manual file deletion leaves the database inconsistent, and how repository configuration differs between Debian-style and RPM-style systems.
What to do instead
Anchor on the database: dpkg and rpm track installed files and metadata; apt and dnf sit above them and fetch from configured repositories. Learn one query per family (dpkg -S /path, rpm -qf /path, apt list --installed, dnf list installed) and one integrity check (dpkg -V, rpm -V). For removal, use the package manager so dependencies and the database stay consistent; never delete managed files by hand.
Answering cloud questions with on-premises instincts: candidates say a stopped virtual machine still incurs compute charges, or that object storage is mounted as a block device and behaves like a local filesystem with in-place edits.
Candidates study cloud vocabulary as definitions without mapping it onto the resource lifecycle they know from local systems. The exam tests the consequences of managed services: billing stops for stopped instances in most models, object storage is accessed over HTTP with whole-object replacement, and durability differs from a single disk.
What to do instead
For each service, write three lines: what it is, how you access it (API, HTTP, block device, network filesystem), and what you are billed for. Compare block storage (attached disk, filesystem, in-place edits), file storage (shared network mount), and object storage (key-value, immutable objects, versioning). Practise the CLI: create and stop an instance, observe billing state, upload and retrieve an object, and note that updating an object means writing a new version.
Confusing authentication with authorisation and applying the wrong control: candidates answer that a firewall rule enforces who a user is, or that a strong password policy prevents a user from reading another user's files.
Both concepts are introduced together as 'security', and candidates memorise examples rather than the boundary. Exam items present a scenario and ask which control class applies, so a fuzzy boundary yields plausible but wrong answers.
What to do instead
Define the boundary explicitly: authentication proves identity (passwords, keys, MFA, certificates); authorisation decides what an identity may do (file modes, ACLs, sudoers, IAM policies, roles). Classify every control you meet into one bucket, then ask what it protects against. For a scenario, name the identity, the resource, and the decision being made; if the question is about proving identity, authorisation answers are wrong even when they sound security-related.
Assuming TLS alone secures an internal service, so candidates answer that enabling HTTPS removes the need for authentication or that a self-signed certificate provides the same identity assurance as one from a trusted CA.
TLS is taught as 'the lock icon' and its two jobs, encryption in transit and server identity, get merged with access control. Candidates also overlook that a self-signed certificate encrypts traffic but cannot be validated by a client that does not already trust it.
What to do instead
State the two properties separately: TLS gives confidentiality and integrity in transit, and certificate validation gives server identity only when the client trusts the issuer. Authentication of the client is a separate mechanism (client certificates, tokens, passwords). Practise generating a self-signed certificate, observing the browser or curl warning, then adding the CA to the trust store and seeing the warning disappear. In questions, ask whether the client can verify the peer before claiming identity is assured.
Treating CI and CD as one pipeline stage, so candidates answer that a successful build means the change is deployed, or that continuous delivery and continuous deployment are the same thing.
The acronym CD is overloaded and tutorials show a single YAML file doing everything. Candidates memorise the pipeline shape without the gate: continuous delivery stops at a manual approval before production, continuous deployment goes straight through.
What to do instead
Write the pipeline as discrete stages with a named artefact at each boundary: commit triggers build, tests run, an immutable artefact is produced, it is deployed to a staging environment, and promotion to production is either automatic (continuous deployment) or gated by approval (continuous delivery). For any scenario, identify which stage failed and what artefact exists. Practise reading a pipeline log and pointing to the exact step where the run stopped.
Reading container images as if they were virtual machines: candidates answer that a container runs its own kernel, that changes inside a running container persist in the image, or that a Dockerfile RUN instruction executes on the host at build time.
Containers are introduced with VM analogies, and the layer model is invisible in normal use. Exam items probe namespaces, the shared host kernel, image immutability, and build-time versus run-time context, all of which the VM analogy gets wrong.
What to do instead
Fix the model: a container is one or more processes isolated by kernel namespaces and limited by cgroups, sharing the host kernel. An image is a stack of read-only layers; a running container adds a writable layer that is discarded on removal, so changes do not flow back into the image. Dockerfile instructions execute at build time in the build context; CMD and ENTRYPOINT define what runs at start. Practise building an image, running it, writing a file inside, removing the container, and confirming the file is gone.
Debugging applications by guessing at the code instead of reading logs and status: candidates answer that a service returning 502 has a bug in its business logic, or that a process with a non-zero exit code definitely failed to start.
Candidates from a development background reach for source-level explanations, and candidates from operations reach for restarts. The exam tests layered diagnosis: exit codes, service status, log location, port binding, and the difference between a process running and a service healthy.
What to do instead
Adopt a fixed order: check exit code and systemctl status, read journalctl -u with -e for the tail, confirm the listening socket with ss -ltnp, then test the endpoint with curl -v. Map symptoms to layers: connection refused means nothing is listening; 502 means a proxy reached but the upstream failed; a non-zero exit code tells you how it ended, not why start failed. Practise reproducing each symptom deliberately and identifying the layer before proposing a fix.