30 Ansible Interview Questions and Answers

Ansible is an open-source automation tool used for configuration management, application deployment, and task automation. It is agentless and uses simple YAML files called playbooks to describe automation jobs. Ansible is commonly used for automating repetitive IT tasks, managing server configurations, and orchestrating complex workflows.

Ansible is agentless, meaning it does not require any software to be installed on managed nodes, relying instead on SSH for communication. It uses YAML for its playbooks, making it simple and human-readable. In contrast, tools like Puppet and Chef require agents and use their own domain-specific languages.

An Ansible playbook is a YAML file that defines a series of tasks to be executed on remote hosts. It consists of one or more plays, each targeting a group of hosts and specifying tasks, variables, and handlers. Playbooks are used to automate complex workflows in a repeatable and consistent way.

An inventory file in Ansible lists the hosts and groups of hosts that Ansible manages. It can be a simple INI or YAML file, or dynamically generated. The inventory allows you to organize your infrastructure and target specific hosts or groups in your playbooks.

Ansible modules are designed to be idempotent, meaning running the same task multiple times will not change the system after the first run if the desired state is already achieved. This ensures that automation is predictable and repeatable.

Ansible modules are reusable, standalone scripts that perform specific tasks such as installing packages, copying files, or managing services. Playbooks call these modules to execute actions on remote hosts. Modules return JSON data to Ansible, which processes the results.

Roles in Ansible are a way to organize playbooks and related files into reusable components. A role contains tasks, variables, files, templates, and handlers, making it easy to share and reuse automation code across different projects.

Variables in Ansible allow you to customize your playbooks and tasks for different environments or hosts. They can be defined in playbooks, inventory files, or external variable files, and are referenced using Jinja2 templating syntax.

Ansible uses a feature called Ansible Vault to encrypt sensitive data like passwords, API keys, or certificates. Vault allows you to store encrypted variables and files, which can be decrypted at runtime using a password or key.

A handler in Ansible is a special task that runs only when notified by another task. Handlers are typically used for actions that should only occur when a change is made, such as restarting a service after a configuration file is updated.

A static inventory is a file (usually INI or YAML) listing hosts and groups explicitly. A dynamic inventory is generated at runtime by querying external sources (like cloud providers or CMDBs) using scripts or plugins. Static inventories are suitable for small, unchanging environments, while dynamic inventories are ideal for cloud or large-scale infrastructures where hosts change frequently.

Ansible facts are pieces of information automatically gathered about remote systems (such as OS, IP addresses, memory, etc.) using the 'setup' module. These facts can be used in playbooks to make decisions, conditionally execute tasks, or template configuration files based on the target system's characteristics.

You can use the 'serial' keyword in a playbook to limit the number of hosts updated at a time, enabling rolling updates. For example, setting 'serial: 2' will update two hosts at a time, ensuring minimal downtime and easier rollback if issues occur.

Ansible Galaxy is a repository for sharing and downloading Ansible roles and collections. You can use Galaxy to find pre-built roles for common tasks, reducing development time and promoting best practices. Roles from Galaxy can be installed and integrated into your playbooks easily.

Ansible provides 'ignore_errors', 'failed_when', and 'retries' with 'until' keywords to control error handling. 'ignore_errors' allows playbooks to continue on failure, 'failed_when' customizes failure conditions, and 'retries' with 'until' enables retrying a task until a condition is met.

'import' statements (like 'import_tasks') are processed at playbook parsing time, making them static. 'include' statements (like 'include_tasks') are processed at runtime, allowing for dynamic inclusion based on variables or conditions. Use 'import' for static task inclusion and 'include' for dynamic scenarios.

Environment-specific configurations can be managed using group variables, host variables, or separate variable files for each environment. You can structure your inventory and variable files to load the appropriate settings based on the target environment, ensuring playbooks remain reusable and maintainable.

You can define multiple plays in a playbook, each targeting different host groups (e.g., database, backend, frontend). By sequencing plays and using dependencies, handlers, and variables, you can coordinate the deployment and configuration of each tier in the correct order.

Callbacks are plugins that allow you to customize Ansible's output or trigger actions based on playbook events. For example, you can use callback plugins to send notifications to Slack, log results to a database, or change the format of playbook output.

You can use 'ansible-playbook --check' for dry runs, 'ansible-lint' for code quality checks, and tools like Molecule for automated testing in isolated environments. These practices help catch errors early and ensure playbooks work as expected before affecting production systems.

Ansible Collections are a distribution format for Ansible content, including roles, modules, plugins, and documentation. Collections allow you to package and distribute automation content in a modular way, making it easier to share, version, and reuse across projects and teams. They are published on Ansible Galaxy or private repositories and can be installed as needed.

To implement idempotent database schema changes, you can use Ansible modules like 'postgresql_db', 'mysql_db', or custom scripts that check the current schema state before applying changes. Challenges include handling complex migrations, ensuring changes are repeatable, and managing dependencies between schema updates. Proper error handling and state checks are essential to avoid data loss or inconsistent states.

'delegate_to' is used to run a task on a host different from the one being managed, such as running a task on a bastion host or a central logging server. 'local_action' runs a task on the control node itself. Use 'delegate_to' for targeting specific remote hosts and 'local_action' for tasks that must run locally, like interacting with APIs or generating files before distribution.

Optimizing playbooks for scale involves using strategies like 'free' or 'linear', tuning forks and parallelism with the '-f' flag, minimizing fact gathering, using efficient inventory plugins, and leveraging asynchronous tasks. Breaking playbooks into smaller, targeted plays and using dynamic inventories also helps manage large environments efficiently.

Integrate Ansible with CI/CD tools (like Jenkins, GitLab CI, or Azure DevOps) by triggering playbook runs as pipeline steps. Store playbooks in version control, use environment variables for secrets, and leverage Ansible Vault for sensitive data. Automated testing (with Molecule or ansible-lint) and dry runs ensure reliability before production deployment.

Custom modules are written when existing modules do not meet specific requirements. They are typically written in Python and must return JSON. Use cases include interacting with proprietary APIs, performing complex logic, or integrating with in-house systems. Custom modules should be idempotent and follow Ansible's guidelines for consistency and error handling.

At scale, use Ansible Vault to encrypt sensitive variables and files, and manage vault passwords securely (e.g., with environment variables or external secret managers). For collaboration, restrict vault access, use role-based access controls, and integrate with centralized secret management solutions like HashiCorp Vault or AWS Secrets Manager.

Start by reviewing the verbose output ('-vvv' flag) to identify the failing task and error message. Check logs on both the control node and target hosts. Validate inventory, variables, and connectivity. Use 'ansible --module-name ping' to test connectivity, and isolate issues by running tasks individually. Review playbook logic and dependencies for errors.

'block' groups related tasks, 'rescue' defines tasks to run if any task in the block fails, and 'always' runs tasks regardless of success or failure. This structure allows you to implement try/catch/finally logic, such as rolling back changes or cleaning up resources if an error occurs, improving playbook reliability.

Design the playbook to manage two environments (blue and green), update the idle environment, run health checks, and switch traffic using load balancer modules. Considerations include minimizing downtime, ensuring rollback capability, synchronizing state between environments, and automating DNS or load balancer updates. Use variables and handlers to coordinate the deployment steps.