How to Study the Linux+ Scripting, Containers, and Automation Domain
The CompTIA Linux+ XK0-005 exam splits into four domains, and the one that catches the most candidates off guard is Scripting, Containers, and Automation. The name suggests a bash-heavy exam where you'll be parsing log files with sed and writing for-loops on a whiteboard. The reality is the opposite: this is a DevOps tooling exam dressed in a Linux name tag. The questions you'll actually see are framed almost identically: "you need to do X — which tool would you use?" Master that pattern and the domain stops being intimidating. This guide walks the use cases the way the exam asks them, with one section per real-world scenario, the toolkit each scenario maps to, and the pairwise distinctions you'll be tested on the most.
The tooling map you actually need
Before any one tool, internalise the categories. Most questions in this domain reduce to recognising which category a scenario is asking about and then picking the right tool inside it.
Containers package applications and their dependencies (Docker, Podman). Container orchestration runs those containers at scale across multiple hosts (Kubernetes, with kubectl and Helm as its tooling). Configuration management brings existing servers into a desired state (Ansible, Puppet, Chef, SaltStack). Infrastructure as code creates the servers in the first place (Terraform, plus cloud-native equivalents like AWS CloudFormation). CI/CD automates build, test, and deploy pipelines (Jenkins, GitHub Actions, GitLab CI). Scheduling runs jobs at a time (cron, at, systemd timers). Version control tracks code and configuration changes over time (Git). Shell scripting ties any of these together (bash, plus tools like sed, awk, and grep for text processing). Eight categories. Recognising which one a question lives in is half the work.
Scenario 1: deploy a containerized application
If the scenario describes building or running a single containerized app, the answer is almost always Docker — the bank treats Docker as the default container runtime, and you should expect Docker syntax in scenario questions. Memorise the small core of commands: docker build to create an image from a Dockerfile, docker run to start a container, docker ps to list running containers, docker logs to read a container's output, docker exec -it <name> /bin/bash to drop into a shell inside a running container. Podman exists and the syntax is intentionally Docker-compatible, but the exam leans Docker. Know that Podman is the daemonless alternative favoured on RHEL — that one sentence will cover almost every Podman question you'll see.
If the scenario describes multiple containers, multiple hosts, or anything that talks about scaling, the answer shifts to Kubernetes. Know that kubectl is the CLI, kubectl get pods lists running pods, kubectl logs <pod> reads logs from one, and kubectl describe pod <pod> gives you the lifecycle history when something fails. Kubernetes objects are defined in YAML — the minimum top-level keys you should recognise are apiVersion, kind, metadata, and spec. Helm is Kubernetes's package manager; if the scenario mentions "chart" or templated manifests, the answer is Helm.
Scenario 2: configure a fleet of servers
The moment a scenario mentions "configure multiple servers," "enforce a desired state," or "automate package installation across hosts," you're in configuration-management territory. This is where the exam loves the pairwise comparison questions, and the four tools you need to be able to distinguish in one sentence each are these.
Ansible is agentless, push-based, and configured with YAML playbooks. It connects over SSH to managed hosts, runs tasks, and exits. No agent installation on targets. If the scenario mentions "playbook" or "YAML" or "no agent on managed nodes," the answer is Ansible.
Puppet is agent-based, pull-based, and configured in its own declarative DSL using .pp manifest files. Agents on each host pull configuration from a master at regular intervals. If the scenario mentions "manifests," ".pp files," or "agents pulling from a master," the answer is Puppet.
Chef is also agent-based, also pull-based, but configured in Ruby using "recipes" grouped into "cookbooks." If the scenario uses the words "recipe" or "cookbook," the answer is Chef.
SaltStack can run master-minion (agent-based) or masterless, uses YAML state files, and is the one designed for high-speed remote execution. If the scenario emphasises speed at scale or mentions "minions," the answer is Salt.
The whole framework above is what the exam tests. You will not be asked to write a playbook from scratch — you will be asked which tool fits a described scenario. Practising the one-sentence distinction per tool is the highest-leverage thing you can do in this domain.
Scenario 3: provision the underlying infrastructure
Configuration management assumes the servers already exist. When the scenario is about creating servers, networks, load balancers, or other infrastructure in the first place — usually in a cloud environment — the category is infrastructure as code, and the tool is almost always Terraform. Terraform is vendor-neutral, uses its own HCL syntax, maintains state files, and is the right answer whenever a question mentions multi-cloud or vendor-agnostic provisioning. If the question specifically pins itself to AWS and asks for a cloud-native option, the answer is AWS CloudFormation. The exam will test that you know the difference between Terraform (provisions infrastructure) and Ansible (configures existing infrastructure), because the line between them is the most-confused distinction in this whole domain.
Scenario 4: schedule a recurring task
Three scheduling mechanisms, each with a distinct use case. Cron runs commands on a recurring schedule defined in a crontab. The five-field syntax is minute, hour, day-of-month, month, day-of-week, with * as a wildcard. Know that /etc/crontab is the system crontab and crontab -e edits the current user's. at schedules a one-time command for a future moment — pair it with cron in your head: cron for recurring, at for one-off. systemd timers are the modern replacement for cron on systemd-based systems and are configured via .timer unit files paired with .service unit files. The exam will sometimes ask which mechanism is "more flexible" or "more tightly integrated with systemd-managed services" — both phrasings point at systemd timers.
Scenario 5: track configurations and run a CI/CD pipeline
Git is the version-control answer for everything. The handful of commands the exam may test: git clone <url> downloads a repository, git pull updates the local copy with remote changes, git push sends local commits to the remote, git branch creates or lists branches, git merge combines branches. There's no real depth here on the exam, but the basics will come up in a scenario about automating a deployment from a repo.
For CI/CD, the bank's most-named tool is Jenkins — the long-running open-source build server. Know what a Jenkins pipeline is at one paragraph of depth: stages that run sequentially (build, test, deploy), triggered by repo changes, executed by agents. GitHub Actions and GitLab CI are the modern platform-integrated equivalents; the exam doesn't go deep on either but you should recognise the names.
Scenario 6: actually script something in bash
The bank does test bash, but less heavily than the domain name implies, and almost entirely on fundamentals. A handful of facts will cover most of what you'll see. Every script starts with a shebang line — #!/bin/bash for bash, #!/usr/bin/env python3 for Python. Positional parameters inside a script are $1, $2 and so on, with $@ for all arguments and $# for the count. The exit code of the previous command is in $? — zero means success, non-zero means failure.
Login script locations matter because the exam likes to test them: ~/.bashrc runs for interactive non-login shells (the typical case), ~/.bash_profile or ~/.profile runs at login, and /etc/profile plus /etc/profile.d/*.sh run system-wide at login. If a question asks where to put a command that should run every time a specific user opens a terminal, the answer is ~/.bashrc.
For text processing, sed is the workhorse. The single most-tested syntax is the substitution form: sed -i 's/old/new/g' file replaces every occurrence of old with new in-place. Awk is mentioned but rarely tested in depth — recognise it as the field-processing tool (awk '{print $2}' prints the second whitespace-separated field of each line). Grep is the search tool; know that grep -r pattern dir/ searches recursively and grep -v inverts the match.
The meta-pattern that wins marks
Almost every question in this domain reduces to: "here is a scenario, which tool fits it?" The candidates who pass don't do so by memorising syntax — they do it by holding a clean mental map of what each tool is uniquely good at. Containers package apps. Orchestration scales them. Configuration management enforces state on existing servers. Infrastructure as code creates the servers in the first place. CI/CD glues the whole pipeline together. Scheduling triggers it. Version control records it. Once that map is solid, the answer to almost every question becomes mechanical — read the scenario, identify the category, pick the tool inside it.
How to drill this
Reading this guide is the orientation; the marks come from practice. The Linux+ XK0-005 question bank on IT Exam Certs includes a dedicated Scripting, Containers, and Automation domain page that lets you drill this single domain in isolation, then run a domain-weighted exam simulation to see whether your tool-recognition pattern is sharp enough yet. Pair it with the rest of the Linux+ XK0-005 cert page, and the four-domain split lets you spot weak areas inside an afternoon instead of an exam-day surprise. Most of what's hard about this domain is unfamiliarity with the toolkit, and unfamiliarity yields fast to deliberate practice.
Photos from Pexels: cover by Paras Katwal, shipping containers by Jan van der Wolf, gears by Miguel Á. Padriñán, code by Godfrey Atima.