Ansible Interview Questions: Real DevOps Practice Quiz

True. Ansible Vault is a built-in feature that encrypts sensitive data — passwords, certificates, SSH keys, and other secrets — so those values can be safely stored in files checked into version control. The encrypted content is decrypted at runtime using the vault password.

False. Ansible Vault uses symmetric AES-256 encryption driven by a single shared password — the same password both encrypts and decrypts the data. It does not use a public/private key pair, which is the hallmark of asymmetric encryption schemes like RSA or SSH keys.

The correct syntax is ansible all -m ping. Ad-hoc commands use the ansible CLI, all targets every host in the inventory, and the -m flag specifies the module to run — in this case, ping. ansible-playbook is for running playbook files, and -a is for passing arguments to a module, not for selecting one.

AWX is the open-source upstream community project, while Ansible Tower (now Red Hat Ansible Automation Platform) is the commercially supported downstream product built from the AWX codebase. AWX releases first as the rapid-iteration community edition, and Tower/AAP packages a stabilized, enterprise-supported version of that same project.

Pass --ask-vault-pass (or its short form -J) to ansible-playbook; Ansible will then prompt you to type the vault password before executing the playbook.

Use ansible-vault rekey <file>. It decrypts the file with the old password and re-encrypts it with a new password in one step, so the file never needs to be stored in plaintext on disk.

Use ansible-vault encrypt_string. It encrypts a single string value and outputs YAML with a !vault tag and the ciphertext, which you can paste directly into a variables file or group_vars.

The task retries 3 times and then fails, halting play execution unless ignore_errors: yes or a rescue block handles it. The retries parameter caps the number of retry attempts, and until is re-evaluated after each one. When until is never satisfied within the retry budget the task is marked failed — changed_when: false only suppresses the changed/ok status and has no effect on the failure caused by the unsatisfied until condition.

Ansible first reads its configuration and -i arguments to identify inventory sources, then loads the dynamic inventory plugin, calls its parse() method to query the external source and populate the in-memory inventory, matches the play's host pattern against that populated inventory, and finally opens connections and sends the first task to each matched host. Each step depends on the previous one completing first.

Write the inventory script to emit JSON in Ansible's expected format (top-level groups and a _meta section), make it executable with chmod +x, test it by running ./script.py --list to verify the JSON, reference it as an inventory source via -i or ansible.cfg, and then run the playbook. Each step builds on the prior one — the script must exist, be executable, be tested, be configured, and only then be invoked by a playbook run.

The correct order is: (1) Ansible reads the inventory source file and identifies the plugin: key, (2) Ansible loads the plugin class, (3) Ansible calls the plugin's parse() method, (4) the plugin populates InventoryData with hosts, groups, and variables, and (5) the populated inventory becomes available to the playbook. Each step depends on the completion of the previous one — you cannot call a plugin you have not loaded, and you cannot use inventory data that has not yet been populated inside parse().

In Ansible, the command ansible-**inventory** --list is used to display the complete inventory tree — all groups, hosts, host variables, and group variables — exactly as resolved from a dynamic inventory source. It is the recommended tool for debugging and verifying the output of an inventory plugin or a legacy inventory script before running a playbook.

To enable a dynamic inventory plugin in Ansible (for example aws_ec2 or gcp_compute from a collection), you must list it under the enable_**plugins** directive inside the [inventory] section of ansible.cfg. This directive specifies the ordered list of inventory plugins Ansible will attempt to use when parsing inventory sources. If a plugin is not listed there, Ansible will not load it even if the plugin code is installed and available on the controller.

When a legacy dynamic inventory script is called with the --list argument, it can include a top-level key named **_meta** containing a sub-key called hostvars with all per-host variables pre-populated. When this key is present, Ansible skips calling --host <hostname> for each individual host, avoiding N+1 script invocations and dramatically improving performance at scale when managing thousands of hosts.

Ansible Tower/AWX Job Templates bind a playbook (from a Project) to an Inventory and a Credential; Workflow Templates chain Job Templates with success/failure branching; and Surveys collect extra_vars at launch. Credentials are encrypted at rest, not plaintext, and dynamic inventories can be scheduled or synced on project update—not only manually.

strategy: free lets each host proceed independently; serial batches hosts for controlled rolling updates and limits the blast radius of failures; and fact caching (Redis or JSON files) avoids re-gathering facts every run when gather_facts is on. Pipelining reduces per-task SSH overhead but does not eliminate the value of ControlMaster/ControlPersist, and increasing forks past the host count yields sub-linear, not linear, gains.

Organizations are Tower's top-level scope for users, teams, projects, and inventories; the Use role on a credential (granted to a Team) permits attaching it to a Job Template; and Tower RBAC is per-resource—admin on one Inventory does not transfer to others. The Auditor role is read-only and cannot launch or modify jobs, and credentials are not auto-shared inside an Organization without an explicit Use grant.

