Infrastructure as Code (IaC)

Answer Strategy

Structure the answer using a phased approach (immediate, week 1-2, week 3-4). Demonstrate prioritization of risk mitigation before optimization. Sample: 'Day 1: Immediately migrate state to S3 backend with DynamoDB locking and enable versioning-this is the highest-risk item. Week 1: Extract hardcoded values into `variables.tf` with `.tfvars` per environment, introduce basic directory structure separating environments. Week 2: Implement a CI pipeline with `terraform validate`, `tflint`, and `plan` on PRs with manual `apply` approval. Week 3-4: Begin modularizing the monolith by extracting logical groupings (networking, compute, data) into modules. Key principle: don't refactor everything simultaneously-each change should be a safe, reviewable PR.'

Answer Strategy

Tests understanding of preventive controls, blast radius management, and incident response. Sample: 'Prevention: Implement `prevent_destroy` lifecycle meta-arguments on critical resources, configure IAM policies denying destroy actions on production, require two-person approval via Atlantis/Spacelift with production workspaces, and use `terraform plan -target` restrictions. Architecture: Separate state files per environment and per blast radius-networking, database, and application layers in distinct state files so a destroy cannot cascade. Response: Immediately halt any in-progress operations, check if state file shows resources as destroyed but AWS shows them existing (destroy failed partway). If resources are gone, run `terraform apply` from the last known-good commit to recreate. AWS-specific: RDS has automated backups with point-in-time recovery, S3 has versioning, EBS snapshots provide recovery points. Conduct blameless postmortem and add preventive guardrails.'

Answer Strategy

Tests depth of HCL knowledge and practical experience. Sample: '`count` is index-based (0, 1, 2...) and is used for simple replication-e.g., `count = var.instance_count`. Pitfall: removing the middle item causes recreation of all subsequent resources due to index shift. `for_each` is key-based using a map or set-e.g., `for_each = var.subnets` where each subnet has a stable key. Resources are tracked by key, so adding/removing one subnet doesn't affect others. Always prefer `for_each` over `count` when items have natural identifiers. Dynamic blocks are used *within* a resource to generate repeatable nested configuration blocks (like ingress rules, DNS records) from a collection. Use when the number of nested blocks varies. Pitfall: overusing dynamic blocks reduces readability-sometimes explicit blocks are clearer for 2-3 instances.'

Answer Strategy

Tests architectural thinking and abstraction design. Sample: 'Use a three-layer architecture. Layer 1: Provider-agnostic modules defining logical components (compute-cluster, object-storage, managed-database) with standardized inputs/outputs. Layer 2: Provider-specific implementations-`modules/compute-cluster/aws` uses EC2/ECS, `modules/compute-cluster/gcp` uses GCE/GKE-each satisfying the same interface contract. Layer 3: Environment compositions that select providers. Use Terraform workspaces or directory-based separation per environment. For shared concerns (DNS, IAM federation), create cross-provider modules. Alternatively, consider Pulumi with component resources that abstract provider differences in a real programming language, giving you if/else logic and interfaces. The key principle: abstract the *what* (logical architecture) from the *how* (provider-specific implementation).'