Implement advanced Ansible automation practice questions

Set 'ignore_errors: yes' on the package installation task and handle the failure later.

Why it fails: Ignoring errors can lead to an inconsistent system state.

Add retries and delay to the package installation task.

Why it fails: Retries only help with transient failures, not with permanently missing packages.

Use the 'get_url' module to download the package from an external source and install it manually.

Why it fails: While possible, it adds complexity and may not be a best practice.

Set 'gather_facts: no' to skip fact collection.

Why it fails: Skipping facts does not test connectivity.

Use 'throttle: 1' to limit concurrent connections.

Why it fails: Throttle limits the number of forks, not connectivity.

Set 'serial: 1' to run on one host at a time.

Why it fails: Serial controls parallelism, not connectivity.

The 'lineinfile' module is not idempotent when used with loops.

Why it fails: The loop itself is not the problem: `lineinfile` remains idempotent per iteration, and each key is matched by its own `regexp`. Duplicates arise because `regexp` lacks a trailing anchor or whitespace class, so `^Port` also matches `Port 22` variants and commented or partially matching lines, appending new entries. Loops are correct when managing several distinct settings.

The loop should use 'with_items' instead of 'loop' for proper idempotence.

Why it fails: with_items and loop are functionally equivalent for this task, so switching keywords changes nothing about idempotence. It is tempting because older playbooks commonly use with_items, but the duplicate lines stem from the regexp pattern failing to match existing entries, not from the loop keyword chosen.

The 'line' parameter should use backreferences to avoid duplication.

Why it fails: Backreferences in 'line' only substitute captured regexp groups into the replacement text; they do not make lineinfile idempotent. Duplicates arise because the regexp '^Port' matches 'Port 22' yet the line comparison still appends when whitespace or existing variants differ. Backreferences suit rewriting captured values, not preventing repeated insertion.

Set `gather_facts: no` to skip fact gathering and reduce failure points.

Why it fails: gather_facts only controls whether setup runs before tasks; it does not alter failure handling, so a failed task still removes that host from the play. It is tempting because skipping fact gathering avoids setup-related failures, and would be correct when hosts lack Python or facts are unnecessary.

Set `any_errors_fatal: true` at the play level.

Why it fails: any_errors_fatal does the opposite: it aborts the entire play for all hosts when any host fails a task. It is tempting because it is a play-level failure keyword, and would be correct when you want a single host failure to halt execution across every host immediately.

Set `force_handlers: true` at the play level.

Why it fails: force_handlers only ensures notified handlers run even after a task failure; it does not stop a failed host being removed from the play. It is tempting because it concerns failure behaviour, and would be correct when handlers must still execute despite an earlier task failing on that host.

In `defaults/main.yml`: `microservice_version: latest` and reference `{{ microservice_version }}` in the task.

Why it fails: This works but is less idiomatic for inline defaults; the default filter is more explicit and flexible.

In the task: `image: "myimage:{{ microservice_version }}"` and use `| mandatory` to fail if undefined.

Why it fails: The mandatory filter aborts execution when the variable is undefined, which contradicts the requirement to fall back to latest. It is tempting because mandatory is the correct choice when a missing variable should halt the play rather than silently default.

In the task: `vars: microservice_version: "{{ microservice_version | default('latest') }}"`

Why it fails: Setting vars at task level with a self-referential default redefines microservice_version for that task, so the outer value is shadowed and the default always applies. It is tempting because the default filter is the right tool, but it belongs in defaults/main.yml or the task's own argument, not in a vars block naming the same variable.

A role can directly include tasks from another role using the `include_tasks` module.

Why it fails: Incorrect. To include tasks from another role, you use `include_role`, not `include_tasks`. `include_tasks` is for including a tasks file from within the same role.

Variables defined in `defaults/main.yml` override those in `vars/main.yml`.

Why it fails: Incorrect. Variables in `vars/main.yml` override those in `defaults/main.yml`; `defaults` have the lowest precedence.

1. Create a Project in Tower, pointing to the Git repository and associate the Source Control Credential. 2. Create a Job Template referencing the Project. 3. Add the Machine Credential to the Job Template. 4. Create a Schedule for the Job Template. 5. Assign the development team execute-only permissions on the Job Template. 6. Configure a Notification Template for email on failure.

