LCA ICT Specialism common mistakes
LCA ICT Specialism · Understand the traps and how to avoid them.
Confusing absolute and relative paths when answering command-line questions, e.g. running `chmod 755 scripts/deploy.sh` from the home directory when the file is at `/opt/app/scripts/deploy.sh`, or assuming `cd /etc` persists across separate command invocations in a scenario.
Candidates memorise command syntax but not the shell's working-directory model. On a written exam, each command is often shown in isolation, and the candidate silently assumes the previous cd still applies or that the current directory is root.
What to do instead
Before answering any command question, explicitly write down the working directory and resolve every path to absolute form. Practise a drill where you convert 20 relative paths to absolute paths given a stated pwd, and check whether a command would fail with 'No such file or directory' if run from /.
Using `kill <PID>` (SIGTERM) to stop a process that is ignoring termination, or conversely using `kill -9` as the first resort, and being unable to explain why the process persists or becomes a zombie.
Candidates learn kill as a single verb and never internalise signal semantics. They also miss that SIGKILL cannot be caught, so a zombie or uninterruptible (D-state) process will not disappear regardless of signal.
What to do instead
Memorise the signal table: SIGTERM (15) is catchable and the correct first attempt; SIGKILL (9) is uncatchable and last-resort; SIGSTOP/SIGCONT control suspension. Learn that zombies are reaped by the parent, not killed, and that D-state processes wait on I/O. Practise ps -eo pid,ppid,stat,cmd and reading the STAT column.
Diagnosing a 'host unreachable' or 'service down' report by jumping straight to restarting the service, without first checking IP configuration, default gateway, DNS resolution, and listening sockets in a defined order.
Candidates treat troubleshooting as a memory test for fixes rather than a layered method. They skip the cheap checks (is the interface up, is the port listening) and restart services that were never the problem.
What to do instead
Adopt a fixed checklist and state it in answers: ip addr (link/address), ip route (gateway), ping gateway then external IP, getent hosts/dig (DNS), ss -tlnp (listening socket), then firewall. Learn which layer each command proves, and practise writing the order out before answering scenario questions.
Treating numeric permission modes as opaque octal strings, e.g. answering that `chmod 644` on a directory makes it readable and traversable, or forgetting that the execute bit on a directory means 'can enter/traverse' rather than 'can run'.
Candidates memorise 755 and 644 as recipes for files and directories without decomposing them into owner/group/other and read/write/execute bits. Directory semantics are taught less often than file semantics.
What to do instead
Practise converting between symbolic (rwxr-x---) and octal forms until it is automatic: r=4, w=2, x=1 per triad. Explicitly learn directory rules: r lists names, x allows traversal and access to entries, w allows create/delete/rename. Also learn the special bits (setuid 4, setgid 2, sticky 1) and their effects.
Assuming `sudo` means 'full root with no restrictions', and failing questions about why a user with sudo still cannot read a file, or why a service started with sudo behaves differently from one started as the user.
Candidates conflate privilege escalation with identity. They forget that sudo runs a command as another user (usually root), so environment, home directory, umask, and file ownership change, and that sudoers can restrict which commands are allowed.
What to do instead
Learn the model: sudo executes a command as a target user per /etc/sudoers rules; check sudo -l to see permitted commands. Understand that root bypasses DAC permission checks but not mandatory controls (SELinux/AppArmor) or read-only mounts. Review how sudo -u and sudo -i differ from su.
Writing shell scripts that work interactively but fail in automation: unquoted variables, no `set -euo pipefail`, reliance on the caller's working directory, and no exit-status checks, then misreading why a cron job produced no output.
Candidates test scripts by hand in an interactive shell where $PATH, $HOME, and the current directory are convenient. Cron runs with a minimal environment and a different working directory, so relative paths and unset variables break silently.
What to do instead
Adopt a script skeleton: shebang, set -euo pipefail, quote all expansions ("$var"), use absolute paths or compute them from $(dirname "$0"), check $? or use if ! cmd; then, and log to a file. Test with env -i /bin/bash script.sh to simulate a bare environment.
Confusing virtual machines with containers when answering questions about isolation, kernels, and resource overhead, e.g. claiming a container needs its own kernel or that a VM shares the host kernel.
The terms are used loosely in day-to-day support work, and candidates pick up the vocabulary without the underlying model. Exam questions probe exactly this boundary.
What to do instead
Learn the one-line distinction: a VM virtualises hardware and runs a full guest kernel via a hypervisor; a container isolates processes on the shared host kernel using namespaces and cgroups. Be able to say what each isolates (VM: hardware; container: process view, filesystem, network, resource limits) and which has lower overhead.
Escalating or closing a support ticket without recording the reproduction steps, the commands run, and the resolution, or recording only 'fixed it' with no evidence.
Under time pressure, candidates prioritise the fix over the record, and documentation is treated as an afterthought rather than part of the task. Exam scenarios test whether the candidate knows what a usable ticket note contains.
What to do instead
Use a fixed note structure: symptom as reported, environment, steps to reproduce, diagnosis, commands/actions taken with outputs, resolution, verification, and follow-up. Practise writing a ticket note for a scenario in under five minutes that a colleague could use to reproduce and verify the fix.
Answering 'check the logs' or 'restart the service' as a complete troubleshooting step, without naming the specific log path, the command to read it, or what pattern would confirm the hypothesis.
Candidates know the general shape of troubleshooting but have not memorised where logs live on a systemd distribution or how to filter them, so answers stay generic and score poorly on specificity.
What to do instead
Learn concrete locations and commands: journalctl -u <unit> -b --no-pager, journalctl -p err -b, /var/log/syslog or /var/log/messages, /var/log/auth.log, and dmesg -T for kernel messages. For each scenario, state the command, the expected evidence, and the next branch if the evidence is absent.
Misreading the question's scope when it asks for the first or best next step, and giving the final fix instead, e.g. answering 'reinstall the package' when the question asks what to check first.
Candidates pattern-match keywords to known fixes and answer the question they expected rather than the one asked. Qualifiers like 'first', 'most likely', 'least disruptive', and 'next' are skimmed.
What to do instead
Underline the qualifier before choosing an answer. Rank options by cost and reversibility, and prefer the diagnostic step over the destructive fix when the question asks for 'first'. Practise rewriting questions to make the qualifier explicit, then answer only that.