AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 32“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Configuration Management with Ansible

Terraform can create TechLearningPro’s VPC, instance profile, and EC2 host. It should not become a general-purpose package manager for every 'yum install' forever. **Configuration

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Configuration Management with Ansible

AWS Cloud & DevOps Engineering · Lesson 32 · DevOps Automation and IaC

Lesson Overview

Terraform can create TechLearningPro’s VPC, instance profile, and EC2 host. It should not become a general-purpose package manager for every yum install forever. Configuration management converges the software and files on a machine toward a desired state: packages, services, users, config files, and handlers that restart only when needed. Ansible is a popular agentless (SSH or, on AWS, often SSM-backed) automation tool using inventories, playbooks, roles, variables, and idempotent modules.

Terraform State, Modules and Workspaces owns topology and cloud resources. This lesson draws a bright line: do not replace Terraform for VPC and security-group topology with Ansible AWS modules “because we can.” Use Ansible for guest configuration and operational remediation; use Terraform/CDK/CloudFormation for cloud control-plane resources. AWS Systems Manager and Fleet Operations remains the preferred access path—pair Ansible with SSM where possible instead of opening SSH to the world.

Budget alert on. Tag Project=tlp-lesson32. No hardcoded secrets in playbooks. Clean up instances when done.

Learning Objectives

By the end of this lesson you will be able to:

Explain configuration management versus infrastructure as code and when each owns a change.
Describe Ansible inventory, playbooks, roles, tasks, handlers, and variables.
Argue why idempotency matters and how modules should converge without unnecessary restarts.
Build a role that configures a Linux application host for a TechLearningPro lab service.
Choose inventory patterns: static files, dynamic AWS inventory concepts, or SSM-based targeting.
Integrate with Session Manager / SSM rather than bastion+key sprawl when practical.
Avoid managing VPC/subnet/IGW lifecycle in Ansible when Terraform already owns them.
Store secrets via Ansible Vault awareness or, better for AWS, pull from Secrets Manager/SSM Parameter Store at runtime.
Use tags and limits to scope blast radius of playbook runs.
Connect Ansible runs to CI for controlled config promotion—not laptop cowboy applies to prod.
Contrast immutable images (AMI/EC2, containers) with mutable config management and hybrid approaches.
Troubleshoot common failures: unreachable hosts, privilege escalation, module errors, partial converges.
Budget and clean up lab hosts; prefer small instance counts.
Document an ADR: Terraform for cloud, Ansible for guest, SSM for access.
Preview AWS CDK as another IaC path—still not a substitute for in-guest config when you truly need it.

Prerequisites

Terraform Fundamentals for AWS and Terraform State, Modules and Workspaces.
AWS Systems Manager and Fleet Operations.
Compute Services: EC2, AMIs and Auto Scaling.
Secrets Manager and Systems Manager Parameter Store.
Containers with Docker for AWS Workloads for the immutable alternative mindset.
Linux shell comfort; Ansible installed per current Ansible documentation for your control node.
Sandbox account with budget alert.

Detailed Core Concepts

IaC vs configuration management

IaC (Terraform/CloudFormation/CDK): creates/updates/deletes cloud APIs—VPC, IAM roles, load balancers, managed services.

Config management (Ansible, and partly SSM State Manager): configures operating systems and apps on compute.

Immutable infrastructure: bake AMIs or container images in CI; replace instances rather than mutating. Often best for TechLearningPro app hosts at scale.

Mutable config: patch and converge long-lived hosts. Still real for bastions you wish you did not have, certain COTS tools, and brownfield.

TechLearningPro default aspiration: immutable images for app runtimes; Ansible or SSM for bootstrap leftovers and emergency remediation; Terraform for AWS resources.

Ansible building blocks

Inventory. Lists hosts and groups ([progress_api], [content_workers]). Can be INI/YAML static or dynamic from AWS APIs.

Playbook. YAML mapping hosts → roles/tasks, ordered automation.

Task. A call to a module (ansible.builtin.yum, copy, service, template).

Module. Idempotent unit of work when used correctly—install package if missing; copy file if content changed.

Handler. Runs on notify, typically restart service only when a config file changed.