Ansible Vault encrypts with AES-256 in CTR mode and authenticates with HMAC-SHA256. The vault password is stretched via PBKDF2-HMAC-SHA256 (since Ansible 2.6) using a per-file random salt, deriving separate AES and HMAC keys. The file begins with the header $ANSIBLE_VAULT;1.1;AES256 followed by hex-encoded salt, HMAC digest, and ciphertext.

Each vault-encrypted file carries a vault ID label in its header (e.g., dev, prod). On decrypt, Ansible first tries the password whose label matches the file's vault ID, then falls back to trying every other supplied vault password. Setting DEFAULT_VAULT_ID_MATCH = True in ansible.cfg disables the fallback so only the matching label's password is attempted—preventing accidental cross-environment decryption when many vault passwords are in play.

At scale, stop committing many vault-encrypted files to version control and instead integrate an external secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) via community collections or a custom lookup/credential plugin. This centralizes rotation, RBAC, and auditing, and eliminates distributing vault passwords to every team. For remaining vault-encrypted files, assign a distinct vault ID per environment and run ansible-vault rekey periodically to rotate passwords without re-encrypting file contents.

True. Ansible Automation Platform 2 (AWX 19+) replaced the legacy custom-virtualenv isolation model with execution environments — OCI-compatible container images built with ansible-builder that bundle ansible-core, collections, Python, and system-level dependencies. Virtualenvs are no longer supported for job execution isolation in AAP 2; EEs are the sole mechanism.

True. Job slicing in Tower/AWX, when set to N, partitions the inventory into N evenly-sized subsets and launches a concurrent child job per slice — each running the same playbook against its inventory portion — with all results aggregated under a single parent job record, subject to available capacity and license seat counts.

I would replace the static YAML and ad-hoc scripts with native Ansible inventory plugins — one per cloud: awsec2 for AWS, gcp_compute for GCP, and vmware_vm_inventory for the vSphere estate. Each is configured via a per-tenant YAML inventory source file. Plugins run in-process, so they can use the Ansible cache framework directly and populate host_vars/_meta natively without the JSON re-parse overhead of an external script. They also support constructed features like keyed_groups and compose for tag-to-group mapping without a second pass.

For caching, I would enable cache_plugin: redis (or jsonfile on smaller tenants) on every inventory plugin with a 5-minute TTL. The cache key is scoped per tenant + region + source so a refresh for tenant Acme does not invalidate tenant Globex's cache. In CI, where freshness is critical, I set cache: false or pass --flush-cache to force a live API fetch; for interactive operator use, the cached data keeps ansible-inventory --list under 30 seconds instead of 20 minutes. The cache_connection points to a shared Redis instance reachable from all control nodes.

The parse-time bottleneck is serial pagination across three cloud APIs for 50k hosts. I would shard the inventory by region/account: each region in each cloud is its own inventory source file/plugin instance with a scoped regions or instance_filters parameter. In CI, the inventory refresh is a parallelized pipeline stage — one ansible-inventory --list --export per source, all writing to the shared Redis cache simultaneously. The vmware_vm_inventory and gcp_compute plugins support batch fetching natively; for awsec2, setting regions explicitly and using instance_filters limits each instance's scope.

For grouping, I'd use keyed_groups in each plugin's constructed section: keyed_groups: [{prefix: tenant, key: tags.tenant}, {prefix: env, key: tags.env}, {prefix: role, key: tags.role}, {prefix: region, key: placement.region}, {prefix: lifecycle, key: tags.lifecycle}]. This produces groups like tenant_acme, env_prod, role_web, region_us_east_1, lifecycle_in_service. Playbooks then use --limit 'tenant_acme:env_prod:role_web:lifecycle_in_service' to target the intersection. The lifecycle tag (ready, in_service, draining, decommissioned) is maintained by the provisioning pipeline and reflected live by the inventory plugin on each refresh.

For CI safety, all pipeline runs pass --limit to scope to the changed tenant and --check for dry-run validation, with ansible-inventory --graph --vars as a pre-flight step to catch stale or malformed inventory before any playbook executes. Destructive playbooks are gated behind AWX/AAP approval workflows. Write access to the inventory source configuration is restricted to the platform team via Git branch protection on the inventory repository, so tenants can tag their resources but cannot alter the inventory plugin configuration.

I would move from a single control node to AAP/AWX with distributed execution environments, routing jobs to multiple isolated nodes or containerized runners via capacity-based job routing. The fleet is sharded across N execution nodes by inventory group — each node is assigned one or more region/tenant groups from the dynamic inventory, and the job template's --limit ensures each node only operates on its shard with no overlap. This distributes both the control-plane load and the SSH fan-out. With 10 nodes, each handles ~1,000 hosts, bringing the total wall-clock from 8 hours to under 30 minutes.