Why it fails: Assigning execute-only permissions (instead of read) would prevent the dev team from launching; they need launch (execute) permission but not edit. Also, the schedule should be created after the job template.

1. Create a Schedule for 2:00 AM. 2. Create a Project in Tower with Source Control Credential. 3. Create a Job Template with Machine Credential. 4. Assign the development team admin permissions on the Job Template. 5. Configure a Notification Template.

Why it fails: Schedule must be associated with a job template, so creating it first is invalid. Admin permissions would allow modification, violating requirements.

1. Create a Project in Tower, pointing to the Git repository without a credential. 2. Create a Job Template referencing the Project. 3. Add the Source Control Credential to the Job Template. 4. Create a Schedule for the Job Template. 5. Assign the development team read-only permissions on the Job Template. 6. Configure a Notification Template for email on failure.

Why it fails: The Source Control Credential should be associated with the Project, not the Job Template; Tower requires the credential at project sync time.

Only the 'configure firewall' task is executed; the rest are skipped.

Why it fails: The block contains only the failing command task, and no rescue or always section exists, so the failure aborts the play and skips the remaining service tasks plus the second play. It is tempting because a bare block with no rescue does isolate its tasks, but it cannot stop the host failing.

All tasks are executed and the playbook completes successfully.

Why it fails: The command task returns a non-zero exit code, which Ansible treats as a fatal failure, so the play aborts and the second play never runs. It is tempting because a block without rescue looks like a harmless grouping, and successful runs of similar playbooks do complete all tasks.

The 'configure firewall' and 'enable service' tasks are executed; the 'start service' task is skipped.

Why it fails: The failure occurs on the first task inside the block, so Ansible aborts the play immediately; the enable and start service tasks never execute at all. It is tempting because a block with rescue would continue, but here no rescue is defined.

Use the serial keyword to limit concurrent execution to 1 host at a time.

Why it fails: Serial: 1 forces strictly sequential host execution, so a large inventory takes proportionally longer with no accuracy gain. It is tempting when tasks share a resource or ordering matters, where serialising a small batch genuinely prevents race conditions, but here it throttles throughput unnecessarily.

Set forks to 50 in ansible.cfg to maximize parallel execution.

Why it fails: Raising forks to 50 increases parallel execution, but the option omits any accuracy safeguard; uncontrolled concurrency can exhaust the control node or target resources and cause intermittent failures. It is tempting because forks is the standard throughput lever, and it is correct when inventory and targets can sustain that parallelism.

Set gathering = explicit in ansible.cfg to skip fact gathering.

Why it fails: gathering = explicit skips fact gathering entirely, so any task relying on gathered facts (ansible_facts, hostvars) fails or uses stale values, sacrificing accuracy. It is tempting because fact gathering is slow on large inventories; it is correct only when the playbook genuinely needs no facts.

Use the --limit flag to run the playbook against a subset of hosts.

Why it fails: --limit reduces the host count per run, cutting total work rather than control-node load per host, and it changes which hosts are managed, violating the no-reduced-functionality requirement. It is tempting as a quick throughput fix, but the CPU and memory pressure stems from dynamic include_tasks evaluation on the control node.

Increase the forks value in ansible.cfg to 100 to speed up execution.

Why it fails: Raising forks increases parallel worker processes on the control node, amplifying CPU and memory consumption rather than relieving it. Higher forks suit latency-bound runs against many hosts with light tasks, but here the bottleneck is control-node processing of conditional include_tasks, which more forks would worsen.

Migrate to AWX to distribute job execution across multiple nodes.

Why it fails: AWX distributes job scheduling and execution across containerised execution nodes, but the control-node load from evaluating dynamic include_tasks persists within each job's execution environment. It is tempting for scaling large inventories, yet it adds infrastructure without addressing the per-job CPU and memory cost of conditional includes.

The 'include_tasks' is used inside a block that has 'always' section.

Why it fails: Incorrect: Using include_tasks inside a block with always does not cause intermittent file access errors.

The task file path is not absolute and Ansible's search order is inconsistent.

Why it fails: Incorrect: Ansible's search order is deterministic; inconsistency is unlikely.

The playbook uses 'any_errors_fatal: true' causing early exits.

Why it fails: Incorrect: This setting causes the play to stop on any failure, but would not produce an intermittent file error.

Use 'condition' field in the dependencies list.

