Configuration Management & Ansible

For a DevOps engineer, Configuration Management (CM) is the backbone of consistency. It is the automation of your server's state—ensuring that every system (dev, test, prod) is configured exactly as defined in your code, rather than manually tweaked.

Here is a breakdown of Configuration Management tailored for your interview preparation and daily work.

1. The Core Concept

At its simplest, CM replaces "manual runbooks" with code. Instead of SSH-ing into a server to run apt-get install nginx, you write a script (a playbook, manifest, or recipe) that declares: "Nginx must be present." The CM tool ensures this state is true.

The Main Goal: Prevent Configuration Drift.

• Drift happens when ad-hoc changes (hotfixes, manual tweaks) make servers inconsistent over time.
• CM enforces the "Desired State," bringing stray servers back in line automatically.

2. Key Components (The Theory)

In an interview, you may be asked about the formal process. These are the four pillars:

• Identification: Knowing what you have (inventory of servers, versions, and software).
• Control: Managing changes to those items (ensuring changes are approved, versioned, and rolled out systematically).
• Status Accounting: Recording and reporting the state of your systems (e.g., "70% of servers have the latest security patch").
• Audit: Verifying that the actual state matches the desired state (finding the unauthorized changes).

3. CM vs. Infrastructure as Code (Provisioning)

This is a common point of confusion.

• Provisioning (e.g., Terraform): Creates the infrastructure itself (VPCs, EC2 instances, Load Balancers).
• Configuration Management (e.g., Ansible): Configures the software inside that infrastructure (installing Docker, copying config files, starting services).
• Note: While Ansible can provision and Terraform can configure, it is best practice to use the right tool for the job.

4. Popular Tools: The "Big Three"

Understanding the architecture differences is crucial for interviews.

Tool	Architecture	Language	Push/Pull	Key Characteristic
Ansible	Agentless	YAML	Push	Uses SSH. Easiest to learn. Good for ad-hoc tasks.
Puppet	Master-Agent	Custom DSL	Pull	Mature. Agents check in every 30 mins to enforce state.
Chef	Master-Agent	Ruby	Pull	"Infrastructure as Code" pioneer. Very powerful, steeper learning curve.

5. Why It Matters for You (DevOps Interview Prep)

