20 Automation, CI/CD & Version Control Practice Questions & Answers

1. 1. An administrator must guarantee that on forty servers a package is installed, a service is enabled, and a configuration file holds specific contents, and the procedure must be safe to run again every week. Why does a declarative configuration management definition suit this better than a shell script that issues the install and enable commands in order?

   • A.It issues the same commands in the same order on every host, so the outcome cannot vary from one server to another.
   • B.It runs entirely in the shell on each host, so no interpreter or management software is needed anywhere else.
   • C.It states the end state each resource must be in, and the tool changes only what does not already match.✓ Answer
   • D.It records each command in the order it was executed, so any host can later be rebuilt by replaying that record.

   A declarative definition names the desired end state of each resource; the tool reads the current state of the host and acts only where the two differ, which is why the same definition can be applied weekly without doing harm. A script simply re-issues its commands, so on a host that is already configured it can fail, duplicate work, or restart a service that needed no change.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: infrastructure as code and declarative desired stateReport a problem with this question

2. 2. A configuration definition is applied to a host a second time with no edits in between, and the run reports four resources checked and none changed. Which property of the tool does this result demonstrate?

   • A.Idempotence, because applying the same definition to a host that already matches it produces no further change.✓ Answer
   • B.Atomicity, because a run either applies every resource it contains or rolls all of them back together.
   • C.Orchestration, because the run coordinates the order in which work is carried out across several hosts.
   • D.Check mode, because the run compares the host with the definition and only reports what it would change.

   Idempotence means that applying a definition to a host that already matches it changes nothing, so a second run reports resources as checked rather than changed. That silent second run is the convergence signal administrators look for; a run that only reported intended changes without applying them would be a dry run, not a normal apply.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: idempotence in configuration managementReport a problem with this question

3. 3. A change to a configuration definition affects every production web host. Before anything is altered, the administrator wants a list of the files and services the run would modify. What is the appropriate step?

   • A.Apply the definition in check mode, which compares each resource with the host and reports but changes nothing.✓ Answer
   • B.Apply the definition with most resources commented out, so only the parts left active are evaluated on the hosts.
   • C.Apply the definition to one production host first, then read that host's files to infer what the rest will do.
   • D.Apply the definition with the highest log verbosity, then read the log afterwards to see which resources were modified.

   Check mode, commonly called a dry run, evaluates every resource against the live host and prints the differences it would apply without writing anything, which is exactly the preview needed before touching production. Reading logs after a real apply is too late, because the hosts have already been changed.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: configuration management dry run (check mode) before applying changesReport a problem with this question

4. 4. Site policy forbids installing any additional resident daemon on the managed hosts, while administrative access over the existing encrypted remote login service is already permitted. Which configuration management model fits that constraint?

   • A.A pull model, where a resident client on each host periodically fetches and applies its own catalog of state.
   • B.A pull model, where the central server opens a session to each host on a timer and installs whatever client it needs.
   • C.A push model, where a control host connects over the permitted remote login transport and applies the work itself.✓ Answer
   • D.A push model, where each managed host runs a local timer that clones the definition repository and applies it.

   An agentless push model needs nothing resident on the managed hosts: the control host connects over the already-permitted encrypted remote login transport, performs the work and disconnects, so only the control host carries the management software. Pull models depend on an installed client that periodically contacts a central server, which is precisely the resident daemon the policy rules out.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: agentless push versus agent-based pull configuration managementReport a problem with this question

5. 5. One configuration definition must set a different document root on the web servers and a different memory value on the database servers, without keeping two copies of the definition. How should this be arranged?

   • A.List every host in one flat inventory and apply the definition twice, once with each set of values.
   • B.List every host in one flat inventory and keep a hand-edited copy of the definition for each kind of host so the values can differ.
   • C.List every host in the inventory, group them as web and database hosts, and set the differing values per group.✓ Answer
   • D.List every host in the inventory and write the finished values straight into the files copied to each host.

   The inventory lists the managed hosts and places them in groups, and variables attached to each group supply the values that differ, so a single definition with templated configuration files serves both kinds of host. Duplicating the definition or hard-coding finished values defeats the whole reason for keeping one reviewable source of truth.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: inventory of managed hosts, host groups and group variablesReport a problem with this question