Role. Packaged tasks, handlers, templates, defaults, vars—reusable unit (roles/progress_api_host).

Variables. Precedence is famously complex—keep vars simple; prefer role defaults + group_vars + extra-vars for env.

Idempotency

Running the playbook twice should not thrash. If your tasks always restart nginx, you do not have idempotent operations—you have a reboot script. Handlers and correctly chosen modules fix that.

AWS inventory and SSM patterns

Patterns:

Terraform outputs instance IDs → generate inventory in CI.
Dynamic inventory plugin for AWS EC2 filtered by tags Project=tlp-lesson32.
SSM connection: prefer community/documented approaches that run automation via Systems Manager rather than SSH from the internet—align with lesson 20. Exact plugin names and options evolve; verify current Ansible AWS/SSM documentation.

Do not open 0.0.0.0/0 SSH to make Ansible “easier.”

What Ansible should not own

VPC CIDRs, subnet layout, IGW, NAT, core route tables → Terraform.
Long-lived IAM policy design for the platform → Terraform.
Replacing ECS/EKS service deployments → use container pipelines; Ansible is a poor Kubernetes controller.

Ansible AWS modules exist for EC2 and friends. Using them for the same VPC Terraform manages creates dual control planes—the same anti-pattern as dual Terraform roots without boundaries.

Secrets

Ansible Vault encrypts vars at rest in Git—acceptable for some shops. On AWS, prefer: playbook retrieves secret from Secrets Manager with instance/control role permissions; never commits plaintext tokens. Do not put production DB passwords in group_vars/all.yml unencrypted.

Immutable vs Ansible

If every change is a new AMI/container, Ansible may only harden the golden image build host or run one-shot bootstrap. If you mutate pets weekly, Ansible roles become critical—and so does drift detection. Prefer reducing pets.

Architecture and Design Diagrams

mermaid
flowchart LR
  TF[Terraform: VPC IAM EC2]
  Inv[Inventory by tags / outputs]
  ANS[Ansible control node / CI]
  SSM[SSM or SSH securely]
  Host[Linux app host]

  TF --> Host
  TF --> Inv
  Inv --> ANS
  ANS --> SSM --> Host

Ownership swimlane:

mermaid
flowchart TB
  subgraph terraform_own [Terraform owns]
    VPC[VPC Subnets SG]
    IAM[Instance profile]
    EC2[Instance lifecycle]
  end
  subgraph ansible_own [Ansible owns]
    Pkg[Packages]
    Cfg[App config files]
    Svc[OS services]
  end
  EC2 --> Pkg

Technical Explanation

Playbook sketch

yaml
# Conceptual — verify module FQCNs and options against your Ansible version docs
- name: Converge TechLearningPro progress host
  hosts: progress_api
  become: true
  roles:
    - role: progress_api_host

Role sketch

text
roles/progress_api_host/
  tasks/main.yml
  handlers/main.yml
  templates/app.env.j2
  defaults/main.yml

Tasks install packages, template config, enable service; handler restarts on template change.

Inventory by tag philosophy

Target tag_Project_tlp_lesson32:&tag_Role_progress_api. Limits (--limit) protect you from running against all hosts.

Privilege escalation

become: true for root-level package installs. Prefer least privilege on the control path; do not leave NOPASSWD wide open without understanding.

Performance

Fan-out with forks carefully; do not DDoS your own fleet. For large fleets, prefer image baking and Auto Scaling refresh over long Ansible runs every deploy.

Security

No secrets in repos.
Scoped inventory.
SSM Session logging where required.
Change control for production playbooks—same as Terraform.

Practical Implementation or Design Walkthrough

Problem

A Terraform-provisioned Amazon Linux host must present a simple systemd-managed demo service (or nginx static page) configured by an Ansible role, reached via SSM-compatible design without public SSH.

Steps

Budget alert; ensure Terraform (or console lab) created tagged instance + SSM profile.
Install Ansible on control node; verify versions.
Create inventory from tags/IPs/SSM as documented in your chosen pattern.
Scaffold role progress_api_host with package, template, service, handler.
Run playbook with check mode first if appropriate; then apply.
Re-run; confirm changed=0 for idempotent tasks.
Introduce a template change; confirm handler fires once.
Negative: wrong become permissions; capture failure.
Destroy instance / terraform destroy; remove lab artifacts.

