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

31 practiced

Provide a Terraform HCL snippet that provisions an AWS EC2 instance using a data source to fetch the latest Amazon Linux 2 AMI, creates a security group allowing SSH from a variable CIDR block, and tags both the instance and security group. Assume provider credentials are configured; keep the snippet minimal and clear.

Sample Answer

**Approach**Use the aws_ami data source to find the latest Amazon Linux 2 AMI, a variable for the allowed SSH CIDR, create a security group that allows SSH from that CIDR, and launch an EC2 instance with tags applied to both resources.

hcl

# variables
variable "ssh_cidr" {
  type    = string
  default = "203.0.113.0/24"
}
variable "instance_type" {
  type    = string
  default = "t3.micro"
}
variable "common_tags" {
  type = map(string)
  default = { Environment = "dev"  Owner = "cloud-team" }
}

# data source: latest Amazon Linux 2 AMI
data "aws_ami" "amazon_linux_2" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# security group allowing SSH from variable CIDR
resource "aws_security_group" "ssh_sg" {
  name        = "ssh-from-variable-cidr"
  description = "Allow SSH from configured CIDR"
  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [var.ssh_cidr]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = var.common_tags
}

# EC2 instance using the AMI and security group
resource "aws_instance" "example" {
  ami           = data.aws_ami.amazon_linux_2.id
  instance_type = var.instance_type
  vpc_security_group_ids = [aws_security_group.ssh_sg.id]
  tags = merge(var.common_tags, { Name = "example-instance" })
}

Key notes:- Keep credentials/providers configured separately.- Change ssh_cidr variable for stricter access.- For multi-AZ or hardened setups, consider custom AMIs, user_data, and IAM roles.

HardSystem Design

30 practiced

You are responsible for testing IaC at platform scale across 10k resources. Propose a testing strategy including linting, policy tests, unit/contract tests, integration tests, smoke tests, test data management, ephemeral environment provisioning, cost control, and how to parallelize tests in CI to obtain reasonable feedback times without excessive cloud spend.

Sample Answer

**Clarify goals & constraints**- Fast feedback (<15–30m), safety (no production drift), cost cap, coverage across 10k resources.

**High-level strategy**- Shift-left: lint + policy → unit/contract → integration/smoke on ephemeral infra → teardown.- Prioritize tests by risk/impact; run full expensive suite nightly.

**Linting & policy**- Pre-commit + CI pre-merge: tflint/terraform fmt/terraform validate, tfsec.- Policy as code: OPA/Conftest, Checkov, CFN-NAG; fail fast on security/compliance rules.

**Unit / contract tests**- Use Terratest/unit tests with mocking for modules; validate module inputs/outputs and interfaces.- Contract tests for shared modules: golden files, schema validation.

**Integration & smoke**- Local/emulated where possible (LocalStack, azurite, emulator for GCP).- For true cloud integration, provision minimal blueprints (module-level stacks) in ephemeral envs.

**Ephemeral envs & test data**- Use templated environment blueprints sized for tests (subset of resources), auto-created with prefixes/tags.- Test data: synthetic datasets stored in test buckets, seeded and isolated per run; use fixture teardown and unique IDs.

**Parallelization & CI**- Build dependency graph of modules; shard tests by independent modules/services.- Use job matrix: fast lint/policy/unit on every PR; split integration tests across parallel runners; use dynamic runner autoscaling.- Cache terraform init/plugins, use remote state per test env, and reuse pre-created VPCs/nat gateways to reduce time/cost.

**Cost control**- Small instance types, spot/low-priority VMs for tests; shared reusable infra (network, databases) with tenant isolation; auto-destroy after TTL; enforce org quotas and cost alerts.- Nightly full-run on larger ephemeral infra; otherwise run sampled/regression suites.

**Observability & guardrails**- Tagging, billing alerts, test dashboards, abort on cost thresholds.- Test telemetry: duration, cost per run, failure patterns -> shift tests lower/higher in pipeline.