6. 6. During review, a database password is found written in clear text inside a template that is committed to the configuration repository. Beyond being untidy, why is this treated as a security incident?

   • A.Templates are rendered on the control host only, so a clear-text value there can never be delivered to a managed host.
   • B.The repository stores objects compressed, so a clear-text value corrupts the stored object the next time the file changes.
   • C.A clear-text value is re-read on every run, so the definition stops being idempotent and reports a change each time.
   • D.Everyone who can read the repository, including its history, now holds that password, and removing it later does not unpublish it.✓ Answer

   A configuration repository is readable by everyone with access and it keeps every earlier version of every file, so a committed credential must be considered disclosed and must be rotated; deleting it in a later commit leaves it sitting in the history. Secrets belong in an encrypted store or a secret manager that the definition references at run time, never in clear text in the repository.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: secret handling in infrastructure-as-code repositoriesReport a problem with this question

7. 7. A release requires the schema migration on the database host to finish before the application hosts are updated, and the load balancer configuration may be changed only after that. Which capability is being described?

   • A.Orchestration, because work has to be sequenced across separate hosts rather than within one host.✓ Answer
   • B.Configuration management, because each host's declared state already fixes when that host is changed.
   • C.Unattended installation, because the answer file each host reads at install time decides the order of the release.
   • D.Version control, because the order of the commits in the repository sets the order of application.

   Coordinating steps in a required order across different machines is orchestration. Configuration management declares what state each host should be in, but a desired-state definition does not by itself express that one host must finish its work before another begins.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: orchestration across hosts compared with configuration managementReport a problem with this question

8. 8. Applying a definition change restarts the application service. Thirty identical application hosts sit behind a load balancer, and applying it everywhere at once caused a complete outage last time. What is the correct approach?

   • A.Apply the change to every host at once but delay each service restart by a random number of seconds.
   • B.Apply the change to a few hosts at a time and wait for each batch to pass its health check first.✓ Answer
   • C.Apply the change to one host only and leave the others on the old state so the two can be compared.
   • D.Apply the change to every host at once outside business hours, when a short total outage is tolerable.

   Rolling the change out in batches and gating each batch on a health check keeps most of the pool serving traffic while the change proves itself, so a bad change costs a fraction of capacity instead of the whole service. Restarting every host at once, even staggered by a few seconds, can still drain every backend at the same moment.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: rolling deployment in batches during orchestrated releasesReport a problem with this question

9. 9. A team wants to make it impossible for a change to reach the shared mainline unless the automated test suite has passed on that change. What arrangement achieves this?

   • A.Have the pipeline run nightly on the mainline and revert every change that landed since the last pass.
   • B.Have the pipeline run on the mainline after each merge and notify the author when a test fails.
   • C.Have each author run the suite locally and state in the change description that everything passed.
   • D.Have the pipeline run on the proposed change and block the merge until its test stage succeeds.✓ Answer

   Continuous integration gates the merge: the pipeline runs on the proposed change before it lands and the merge stays blocked until the test stage reports success, so the mainline is kept buildable by construction. Testing only after the merge, or trusting a locally reported pass, allows a failing change into the shared branch first and repairs it afterwards.

   Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: CI/CD pipelines and shift-left testingReport a problem with this question

10. 10. Every change that passes the pipeline is built, tested and packaged into a release candidate, but a release manager still has to approve the push to production. Which practice is this, and what single change would make it the other one?

    • A.Continuous deployment; putting the automated tests back before the approval gate is what would make it continuous delivery.
    • B.Continuous integration; adding a packaging stage after the tests is what would make it continuous deployment.
    • C.Continuous delivery; adding a second approval step before production is what would make it continuous integration.
    • D.Continuous delivery; removing the human approval so a passing build releases itself makes it continuous deployment.✓ Answer

    Continuous delivery means every passing build is proven releasable while a human still decides when it is released; continuous deployment removes that decision so a passing build promotes itself to production. The distinguishing factor is the human release gate, not the presence of tests or packaging, which both practices share.

    Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: continuous delivery compared with continuous deploymentReport a problem with this question

11. 11. A defect appears only in production. Investigation shows that each environment builds the application from source independently, so the resulting binaries differ. What practice removes this class of problem?

    • A.Rebuild in every environment but pin the compiler and library versions so that each build comes out identical.
    • B.Build the artifact once, store it, and promote that same stored artifact through test, staging and production.✓ Answer
    • C.Rebuild in every environment, then compare checksums and rebuild again wherever the checksums disagree.
    • D.Build in production first, then copy that environment's source tree back into test and staging to match.

    Building the artifact once and promoting that identical stored artifact through each environment means the thing that was tested is the thing that is deployed, so a defect can no longer come from a build difference between environments. Rebuilding per environment reintroduces build-time variation, and the binary running in production was then never the one the tests approved.

    Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: CI/CD pipeline artifacts and promotion between environmentsReport a problem with this question