Enterprise Real-World Scenarios

Ansible recreates VPC

Team “standardized on Ansible” and builds networks with ec2 modules while Terraform also runs. Symptom: fights and drift. Fix: ADR ownership.

SSH keys in chat

Keys pasted to unlock Ansible. Fix: SSM + IAM.

Non-idempotent deploys

Playbook restarts on every run; flapping connections. Fix: handlers + proper modules.

Config in Terraform user_data forever

Unmaintainable bash. Fix: images or Ansible/SSM documents.

Production play from laptop

No audit trail. Fix: CI with approvals.

Best Practices

Terraform for cloud topology; Ansible for guest config.
Prefer SSM over public SSH.
Idempotent roles with handlers.
Tag-based inventory limits.
Secrets from AWS secret stores.
Check mode / dry-run culture where supported.
Version roles; review PRs.
Prefer immutability for apps when possible.
Small blast radius runs.
Budget and cleanup.
Document connection method.
Align with SSM Patch Manager for OS patches rather than inventing only-Ansible patching without baselines.
Do not duplicate ECS deploy tooling.
Keep variable precedence boring.
ADR for tool boundaries.

Common Mistakes and Anti-Patterns

Ansible-managed VPC alongside Terraform.
Open SSH for convenience.
Secrets in plaintext YAML.
Always-restart tasks.
Running against all without limit.
Cowboy laptop prod changes.
Huge monolithic roles.
Ignoring immutable image options.
Hardcoded hostnames in playbooks.
Using Ansible as a poor man’s Kubernetes operator.

Troubleshooting and Design Review

Symptom	Cause	Action
Unreachable	Network/SSH/SSM/IAM	Verify SSM managed, SG, agent
Permission denied	become/IAM	Fix privileges
Changed every run	Non-idempotent task	Fix module usage
Wrong hosts	Inventory error	Dry-run with host list
Secret missing	Vault/AWS perms	Fix retrieval path

Interview Questions and Answers

Q1: IaC vs config management? A: Cloud APIs vs guest/OS/app config.
Q2: Why Ansible? A: Agentless automation with idempotent modules and readable YAML.
Q3: What is a role? A: Packaged reusable unit of tasks/handlers/templates.
Q4: Handlers? A: Run on notify when something changed.
Q5: Why not Ansible for VPC? A: Dual control planes; Terraform/CFN/CDK better fit for topology.
Q6: Inventory strategies? A: Static, dynamic AWS, generated from Terraform outputs, SSM targeting.
Q7: Secrets? A: Vault or AWS Secrets Manager—never plaintext Git.
Q8: Idempotency? A: Repeat runs converge without thrash.
Q9: Immutable alternative? A: Bake AMI/container; replace hosts.
Q10: SSM relation? A: Preferred ops channel; Ansible can leverage it.
Q11: Blast radius? A: limits, tags, environments.
Q12: CI role? A: Controlled runs with audit.
Q13: Drift? A: Manual changes fight playbooks—detect and converge or reimage.
Q14: When Ansible is wrong? A: Managing managed services better expressed in IaC; container orchestration.
Q15: TechLearningPro stance? A: Terraform topology, Ansible/SSM guest as needed, prefer immutability.

Hands-On Exercises

Exercise: Build an Ansible role for a Linux application host

Implement role + playbook + inventory against a tagged lab host; prove idempotency; prove handler on change; no public SSH; cleanup.

Challenge ADR

Constraint: team wants Ansible to create all AWS resources. Reject with rationale; propose Terraform + Ansible split; mention containers as preferred app ship vehicle.

Lab evidence checklist

Inventory snippet, playbook output twice, handler proof, SSM/IAM notes, destroy proof, ADR.

Narrative: enrollment night restart storm

Non-idempotent playbook restarted progress API on every “config deploy,” dropping connections. Fix handlers and move to immutable task definitions on ECS for the API where possible.

Connecting Terraform outputs

Show a CI step that renders inventory from Terraform outputs without committing state.

