kernelry
Configuration Management8 min read•October 2026•Kernelry Staff

Ansible Playbooks, Idempotency & Automation Scenarios

In infrastructure operations, Ansible remains a standard for operating system hardening, bare-metal bootstrapping, and networking device configuration. Interviewers probe whether candidates understand the fundamental principle of idempotency, how to structure reusable roles and collections, dynamic cloud inventory lookups, and secret protection using Ansible Vault.

Architecture Blueprint

Ansible Playbook Execution Lifecycle

How Ansible parses plays, evaluates variable precedence, transfers modules over SSH, executes changes idempotently, and fires registered handlers.

The Core Concept

Ansible is an agentless automation engine that configures servers and provisions software over SSH. You write human-readable YAML playbooks declaring desired system state, and Ansible pushes Python modules to target hosts to reconcile configuration without installing background agents.

Key Rules of Thumb for Production Systems

•Every Ansible task should be idempotent: running a playbook multiple times produces the exact same state without unintended changes.
•Handlers run once, after the section of tasks that notified them (or at meta: flush_handlers), and only when a notifying task reported a change.
•Use Ansible Vault or external secret managers to encrypt credentials rather than committing plain text variables to source control.
•Leverage dynamic inventories (AWS EC2, GCP Compute) to target auto-scaling instances by tags rather than static IP lists.

Why Production Systems Demand This Depth

Non-idempotent playbooks inadvertently restart critical services during routine runs, corrupt database configurations, and cause silent drift across production server fleets. Mastering variable precedence, handlers, and failure recovery is critical for maintaining reliable fleet infrastructure.

Common Diagnostic Pitfalls

  • •Using the command or shell module instead of native modules (like file, copy, or systemd), breaking task idempotency.
  • •Failing to set changed_when on raw command tasks, leading to false-positive change reports on every run.
  • •Misunderstanding variable precedence across inventory files, group_vars, role defaults, and extra vars (-e).
  • •Overusing complex Jinja2 template logic inside playbooks instead of writing clean custom filters or role abstractions.

Best Practices for Scenario Drills

  • •Emphasize the difference between tasks and handlers: handlers only fire when notified and when state actually changed.
  • •Explain how check mode (--check) and diff mode (--diff) allow safe dry-runs against production servers to detect configuration drift.
  • •Discuss how forks parameter in ansible.cfg controls SSH concurrency across large server fleets.

Worked Production Scenarios

Worked Production Scenarios

Study real-world outage patterns, diagnostic trees, and clarifying questions.

#1

Tuning an Unreliable, Non-Idempotent Playbook

Difficulty: mid

Scenario Prompt:

“A nightly configuration playbook restarts NGINX on all 50 web servers every run, causing brief traffic drops, even when no configuration files were changed. Investigation reveals a shell task that regenerates an SSL bundle every run. How do you fix this?”

Substantive Technical Concepts to Hit:

Idempotent Task Design

Replace the raw shell task with modules such as community.crypto.x509_certificate (formerly openssl_certificate) or template, which only report a change when the file actually differs.

Changed When Directives

If a custom script must run, use creates to skip it when its output already exists, and changed_when so the task only reports a change when it made one.

Handler Decoupling

Ensure NGINX service restarts are triggered via notify: restart nginx, ensuring handlers only execute when configuration files actually change.

Serial Rolling Restarts

Configure serial: 20% in the play header so restarts occur in batches rather than simultaneously impacting all 50 instances.

Senior Clarifying Questions to Investigate:
  • Are servers sitting behind a load balancer that supports health-check draining during the rolling update?
  • Can we validate the SSL certificate expiration date programmatically before attempting regeneration?
  • What error handling strategy (e.g., max_fail_percentage) should halt the playbook if a batch fails?
#2

A Playbook Takes Hours Across 2,000 Hosts

Difficulty: senior

Scenario Prompt:

“A patching playbook that finished in minutes on 50 servers now takes over three hours on 2,000. The control node is mostly idle. How do you find the bottleneck and speed it up?”

Substantive Technical Concepts to Hit:

Forks and Execution Strategy

Ansible runs 5 forks by default, so only five hosts are worked on at once. Raise forks to what the control node can sustain, and consider strategy: free so fast hosts are not held back by slow ones on every task.

SSH Pipelining and ControlPersist

pipelining = True sends modules over the existing SSH session instead of copying a file per task, and ControlPersist reuses connections. Pipelining needs requiretty disabled in sudoers.

Fact Gathering Cost

Full fact gathering runs on every host before the first task. Use gather_facts: false or gather_subset when facts are not needed, or enable fact caching so repeated runs skip it.

Profiling Before Tuning

Enable the ansible.posix.profile_tasks callback to see which tasks dominate. A single slow package-manager task with async and poll can matter more than any connection setting.

Senior Clarifying Questions to Investigate:
  • Is the limit the control node, the network path, or a shared service such as a package mirror that all hosts hit at once?
  • Should the run be split into serial batches so a bad patch stops after the first group?
  • Is this running from AWX or Ansible Automation Platform, where load can be spread across execution nodes?
Interactive Scenario Drills

That's where we come in.

Explaining architectural trade-offs under time constraints is very different from reading about them.

Kernelry helps you rehearse technical questions, evidence-led debugging, safe next steps, and the clear communication teams expect. The drills adapt to your answer, so you practice the reasoning rather than memorize a company-specific script. During early access, free accounts include ten daily scenarios across our mixed question pool, with no credit card required.