Q: When architecting infrastructure for high-growth enterprise platforms, how do you decide between Terraform (or OpenTofu) and native AWS CloudFormation / AWS CDK? In a senior/staff interview, explain how each handles state management, resource drift, stack rollbacks, and provider lifecycle under high-concurrency CI/CD.

Terraform relies on an explicit state machine (typically backed by S3 with DynamoDB state locking or HCP Terraform). The execution client constructs the dependency directed acyclic graph (DAG) locally and issues granular API calls. If a plan crashes or a provider times out, locks can persist, but the entire state graph is transparent and inspectable. Conversely, CloudFormation is a fully managed, serverless convergence engine hosted within AWS control planes. There is no state file to leak secrets or corrupt; AWS handles state convergence behind its management API. However, diagnosing hung stack states (such as UPDATE_ROLLBACK_FAILED) requires manual out-of-band resource surgery or ContinueUpdateRollback skip flags.

# Terraform state manipulation for surgical drift recovery
terraform state rm aws_security_group_rule.legacy_allow
terraform import aws_security_group_rule.legacy_allow sgr-0123456789abcdef

# CloudFormation rollback override via AWS CLI
aws cloudformation continue-update-rollback \
  --stack-name prod-vpc-stack \
  --resources-to-skip SecurityGroupIngressRule

Terraform computes diffs by refreshing state against live cloud provider APIs via GET calls on every execution. In modern GitOps pipelines, teams schedule headless `terraform plan -refresh-only -detailed-exitcode` checks to detect unauthorized drift before deployment. CloudFormation supports on-demand drift detection across supported resource types, but does not natively prevent subsequent stack updates from overwriting manual hotfixes unless operators inspect and execute CloudFormation Change Sets.

# Terraform headless drift scan in CI/CD
terraform plan -refresh-only -detailed-exitcode
# Exit code 0 = No drift, 2 = Drift detected, 1 = Error

# AWS CloudFormation CLI drift execution
aws cloudformation detect-stack-drift --stack-name prod-eks-cluster
aws cloudformation describe-stack-drift-detection-status --stack-drift-detection-id <id>

Terraform employs HashiCorp Configuration Language (HCL2)—a declarative, domain-specific language designed for strict static analysis, immutability, and deterministic graph validation. AWS CDK empowers developers to utilize familiar programming languages (TypeScript, Python, Go, Java), synthesizing code into raw CloudFormation JSON/YAML. CDK offers superior abstraction ergonomics via L2/L3 constructs (e.g., provisioning an enterprise VPC with subnets and NAT gateways in under 10 lines of TypeScript). However, CDK introduces non-deterministic programming risks (unbounded loops, arbitrary external HTTP calls during synthesis, unversioned npm dependency churn) into infrastructure definitions.

// AWS CDK (TypeScript) High-Level L2 Construct
import * as ec2 from 'aws-cdk-lib/aws-ec2';

export class NetworkStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    new ec2.Vpc(this, 'ProdVPC', {
      maxAzs: 3,
      natGateways: 2,
      ipAddresses: ec2.IpAddresses.cidr('10.100.0.0/16')
    });
  }
}

CloudFormation updates are transactional by default: if 1 of 50 resources fails to provision, CloudFormation automatically initiates a complete rollback to the prior known-good stack state. While this guarantees transactional purity, complex rollbacks on persistent resources (RDS clusters, EFS volumes, KMS keys) can deadlock if deletion policies or dynamic dependencies fail. Terraform does not automatically roll back on failure; it halts execution at the failing node, saves successfully created resources to state, and allows operators to remediate forward incrementally.