Anti-pattern deep dive: Ansible Kubernetes modules as primary CD

Explain why GitOps/Helm/ECS services fit better for TechLearningPro containers.

Deep walkthrough: one converge

Inventory resolve → gather facts → install package (changed) → template config (changed) → notify handler → restart once → second run all ok.

Security review script

Secrets? SSH exposure? Who can run against prod inventory? Logging?

Cleanup order

Stop scheduling playbooks. 2. Destroy hosts via Terraform. 3. Delete lab keys if any. 4. Remove local vault test files.

Continuity

Next lesson: CDK—programming-language IaC that still synthesizes to CloudFormation, still not a guest config tool.

Inventory deep dive for TechLearningPro fleets

Progress API hosts, content workers, and occasional build workers should appear in Ansible inventory as groups that match operational reality—not as a flat list of IPs someone pasted last quarter. Prefer tag-driven discovery: Role=progress-api, Project=tlp-lesson32, Environment=sandbox. When Terraform creates the instance, it must apply those tags in the same apply that creates the host; otherwise Ansible invents a parallel naming scheme and on-call invents folklore.

Static inventory files are acceptable for a two-host lab. They are unacceptable as the only source of truth for an Auto Scaling group that replaces instances hourly. If the fleet is cattle, inventory must be cattle-aware: dynamic plugin, SSM inventory, or a CI-rendered file from a describe-instances query filtered by tags. Document which identity the control node uses to call AWS APIs—another IAM story, another least-privilege chart.

Never put bastion jump configuration that requires inbound SSH from the public internet into the “default” group_vars. If a jump host exists as a temporary exception, isolate it in inventory and expire it.

Handlers, services, and Monday morning flaps

A progress API systemd unit that restarts on every playbook run will drop in-flight progress writes and look like a platform outage on the board. Handlers exist so configuration changes restart once. Test the double-run: second run should report zero changed tasks for the steady state. If changed remains high, you have non-idempotent modules, templating that rewrites timestamps, or a task that runs shell scripts unconditionally.

Prefer ansible.builtin.copy/template with checksum awareness over shell echo redirection. Prefer package modules over raw yum install commands that always report changed. When you must use command or shell, set creates/removes or explicit change-when logic carefully—and treat those tasks as code smells to eliminate.

SSM Session Manager as the Ansible transport story

Lesson 20 taught operators to avoid SSH keys as the primary control plane. Ansible can still be useful if the control path respects that design. Patterns include running playbooks from a control node inside the VPC, using SSM port forwarding patterns where documented, or using automation documents for simpler tasks instead of full Ansible. Exact connection plugin configuration changes across Ansible versions—verify against current docs before the lab write-up claims a specific plugin flag.

The exam-level point is architectural: configuration management must not reopen the security group holes that VPC and SSM lessons closed. If your Ansible design requires 0.0.0.0/0:22, the design failed even if the playbook is elegant.

Secrets retrieval pattern without Vault dogma

Ansible Vault is fine for encrypting non-AWS lab credentials in Git when the team understands key distribution. On AWS, a stronger default is: the playbook or role retrieves a secret at runtime using the control node or host instance role, from Secrets Manager or Parameter Store, and never writes the secret back into world-readable files. Template files that need a database password should leave placeholders resolved at runtime with constrained file permissions.

Rotate secrets with the secrets lesson practices; do not bake secret values into AMIs “so Ansible does not need them.” Baking secrets into images is how images become secret stores.

Immutable images vs Ansible: the hybrid TechLearningPro answer

Containerized progress API on ECS should ship config as image + task definition environment (from SSM/Secrets), not as Ansible converging containers. Ansible might still build the golden AMI for a leftover EC2 content worker or configure a jump exception. Write the ADR so new engineers do not Ansible-deploy ECS services by copying a blog from 2016.

Role directory discipline and versioning

