Infrastructure as Code and Configuration Management Questions

Infrastructure as Code and Configuration Management covers designing, implementing, and operating infrastructure defined as code and the practices that keep that infrastructure consistent and auditable. Topics include Infrastructure as Code principles and patterns, declarative versus imperative approaches, idempotency, state management, module and template design for reusable infrastructure, version control integration, testing and validation of infrastructure code, drift detection and remediation, safe rollout and rollback strategies, policy as code and Git operations for infrastructure, and how to scan and remediate infrastructure misconfigurations. This topic also encompasses integration points with system configuration tools and considerations for managing secrets and secure defaults within infrastructure definitions.

EasyTechnical

26 practiced

Explain the sequence and purpose of Terraform commands in a typical workflow: 'terraform init', 'terraform validate', 'terraform plan', and 'terraform apply'. For each step, say what you would check in a PR and why 'terraform plan' should be part of automated PR checks.

HardTechnical

26 practiced

How would you incorporate database schema migrations into an IaC-driven deployment pipeline for a high-traffic production service? Describe safe rollout strategies (backfills, rolling migrations, feature toggles), backout procedures, coordination between infra and app teams, and how you would test schema changes to prevent data loss or downtime.

Sample Answer

**Approach summary (why this matters)** For a high‑traffic service, schema changes must be non‑blocking, reversible, and coordinated across infra and app teams. Treat migrations as first‑class artifacts in the IaC pipeline (versioned, reviewable, automated), and design changes for forward/backward compatibility so deploys can be decoupled.

**Pipeline & IaC integration**- Store migration files (Flyway/Liquibase/Alembic) alongside application repo; reference migration version in CI.- Pipeline stages: build → unit/integration tests → migration dry‑run on ephemeral DB (Terraform to create test infra) → staging with production‑sized dataset → canary rollout → production.- Use IaC (Terraform/CloudFormation) to provision DB replicas, read replicas, and orchestration jobs for backfills so infra changes are reproducible.

**Safe rollout strategies**- Forward/backward compatible changes only: add columns nullable/defaulted, create new tables, avoid dropping/renaming in same release.- Rolling migrations: apply non‑blocking DDL on replicas, then promote; use online schema change tools (gh‑ost, pt‑online‑schema‑change) for large tables.- Backfills: run idempotent, batched background jobs with rate‑limits and monitoring; use worker pods scaled by k8s HPA and job queues to avoid DB spikes.- Feature toggles: behind a remote flag (LaunchDarkly, Unleash) so new code paths reading/writing new schema can be toggled independently.- Canary deploy: enable new feature only for small subset of traffic/users; monitor latency, error rates, DB load.

**Testing to prevent data loss/downtime**- Unit tests for migration scripts; CI runs migration and rollback on ephemeral DB.- Staging run using production snapshot (anonymized) to exercise backfills and queries.- Load test targeted queries and migration jobs to measure locks/latency.- Schema compatibility tests: run old app + new DB and new app + old DB combinations.

**Backout & emergency procedures**- Always ship reversible migrations; include explicit rollback scripts in same PR.- Pre‑migration backups (logical and physical snapshots); test restoration runbooks.- Emergency kill switches: feature flag to stop writes to new columns, redirect traffic (Ingress/K8s), or put app into read‑only maintenance mode.- If rollback required: stop writers, run rollback migration, restore from snapshot only if rollback SQL insufficient. Use point‑in‑time recovery as last resort.

**Coordination & runbooks**- Cross‑team change ticket with migration plan: schema diff, expected duration, rollback plan, monitoring thresholds, paging list.- Migration window agreement for mass changes; otherwise prefer online, progressive strategies.- Shared runbooks in repo: preflight checks, monitoring dashboards (DB locks, replication lag, query latency), and post‑mortem template.

This approach minimizes blast radius while enabling automated, auditable schema evolution in an IaC-driven pipeline.

EasyTechnical

32 practiced

Describe how you would integrate Infrastructure-as-Code changes into a Git-based workflow for a team of developers and operators. Include the branch strategy, PR validation gates, required automated checks (name at least two), and how approvals should be managed to ensure safe production changes.

MediumTechnical

34 practiced

Write an Open Policy Agent (Rego) policy that denies resources that do not include a 'tags' map containing keys 'owner' and 'environment'. Provide the Rego policy and a short explanation of how you would evaluate Terraform plan output with this policy in CI to block merges.

Sample Answer

**Rego policy**

rego

package terraform.tags

# deny when resource does not have tags.owner and tags.environment
deny[msg] {
  input.resource_changes[_] = rc
  rc.change.actions[_] != "delete"           # ignore deletes
  attrs := rc.change.after
  not is_map(attrs.tags)
  msg = sprintf("resource %v missing tags map", [rc.address])
}

deny[msg] {
  input.resource_changes[_] = rc
  rc.change.actions[_] != "delete"
  attrs := rc.change.after
  is_map(attrs.tags)
  not attrs.tags.owner
  msg = sprintf("resource %v missing tags.owner", [rc.address])
}

deny[msg] {
  input.resource_changes[_] = rc
  rc.change.actions[_] != "delete"
  attrs := rc.change.after
  is_map(attrs.tags)
  not attrs.tags.environment
  msg = sprintf("resource %v missing tags.environment", [rc.address])
}

is_map(x) { x != null; type_name(x) == "object" }

**How to evaluate Terraform plan in CI to block merges**

- Generate plan in CI: `terraform plan -out=plan.binary && terraform show -json plan.binary > plan.json`.- Run OPA/Conftest: `conftest test --policy ./policy --input plan.json` or `opa eval --input plan.json --data policy.rego "data.terraform.tags.deny"`.- Fail the pipeline if any deny messages are returned (non-zero exit). For PRs, attach output to the merge check so reviewers see which resources violate tags.- Tips: run on feature branches, allow exceptions via a whitelisted tag or resource list, and include tests for the policy (unit tests with example plan.json files).

MediumSystem Design

34 practiced

Design a Terraform repository layout and module strategy to support multiple environments (dev, staging, prod) with different configurations such as CIDR ranges and instance sizes. Describe directory layout, how you would isolate state per environment, how to parameterize modules, and how you would promote tested changes from dev to prod safely.

Unlock Full Question Bank

Get access to hundreds of Infrastructure as Code and Configuration Management interview questions and detailed answers.

Join thousands of developers preparing for their dream job.