Infrastructure as Code Design and Modularity Questions

Deep expertise with Terraform, CloudFormation, or Pulumi at scale. Module design patterns, code organization across monorepos vs polyrepos, state management strategies, remote backends, workspaces, and dependency management. Version control strategies for infrastructure, handling breaking changes, and managing IaC across teams. DRY principles and reducing repetition across infrastructure definitions.

HardSystem Design

25 practiced

Design a multi-cloud IaC strategy that allows teams to target AWS and GCP using shared Terraform or Pulumi modules. Discuss abstraction layers, provider-specific implementations, testing matrices, handling feature divergence, and how to prevent accidental use of cloud-specific features in the shared layer.

Sample Answer

**Clarify requirements & goals**Support AWS + GCP with a single developer experience, enforce guardrails, allow provider-specific differentiation, enable CI testing and prevent leakage of provider-only features into shared modules.

**High-level abstraction**- Shared "core" API modules: define neutral primitives (network, compute, storage, iam-role, secret-store) expressed in provider-agnostic inputs (e.g., subnet_cidr, instance_type_hint, storage_class_abstract).- Provider adapters: small provider-specific modules that map core API to concrete resources (aws_vpc → aws_subnet/route_table, gcp_network → google_compute_network).- Composition layer: environment stacks composed of core + selected adapter.

**Provider-specific implementations**- Keep provider code isolated in /providers/aws and /providers/gcp. Expose only adapter functions/types to core.- In Pulumi use strongly-typed language wrappers; in Terraform use module interfaces and wrapper modules with variable schemas.

**Testing matrix**- Unit: local plan/diff via terraform validate/plan or pulumi preview for core and adapters.- Integration: CI matrix runs combinations: (core + aws adapter), (core + gcp adapter) across dev/stage/prod configs.- Contract tests: verify adapter outputs match core API contract (expected outputs/inputs).- Acceptance: apply to ephemeral accounts (sandbox projects) then run smoke tests and drift checks.

**Handling feature divergence**- Feature flags in core inputs (opt-in advanced features). Adapter returns explicit error if not supported.- When a cloud-specific capability is required, implement it in provider module and expose an explicit provider-only API; document clearly.

**Prevent accidental cloud-specific use**- Static checks: Terraform linter (tflint/custom rules) or Pulumi policy-as-code that forbid provider resource types in core modules.- Code review + PR templates requiring runtime plan/preview artifacts.- CI gating: reject merges if plan shows provider resources under core namespace or if contract tests fail.

This balances reuse, safety, and flexibility for a multi-cloud IaC strategy.

MediumTechnical

21 practiced

You are designing a monorepo layout for Terraform modules and environment overlays used by multiple teams. Propose a concrete directory structure, explain how CI should detect changes and run only affected plans, and outline access controls for protecting production state and variables.

Sample Answer

**Concrete directory structure**

**/terraform**- modules/ (reusable modules, versioned by tags) - network/ - compute/ - db/- envs/ - shared/ (cross-team shared infra: VPC, logging) - team-a/ - dev/ - main.tf, vars.tf - staging/ - prod/ - team-b/...- pipeline-scripts/ (helpers for CI)- docs/

