Title: Quiz 13 — Infrastructure as Code with Terraform
Course: AIINFRA 101: Applied Infrastructure & Containerization > Section: Week 13 — Infrastructure as Code with Terraform

Q: Which of the following best describes Terraform's approach to configuration?
- Imperative — you write the exact sequence of commands to run
- Declarative — you describe the desired end state and Terraform determines the steps
- Object-oriented — you define classes representing infrastructure
- Event-driven — infrastructure changes in response to triggers
A: Declarative — you describe the desired end state and Terraform determines the steps

Q: In Terraform, a "provider" is the file that stores the current mapping between your configuration and real infrastructure.
- True
- False
A: False

Q: What is the Terraform state file's role in determining what changes to make during terraform plan or terraform apply?
Feedback: Sample/expected answer: The state file is Terraform's source of truth mapping configuration to real infrastructure; Terraform compares it against the current `.tf` configuration to compute the minimal diff of what to create, change, or destroy.

Q: What is the correct order of the core Terraform workflow?
Feedback: Sample/expected answer: terraform plan → terraform init

Q: Local Terraform state (a .tfstate file on one person's laptop) scales fine for team projects with multiple people running terraform apply.
- True
- False
A: False

Q: Explain what configuration/state drift is and give one example of how it can happen.
Feedback: Sample/expected answer: Drift is when Terraform's state file becomes out of sync with the real infrastructure, typically because someone made a manual change outside Terraform — for example, resizing an EC2 instance in the AWS console or scaling a Kubernetes Deployment with `kubectl` — without updating the Terraform code. Terraform doesn't detect this automatically; it only notices on the next `plan`.

Q: Why do teams commonly use a remote backend such as S3+DynamoDB, GCS, or Terraform Cloud for state?
- It makes HCL syntax easier to write
- It centralizes state storage, provides locking so only one apply runs at a time, and keeps a version history
- It eliminates the need for `terraform plan`
- It automatically resolves all configuration drift
A: It centralizes state storage, provides locking so only one apply runs at a time, and keeps a version history

Q: Why should secrets never be hardcoded into Terraform .tf files or .tfvars variable files?
- Terraform will refuse to run if it detects a secret in a file
- Those files typically live in version control, exposing the secret in history even after deletion
- `.tf` files have a strict character limit that excludes secret values
- Terraform automatically encrypts all `.tf` file contents, so this concern doesn't apply
A: Those files typically live in version control, exposing the secret in history even after deletion