12. 12. A pipeline builds, tests and publishes an archive on every commit. An engineer then downloads that archive and copies it onto the servers by hand. Why is this not yet an automated deployment?

    • A.The archive loses its checksum when a person downloads it, so the servers cannot verify what they received.
    • B.A pipeline cannot publish an archive at all unless its deployment stage is declared in the same definition.
    • C.A hand copy always lands in the wrong location, because the pipeline's environment variables are missing.
    • D.The last step is neither recorded nor repeatable by machine, so the deployed result depends on who performed it.✓ Answer

    An automated deployment is defined in code, triggered by the pipeline and repeatable without a person in the loop. A hand copy is unrecorded, unreviewed and varies with whoever performs it, so that step is the one that has to be moved into the pipeline before the deployment can be called automated.

    Source: CompTIA Linux+ exam objectives, Automation, Orchestration and Scripting domain: CI/CD pipeline automation of the deployment stageReport a problem with this question

13. 13. Three files in the working tree have been edited. Only two of those changes belong in the next commit, and the third must stay as a local edit. What is the correct action?

    • A.Commit all three files and add the third one to the ignore list so that it stops being recorded.
    • B.Commit all three files, then amend the commit so that the third file is taken back out of it.
    • C.Stage the two wanted files and commit, because a commit records exactly what is in the staging area.✓ Answer
    • D.Stash all three files and then commit, because a commit is built from the most recent stash entry.

    A commit records the contents of the staging area rather than the whole working tree, so staging only the two wanted files commits exactly those changes and leaves the third one as an uncommitted local edit. The ignore list has no effect on a file that is already tracked, and stashing removes the changes from the working tree instead of committing them.

    Source: Git documentation, git-add and git-commit manual pages: the index (staging area) as the source of a commitReport a problem with this question

14. 14. A long-lived feature branch has fallen behind the mainline. The team wants the branch's work to appear as a straight line on top of the current mainline tip rather than joined by a merge commit. What does rebasing do, and what limit does it impose?

    • A.It moves the branch label to the new base without altering any commit, so copies held by other people stay valid.
    • B.It replays the branch's commits onto the new base as new commits, so it must not be used on commits others already have.✓ Answer
    • C.It joins the two histories in a new commit with two parents, which is what keeps the mainline history linear.
    • D.It discards the commits unique to the branch and keeps only the newest one, so no conflict can be raised.

    Rebasing writes new commits with new identities on top of the new base, which is what produces a linear history without a merge commit. Because the original commits are replaced rather than kept, rebasing work that other people have already fetched leaves them holding two versions of the same change, so rebasing is restricted to commits that have not been published.

    Source: Git documentation, git-rebase manual page: replaying commits and the warning against rebasing published commitsReport a problem with this question

15. 15. A commit that introduces a defect was pushed to the shared remote days ago and several colleagues have already pulled it. What is the appropriate way to undo it?

    • A.Rewrite the history to drop the commit and force it onto the remote, since the error must disappear.
    • B.Delete the shared branch on the remote and push a fresh one holding only the commits that are wanted.
    • C.Reset the local branch to the commit before it and keep committing new work from that point on.
    • D.Record a new commit that reverses the change, leaving the published history intact for everyone.✓ Answer

    Once a commit is published and other people hold it, the safe undo is a new commit that reverses its content, because that leaves every existing clone's history valid and simply adds the correction. Rewriting published history and force-pushing it breaks every clone that already contains the old commits and forces each colleague to repair their own copy.

    Source: Git documentation, git-revert manual page: undoing a commit that has already been sharedReport a problem with this question

16. 16. Months after a release, an operator must be able to check out the exact code that shipped, although the branch it was released from has received many commits since. What should have been done at release time?

    • A.Tag the release commit, because a tag keeps pointing at one fixed commit while a branch label moves with new work.✓ Answer
    • B.Note the calendar date of the release, because the history can be searched for the commit current that day.
    • C.Keep a copy of the built package, because the commit that produced a package cannot be identified later.
    • D.Note the branch name in the release notes, because a branch name always resolves to the code that shipped.

    A tag is a fixed, named reference to one specific commit, so it still identifies the shipped code long after the branch has advanced. A branch name always resolves to the newest commit on that branch, which is why it cannot be used to name a past release.

    Source: Git documentation, git-tag manual page: tags as fixed references to a release commitReport a problem with this question