• Idempotency: The most important technical term in CM. It means running the same script 1,000 times produces the same result as running it once (it doesn't break things if they are already correct).
• Immutability: Modern CM often leans toward Immutable Infrastructure (instead of updating a server, you destroy it and spin up a new, pre-configured one using tools like Packer).

6. Quick Example (Ansible)

Instead of a shell script that might fail if run twice:

mkdir /etc/myapp # Fails if directory exists

You use an idempotent Ansible task:

- name: Ensure configuration directory exists
  file:
    path: /etc/myapp
    state: directory

---

To a DevOps engineer, Ansible is the "Easy Button" for Configuration Management.

It is an open-source tool that automates software provisioning, configuration management, and application deployment. Unlike other tools that require heavy setup, Ansible is famous for being Simple, Agentless, and Powerful.

Here is the breakdown you need for your interviews and daily work.

1. The "Killer Feature": Agentless Architecture

If you remember only one thing for your interview, make it this: Ansible is Agentless.

• How others do it (e.g., Puppet/Chef): You must install a piece of software (an agent) on every single server you want to manage.
• How Ansible does it: You don't install anything on the target servers. Ansible runs on your machine (the Control Node) and talks to the servers (the Managed Nodes) using standard SSH (for Linux) or WinRM (for Windows).
• Why this matters: You can start managing a server immediately after it's created. No "bootstrapping" agents required.

2. How It Works (The Push Model)

Ansible uses a Push model. You initiate the command, and Ansible "pushes" the changes out to the servers.

1. You write a Playbook (the instructions).
2. You define an Inventory (the list of servers).
3. Ansible connects via SSH, pushes small programs (called Modules) to the servers, executes them, and then removes them.

3. Key Terminology (The "Lingo")

You will need to know these terms to answer technical questions:

Term	Definition
Control Node	The machine where you run the Ansible command (e.g., your laptop or a Jenkins server).
Inventory	A text file listing the IP addresses or hostnames of the servers you want to manage.
Playbook	The file where you write your automation code. It is written in YAML (human-readable).
Module	The "tools" Ansible uses. Examples: yum, apt, copy, service, user. You rarely run raw shell commands; you use modules.
Task	A single action in a Playbook (e.g., "Install Apache").
Role	A way to organize Playbooks into reusable structures (essential for large projects).

4. A Simple Example

Imagine you need to install httpd (Apache) on a server.

Without Ansible (Manual SSH):
You SSH in and run: sudo yum install httpd -y

With Ansible (Playbook):
You write a file called webserver.yaml:

---
- name: Setup Web Server
  hosts: webservers  # Defined in your Inventory file
  become: yes        # Run as root (sudo)

  tasks:
    - name: Install latest version of Apache
      yum:
        name: httpd
        state: latest

    - name: Start Apache service
      service:
        name: httpd
        state: started

5. Why DevOps Engineers Love It

• Written in YAML: You don't need to know Ruby (like for Chef) or complex DSLs. If you can read English, you can read a Playbook.
• Idempotent: (Mention this in your interview!) If you run the playbook above 10 times, Ansible checks the state first. If Apache is already installed, it does nothing. It only acts if a change is needed.

---

This is a favorite topic for interviewers because it tests if you know how to manage scale. Managing 5 servers is easy with any method; managing 500 requires a solid Inventory strategy.

Here is the breakdown of Ansible Inventory, Groups, and Variables.

---

1. The Inventory: Static vs. Dynamic

The inventory is simply the list of "targets" (servers, switches, cloud resources) Ansible will manage.

Static Inventory

• What it is: A simple text file (INI or YAML format) where you manually type out the IP addresses or hostnames.
• Best for: Small, stable environments (e.g., On-premise servers that rarely change).
• Example (hosts.ini):

[webservers]
192.168.1.10
192.168.1.11

[dbservers]
db1.example.com

Dynamic Inventory

• What it is: A script or plugin that talks to a cloud provider (AWS, Azure, Google Cloud) to get the list of servers in real-time.
• Best for: Cloud environments where servers are auto-scaled (created/destroyed frequently). You cannot hardcode IPs if they change every day.
• How it works: Instead of reading a file, Ansible asks AWS: "Give me a list of all EC2 instances with the tag Environment: Production."
• Interview Pro-Tip:
• Old Way: "Inventory Scripts" (Python scripts you had to download).
• Modern Way: "Inventory Plugins" (Built into Ansible, configured via YAML). Always say you use Plugins.

---

2. Groups (Organizing Your Servers)

You never want to run a playbook against "all" servers. You group them logically.

• Standard Groups: Group by function (web, db) or location (us-east, on-prem).
• Nested Groups (Children): You can create "Groups of Groups." This is powerful for applying variables to many teams at once.

Example (hosts.ini):

[frontend]
web01
web02

[backend]
db01
api01

# 'production' is a group that contains both frontend and backend
[production:children]
frontend
backend

---

3. Variables (The Logic)

Variables allow you to use the same Playbook for different environments. (e.g., Install "Version 1.0" in Dev, but "Version 2.0" in Prod).

You can define variables in many places, but interviewers look for structure.

Where to put variables (Best Practice)

• Bad Practice: Putting variables inside the Inventory file itself. It gets messy fast.
• Good Practice: Using host_vars and group_vars directories.

The Directory Structure:
Ansible automatically looks for these folders relative to your inventory file.

.
├── inventory
│   └── hosts.ini         # Just the names/IPs
├── group_vars
│   ├── all.yml           # Vars for EVERY server (e.g., DNS settings)
│   ├── webservers.yml    # Vars just for webservers (e.g., http_port: 80)
│   └── dbservers.yml     # Vars just for DBs (e.g., db_password)
└── host_vars
    └── web01.yml         # Vars specific to a SINGLE machine

---

4. Variable Precedence (The "Gotcha" Question)

Interviewers often ask: "If I define a variable in group_vars/all and the same variable in host_vars, which one wins?"

The Rule: The more specific wins.

1. Command Line (-e): Highest priority (overrides everything).
2. Host Variable: Specific to one machine.
3. Group Variable: Applies to a group.
4. Role Defaults: Lowest priority.

---

Summary for your Resume/Interview

• Inventory: Use Static for on-prem, Dynamic Plugins for AWS/Cloud.
• Groups: Use children groups to organize environments (Dev vs. Prod).
• Variables: Never put them in the host file. Always use the group_vars/ directory structure for cleanliness.

---

An Inventory in Ansible is simply the list of servers (or network devices) that you want to manage.

Think of it like the Contacts App on your phone. You don't dial a phone number manually every time; you select "Mom" or "Office," and the phone knows which number to call. Similarly, Ansible looks at the Inventory to know which IP addresses belong to "webservers" or "dbservers."

Here is the breakdown for your interview preparation:

1. The Basics

• Purpose: It tells Ansible where to run your automation. Without an inventory, Ansible allows you to do nothing.
• Default Location: /etc/ansible/hosts (though in real projects, you usually keep a custom inventory file inside your project folder).
• Formats: It can be written in INI (most common/simple) or YAML.

2. How it looks (The Alias vs. The Real IP)

A very common interview question is: "How do I give a server a nickname in Ansible?"

You do this in the inventory using the ansible_host variable.

Example (INI Format):

[webservers]
# alias       # actual connection detail
my-website    ansible_host=203.0.113.10  ansible_user=ubuntu
backup-server ansible_host=203.0.113.11  ansible_user=admin

• Usage: Now, in your playbook, you just write hosts: my-website. Ansible looks up the alias and connects to 203.0.113.10.

3. The "All" Group

Ansible includes a hidden group called all.

• If you run a playbook against hosts: all, Ansible will target every single server listed in your inventory file, regardless of what group they are in.

4. Key Takeaway for Interviews

If asked "What is an inventory?", a strong answer is:

"It is the source of truth for the infrastructure. It can be a static file (for stable servers) or a dynamic plugin (for cloud environments like AWS), and it groups servers so we can run playbooks against specific tiers like 'dev', 'prod', or 'database'."

---

An Ansible Playbook is the blueprint of your automation. It is a text file where you declare the "desired state" of your system.

If Inventory is the "Who" (list of servers), and Modules are the "Tools" (hammer, screwdriver), then the Playbook is the "Instruction Manual" (Step 1: Install Nginx, Step 2: Start Service).

Here is the breakdown you need for your interview.

1. The Basics

• Format: Playbooks are written in YAML (.yml or .yaml). This makes them very easy to read, even for non-programmers.
• Purpose: They orchestrate multiple tasks. Unlike "Ad-Hoc commands" (which run one single task), a Playbook can run hundreds of tasks in a specific order across different groups of servers.
• Idempotency: Playbooks are designed to be run repeatedly without breaking things.

2. The Structure of a Playbook

A Playbook is a list of one or more "Plays." A "Play" maps a group of hosts to some tasks.

The Hierarchy:

1. Playbook (The file)
2. Play (Targeting a specific group, e.g., "Webservers")
3. Task (A single action, e.g., "Install Apache")
4. Module (The code that does the work, e.g., yum, service)

3. A Simple Example

Here is a classic playbook that sets up a web server.

---
- name: Configure Web Server      # This is the "Play"
  hosts: webservers               # Target from your Inventory
  become: yes                     # Run as root (sudo)

  tasks:                          # List of "Tasks" starts here
    - name: Install Nginx         # Task 1
      apt:                        # The "Module"
        name: nginx
        state: present

    - name: Start Nginx Service   # Task 2
      service:                    # The "Module"
        name: nginx
        state: started

4. Key Keywords to Know

• hosts: Defines which servers this play applies to.
• become: Tells Ansible to use privilege escalation (sudo) because installing software usually requires root access.
• tasks: The list of actions to perform, executed in order from top to bottom.
• vars: You can define variables directly in the playbook (though group_vars is cleaner).
• handlers: Special tasks that only run when "notified" (e.g., "Restart Nginx" only if the config file changed).

5. Why Interviewers Ask About This

They want to know if you understand Orchestration.

• Question: "Can I have multiple plays in one playbook?"
• Answer: "Yes! You can have one play that updates the Database servers, followed immediately by a second play that updates the Web servers. This allows you to orchestrate a full-stack deployment in a single file."

---

This is the technical core of Ansible. In an interview, these concepts differentiate a beginner from a practitioner.

Here is the breakdown of each concept, how they relate to each other, and why interviewers ask about them.

1. YAML Syntax

YAML (Yet Another Markup Language) is the formatting language Ansible uses. It is designed to be human-readable.

• Key Rules:
• Indentation matters: You must use spaces (usually 2), never tabs. If your indentation is off, the playbook will fail.
• Key-Value Pairs: Represented as key: value (note the space after the colon).

• Lists: Represented by a hyphen -.

• Interview Tip: "YAML is sensitive to whitespace. A common mistake is mixing spaces and tabs."

2. Plays

A Play is the top-level unit of organization in a Playbook. Its primary job is to map a group of hosts to a list of tasks.

• A single Playbook file can contain multiple Plays (e.g., one Play for the database servers, followed by a second Play for the web servers).
• Structure:

- name: This is the Play Name
  hosts: webservers
  tasks: ...

3. Tasks

A Task is a single action to be performed.

• Every task must use a Module (like yum, copy, service).
• Tasks are executed in order, one at a time, against all matched hosts.
• Structure:

  tasks:
    - name: This is the Task Name
      yum: name=httpd state=present  # This is the Module

4. Handlers (Crucial Interview Topic)

Handlers are special tasks that only run when notified.

• Use Case: Restarting a service only when a configuration file changes.
• How it works:
• A Task makes a change (e.g., updates httpd.conf).
• That Task "notifies" the Handler.

• The Handler runs at the very end of the play (not immediately).

• Why efficient: If 5 different tasks notify the "Restart Apache" handler, Apache will only restart once at the end.

5. Idempotency

This is the "Golden Rule" of Ansible.

• Definition: You can run the same playbook 100 times, and the result will always be the same.
• If the server is already in the desired state, Ansible does nothing.

• If the server is not in the desired state, Ansible fixes it.

• Interview Example: "If I run a script mkdir /data twice, it fails the second time (folder exists). If I run the Ansible file module twice, the second time it sees the folder exists and reports 'OK' (no change)."

6. Check Mode ("Dry Run")

This allows you to simulate a playbook run without making actual changes.

• Command: ansible-playbook site.yml --check (or -C).
• What happens: Ansible connects to the servers and checks if changes would be required. It reports "Changed" or "OK" but does not actually touch the system.
• Diff Mode: Often combined with --diff to see the exact lines in a file that would be changed.

---

Putting it all together (The Code)

Here is one snippet that uses all the concepts you asked about:

---
# 1. YAML Syntax: Clean indentation, starts with ---
# 2. Play: Maps 'webservers' group to tasks
- name: Configure Web Server
  hosts: webservers
  become: yes

  tasks:
    # 3. Task: Installs Nginx
    # 5. Idempotency: If Nginx is already there, this does nothing.
    - name: Install Nginx
      apt:
        name: nginx
        state: present

    # 3. Task: Copies config file
    - name: Update Nginx Config
      copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # 4. Handler Trigger: Only runs handler if this file actually changes
      notify: Restart Nginx

  handlers:
    # 4. Handler: Defined here, runs at the end if notified
    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

Modules are the discrete units of code that Ansible pushes out to managed nodes. If the Playbook is the "To-Do List," the Modules are the specific tools used to cross items off that list.

For an interview, you don't need to memorize all 3,000+ modules, but you must know the "Core 10" and how to find the rest.

1. What is a Module?

• Definition: Small programs (usually written in Python) that perform a specific task (e.g., "manage a user," "install a package," "copy a file").
• Execution: Ansible pushes the module to the remote node, runs it, and removes it.
• Idempotency: Most modules are idempotent. They check the state before acting.

2. The "Core 10" Modules (Interview Essentials)

These are the ones you will use 90% of the time.

Package Management

• yum / apt / `dnf`: Installs or removes software packages.

• Usage: name: httpd state: present

• package: A generic module that automatically detects the OS (uses apt on Ubuntu, yum on CentOS). Great for cross-platform playbooks.

Service Management

• service / `systemd`: Starts, stops, or restarts services.
• Usage: name: nginx state: started enabled: yes (enabled=yes ensures it starts on boot).

File Management

• copy: Copies a file from your local machine (Control Node) to the remote server.
• file: Manages file attributes (permissions, ownership) or creates directories/symlinks.

• Usage: path: /data state: directory mode: '0755'

• template: Like copy, but processes the file first using Jinja2. This allows you to inject variables into configuration files dynamically.

• lineinfile: Searches for a line in a file and replaces it (or adds it if missing). Great for editing existing config files without overwriting them.

System & User

• user: Manages user accounts.
• group: Manages user groups.

Utilities

• debug: Prints statements during execution (like print() in Python). Essential for troubleshooting variables.
• ping: Checks connectivity to the host (does not actually send ICMP ping, but verifies Python and SSH are working).

3. The Classic Interview Question: command vs shell

Interviewers love asking the difference between these two modules.

Feature	command Module	shell Module
Safety	Safer (Default). It does not use a shell environment.	Less Safe. Uses /bin/sh.
Capabilities	CANNOT use pipes (`	), redirects (>), or &&`.
Idempotency	Not idempotent (runs every time).	Not idempotent (runs every time).
Recommendation	Use this unless you really need shell features.	Use only when absolutely necessary (e.g., complex piping).

Pro Tip: If you use shell or command to install software (e.g., command: yum install httpd), the interviewer will fail you. Always use the dedicated module (yum) because it handles errors and idempotency for you.

4. How to find Module info (ansible-doc)

You don't need to memorize parameters. In your daily work (and sometimes in live coding interviews), you use the command line documentation.

• Command: ansible-doc <module_name>
• Example: ansible-doc user
• This shows you the description, all available parameters (required vs. optional), and examples at the bottom.

---

These are the "Bread and Butter" modules. In a DevOps interview, you will likely be asked to write a snippet of code on a whiteboard or shared screen using exactly these modules.

Here is the breakdown of the core modules for Package, File, and System management, focusing on the syntax you need to know.

1. Package Management (apt, yum)

These modules install, update, or remove software.

• apt: Used for Debian/Ubuntu systems.
• yum (or dnf): Used for RHEL/CentOS systems.
• Key Concept: You don't type apt-get install; you declare the state you want the package to be in.

Key Parameters:

• name: The name of the package (e.g., git, nginx).
• state:
• present: Ensure it is installed (default).
• absent: Ensure it is removed.

• latest: Ensure it is installed AND the newest version.

• update_cache: (apt specific) Run apt-get update before installing.

Example (Installing Git on Ubuntu):

- name: Install Git
  apt:
    name: git
    state: present
    update_cache: yes

Interview Pro-Tip: If asked "How do I write one task for both Ubuntu and CentOS?", mention the package module. It is a generic wrapper that automatically detects the OS and uses the correct manager (apt or yum) behind the scenes.

---

2. File Management (copy, file)

These modules handle the configuration files and directory structures.

A. The copy Module

Moves a file from your Control Node (your laptop/Jenkins) to the Managed Node (the server).

• Use Case: Deploying a static file that doesn't change (e.g., a binary, a certificate, or a fixed config).

Example:

- name: Copy SSL Certificate
  copy:
    src: files/domain.crt       # Location on YOUR machine
    dest: /etc/ssl/domain.crt   # Location on SERVER
    owner: root
    group: root
    mode: '0644'

B. The file Module

Manages the attributes of a file, symlink, or directory. It does not transfer content; it sets permissions or creates folders.

• Use Case: Creating a directory for log files or changing ownership.

Example:

- name: Create Log Directory
  file:
    path: /var/log/myapp
    state: directory     # "directory", "file", "touch", or "absent"
    owner: www-data
    group: www-data
    mode: '0755'

Crucial Distinction (Interview Question):

• Q: "What is the difference between copy and template?"
• A: copy moves a file as-is. template processes the file first using Jinja2, allowing you to inject variables (like IP addresses or passwords) into the file before it lands on the server.

---

3. System Management (user)

The user module manages user accounts, UIDs, groups, and shell access.

Key Parameters:

• name: Username.
• uid: Force a specific User ID (critical for NFS/Shared storage consistency).
• groups: Add user to groups (e.g., wheel, docker).
• append: If yes, add to groups without removing them from other existing groups (Safe). If no, it resets groups to only what is listed (Dangerous).
• shell: Default shell (usually /bin/bash).

Example:

- name: Create Deploy User
  user:
    name: deploy
    uid: 1001
    shell: /bin/bash
    groups: docker,wheel
    append: yes
    state: present

Summary Cheat Sheet

Category	Module	Primary Action	Key Parameter (state)
Package	apt/yum	Install Software	present, absent, latest
File	copy	Upload Static File	(Implied present)
File	file	Create Dir / Set Perms	directory, touch, file
System	user	Create/Delete User	present, absent