Refer to the Exhibit Practice Questions

It ensures the task never fails regardless of return code.

Why it fails: failed_when overrides the default return-code failure test with a custom expression; it does not suppress failure universally, since a true expression still fails the task. It is tempting because ignoring a non-zero return code is a real requirement when a command legitimately exits non-zero, achievable by setting failed_when to false.

It fails the task only if the package is installed.

Why it fails: The condition as written inverts the logic: it would fail the task when the package is present, whereas failed_when should flag genuine failure conditions such as a non-zero command result. It tempts because failed_when does override default failure detection, but the correct use targets unsuccessful outcomes, not successful installation.

It fails the task if the package is not installed.

Why it fails: The condition only triggers failure when its expression evaluates true, so it cannot detect an uninstalled package unless the expression inspects package state, which the exhibit's return-code test does not. It is tempting because failed_when can gate on arbitrary facts, and asserting package presence would be a legitimate use in a compliance playbook.

Modify the deploy role to use the force parameter when copying files.

Why it fails: The force parameter on copy overwrites the destination every run, so the task always reports changed and idempotency is lost. The failure stems from a missing directory, which a file task with state: directory should create. It is tempting to silence the copy error, but forcing masks rather than fixes the cause.

Run the playbook without check mode to force the deployment.

Why it fails: Running without check mode forces changes and hides the underlying non-idempotent task, so a second run still reports changed. Check mode exists to expose exactly this drift. It is tempting to bypass the error, but the requirement is a playbook that converges without forcing.

Add a pre_task in the playbook to create /var/www/html before roles execute.

Why it fails: A pre_task creating /var/www/html runs before roles, but check mode still reports the role's copy as changed because the directory is absent at check time; the fix belongs in the role's own tasks using a file task with state: directory. It is tempting as a quick ordering fix, yet it does not make the role idempotent.

ansible-vault rekey file.yml

Why it fails: ansible-vault rekey changes the vault password protecting the file and rewrites it, neither displaying the decrypted value nor leaving the file unmodified. It is tempting because it operates on vault-encrypted files, and is correct when the existing vault password must be rotated.

ansible-vault decrypt file.yml

Why it fails: ansible-vault decrypt rewrites the file in plaintext on disk, permanently removing encryption, which modifies the file and exposes the secret. It is tempting because it reveals the decrypted value, and would be correct when the file should no longer be vault-encrypted at all.

ansible-vault edit file.yml

Why it fails: ansible-vault edit opens the file in an editor and writes changes back on save, so it modifies the file rather than merely displaying the decrypted value. It is tempting because it does decrypt content for viewing, and is correct when the administrator genuinely needs to change an encrypted variable.

Re-encrypt the vault file with a different password.

Why it fails: Re-encrypting with a different password does not fix a playbook that cannot decrypt the existing vault; the error concerns the supplied password or vault ID, not the file's encryption key. Re-encryption suits rotating credentials after a compromise, not resolving a decryption error.

Add 'vault_httpd_port' to the group_vars/all.yml file without encryption.

Why it fails: Storing the variable unencrypted in group_vars/all.yml defeats the vault's purpose and does not address the decryption failure shown. Plain group_vars files are the right place for non-sensitive variables, so this would be correct only if the value were never meant to be secret.

Use the --ask-vault-pass option again with a different password.

Why it fails: Retrying with another password assumes the first was wrong, but the error typically indicates the vault password source was not supplied or the wrong vault ID was referenced. Re-prompting is correct when the administrator genuinely mistyped the password during an interactive run.

The http_port variable is misspelled.

Why it fails: Incorrect: http_port is defined correctly.

The wait_for module requires the 'port' parameter to be an integer.

Why it fails: Incorrect: wait_for accepts strings for port.

The delegate_to should be set to the remote host.

Why it fails: Incorrect: delegate_to to localhost is valid for checking port connectivity.

The constructed plugin cannot be used with the add_host module.

