CCP-C study materials
CCP-C study resources

CCP-C: Automation, DevOps, and Infrastructure as Code

CCP-C · Work through your exam, one topic at a time.

All guide sections

Automation, DevOps, and Infrastructure as Code

DevOps fundamentals

DevOps is a culture and practice set summarised by CALMS - culture, automation, lean, measurement, sharing - expressed operationally through continuous integration (merge often, build and test automatically) and continuous delivery (every change is deployable). Automation exists to remove toil, shorten feedback loops and make change smaller and reversible.

Infrastructure as Code

IaC defines infrastructure in versioned files instead of console clicks. Declarative tools (Terraform, CloudFormation, ARM/Bicep, Pulumi) describe the desired end state and the tool computes the diff; imperative scripts describe steps and are not inherently idempotent. Idempotency means running the same definition twice leaves the same result - a defining property of declarative tooling. Tools maintain state mapping definitions to real resources; the state must live in a remote, locked backend because it contains sensitive values and concurrent runs corrupt it. Drift is the divergence between code and reality caused by out-of-band manual changes; drift detection surfaces it, but IaC does not prevent it automatically.

Pipelines and governance

A typical pipeline: commit → build → unit tests → static and security scans → deploy to staging → integration/acceptance tests → approval gate → production. GitOps takes this further by making Git the single source of truth, with an in-cluster agent continuously reconciling live state to the repository (pull-based). Policy as code (OPA, Azure Policy, SCPs) enforces guardrails automatically. Secrets belong in a secret manager, never in repositories - and remember they also leak into IaC state files.

Trap: statements like "IaC eliminates drift" (it doesn't; manual changes still happen) and confusing declarative convergence with imperative scripting.

Rule of thumb: if a task must be repeatable and reviewable, it belongs in code; if it must be identical every run, it must be idempotent.