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.

HardTechnical

21 practiced

Describe patterns for creating cross-account resources in AWS (e.g., IAM roles in central account assumed by services in consumer accounts) using Terraform modules while avoiding circular dependencies and state-spaghetti. Include an example composition pattern.

Sample Answer

**Approach (summary)** Create one-way, clearly ordered deployments: a central IAM-role module that owns cross-account roles and exposes outputs; consumer/account modules that consume those outputs (via remote state, data lookup, or an orchestration root) but never try to create or modify the same resources. That prevents circular dependencies and “state spaghetti.” Use least-privilege trust policies, optional external IDs, and explicit versioned deployment order.

**Pattern / composition**- central-account module: creates iam_role + inline policies; outputs role_arn, role_name- publish outputs: Terraform remote state (S3 backend with locking) or a parameter in SSM / Secrets Manager- consumer-account module: reads central outputs (terraform_remote_state or data.aws_ssm_parameter) and uses them in configs (e.g., tasks assume role ARN or add permissions locally)- Orchestration/root: deploy central first, then consumers. CI pipeline enforces ordering.

**Why this avoids circular deps**- Only central writes the role resource/state. Consumers read immutable outputs. No module writes the same resource. Remote-state or SSM is a read-only dependency, so graph stays acyclic.

**Example central module (snippet)**

hcl

# modules/central-iam/main.tf
resource "aws_iam_role" "cross_account_role" {
  name = var.role_name
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { AWS = "arn:aws:iam::${var.consumer_account_id}:root" }
      Action = "sts:AssumeRole"
      Condition = var.require_external_id ? { StringEquals = { "sts:ExternalId" = var.external_id } } : null
    }]
  })
}
output "role_arn" { value = aws_iam_role.cross_account_role.arn }

**Consumer usage (reads remote state)**

hcl

data "terraform_remote_state" "central" {
  backend = "s3"
  config = { bucket = "central-iam-state", key = "central.tfstate", region = "us-east-1" }
}
# Use data.terraform_remote_state.central.outputs.role_arn where needed (e.g., ECS task assume role)

**Best practices & trade-offs**- Prefer remote-state or SSM over resource-level data sources to decouple state. Remote-state centralizes outputs; SSM avoids tight Terraform backend coupling.- Add CI gating: central deployment pipeline publishes outputs, consumers trigger after success.- Use AWS Organizations/OIDC and conditions (SourceAccount, ExternalId) to reduce risk.- Alternative: have consumers create their own roles and central publishes managed policies — useful if many consumers need unique principals.

This pattern enforces single ownership, clear read-only consumption, pipeline-ordered deployments, and minimal trust surface — preventing circular references and state entanglement.

EasyTechnical

22 practiced

Design a small reusable Terraform module (in HCL) for applying standard tags to AWS resources. The module should accept a map of custom tags and merge them with required organizational tags. Show the inputs, outputs, and a short example of how a consumer uses it.

Sample Answer

**Approach**Provide a minimal reusable Terraform module that: accepts a map of custom tags, merges with required org tags (immutable keys like "Company" and "Environment"), and exposes the merged map for resource usage.

**Module: files (modules/tags/)**

variables.tf

hcl

variable "custom_tags" {
  description = "User-supplied tags to merge with org tags"
  type        = map(string)
  default     = {}
}

variable "environment" {
  description = "Deployment environment (used for org tag)"
  type        = string
}

main.tf

hcl

locals {
  org_tags = {
    Company     = "AcmeCorp"
    Environment = var.environment
  }

  merged_tags = merge(local.org_tags, var.custom_tags)
}

outputs.tf

hcl

output "tags" {
  description = "Merged tags combining org and custom tags. Org tags take precedence."
  value       = local.merged_tags
}

**Usage example**

hcl

module "tags" {
  source      = "../modules/tags"
  environment = "prod"
  custom_tags = {
    Owner = "team-foo"
    CostCenter = "CC123"
    Environment = "should-be-ignored"
  }
}

resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
  tags   = module.tags.tags
}

**Notes**- merge() makes custom tags override org tags; to ensure org precedence swap order or use a function that preserves org keys.- Validate required keys with validation blocks if needed.

HardTechnical

23 practiced