Why it fails: The constructed inventory plugin reads variables from existing inventory sources; hosts added at runtime by add_host exist only in memory for that play and are never persisted to an inventory source the plugin parses. It is tempting because add_host genuinely creates hosts dynamically, but those hosts are unavailable to inventory plugins.

The 'strict: false' setting ignores missing variables, causing the group to be empty.

Why it fails: strict: false only controls whether the plugin errors on undefined variables in its expressions; it does not empty groups that match valid variables, so grouping by ansible_distribution would still succeed. It is tempting because strict settings do affect plugin error behaviour, but they are not the cause of missing groups here.

The variable ansible_distribution is not defined because gather_facts is set to no.

Why it fails: gather_facts on the play does not populate variables for the constructed inventory plugin, which reads its variables from inventory sources rather than from fact gathering during a play run. It is tempting because ansible_distribution is indeed a fact, but the plugin needs it present in inventory data, not gathered at play time.

Configure the controller to use the AWS execution nodes for all branch office jobs via a proxy.

Why it fails: Proxying branch jobs to AWS still routes traffic over the same high-latency VPN path and adds a hop, worsening timeouts. It is tempting because AWS nodes perform well, but the fix is placing an execution node nearer the branch, not redirecting jobs.

Increase the `ansible_timeout` setting in the controller configuration to 120 seconds.

Why it fails: Raising ansible_timeout only extends how long tasks wait before failing; it cannot reduce the VPN's high latency or prevent the hangs caused by the controller-to-branch direct mesh connection. Timeout tuning suits slow-but-reachable hosts, whereas the branch nodes need a relay or hop to reduce round trips.

Reduce the forks value for branch office execution nodes to 1.

Why it fails: Lowering forks reduces parallel execution but leaves the high-latency VPN hop between controller and branch nodes, so timeouts persist. It is tempting because forks tuning helps resource-constrained hosts, yet the bottleneck here is mesh topology, not concurrency.

The execution-environment.yml file uses incorrect syntax for the 'dependencies' section.

Why it fails: The failure concerns Python package resolution, not YAML parsing; the build would abort earlier with a schema or syntax error if the `dependencies` section were malformed. This option tempts because `execution-environment.yml` does define dependencies, so incorrect syntax would genuinely break builds — but the stem already reports an incompatible Python dependency error.

The collections in requirements.yml are not fully qualified.

Why it fails: Fully qualified collection names affect resolution, not Python dependency conflicts. The build error stems from incompatible Python packages, so collection naming is irrelevant here. This option would be correct when collections fail to resolve or download during environment creation, where namespace omission genuinely breaks installation.

The base image 'ee-minimal-rhel8' is not a valid execution environment base image.

Why it fails: The base image name is valid; execution environment build failures citing incompatible Python dependencies stem from conflicting package versions declared in the requirements or bindep files. It is tempting to blame the base image, but the error explicitly names a dependency conflict, not an image resolution problem.

requirements.yml

Why it fails: requirements.yml lists Ansible Galaxy collections and roles to install; ansible-builder does not generate it as build output. It is tempting because it is a real Ansible file, and it would be correct when declaring collection dependencies for a project before building the execution environment.

execution-environment.yml

Why it fails: execution-environment.yml is the input definition file that ansible-builder reads, not a file it generates as build output. It is tempting because it is central to the build process, and it would be correct as the file an administrator authors to specify base images and dependencies.

ansible.cfg

Why it fails: ansible.cfg configures Ansible runtime behaviour such as inventory and connection settings; ansible-builder does not generate it during a build. It is tempting because it is a familiar Ansible file, and it would be correct when customising how ansible-playbook executes against managed hosts.

The role 'database' is not found in the roles_path.

Why it fails: A missing role produces an error about the role not being found, not silently skipped tasks. Tag filtering skips tasks cleanly without role-resolution failures. It is tempting because roles_path misconfiguration does break role loading, but that scenario yields a fatal error rather than the observed skip behaviour.

The inventory host db1.example.com is not in the dbservers group.