17. 17. A generated log file was committed by mistake and now shows as modified after every run. The administrator adds its path to the repository's ignore list, but it still shows as modified. Why?

    • A.The ignore list matches directories alone, so an entry naming a single file is discarded when it is read.
    • B.The ignore list takes effect for a repository only after the next tag is created, so it is not active yet.
    • C.The ignore list applies only to untracked paths, so the file must also be removed from tracking.✓ Answer
    • D.The ignore list is fetched from the remote, so the entry must be pushed before the local copy obeys it.

    Ignore rules are consulted only for paths that are not already tracked, so a file that has been committed stays tracked and keeps being reported as modified. It has to be removed from tracking, while being left in place on disk, before the ignore entry has any effect on it.

    Source: Git documentation, gitignore manual page: ignore patterns apply only to untracked filesReport a problem with this question

18. 18. An assistant produces a shell function that rotates and compresses log files, and it looks correct at a glance. The administrator is behind schedule. What is the responsible course of action?

    • A.Commit and run it in production now, and restore from backup if the first execution misbehaves.
    • B.Read every line, confirm it does what is intended, and test it on a non-production system before use.✓ Answer
    • C.Commit it unchanged and note in the message that it was generated, so the reviewer carries responsibility.
    • D.Run it in production and then ask the assistant to explain it, which serves as the review step.

    Generated code is the responsibility of the person who commits it: it can be subtly wrong, out of date for the distribution family in use, or carry a licence the organisation cannot accept, and none of that is visible at a glance. Reading it line by line and exercising it outside production is the review, and that review cannot be delegated to the tool that wrote the code.

    Source: CompTIA Linux+ exam objectives, responsible use of AI: avoid copy and paste without review, verify outputReport a problem with this question

19. 19. While debugging a failing automation definition, an administrator wants to paste the whole file into a hosted assistant. The file contains an API token, internal hostnames and a customer account identifier. What should be done first?

    • A.Upload the file unchanged, because prompt text is transient and is discarded when the session closes.
    • B.Remove the token and the identifying details first, or use a locally hosted model for the whole session.✓ Answer
    • C.Paste the file unchanged but add a line forbidding the service to retain it or train on it.
    • D.Include only the credential, because a token alone cannot be linked to the system it came from.

    Content submitted to a hosted model leaves the organisation's control and may be retained or used for training, so credentials, internal identifiers and customer data must be stripped before the content is sent, or the work must be done on a locally hosted model that keeps the data inside the organisation. An instruction written inside the prompt is a request, not an enforceable control, and corporate policy on approved tools governs the choice.

    Source: CompTIA Linux+ exam objectives, responsible use of AI: data governance and private versus public modelsReport a problem with this question

20. 20. An assistant returns a single command line meant to delete stale files beneath a directory tree, using two options the administrator has never used before. What is the correct handling?

    • A.Read the manual page for the command and its options, then try it against a disposable copy of the data.✓ Answer
    • B.Run it on the production tree with elevated privileges, since insufficient privilege is the usual failure.
    • C.Ask the assistant whether the command is safe and treat that answer as the verification of the command.
    • D.Run it on the production tree, because a returned command is validated against the system before it is sent.

    A destructive command is exactly as destructive when it was generated as when it was typed by hand, and a generated command line often carries options whose real behaviour differs from the surrounding description. Checking each option in the manual page on the system itself and rehearsing the command against disposable data is the verification step; asking the tool to vouch for its own output verifies nothing.

    Source: CompTIA Linux+ exam objectives, responsible use of AI: verify generated output and test outside productionReport a problem with this question

Practice questions written to the published CompTIA Linux+ exam objectives and to standard Linux administration practice. CompTIA and Linux+ are marks of CompTIA, and Linux is a registered trademark of Linus Torvalds; this site is not affiliated with or endorsed by CompTIA. The real exam mixes multiple-choice items with performance-based questions that ask you to carry out a task in a simulated environment — those cannot be reproduced in a four-option format, so this bank covers the knowledge half and you should practise on a real system alongside it. CompTIA revises and version-numbers the objectives periodically: confirm the current objectives, exam code and requirements with CompTIA before testing. About the CompTIA Linux+ certification →