Implement advanced Ansible automation practice questions

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

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

Add retries and delay to the package installation task.

Why wrong: 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 wrong: While possible, it adds complexity and may not be a best practice.

Add the tasks to the inventory file under a group.

Why wrong: Inventory files define hosts and variables, not tasks.

Define the tasks in a vars file and include it.

Why wrong: Vars files cannot contain tasks.

Define the tasks as handlers and notify them.

Why wrong: Handlers are only triggered by notifications, not called directly.

The included task file does not exist on the control node.

Why wrong: Missing file causes a 'file not found' error.

The included task file has incorrect permissions.

Why wrong: File permissions do not produce template errors.

The included tasks contain a syntax error.

Why wrong: A syntax error would be reported as a YAML or Ansible syntax error, not a template error.

ignore_errors: yes

Why wrong: ignore_errors does not affect whether the task runs.

run_once: true

Why wrong: run_once runs the task on only one host, but not necessarily the primary.

delegate_to: "{{ primary }}"

Why wrong: Delegate_to changes the host that executes the task, but does not conditionally run it.

The rescue section runs and retries the failed task.

Why wrong: Rescue does not retry; it handles the error.

The playbook fails with an error message.

Why wrong: Rescue prevents the playbook from failing if it succeeds.

The remaining tasks in the block run, then the rescue section runs.

Why wrong: The block stops at the first failure.

Set the password in a variable and use 'no_log: true' on tasks that use it.

Why wrong: No_log prevents logging but the variable is still stored in plain text.

Store the password in a host_vars file with restricted file permissions.

Why wrong: File permissions do not encrypt the content.

Prompt for the password and pass it as an extra variable using -e.

Why wrong: Extra variables are visible in the process list and logs.

Set 'gather_facts: no' to skip fact collection.

Why wrong: Skipping facts does not test connectivity.

Use 'throttle: 1' to limit concurrent connections.

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

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

Why wrong: Serial controls parallelism, not connectivity.

Role defaults

Why wrong: Role defaults have the lowest precedence.

Inventory group vars

Why wrong: Inventory group vars have lower precedence than play vars.

Role vars

Why wrong: Role vars are overridden by play vars.

Collections cannot be versioned.

Why wrong: Collections have a version specified in galaxy.yml.

Collections replace the need for inventory files.

Why wrong: Inventory files are separate from collections.

Collections can only contain modules and roles.

Why wrong: Collections can also contain plugins, playbooks, and more.

Dynamically set the role name using a variable without the 'name' parameter.

Why wrong: The role name must be specified with the 'name' parameter.

Apply tags to all tasks within the included role.

Why wrong: Tags are applied at the include level, not propagated to all tasks.

It eliminates the need for an inventory file.

Why wrong: ansible-pull still requires an inventory or localhost target.

It supports a different syntax for playbooks that is more efficient.

Why wrong: ansible-pull uses standard playbook syntax.

It reduces load on the control node because it runs locally on each node.

Why wrong: ansible-pull runs on the managed node, not the control node.

Change the variable in group_vars/all.yml to a list and use 'include_role' with loop.

Why wrong: This would still apply all roles to all groups.

Add a 'when' condition to the include_role task to check the group name.

Why wrong: This requires modifying the playbook, which is not allowed.

Define the server_role in host_vars for each server.

Why wrong: Too much maintenance for 500 servers.

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

Why wrong: The module is idempotent if the regexp matches correctly.

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

Why wrong: Both 'loop' and 'with_items' work similarly.

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

Why wrong: Backreferences are not needed for simple key-value pairs.

Set `max_fail_percentage` in the play to 0 and use `ignore_errors: yes` with a rescue block.

Why wrong: `max_fail_percentage` controls play failure, not retries; `ignore_errors` prevents failure but doesn't retry.

Use the `throttle` keyword to limit concurrent tasks and rely on idempotency.

Why wrong: `throttle` limits concurrency but does not retry failed tasks.

Set `serial: 1` on the play to ensure only one host is processed at a time and rely on idempotency.

Why wrong: `serial` controls batch size, not retries; it doesn't handle transient failures.

`register: result`, `until: status == 200`, `retries: 5`, `delay: 30`

Why wrong: The `until` condition should reference the registered variable, e.g., `result.status`, not just `status`.

`until: result.status == 200`, `retries: 5`, `delay: 30`

Why wrong: Missing `register: result`, so `result` is undefined.

`register: result`, `retries: 5`, `delay: 30`

Why wrong: Missing `until`, so the task will not retry based on condition; it would only run once.

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

Why wrong: Skipping facts does not alter failure handling behavior.

Set `any_errors_fatal: true` at the play level.

Why wrong: `any_errors_fatal: true` would cause the play to abort on the first failure, opposite of desired.

Set `force_handlers: true` at the play level.

Why wrong: `force_handlers` forces handlers to run even if the play fails, but does not affect continuation after task failure.

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

Why wrong: 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 wrong: `mandatory` would cause failure if undefined, opposite of desired.

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

Why wrong: This sets a variable but is unnecessary; the filter can be used directly in the value.

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

Why wrong: `include_tasks` includes tasks from a file, not from another role; use `include_role`.

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

Why wrong: `vars/main.yml` has higher precedence than `defaults/main.yml`.

Roles cannot include playbooks.

Why wrong: Roles can include playbooks via tasks using `import_playbook` or `include_playbook`.

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 wrong: 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 wrong: 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 wrong: 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 wrong: The 'enable service' task was skipped, but the 'start service' task was continued, meaning it was not executed.

All tasks are executed and the playbook completes successfully.

Why wrong: The playbook did not run to completion; the 'enable service' task was skipped with 'n' and 'start service' was continued.

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

Why wrong: The 'enable service' task was not executed (answered 'n'), and the 'start service' task was continued (answered 'c'), not skipped.