Infrastructure as code Study Guide

📖 Core Concepts Infrastructure as Code (IaC) – Managing data‑center resources with machine‑readable definition files instead of manual hardware setup or ad‑hoc scripts. Version Control – IaC files live in a VCS (e.g., Git) so every change is tracked, auditable, and reversible. Declarative (Functional) Definition – You describe what the final infrastructure should look like; the engine works out how to get there. Imperative (Procedural) Definition – You write explicit, ordered commands that the system must execute to reach the target state. Push vs Pull Deployment – Push: a central controller sends configuration instructions to the target node. Pull: each target node fetches its own configuration from the controller. Continuous Configuration Automation (CCA) – Extends basic IaC with ongoing visibility, drift detection, and tight integration into DevOps delivery pipelines. DevOps Relationship – IaC lets developers author infrastructure, brings operations into the early development lifecycle, and supports a collaborative “shift‑left” culture. Security Implications – Templates are a large attack surface; rigorous review and management are required to avoid vulnerabilities. --- 📌 Must Remember IaC replaces manual steps with version‑controlled code → lower cost, faster rollout, fewer human errors. Declarative = desired end state; Imperative = step‑by‑step commands. Push = controller → target; Pull = target → controller. CCA tools add visibility, efficiency, flexibility and plug into CI/CD pipelines. IaC enables DevOps: developers write infrastructure, ops engage earlier, collaboration improves. Security: Templates must be reviewed; many vulnerabilities arise from unchecked IaC files. --- 🔄 Key Processes Define Desired Infrastructure Write declarative files (e.g., Terraform, CloudFormation) or imperative scripts (e.g., Ansible playbooks). Store in Version Control Commit files to a Git repository; tag releases for reproducibility. Select Deployment Model Choose push for small, static fleets; pull for large, dynamic fleets. Integrate with CI/CD Trigger automated plan/apply steps in the pipeline; run tests and security scans. Apply Configuration Execute the IaC tool; the engine converges the environment to the desired state. Monitor & Drift Detect CCA continuously checks that live resources match the stored definitions; remediate drift automatically. --- 🔍 Key Comparisons Declarative vs Imperative Declarative: “The server must have 4 vCPU, 16 GB RAM, and nginx installed.” Imperative: “Install OS → Allocate 4 vCPU → Add 16 GB RAM → Install nginx.” Push vs Pull Push: Central server sends config to nodes (good for controlled, low‑latency networks). Pull: Node requests its config (scales better, works behind firewalls). Scripted vs Declarative Definitions Scripted: Usually imperative, explicit command sequence. Declarative: Usually functional, expresses target state only. IaC vs Manual Configuration IaC: repeatable, versioned, automated, auditable. Manual: error‑prone, undocumented, hard to scale. --- ⚠️ Common Misunderstandings “IaC is always declarative.” Many tools (e.g., Ansible, Chef) use imperative scripts. “Push is always faster.” Push can bottleneck on the controller; pull scales better for many nodes. “Version control eliminates all mistakes.” VCS tracks changes but does not validate correctness or security. “CCA automatically secures templates.” CCA provides visibility; you still need dedicated security reviews. --- 🧠 Mental Models / Intuition Picture vs Recipe: Declarative = a picture of the finished dish; Imperative = a recipe listing each step. Mail Delivery: Push = the post office drops letters into your mailbox; Pull = you go to the post office to pick them up. Blueprint vs Construction Log: Blueprint (declarative) tells what the building looks like; construction log (imperative) tells how each beam was placed. --- 🚩 Exceptions & Edge Cases Legacy or hardware‑only resources may only support imperative scripts. Hybrid environments (some clouds, some on‑prem) often require a mix of declarative and imperative definitions. High‑security zones may forbid automatic pulls; a push‑only model is enforced. Rapidly changing services (auto‑scaling groups) benefit from pull‑based agents that continuously reconcile state. --- 📍 When to Use Which Declarative → idempotent, cloud‑native resources, when you care about state not order. Imperative → tasks with strict sequencing, complex bootstrapping, legacy APIs. Push → small, static fleets, tight control, low latency, firewall‑restricted targets. Pull → large, dynamic fleets, need for self‑healing agents, environments behind NAT. CCA tools → when you need ongoing drift detection, policy enforcement, or integration into CI/CD pipelines. --- 👀 Patterns to Recognize “Desired state” language (“must have”, “should be”) → declarative approach. Explicit step order (“first do X, then Y”) → imperative approach. “Agent” or “client” fetching config → pull deployment. “Controller pushes” or “runs commands remotely” → push deployment. References to Git, PR, commit → version‑controlled IaC. Mention of pipelines, automated testing, security scanning → CCA integration. --- 🗂️ Exam Traps Confusing push/pull direction – the exam may phrase “who initiates the connection?”; remember pull = target initiates. Assuming all IaC tools are declarative – tools like Ansible use imperative playbooks; watch for wording like “run these tasks in order”. Choosing speed over risk – a question might list “fastest method” but ignore “risk of human error”; the correct answer balances both. Overlooking security review – templates with many variables often need manual audit; a choice that says “templates are automatically safe” is a distractor. Mixing up “continuous configuration automation” with “continuous integration” – CCA focuses on configuration drift, not code compilation.