How do you manage secrets within IaC configurations?

WHAT THIS TESTS: This question probes whether you understand that Infrastructure as Code is fundamentally code that gets executed, which means secrets embedded in it create a persistent attack surface across version history, state files, and execution logs. The interviewer is looking for awareness of the secret lifecycle: generation, distribution, rotation, revocation, and auditing. They also want to see that you treat CI/CD pipelines and orchestrators as untrusted boundaries rather than safe zones for plaintext credentials.

A GOOD ANSWER COVERS: First, contrast a dedicated secrets manager such as AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault against encrypted files in version control like SOPS or git-crypt. For the secrets manager, note the pros of automatic rotation, fine-grained IAM policies, centralized audit logs, and dynamic secrets that expire; note the cons of network dependency, cost, and operational overhead. For encrypted files in Git, note the pros of simplicity and git-native versioning; note the cons of key distribution challenges, risk of key leakage, and difficulty of fine-grained revocation. Second, treat environment variables as runtime injection only, not storage, since they leak in process listings and crash reports. Third, address IaC state files, since Terraform and Pulumi can store secrets in plaintext state unless remote backends encrypt at rest and enforce strict IAM. Fourth, discuss runtime injection via init containers, sidecars, or CI/CD references that fetch credentials at deploy time rather than baking them into images.

COMMON WRONG ANSWERS: Storing plaintext secrets in Git, Terraform variables files, or Docker images. Treating environment variables as a secure vault rather than a transport layer. Ignoring Terraform state file security entirely. Proposing manual secret rotation without automation. Claiming that private repositories are sufficient protection. Failing to mention that logs and crash dumps can capture secrets if they are passed as command-line arguments or plain text outputs.

LIKELY FOLLOW-UPS: How would you rotate a database credential without causing an outage? What is your strategy if your Terraform state file already contains a plaintext secret? How do you handle secrets in a multi-cloud or hybrid environment? What is the blast radius if your CI/CD runner is compromised, and how does your design limit it? How do you audit which human or service accessed a secret and when?

ONE CONCRETE EXAMPLE: Suppose you are deploying an Amazon RDS instance with Terraform. Instead of putting the master password in a terraform.tfvars file, you store it in AWS Secrets Manager with automatic rotation enabled via a Lambda function. Your Terraform configuration references the secret ARN, not the value, and retrieves it through a data source at apply time. The Terraform remote state backend lives in an S3 bucket with server-side encryption and a strict bucket policy denying all but the deployment role. Application pods in EKS retrieve the same secret at startup via the Secrets Store CSI Driver, so the credential never lives in the container image or the manifest in Git. If the secret rotates, the next pod restart picks up the new value without a code change, and AWS CloudTrail logs every retrieval for audit.