**Trade-offs**- Emulation reduces cost/time but misses cloud-managed behavior; selective cloud runs needed.- Parallelization speeds feedback but increases short-term cost—mitigated with small instances, spot and shared infra.

Outcome: fast, safe feedback loop with layered tests that scale to 10k resources while capping spend via small blueprints, parallel sharding, reuse, and strict teardown.

EasyTechnical

26 practiced

What is configuration drift in cloud infrastructure and how does it typically occur? Give a concrete example of drift in AWS and describe methods for detecting drift across Terraform and CloudFormation managed resources, including native tools and community scanning approaches.

Sample Answer

**Definition & how it occurs**Configuration drift is when deployed cloud resources’ actual state diverges from the intended state defined in IaC (Terraform/CloudFormation). It usually occurs when manual changes are made in the console/CLI, out-of-band automation updates, partial/failed deployments, or configuration skew between environments.

**Concrete AWS example**You provision an RDS instance with Terraform specifying publicly_accessible = false. Later an engineer enables Publicly Accessible in the console for debugging. Terraform state still says false, so the live RDS is exposed — that is drift.

**Detecting drift — CloudFormation**- Native: aws cloudformation detect-stack-drift (CLI/Console) and DescribeStackDriftDetectionStatus. CloudFormation reports which resource properties differ. - Limitations: only resources supported by CFN drift detection and it only checks while detection runs.

**Detecting drift — Terraform**- Native: terraform plan (refreshes state by default) will show differences between real resources and state. terraform refresh / terraform show -json / terraform state pull help inspect discrepancies.- Limitations: plan only compares Terraform state vs provider; if state is stale or remote state not refreshed, you may miss drift.

**Complementary / community tools**- AWS Config: continuous monitoring + rules to flag noncompliance and trigger remediation (good for cross-IaC coverage). - driftctl (bridge between IaC and cloud): detects drift across many AWS resources and maps to Terraform resources; can run in CI. - Cloud Custodian: policy-as-code to detect and remediate policy drift. - Additional scanners: tfsec/terrascan (security drift detection), custom lambda/scan runners.

**Operational best practices**- Enforce IaC-only changes via RBAC and guardrails, run automated drift scans (driftctl/AWS Config) on schedule, block console edits with IAM or Service Control Policies, and include remediation in CI/CD pipelines (auto-apply or alert + PR).

MediumTechnical

30 practiced

Write a Conftest or OPA Rego policy that enforces a required tag 'cost-center' on AWS EC2 and S3 resources in a Terraform plan. Describe how you would integrate this policy into a CI pipeline so that failed policy checks block merges or deployments, and how you would provide a mechanism for approved exceptions.

Sample Answer

**Approach (brief)**Write an OPA/Rego policy that inspects Terraform plan JSON for aws_instance, aws_s3_bucket (and aws_s3_bucket_public_access_block if needed) and requires a tag/key "cost-center". Provide an exception mechanism via a Terraform resource tag "policy-exception" or a central allowlist file. Integrate Conftest/OPA into CI to fail the pipeline on violations.

**Rego policy (conftest/opa)**

rego

package terraform.tagging

# Entry: resources come from `conftest test --policy . plan.json`
required_tag = "cost-center"
exception_tag = "policy-exception"

deny[msg] {
  input.planned_values.root_module.resources[_] as r
  is_target_resource(r)
  not has_required_tag(r)
  not is_exceptioned(r)
  msg = sprintf("Resource %v/%v missing '%v' tag", [r.type, r.name, required_tag])
}

is_target_resource(r) {
  r.type == "aws_instance"
} 
is_target_resource(r) {
  r.type == "aws_s3_bucket"
}

has_required_tag(r) {
  tags := r.values.tags
  tags != null
  tags[required_tag]
}

is_exceptioned(r) {
  tags := r.values.tags
  tags != null
  tags[exception_tag] == "true"
}

**CI integration**- Step 1: terraform plan -out=plan.binary && terraform show -json plan.binary > plan.json- Step 2: conftest test --policy ./policy_dir plan.json- Configure CI (GitHub Actions/GitLab) to mark job as required for PR merges; any non-zero exit fails merge.- Provide clear failure message and link to docs.