Draft a comprehensive disaster recovery plan for the scenario where all Terraform state backends are corrupted or deleted for multiple critical environments. Include preconditions, recovery steps (including state reconstruction), verification, and improvements to prevent recurrence.

Sample Answer

**Situation & Preconditions**- All remote Terraform state backends (S3/GCS/AzureBlob/Consul) for prod, staging, qa are corrupted/deleted. No up-to-date remote state accessible. CI/CD pipelines fail. Team access to cloud console, VCS, and runners exists. Backups may exist (S3 object versioning, GCS object versions, Vault copies, local developer .tfstate files).

**Immediate Recovery Steps**1. Isolate risk and communicate incident to stakeholders.2. Snapshot current infrastructure (cloud provider console) — list resources, tags, IPs, ARNs.3. Collect all possible state artifacts: - Object store versions - CI job artifacts - Local .tfstate files from engineers - Terraform Enterprise/Cloud runs and plan outputs4. Reconstruct state per environment: - Create a scratch workspace and import resources individually into Terraform using resource addresses. - Example import pattern:

bash

# import an EC2 instance into module.aws_instance.example
terraform init
terraform import module.web.aws_instance.instance i-0123456789abcdef0
terraform state rm <stale>

- Use `terraform state list`/`show` to verify each import.5. Recreate remote backend with proper access, enable versioning and encryption.

**Verification**- Run `terraform plan` in a read-only mode and ensure zero-drift against live infra.- Run integration smoke tests and CI deploy dry-runs.- Cross-check resource counts, tags, subnets, IPs.

**Postmortem & Improvements**- Enable immutable, automated backups: S3/GCS versioning + lifecycle to separate archive bucket, weekly offsite backups.- Store encrypted state snapshots in a separate vault/repo (access-controlled).- Enforce Terraform Cloud/Enterprise with workspace locking, run history.- Automate periodic drift detection and state export to VCS via CI.- Document recovery runbook and run tabletop exercises quarterly.- Limit who can delete backend buckets with IAM and SCPs; enable MFA delete where available.

Outcome: restored consistent state, verified plans produce no destructive changes, and preventative controls to avoid recurrence.

MediumTechnical

43 practiced

Describe strategies for managing dependencies between Terraform modules without creating brittle cross-module coupling. Discuss the use of outputs, data sources, remote state data, and orchestration tools, and trade-offs for each approach.

MediumTechnical

24 practiced

Compare using Terragrunt, Terraform Cloud workspaces, and composing pure Terraform modules for orchestrating layered deployments. Discuss maintainability, coupling, dependency management, and ease of onboarding for teams.

Sample Answer

**Approach summary** As a DevOps engineer I compare three patterns by how they scale, how tightly they couple environments, how dependencies are expressed, and how easy new team members can pick them up.

**Terragrunt** - Maintainability: High when using DRY patterns (include/locals), but can become hard to reason about if overused dynamic logic. - Coupling: Encourages layer-by-layer directories (live/*) so environments are explicit — moderate coupling via remote state references. - Dependency management: Built-in `dependencies` and remote state fetch make expressing linear DAGs easy. - Onboarding: Requires learning Terragrunt config and CLI; clear repo layout helps new hires.

**Terraform Cloud Workspaces** - Maintainability: Good for centralizing runs, policies (Sentinel), and state. Simpler configs per workspace. - Coupling: Workspaces can be loosely coupled; however, cross-workspace dependencies require remote state or run triggers, adding operational coordination. - Dependency management: Relies on workspace variables, run triggers, or tf remote state; less native than Terragrunt for DAGs. - Onboarding: Easier — UI and VCS integration reduce local tooling needs.

**Composing Pure Terraform Modules** - Maintainability: Modules are portable and testable; top-level orchestration can become repetitive without tooling. - Coupling: Low-level modules are loosely coupled; orchestration code (root modules) can introduce tight coupling if not designed well. - Dependency management: Uses outputs/inputs and data sources; no orchestration primitives — you must design the DAG in CI/CD. - Onboarding: Familiar Terraform only — shallow learning curve, but operational patterns must be documented.

**Recommendation** - For teams needing explicit DAGs and remote-state chaining: Terragrunt. - For teams wanting managed runs, policy, and minimal tooling: Terraform Cloud Workspaces. - For library-first, portable infra and strong module testing: pure Terraform modules combined with CI orchestration.

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.