On each execution node, I'd set forks: 200 (up from the default 5) with serial: "10%" for ordered patching. serial: "10%" means each batch processes 10% of the in-service hosts concurrently, with up to 200 forks available per batch. For patching where order does not matter (e.g., security baseline enforcement), I'd use strategy: free for maximum parallelism — each host runs through all tasks as fast as its own SSH allows without waiting for the rest of the batch. The trade-off: forks: 200 consumes memory on the control node (roughly 30-50 MB per fork with complex module sets), so I'd monitor RSS and tune down if the node approaches 80% memory utilization, with a fallback of forks: 100 + serial: "5%".

For SSH, I'd enable pipelining: true in ansible.cfg — this eliminates the per-task SCP of the module file by piping the module over the existing SSH stdin, cutting per-task overhead from ~200ms to near zero. I'd add ssh_args: '-o ControlMaster=auto -o ControlPersist=60s' for connection multiplexing so the SSH handshake happens once per host per playbook run, not once per task. For bastion hosts, ansible_ssh_common_args: '-J [email protected]' (ProxyJump) routes all SSH through the bastion without a separate config. I'd also set transport = ssh (openssh), not paramiko, which is deprecated, slower, and does not support pipelining.

The dynamic inventory would expose a serial_batch host var computed from the group size (e.g., 10% of the in-service count for the current role) and a patch_window group that defines the rollout order. Playbooks would use serial: "{{ serial_batch | int }}%" so the batch size is data-driven. Hosts with lifecycle: draining or decommissioned are excluded automatically via group membership. Playbooks use idempotent modules (package, template, lineinfile) with a --check pre-flight pass against the full inventory to validate what would change before the live run.

For visibility, I'd deploy a custom callback_plugin that emits per-host task results to Datadog/ELK in real time, alongside AAP job events for operator tracking. For rollback, each batch is wrapped in block/rescue: before the change, the playbook snapshots the current package set (e.g., rpm -qa output) to a temp file; on failure in the rescue block, it reinstalls the previous package versions and re-syncs configs from the last-known-good Git commit tag. max_fail_percentage: 5 on the playbook halts the entire rollout if more than 5% of the in-service fleet fails, preventing a bad change from propagating across the full estate.

I'd configure the dynamic inventory plugin to expose each instance's lifecycle state as a host fact (lifecycle: in_service) and use keyed_groups to create Ansible groups per state: lifecycle_ready, lifecycle_in_service, lifecycle_draining, lifecycle_decommissioned. The inventory plugin — either a custom Python plugin or the constructed inventory applied on top of a cloud/CMDB plugin — queries the CMDB or cloud API for current state on each run, so the inventory reflects real-time lifecycle truth. Playbooks target the lifecycle_in_service group for the rolling change, with when: lifecycle == 'in_service' as a per-host guard. Hosts in draining or decommissioned are automatically excluded from the change by group membership — they are not in lifecycle_in_service.

For the rolling update, I'd set serial: "25%" on the lifecycle_in_service group in the playbook. This means Ansible processes at most 25% of the current in-service instances per batch, with forks high enough to run all hosts in each batch concurrently. The N% cap is relative to the in-service count because serial is applied to the lifecycle_in_service group — not the full inventory — so if 800 instances are in-service, each batch is 200 hosts. If the fleet shrinks to 400 in-service, the batch automatically shrinks to 100.

For load balancer integration, the playbook per batch is structured as a sequential series of plays/tasks:

1. Drain: Set the instance to draining in the LB API — for AWS, community.aws.elb_target with state: draining on the target group; for K8s, kubectl cordon the node or scale the Deployment; for F5, the f5networks.f5_modules module to set the pool member to disabled. Then wait_for with a loop checking active connection count to drain to zero before proceeding.
2. Change: Apply the config change with an idempotent module (template, k8s, copy) — the actual rolling config update.
3. Health check: uri module against the instance's health endpoint with status_code: 200 and retries: 10 — wait for the service to report healthy before re-adding.
4. Re-add: Set the instance back to in_service in the LB — community.aws.elb_target with state: present, or kubectl uncordon, or F5 pool member enabled.

For rollback, each batch is wrapped in block/rescue: if the health check in step 3 fails, the rescue block reverts the config change (re-applies the previous template version from the last-known-good Git tag), re-adds the instance to the LB in its previous state, and marks the host as failed in a hostvars-based tracking var. max_fail_percentage: 5 on the playbook means that if more than 5% of the in-service fleet fails health checks, the entire playbook halts — no further batches run — preventing a bad change from rolling across the full estate.

For idempotency, the playbook uses when: "'lifecycle_in_service' in group_names and not (config_version | default('none')) == target_version" to skip hosts that have already been successfully updated to the target config version. A per-host fact (written to a fact cache or a state file on the host) records the applied config_version. On re-run against the dynamic inventory, hosts already at the target version are skipped entirely — no drain, no change, no re-add — so the playbook reconciles drift without touching healthy, already-updated hosts.