Treat roles like libraries: semantic versions, changelogs, and pinned references from playbooks. A role that silently changes sshd config underneath every host is a blast radius problem. CODEOWNERS for roles/os_hardening/** should be platform/security. Application roles can move faster. Publish roles to an internal collection when the org is ready; until then, monorepo paths with pinned refs are enough.

Failure rehearsal catalog for the lab

Instance not in inventory because tags wrong. 2. SSM agent offline. 3. Become fails. 4. Package repo unreachable without NAT/endpoint. 5. Handler fails because service name typo. 6. Second run still changes. Capture each. This catalog is your troubleshooting muscle memory.

Anti-pattern: Ansible creating the VPC

Show a rejected PR narrative: someone used amazon.aws.ec2_vpc_net to create a VPC that Terraform also manages. Even if modules are excellent, ownership split creates race plans and blame loops. Platform rule: cloud topology PRs go to Terraform/CDK; guest config PRs go to Ansible/SSM.

Linking outputs from Terraform to inventory

CI job: terraform output -json | jq to inventory YAML | ansible-playbook. Do not commit the rendered inventory with temporary IPs if it confuses the next run—render fresh. For SSM-based targeting, outputs may only need to ensure tags; inventory becomes a tag query.

Patch management coexistence

Patch Manager baselines (lesson 20) and Ansible package tasks can fight. Decide: OS patches via Patch Manager; app packages via images/Ansible. Document the boundary so two systems do not upgrade openssl in different moments without coordination.

Enterprise story: the snowflake content worker

A content worker configured by hand for a conference demo becomes the only host that can publish. Ansible role extraction is the migration; AMI bake is the graduation. Tell that story in interviews when asked about config management value.

Lab scoring against the brief rubric

Conceptual split IaC vs config 20; working role 25; security (SSM, secrets, SG) 20; reliability/idempotency evidence 20; docs/ADR 15. Self-score before submitting.

Extended practice scenario 1 — 32 configuration management with ansible

In a timed drill, implement or design the core lab for 32 configuration management with ansible with a partner observing. The observer’s job is to stop any step that invents API flags, hardcodes secrets, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: commands run, screenshots of tagged resources, policy or plan output, and destroy confirmation.

Discuss how this lesson’s tooling interacts with IAM least privilege, VPC private placement, and CI promotion rules from earlier modules. List two failure modes you personally witnessed or simulated, including detection and fix. Estimate cost drivers you touched and how long resources remained before teardown.

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps in the teach-back become your flashcards. Premium courses are not finished when the Markdown ends—they are finished when you can operate the ideas under time pressure without opening the console as a first resort.

Extended practice scenario 2 — 32 configuration management with ansible

Extended practice scenario 3 — 32 configuration management with ansible

Extended practice scenario 4 — 32 configuration management with ansible

Extended practice scenario 5 — 32 configuration management with ansible

Extended practice scenario 6 — 32 configuration management with ansible

Extended practice scenario 7 — 32 configuration management with ansible

Extended practice scenario 8 — 32 configuration management with ansible

Extended practice scenario 9 — 32 configuration management with ansible

Extended practice scenario 10 — 32 configuration management with ansible

Extended practice scenario 11 — 32 configuration management with ansible

Extended practice scenario 12 — 32 configuration management with ansible

Extended practice scenario 13 — 32 configuration management with ansible

Extended practice scenario 14 — 32 configuration management with ansible

Extended practice scenario 15 — 32 configuration management with ansible

Extended practice scenario 16 — 32 configuration management with ansible

Extended practice scenario 17 — 32 configuration management with ansible

Extended practice scenario 18 — 32 configuration management with ansible

Extended practice scenario 19 — 32 configuration management with ansible

Extended practice scenario 20 — 32 configuration management with ansible

Extended practice scenario 21 — 32 configuration management with ansible

Extended practice scenario 22 — 32 configuration management with ansible

Extended practice scenario 23 — 32 configuration management with ansible

Extended practice scenario 24 — 32 configuration management with ansible

Extended practice scenario 25 — 32 configuration management with ansible

Lesson Summary

Ansible converges guest configuration with inventories, playbooks, roles, handlers, and idempotent modules. TechLearningPro uses it beside Terraform—not instead of Terraform for VPCs—and prefers SSM-friendly access over public SSH. Immutability remains the north star for app runtimes; Ansible shines for bootstrap and controlled mutation when pets still exist.

Next: AWS CDK and Infrastructure with Programming Languages.