GISI ADO Level study materials
GISI ADO Level study resources

GISI ADO Level: Infrastructure as Code

GISI ADO Level · Work through your exam, one topic at a time.

All guide sections

Infrastructure as Code

Scope of this domain

Infrastructure as Code tests declarative provisioning: idempotency, state management, drift, immutability, module reuse and safe change preview. Questions often ask you to read a plan, choose between declarative and imperative approaches, or diagnose a state problem.

Core rules and concepts

  • Declarative tools (Terraform, CloudFormation) describe the end state and compute a diff; imperative scripts describe steps and are not self-correcting.
  • Idempotency means applying twice yields the same result with no side effects.
  • State maps real resources to configuration. Store it remotely with locking (for example S3 plus DynamoDB, or a managed backend), never in git: it contains resource IDs and often secrets.
  • The plan is the review artefact; apply follows an approved plan. Watch for attributes that force replacement.
  • Drift is divergence between real infrastructure and code; detect it with scheduled plans and reconcile or import the resource.
  • Immutable infrastructure: replace versioned images and instances instead of patching in place; no snowflake servers.
  • Use modules for reuse, pin provider and module versions, and split state per environment to limit blast radius.
  • Reference secrets from a secret manager and mark sensitive outputs; never hardcode them.

Worked example

A plan shows three instances to destroy and recreate because the AMI ID changed. Reasoning: AMI is a force-new attribute, so Terraform replaces rather than updates. With create_before_destroy and a launch template behind an autoscaling group rolling update, capacity is maintained during replacement. Keep stateful data (EBS volumes, RDS) in separate resources so compute replacement cannot destroy data, and schedule the apply in a change window with the plan posted for review.

Traps that cost marks

  • Manual console fixes that create drift the next apply reverts or fights.
  • Committing .tfstate to version control.
  • No state locking, so concurrent applies corrupt state.
  • Running apply without reading the plan, especially force-new changes.
  • One monolithic state file for every environment and service.