**Approved exceptions**- Short-lived exception via resource tag `policy-exception = "true"` (requires justification in PR description).- Central allowlist: store exceptions in a repo file (exceptions.json) and import it into Rego (allowlist lookup).- Governance: require approver group to approve exceptions; CI can validate PR has associated JIRA/ticket ID.

**Notes & best practices**- Test policy locally with sample plan.json.- Log violation counts, surface in PR comment via CI bot.- Periodically audit exceptions file and enforce TTL.

MediumSystem Design

29 practiced

Design a reusable Terraform module for an AWS VPC that supports N availability zones, public and private subnets, optional NAT gateways, flow logs, route tables, and outputs required by downstream modules (private_subnet_ids, public_subnet_ids, route_table_ids). Describe the module interface: inputs, outputs, versioning strategy, and how you would test and document the module for team reuse.

Sample Answer

**Overview**Design a reusable Terraform AWS VPC module that creates a VPC across N AZs, public/private subnets, optional NAT gateways, flow logs, route tables, and exports IDs consumed by downstream modules.

**Module inputs (key)**- vpc_name (string)- cidr_block (string)- azs (list(string)) — length N- public_subnet_cidrs (list(string)) — optional, or auto-slice from cidr_block- private_subnet_cidrs (list(string))- enable_nat (bool, default = true)- nat_gateway_strategy (string: "one-per-az" | "single" | "none")- enable_flow_logs (bool)- flow_log_destination_arn (string, optional)- tags (map)- enable_dns_hostnames, enable_dns_support (bools)

Example variable snippet:

hcl

variable "azs" { type = list(string) }
variable "nat_gateway_strategy" { type = string, default = "one-per-az" }

**Resources & responsibilities**- aws_vpc, aws_subnet (public/private per AZ), aws_internet_gateway- aws_eip & aws_nat_gateway (per strategy)- aws_route_table + aws_route_table_association (public routes to IGW; private to NAT)- aws_flow_log when enabled (to CloudWatch / S3 via destination ARN)- outputs: private_subnet_ids, public_subnet_ids, route_table_ids, vpc_id, nat_gateway_ids

Example outputs:

hcl

output "private_subnet_ids" { value = aws_subnet.private[*].id }
output "public_subnet_ids"  { value = aws_subnet.public[*].id }
output "route_table_ids"   { value = concat(aws_route_table.public[*].id, aws_route_table.private[*].id) }

**Versioning strategy**- Use semantic versioning (vMAJOR.MINOR.PATCH).- Tag releases in VCS and publish module to private registry / Terraform Registry.- Backwards-incompatible changes bump MAJOR; additions/bugfixes bump MINOR/PATCH.- Maintain CHANGELOG and migration notes for MAJOR bumps.

**Testing**- Unit: terraform validate, tflint, checkov.- Integration: Terratest (Go) or kitchen-terraform to deploy in a sandbox AWS account, verify expected resources, subnets per AZ, NAT behavior, flow logs exist, route tables correct.- CI pipeline: run plan in PR, run tests against ephemeral account, run policy checks.

**Documentation**- README with: purpose, inputs table (required/default), outputs table, examples for common strategies (multi-AZ with single NAT vs one-per-AZ), upgrade/migration notes, testing instructions, IAM permissions required.- Provide example usage snippet and minimal example repo referencing a released module version:

hcl

module "vpc" {
  source = "git::ssh://git@.../modules/vpc.git?ref=v1.2.0"
  vpc_name = "prod-vpc"
  cidr_block = "10.0.0.0/16"
  azs = ["us-east-1a","us-east-1b"]
  nat_gateway_strategy = "one-per-az"
}

**Operational notes / trade-offs**- Cost vs availability: one-per-az increases cost but improves AZ isolation.- Route table design: keep separate RTs per subnet group to allow custom routing later.- Security: default flow logs optional; recommend enabling in prod.

This design balances reusability, clear interface, testability, and operational guidance for team adoption.

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.