LFA study materials
LFA study resources

LFA common mistakes

LFA · Understand the traps and how to avoid them.

Mistake 1

Computes octal permissions as a flat r=4/w=2/x=1 sum without distinguishing file execute from directory traverse, then sets a directory to 644 and cannot cd into it or create files inside.

Candidates memorize permission triads from tables but never connect the directory execute bit to path traversal; many practice labs only use files.

What to do instead

Create a scratch directory and test chmod 644 vs 755, then use stat -c '%A %a' and namei -l to see each path component's mode. Practice symbolic mode (u+rwX,g+rX) and always ask whether the object is a file or directory.

Mistake 2

Claims that deleting the original file destroys the data for a hard link, or that a hard link can span filesystems.

Hard links are confused with symbolic links and copies; the inode/link-count model is learned as a definition rather than observed.

What to do instead

In a lab, create a file, ln it, and compare inode numbers with ls -li; delete the original and show the data is still reachable. Try ln across /tmp and /var to see the EXDEV failure, then contrast with ln -s.

Mistake 3

On a systemd host, edits a unit file or uses service/init.d commands, then expects the change to take effect without systemctl daemon-reload or systemctl enable --now.

Older study material and SysV habits carry over; candidates do not verify which init system is actually PID 1.

What to do instead

Check ps -p 1 -o comm= and systemctl --version first. After unit edits run systemctl daemon-reload; use systemctl enable --now to both persist and start; inspect failures with systemctl status and journalctl -u.

Mistake 4

Diagnoses 'No space left on device' only with df -h; when block usage looks fine, concludes storage is healthy and misses inode exhaustion or deleted-but-open files.

df defaults to block counts, and candidates rarely think about inode limits or file descriptors held by running processes.

What to do instead

Run df -h and df -i together, then du -xsh to find large trees and lsof +L1 to find deleted files still held open. Practice creating many zero-byte files on a small filesystem to trigger inode exhaustion.

Mistake 5

Assigns OS patching to the provider for an IaaS virtual machine, or says the customer must patch the database engine in a managed PaaS database service.

Service-model labels are memorized as definitions rather than as a split of operational responsibility; marketing terms blur the boundary.

What to do instead

Build a responsibility matrix for IaaS/PaaS/SaaS covering OS, runtime, database engine, application code, identity, and data. For each exam scenario, identify the highest managed layer and assign everything below it to the provider.

Mistake 6

Designs an application to write session state to the instance's local disk and expects it to survive instance replacement or be shared across autoscaled instances.

The on-premises mental model treats a server's disk as permanent and singular; cloud ephemeral storage behavior is not practiced.

What to do instead

Distinguish ephemeral instance storage, persistent block volumes, shared file systems, object storage, and managed databases. Rebuild an instance in a sandbox to observe data loss, then move state to a managed database or object store.

Mistake 7

States that TLS uses asymmetric encryption for the bulk application data and symmetric encryption only for key exchange, or describes hashing as reversible encryption.

Simplified explanations compress the handshake and record layers into one step; encryption, encoding, and hashing are treated as synonyms.

What to do instead

Trace a TLS session: asymmetric cryptography authenticates and agrees on a shared secret; symmetric ciphers protect record data. Compare hashing (one-way, fixed length), encoding (reversible, not secret), and encryption (reversible with a key) using openssl dgst, base64, and openssl enc.

Mistake 8

Sets umask 022 and expects newly created files to be 755, or applies the umask to directories as 666 minus the mask.

Candidates remember 'subtract the umask' but forget the base modes differ: 666 for files and 777 for directories, and the mask clears bits rather than subtracting numerically.

What to do instead

Calculate both cases explicitly: files 666 & ~022 = 644, directories 777 & ~022 = 755. Test with umask 022; touch f; mkdir d; stat -c '%a %n' f d. Repeat with umask 027 and verify the group write bit is cleared.

Mistake 9

Treats a container as a lightweight VM: expects systemd inside, writes persistent data to the container filesystem, and assumes data survives docker rm or a new container from the same image.

Docker tutorials hide the lifecycle; candidates extrapolate VM behavior to containers and do not separate image layers from writable container layers.

What to do instead

Run a container, write a file, remove the container, and show the file is gone; repeat with a named volume or bind mount. Inspect an image with docker history and docker inspect to see layers, and run a single foreground process instead of an init system.

Mistake 10

Debugs a failing application by reading only the application's own log file, ignoring journalctl -u, dmesg, exit codes, and where the service unit sends stderr.

Candidates assume the app's log path is the only source of truth and have not traced how systemd captures stdout/stderr for a unit.

What to do instead

For a failing unit, run systemctl status, journalctl -u -b --no-pager, and systemctl show -p ExecMainStatus. Check StandardOutput/StandardError in the unit, reproduce the command manually to capture the exit code, and use dmesg for kernel-level errors such as OOM kills.