# Ansible

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/ansible

## Quick definition

Ansible is a tool that lets IT teams write simple instructions to automatically set up and manage hundreds of computers at once. Instead of logging into each server separately, you write a playbook that tells every server exactly what to do. It uses a plain language format called YAML, so you don’t need to be a programmer. Ansible doesn’t require additional software on the machines it manages, which makes it faster to start using.

## Simple meaning

Imagine you are the manager of a large restaurant with many kitchens. Each morning, every kitchen needs to be set up the same way: turn on the ovens, stock the fridge, set the timers, and arrange the tools. If you walked to each kitchen and did these steps by hand, it would take hours and you might forget something. Instead, you could write one clear checklist and hand it to a supervisor who visits each kitchen and reads the list out loud. That is essentially what Ansible does for computer servers.

Ansible is an automation tool that helps IT professionals manage many computers without having to manually log into each one. You write a set of instructions called a playbook, which describes exactly what you want done. A playbook might say: install this software, update that configuration file, restart the web server, and verify that the service is running. Ansible then connects to each target computer using a secure method called SSH, reads the playbook, and carries out each step in order.

Because Ansible does its job over the network and does not require a special program to be installed on the target machines, it is considered agentless. This makes it simpler to get started and reduces the number of things that can break. IT teams use Ansible for tasks like setting up new servers, applying security settings, deploying applications, and even automating cloud resources. In the context of an Azure DevOps certification (AZ-400), Ansible is a key tool for implementing infrastructure as code and continuous delivery pipelines.