Why it fails: An absent host in the group means the play targets no managed nodes, so tasks are not skipped but simply never run, and no task output appears. It is tempting because inventory grouping errors do prevent execution, but the symptom would be an empty host list, not skipped tasks.

The tags in the role tasks conflict with the play tags, causing a syntax error.

Why it fails: Conflicting tags do not cause a syntax error; Ansible simply matches tasks whose tags intersect the requested ones. A syntax error would abort the run entirely rather than skip tasks. It is tempting because tag mismatches do cause skipping, but the mechanism is non-matching tags, not a parse failure.

The container image tag is incorrect.

Why it fails: The tag matches the image the user built and pushed, so a mistyped tag is unlikely to be the cause; the error typically reports a missing or unreadable image, not a tag mismatch. Tag errors occur when the referenced tag was never built or pushed to the local registry.

The ansible-runner process does not have network access.

Why it fails: The error stems from the container image not being present locally and the runner failing to pull it, not from network access. Network access matters when the image must be fetched from a remote registry, but here the localhost/ prefix denotes a locally built image that must already exist in the local container storage.

The execution environment is not listed in the project's execution-environment.yml.

Why it fails: ansible-runner's --container-image flag supplies the image directly on the command line, so the project's execution-environment.yml is not consulted for this invocation. That file matters when using ansible-navigator or defining project defaults, not when the image is passed explicitly.

Set the base container image.

Why it fails: The galaxy entry names an Ansible collection dependency, not a container base image; base images are declared via the containers' image references in the execution environment definition. It is tempting because dependency resolution and image layering both concern build inputs, but galaxy resolves role or collection sources, which is correct when a playbook requires external collections.

Specify Python packages to install via pip.

Why it fails: The galaxy dependency resolves Ansible roles and collections from Galaxy or a requirements file, not Python packages, which the pip module handles. It is tempting because both install external content, and would be correct for provisioning Python libraries inside a virtual environment.

Configure environment variables for the container.

Why it fails: The galaxy dependency installs Ansible roles or collections from Galaxy, not container environment variables, which belong in a task using the environment keyword. It is tempting because dependencies configure content, and would be correct for managing runtime variables passed to a launched process.

import_tasks must be placed in a role.

Why it fails: import_tasks works in any playbook, not only inside roles, so this restriction does not exist and cannot cause the failure. It is tempting because import_tasks is frequently seen within roles, but the real error stems from something else in the exhibit, such as a syntax or module issue.

The loop variable should be referenced as '{{ item }}' without quotes.

Why it fails: Quoting '{{ item }}' still resolves the variable; Ansible strips the quotes during templating, so this is not the failure. It is tempting because quoting Jinja expressions looks suspicious, but the actual error lies elsewhere, such as a malformed module argument or indentation.

The file names must be literal without templates.

Why it fails: Templated file names are permitted in copy and template modules, so literal names are not required and this cannot trigger the error. It is tempting because templating filenames can confuse debugging, but the actual failure comes from another cause visible in the exhibit.

The base image itself

Why it fails: Could be changed but bindep.txt is the direct method.

requirements.yml

Why it fails: Contains collections, not system packages.

requirements.txt

Why it fails: Contains Python packages.

10.0.0.5

Why it fails: The debug task prints whatever the registered variable holds at runtime, not a hard-coded literal; 10.0.0.5 would only appear if the play had set that exact value from gathered facts or inventory. This address is tempting because it looks like a typical host IP, which is what the task actually returns when the variable resolves to an inventory host address.

[ '192.168.1.10' ]

Why it fails: The debug task returns the value of a variable, and a list containing one IP address would only appear if the variable itself held a list. It is tempting because registered variables often store lists of host addresses, which is correct when the task loops over multiple hosts rather than a single interface.

eth0

Why it fails: A bare interface name such as eth0 is a string, not the address the task resolves, so the debug output would not match. It is tempting because interface facts commonly feed network configuration, which is correct when gathering adapter names rather than querying an address value.