**How CI detects changes & runs only affected plans**- Use git path filters in CI: on PR, run a changed-files job to list paths (git diff --name-only origin/main...HEAD).- Map changed paths to targets: - changes under modules/ -> run plans for all envs that reference the module (maintain a manifest or scan envs for module usage). - changes under envs/team-a/dev/* -> plan only that workspace.- CI flow: 1. Detect changed files. 2. Resolve affected workspaces (scan .tf files or manifest). 3. For each workspace: terraform init -backend-config=<env> && terraform plan. 4. Persist plan artifacts; require approvals for prod plans before apply.- Use a matrix job to parallelize per-workspace plans.

**Access controls & protecting production state/vars**- Remote state per environment in separate backends (e.g., S3 bucket per account + DynamoDB lock) or separate workspaces; enable server-side encryption.- State ACLs: S3 bucket policies + KMS key policies restrict access to CI service account and a small set of admins; deny delete unless MFA.- Secrets: store sensitive variables in a secrets manager (SSM Parameter Store + KMS, or Vault). Do not commit vars.tfvars to repo.- CI permissions: least-privilege IAM roles per pipeline: - PR pipelines: read-only access to state, plan-only; no apply. - Prod apply: assume a separate role requiring human approval (e.g., GitHub/GitLab protected branch + manual approval step) and MFA.- Audit & approvals: require code owners for prod changes, require manual approval in CI, enable CloudTrail/Stackdriver logging for all state and apply operations.

This layout balances reuse, targeted CI runs, and strict production protection while keeping developer workflows fast.

HardTechnical

22 practiced

Evaluate the use of Terragrunt to manage many Terraform modules and environments in a large organization. Discuss its advantages (DRY remote state config, common variable inheritance), known pitfalls (complex layering, slow execution, coupling), and operational mitigations to avoid locking and drift issues.

Sample Answer

**Summary / Context**As a Cloud Engineer I’ve used Terragrunt as a thin wrapper over Terraform to enforce DRY patterns across dozens of modules and multiple environments (dev/stage/prod). It’s useful where many teams share similar remote state, provider configs, and wrapper logic.

**Advantages**- DRY remote-state & provider config: centralize backend and provider blocks so modules don’t repeat S3/GCS/azurerm state config, KMS keys, or workspace naming.- Common variable inheritance: keep environment-level inputs, tagging, and lifecycle rules in one place using include/locals so module calls stay minimal.- Composition: promote reusable stacks by composing modules with consistent inputs, reducing human error.- Environment orchestration: terragrunt.hcl allows running same lifecycle ops across multiple stacks.

**Known pitfalls**- Complex layering: deep include/override trees become hard to reason about — unexpected inheritance can silently change inputs.- Coupling & implicit behavior: terragrunt can hide important details; teams may not realize remote-state or provider differences.- Performance: terragrunt run-all can be slow (many network calls, serial steps), and parallelism can hit provider/API limits.- Locking & drift: centralized state increases lock contention; long-running operations raise risk of drift if others apply concurrent changes.

**Operational mitigations**- Keep hierarchy shallow and document inheritance. Prefer explicit inputs for critical resources.- Use per-team/per-environment backends with clear naming to reduce contention; shard state by component.- Configure reasonable apply timeouts, shorter locks where supported, and avoid large monolithic applies — break into smaller stacks.- Use CI pipelines that run plan in parallel but gate applies through a single orchestrator (or leader election) to avoid concurrent applies.- Enable extensive automated drift detection: scheduled terraform plan/compare, Cloud native config rules (AWS Config, GCP Forseti), and alerting.- Cache provider plugins and use terragrunt options to control concurrency (--terragrunt-parallelism).- Add pre-apply checks: schema validation, policy-as-code (OPA/Conftest), and approve gates in CI.- Train teams on terragrunt idioms and run occasional audits of terragrunt.hcl to catch hidden overrides.

**Trade-offs**Terragrunt accelerates consistency and reuse but requires disciplined conventions, small state shards, and operational guardrails to avoid coupling, slow operations, and drift. In large orgs, evaluate alternatives (module registries, Terraform Cloud/Enterprise workspaces) and adopt the pattern that best fits scale and governance.

MediumTechnical

22 practiced

You find a lot of duplicated configuration across multiple Terraform stacks. Explain the trade-offs between extracting a shared module, using locals and variable maps, or generating configs via templating in CI. Which approach would you choose for high reuse with low runtime complexity?

Sample Answer

**Answer (direct, role: Cloud Engineer)**

**Clarify goal**- High reuse across stacks, minimal runtime complexity (i.e., simple plan/apply, minimal preprocessing).

**Options & trade-offs**- Shared Terraform module - Pros: Encapsulates resources, inputs/outputs, versioned in registry/git; strong lifecycle and state isolation; easy to test and review. - Cons: Requires thoughtful API design; breaking changes require versioning.- Locals + variable maps per-stack - Pros: Quick to implement for small variations; no external package/versioning. - Cons: Duplicates logic across stacks, harder to enforce consistency, can become messy as permutations grow.- CI templating (generate configs) - Pros: Powerful for heavy customization; can produce simplified per-stack code. - Cons: Adds build-step complexity, debugging harder (generated code vs source), risk of drift and unreviewed changes.

**Recommendation**- Use a well-designed, versioned shared Terraform module for core reusable pieces. For small per-stack variations, accept maps/objects as module inputs and use locals inside the module to keep runtime complexity low.- Reserve CI templating only when configuration must be generated dynamically or when multiple providers/environments need structural changes that modules can’t express.

**Example module usage**

hcl

module "vpc" {
  source      = "git::ssh://git@repo/modules/vpc.git?ref=v1.2.0"
  name        = var.name
  cidr_blocks = var.environment == "prod" ? ["10.0.0.0/16"] : ["10.1.0.0/16"]
  tags        = var.tags
}

This gives strong reuse, clear versioning, and low runtime complexity.

EasyTechnical

22 practiced

Describe what information Terraform stores inside state files and why the state file is critical for plan and apply operations. Explain how state influences idempotency, resource targeting, and the ability to import existing resources.

Unlock Full Question Bank

Get access to hundreds of Infrastructure as Code Design and Modularity interview questions and detailed answers.

Join thousands of developers preparing for their dream job.