## Technical definition

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs. It was developed by Michael DeHaan in 2012 and later acquired by Red Hat. Ansible uses a declarative model written in YAML (YAML Ain't Markup Language) to describe the desired state of systems. It connects to target nodes via SSH on Linux or WinRM on Windows, executing modules that perform discrete tasks like installing packages, copying files, or restarting services.

At its core, Ansible relies on a push-based architecture where the control node (where Ansible is installed) initiates connections and pushes configurations out to managed nodes. This contrasts with pull-based tools like Chef or Puppet that require agents on each node to check in with a central server. Ansible’s key components include the inventory (a list of managed hosts), modules (small programs that do the actual work), playbooks (YAML files describing automation jobs), and roles (a way to organize playbooks and related files into reusable components).

Ansible's execution flow begins with the control node reading the inventory and playbook. For each task in the playbook, Ansible creates a Python script from the appropriate module, transfers it to the managed node over SSH, executes it, and then waits for the result. If a task fails, the playbook can be configured to stop immediately or continue with the remaining tasks. The order of tasks is deterministic and defined by the playbook author.

In enterprise environments, Ansible Tower (now Red Hat Ansible Automation Platform) provides a web UI, role-based access control, job scheduling, and audit logs. Ansible Vault allows you to encrypt sensitive data such as passwords and API keys directly within your playbooks. Ansible Galaxy is a community hub for sharing pre-built roles. For the AZ-400 exam, candidates need to understand how Ansible integrates with Azure to automate the provisioning and configuration of virtual machines, networking, and PaaS services. Ansible can run within Azure DevOps pipelines as a task or via command line, making it a powerful ally in implementing continuous integration and continuous delivery (CI/CD).

## Real-life example

Think about moving into a new apartment. When you first move in, you have to set up the internet, connect the TV, install the light bulbs, set the thermostat, and arrange the furniture. If you did this every time you move, you would repeat many of the same steps. Now imagine you are a property manager who moves tenants into fifty identical apartments every month. Doing setup manually for each apartment would be exhausting and you would likely make mistakes.

Instead, you write a master checklist called the Apartment Setup Guide. It says: install the router, set the thermostat to 72, screw in the bulbs, mount the TV bracket, and test the smoke alarm. You then give this checklist to a helper who goes to each apartment, reads each step out loud, and checks it off. The helper does not need to be an expert in electronics or heating, they just follow the list. Ansible works exactly the same way.

The checklist is your Ansible playbook. The helper is the Ansible control node. Each apartment is a managed server. The helper connects to each apartment’s keybox (SSH key), reads the checklist, and completes each task. If a bulb is missing in one apartment, the helper reports the failure. If the thermostat is already at 72 in another, the helper skips that step because the desired state is already met. The helper finishes all fifty apartments in the time it would take one person to do two manually. That is the power of Ansible for IT automation.

## Why it matters

In modern IT environments, servers are no longer hardware you touch and repair manually. They are virtual machines spinning up in the cloud, often by the dozens or hundreds. Managing these servers one by one is not just slow, it is risky. A single missed step or typo can open a security hole or bring down a production application. Ansible eliminates that risk by making configuration consistent across every server in your fleet.

For Azure DevOps engineers and anyone studying for the AZ-400 exam, Ansible is a critical skill because it enables infrastructure as code. You store your server configurations in version control, review them with your team, and deploy them automatically via pipelines. This means that if a server fails, you can replace it with a new one that is automatically configured exactly like the original. It also means you can test configuration changes in a development environment before pushing to production.

Ansible’s agentless nature also reduces management overhead. You do not need to install, update, or monitor agent software on every node. This lowers the attack surface and simplifies compliance audits. Many organizations use Ansible to enforce security baselines across their entire infrastructure, ensuring that every server meets corporate standards for password policies, firewall rules, and installed patches. Understanding Ansible is not just about passing a certification, it is about being able to build scalable, repeatable, and secure systems that your company can trust.

## Why it matters in exams

The Microsoft AZ-400 exam, titled Designing and Implementing Microsoft DevOps Solutions, includes infrastructure as code as a major domain. Ansible appears specifically in the area of configuring and managing infrastructure using automation tools. While Microsoft promotes Azure-specific tools like Azure Resource Manager (ARM) templates and Bicep, Ansible is recognized as a cross-platform, open-source alternative that is widely used in multi-cloud and hybrid environments.

In the exam, you may be asked to identify how Ansible fits into a DevOps pipeline. For example, you might need to decide whether to use Ansible or Azure Automation for a particular configuration task. You could be presented with a scenario where an organization has a mix of on-premises and Azure VMs and needs to apply a consistent security policy. Ansible would be the right choice because it can manage both environments with the same playbook.

Another common exam area is comparing Ansible with other configuration management tools like Chef, Puppet, and Terraform. Ansible is agentless and push-based, while Chef and Puppet use agents and a pull model. Terraform focuses on infrastructure provisioning (creating resources), whereas Ansible focuses on configuration (setting up resources after they are created). Knowing these distinctions helps you choose the right tool for a given requirement.

The exam also tests your understanding of Ansible concepts such as playbooks, modules, inventory, and roles. You may be asked to read a YAML playbook snippet and identify what it will do, or to write a simple playbook to install a package and start a service. Understanding Ansible Vault for securing secrets is also important. While the exam does not require deep Ansible mastery, you should be comfortable with its core workflow and how it integrates with Azure DevOps pipelines via the Ansible task extension.

## How it appears in exam questions

AZ-400 exam questions that involve Ansible typically fall into three patterns: scenario-based, configuration analysis, and tool comparison.

In scenario-based questions, you are given a description of an organization’s environment and asked which tool or approach best meets a requirement. For example: A company has 200 virtual machines running Linux in Azure and 50 physical servers running Windows Server on-premises. They need to apply a security baseline configuration to all machines. Which tool should they use? The correct answer is Ansible because it can manage both Linux and Windows machines with WinRM and SSH, and it works across cloud and on-premises without agents. A trap in such questions is choosing Azure Automation or PowerShell DSC, which are also valid but may be limited to Azure-only environments or require agents.

In configuration analysis questions, you are shown a snippet of an Ansible playbook and asked what it will accomplish. For instance:
---
- hosts: webservers
 tasks:
 - name: install nginx
 apt:
 name: nginx
 state: present
 - name: start nginx
 service:
 name: nginx
 state: started
You might be asked what the playbook does. The answer: It ensures that nginx is installed and running on all hosts in the webservers group. If a candidate misreads the module and thinks it is for Windows, they may pick a wrong answer.

Tool comparison questions ask you to differentiate Ansible from alternatives. For example: Which statement best describes Ansible? The correct option might be: Ansible uses a push model and does not require an agent on managed nodes. A distractor might claim that Ansible uses a pull model similar to Puppet. Knowing the architecture is key to choosing the right answer.

Finally, integration questions appear about Azure DevOps pipelines. You might be asked how to run an Ansible playbook as part of a release pipeline. The answer typically involves using the Ansible CLI task or the Azure DevOps Ansible extension to execute playbooks against Azure VMs. Some questions test your understanding that Ansible can be invoked from a pipeline agent that has Ansible installed.

## Example scenario

You work for a company that runs an e-commerce website on ten Azure virtual machines. Every time the development team releases a new version of the web application, you need to manually update each VM: stop the web server, copy the new application files, update the configuration file with the new database connection string, start the web server, and verify that the application responds correctly. This process takes thirty minutes per VM, and you have done it many times. But today, you are tired and you miss updating the configuration file on one VM. That VM goes live with the old settings and causes errors for customers.

To fix this, you decide to automate the process with Ansible. You write a playbook called update-webapp.yml that contains the following steps:
- Stop the Apache web server.
- Copy the new application package from an Azure storage account.
- Deploy the updated configuration file using a template.
- Start the Apache web server.
- Perform a simple health check by requesting the homepage.

You also create an inventory file listing all ten VMs. You run the playbook from your Azure DevOps pipeline agent using the Ansible command line. The playbook runs against all ten VMs in parallel. Because Ansible is idempotent, if one VM already has the correct configuration file, it will skip that step. If a VM fails the health check, the playbook stops and alerts you before the deployment is considered complete.

This scenario shows how Ansible saves time, reduces human error, and enforces consistency. In the AZ-400 exam, you might be asked to design a similar automated deployment strategy, or to identify why Ansible is a better choice than manual procedures for this situation.

## Common mistakes

- **Mistake:** Thinking Ansible requires agent software on every managed node.
  - Why it is wrong: Ansible is agentless. It uses SSH or WinRM to connect and run modules, with no long-lived agent installed on the target.
  - Fix: Remember: Ansible push model, no agent needed. Just network access and Python on Linux (or PowerShell on Windows).
- **Mistake:** Believing Ansible playbooks are written in JSON.
  - Why it is wrong: Playbooks are written in YAML, which is more human-readable than JSON. While Ansible can consume JSON, the standard format is YAML.
  - Fix: Learn YAML syntax: use spaces, no tabs, and proper indentation. Know that YAML lists start with hyphens and dictionaries use colons.
- **Mistake:** Confusing Ansible with Terraform and thinking both do the same thing.
  - Why it is wrong: Terraform is for provisioning infrastructure (creating VMs, networks, storage). Ansible is for configuring that infrastructure after it is created (installing software, applying settings). They are complementary, not identical.
  - Fix: Use Terraform to create the servers, then Ansible to set them up. In exams, choose Ansible when the task is about configuration, not creation.
- **Mistake:** Assuming Ansible can only manage Linux machines.
  - Why it is wrong: Ansible can manage Windows machines using WinRM and the win_* modules (e.g., win_service, win_package). It also supports network devices via specific modules.
  - Fix: Remember: Ansible supports Linux, Windows, macOS, and many network devices. Check the module name prefix, 'win_' for Windows modules.
- **Mistake:** Thinking that Ansible playbooks always run tasks in random order.
  - Why it is wrong: Tasks in a playbook run sequentially from top to bottom. The order is deterministic and controlled by the author. You can also use 'order' or 'strategy' to change concurrency but not the sequence.
  - Fix: Always write tasks in the order you want them executed. Use 'name' tags for readability and debugging.

## Exam trap

{"trap":"A question states: 'Which configuration management tool uses a pull model and requires an agent?' Some learners choose Ansible because they confuse it with Chef or Puppet.","why_learners_choose_it":"Many learners have heard that configuration management tools require agents, and they mistakenly assume that popular tools like Ansible also follow that pattern.","how_to_avoid_it":"Memorize the architecture: Ansible is push-based and agentless. Chef and Puppet are pull-based and require agents. If the question mentions 'agent' or 'pull model', eliminate Ansible immediately."}

## Commonly confused with

- **Ansible vs Terraform:** Terraform is an infrastructure provisioning tool that creates and manages cloud resources like VMs, networks, and storage. Ansible focuses on configuring those resources after they exist. Terraform is declarative and stateful, while Ansible is procedural and/or declarative but does not manage state of cloud resources. (Example: Use Terraform to create an Azure VM, then use Ansible to install IIS and configure the firewall on that VM.)
- **Ansible vs Chef:** Chef uses a pull model where agents on each node periodically check in with a Chef server to fetch and apply configurations. Chef cookbooks are written in Ruby. Ansible uses a push model, no permanent agent, and playbooks are in YAML. Ansible is generally simpler to learn and set up. (Example: With Chef, you install chef-client on each server; with Ansible, you just run ansible-playbook from your laptop.)
- **Ansible vs Puppet:** Puppet also uses a pull model and a custom declarative language (Puppet DSL). It requires a Puppet master server and agents. Ansible is agentless and uses push. Puppet is great for large environments with many nodes, while Ansible is often chosen for its simplicity and quick adoption. (Example: Puppet needs a server architecture; Ansible can be run from a single control node without any other infrastructure.)
- **Ansible vs Azure Automation:** Azure Automation is a Microsoft service that runs PowerShell scripts, Python runbooks, and DSC configurations specifically for Azure resources. It is cloud-native and tightly integrated with Azure. Ansible is a cross-platform tool that can manage Azure, on-premises, and other clouds equally. Ansible is more portable. (Example: If your environment is only Azure, Azure Automation might be simpler. For hybrid or multi-cloud, Ansible is a better fit.)

## Step-by-step breakdown

1. **Install Ansible** — First, you install Ansible on a control node. This can be your local machine, a dedicated build server, or an Azure DevOps agent. On Linux, you can use a package manager like apt or yum. On Windows, you can use Windows Subsystem for Linux (WSL) or run Ansible in a container. Your control node is the brain that pushes configurations.
2. **Define your inventory** — Create a file that lists the machines you want to manage. This is called the inventory. It can be a simple text file with IP addresses or hostnames grouped by function, like [webservers] and [databases]. You can also use dynamic inventory scripts to pull hosts from cloud providers like Azure.
3. **Write a playbook** — Create a YAML file that describes the tasks you want to perform. A playbook starts with three dashes (---), lists the hosts it applies to, and then the tasks. Each task has a name, a module (like apt, copy, service), and parameters.
4. **Establish connectivity** — Before running the playbook, ensure your control node can connect to the target machines. For Linux, this usually means SSH key-based authentication. For Windows, configure WinRM. Ansible will use the credentials you provide (via --user, --ask-pass, or SSH keys).
5. **Run the playbook** — Execute the playbook with the command: ansible-playbook -i inventory myplaybook.yml. Ansible connects to each host, tasks run in order, and output shows success or failure. If a task fails, the playbook stops by default, letting you investigate.
6. **Verify and iterate** — After running, Ansible reports changes (changed=1) or no changes (ok=5). You can verify logs or connect to a host to confirm. If something is off, edit the playbook and rerun. Because Ansible is idempotent, rerunning the same playbook only makes necessary changes.

## Practical mini-lesson

In real-world IT environments, professionals use Ansible to achieve consistent, repeatable, and auditable infrastructure management. The key to success is understanding idempotency. Idempotency means that running the same playbook multiple times produces the same result: if a package is already installed, Ansible skips that step; if a file already has the correct content, it is not overwritten. This saves time and prevents unintended side effects.

When writing playbooks, always think in terms of desired state. Instead of writing a task that says 'install version 2.3 of nginx', write 'ensure nginx is present with version 2.3'. Ansible modules are designed to enforce state. For example, the yum module has a state parameter: present assures the package is installed, latest updates it, and absent removes it. Use state: present for most tasks unless you specifically need the latest version.

Organizing playbooks into roles is a best practice. Roles allow you to group tasks, variables, files, templates, and handlers together. For example, you can create a 'webserver' role that installs Apache, opens firewall ports, and deploys a default index.html. Then you can reuse that role across different playbooks and environments. Roles are easy to share via Ansible Galaxy.

Handlers are another important concept. A handler is a task that runs only when notified by another task. For example, after you change the Apache configuration file, you notify a 'restart apache' handler. The handler runs at the end of the playbook, not immediately. This prevents restarting the service multiple times during a run.

A common mistake in practice is forgetting to test playbooks in a safe environment before running against production. Always use --check mode to do a dry run, and --diff to see what changes would be made. Also, use Ansible Vault to encrypt sensitive data like passwords and API keys. Store the vault password securely, or integrate with Azure Key Vault.

For AZ-400, professionals should also know how to run Ansible within Azure DevOps. You can install Ansible on a Microsoft-hosted agent or use a self-hosted agent. Then add a command line task or use the Ansible extension to execute your playbooks as part of a release pipeline. This allows full automation from code commit to production deployment.

## Memory tip

Ansible Agentless, Push Architecture, YAML Playbooks. Remember: APPY, Agentless, Push, Python, YAML.

## FAQ

**Do I need to learn Python to use Ansible?**

No, you do not need to write Python code to use Ansible for everyday automation. Playbooks are written in YAML, which is easy to read and write. However, Ansible modules are written in Python, so if you want to extend Ansible with custom modules, Python knowledge helps.

**Is Ansible free?**

Yes, Ansible is open-source and free to use. Red Hat offers Ansible Automation Platform, which is a commercial version with additional features like a web UI, role-based access control, and support.

**Can Ansible manage both Linux and Windows servers?**

Yes. Ansible manages Linux servers via SSH and Windows servers via WinRM. You will use different modules for each, such as apt for Linux and win_package for Windows.

**What is the difference between Ansible and Azure Automation?**

Ansible is a cross-platform automation tool that can manage any environment (Azure, AWS, on-premises, etc.). Azure Automation is a Microsoft cloud service limited to Azure resources. Ansible is agentless while Azure Automation uses agents for some scenarios.

**What is Ansible Vault?**

Ansible Vault is a feature that lets you encrypt sensitive data such as passwords, API keys, and secrets directly inside your playbook files. You can encrypt entire files or just specific variables.

**How does idempotency work in Ansible?**

Idempotency means that running the same playbook multiple times results in the same system state. Ansible modules check the current state before taking action. If the desired state is already met, the module does nothing. This prevents unnecessary changes.

**Do I need a separate server to run Ansible?**

No, you can run Ansible from any machine with Ansible installed, including your laptop. This machine is called the control node. You can also run it from an Azure DevOps pipeline agent.

## Summary

Ansible is a powerful and simple automation tool that helps IT professionals manage infrastructure efficiently. Its key strengths are being agentless, using a push-based model, and describing tasks in YAML playbooks that are easy to read. For the AZ-400 exam, understanding Ansible is important because it embodies the principles of infrastructure as code, continuous delivery, and cross-platform configuration management.

Professionals use Ansible to automate tasks that would otherwise be manual, error-prone, and time-consuming. From patching servers to deploying applications, Ansible brings consistency and reliability to IT operations. In exams, you will encounter Ansible in scenario questions, playbook analysis, and tool comparison tasks. Knowing that Ansible is agentless and push-based immediately distinguishes it from Chef and Puppet.

The biggest takeaway for certification candidates is to remember the architecture and common use cases. Practice reading simple playbooks and understand the meaning of common modules like apt, yum, copy, service, and debug. Also, know how Ansible integrates with Azure DevOps pipelines. With this knowledge, you will be well-prepared for any Ansible-related question on the AZ-400 exam.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/ansible