Why it fails: The dependencies list in meta/main.yml accepts only role names and optional role arguments; no condition field exists, so Ansible ignores or errors on it. Dependencies are unconditional, which is why conditional inclusion requires include_role with a when clause instead.

Use 'when' condition in the role's tasks to include the dependency.

Why it fails: A when clause on a task inside the role runs after the role's own tasks have already been ordered, so it cannot place the dependency before them. Task-level conditionals suit skipping individual tasks, not controlling role dependency execution order.

Use 'pre_tasks' in the playbook to run the conditional dependency.

Why it fails: Placing the conditional logic in `pre_tasks` runs it before every role in the play, not just this role's dependency, and it cannot satisfy a dependency declared in `meta/main.yml`. `pre_tasks` suits play-wide setup such as gathering facts or draining a node. Conditional role dependencies belong in `meta/main.yml` using `when` on the dependency entry.

Increase 'forks: 1' to serialize execution.

Why it fails: Incorrect: Serializing all tasks reduces parallelism unnecessarily; run_once is more targeted.

Use 'throttle: 1' on the task.

Why it fails: Incorrect: Throttle limits concurrency but still runs the task on each host sequentially, causing overwrites.

Use 'serial: 1' at the play level.

Why it fails: Incorrect: Serial batches hosts but still runs the task on each host, leading to overwrites.

The 'async' timeout was set too high.

Why it fails: Incorrect: Timeout affects how long to wait, not the accuracy of the result.

The 'poll' interval was set too low.

Why it fails: Incorrect: Poll interval affects how often to check, but does not cause false success.

The playbook used 'ignore_errors: true' on the async task.

Why it fails: Incorrect: ignore_errors would suppress an error, but the async task itself does not produce an error on start; the failure is detected later.

Use 'gather_facts: no' and manually run 'setup' module with specific filter.

Why it fails: Incorrect: This reduces fact collection but does not cache them for subsequent runs.

Use 'tags' to only gather facts on selective runs.

Why it fails: Incorrect: Tags control task execution but do not persist facts across runs.

Disable fact caching and gather facts every time.

Why it fails: Incorrect: This ensures facts are fresh but not consistent across runs; each run gathers new facts.

Using 'include_vars' to reuse variable files.

Why it fails: Incorrect. include_vars only loads variable files; it does not encapsulate the task logic for checking, starting, and verifying a service.

Using 'debug' module to output the status.

Why it fails: Incorrect. The debug module prints messages but does not encapsulate the control flow or state-checking logic.

Creating a custom filter plugin to encapsulate the logic.

Why it fails: Incorrect. Custom filter plugins are meant for transforming data in Jinja2 templates, not for defining reusable task sequences or conditionally executing tasks.

The playbook is running without '--become' flag.

Why it fails: Incorrect: Without --become, Ansible would not attempt sudo at all, so no sudo-related error.

The 'become_method' is set to 'su' instead of 'sudo'.

Why it fails: Incorrect: Using 'su' would produce a different error message, not 'Missing sudo password'.

The 'ansible_become_password' was provided but incorrect.

Why it fails: Incorrect: An incorrect password would produce a 'Sorry, try again' or authentication failure, not 'Missing sudo password'.

The remote user is not in the sudoers file.

Why it fails: Incorrect: This would typically produce 'sudo: a password is required' or 'user is not in the sudoers file' but the exact message is about missing password, not permissions.

80

Why it fails: Incorrect: Group variable would apply only if no host variable is defined.

80, because the group variable overrides host variable.

Why it fails: Incorrect: In Ansible, host variables have higher precedence than group variables.

Undefined, causing an error

Why it fails: Incorrect: The variable is defined at the host level.

the 'keyed_groups' syntax uses invalid Jinja2 expressions

Why it fails: Incorrect: invalid syntax would cause clear error.

the inventory file is incorrectly formatted

Why it fails: Incorrect: format errors would cause parsing failure.

the plugin is not enabled in ansible.cfg

Why it fails: Incorrect: enabling is not required; plugin is used via 'plugin: constructed' in inventory.

the rescue section runs and then the playbook resumes with the next task after the block

Why it fails: Incorrect: after rescue, the play continues with tasks after the block, not within it.

the block is re-executed from the beginning

Why it fails: Incorrect: blocks do not automatically retry.

the playbook stops immediately

Why it fails: Incorrect: rescue allows continuation.