Sample questions
Terraform State Backend LockingDifficulty 1
What is the primary purpose of Terraform's state file?
- aIt stores a human-written changelog describing every manual edit made to cloud resources
- bIt stores a cached copy of the provider plugin binaries so they don't need to be re-downloaded
- cIt maps the resources declared in the configuration to the real-world objects Terraform created, along with their attributes✓
- dIt stores the Terraform CLI's own version history and update notifications
Explanation:The state file is Terraform's record of which real infrastructure objects correspond to which resource blocks in the configuration, plus their tracked attributes. Terraform uses this mapping to compute diffs on plan/apply. (a) is wrong because the state file is a machine-generated JSON record, not a manually maintained changelog.
Terraform State Backend LockingDifficulty 1
Why is it generally considered unsafe to hand-edit the terraform.tfstate JSON file directly?
- aTerraform CLI physically locks the file with read-only permissions, so a hand edit is technically impossible
- bA manual edit can easily produce an internally inconsistent state that no longer matches real infrastructure, causing unexpected plans✓
- cThe .tfstate file format is compiled binary, not JSON, so a text editor cannot open it at all
- dHand-editing the file automatically triggers a destroy of every resource listed in it
Explanation:The state file has an internal structure (resource addresses, dependency metadata, attribute values) that Terraform relies on being consistent; a manual edit can silently break that consistency, leading to incorrect plans or drift that's hard to diagnose. Terraform provides dedicated commands (state mv/rm/import) for safe modifications instead. (a) is wrong — nothing prevents opening the file in a text editor; the risk is logical, not a technical lock.
Terraform State Backend LockingDifficulty 1
What key problem does using a remote backend (e.g. S3, azurerm, GCS) solve compared to Terraform's default local state?
- aIt lets a team share a single, centrally-stored state file instead of each engineer having their own local copy that can go out of sync✓
- bIt removes the need for Terraform to track any resource attributes at all
- cIt automatically rewrites the .tf configuration files to match whatever exists in the cloud
- dIt makes 'terraform plan' unnecessary since the backend applies changes on its own schedule
Explanation:By default, Terraform writes state to a local terraform.tfstate file. A remote backend stores that same state centrally so every team member and CI job reads/writes the same source of truth, avoiding divergent local copies. (b) is wrong — the backend still stores the same resource-attribute mapping, it just changes where that data lives.
Terraform State Backend LockingDifficulty 1
In an S3-backed Terraform setup, what has historically been the role of a DynamoDB table alongside the S3 bucket?
- aIt stores a full duplicate copy of the state file as a backup, unrelated to any locking mechanism
- bIt stores the provider plugin binaries so 'terraform init' doesn't re-download them
- cIt stores the Terraform CLI's authentication credentials for the AWS provider
- dIt provides state locking by holding a lock record while an operation runs✓
Explanation:S3 itself is an object store without a built-in mechanism to coordinate concurrent writers, so a DynamoDB table has traditionally been paired with it to hold a lock item during plan/apply, ensuring only one operation modifies the state at a time. (a) is wrong — the table holds a small lock record, not a duplicate of the entire state file.
Terraform State Backend LockingDifficulty 2
What problem does state locking prevent?
- aIt prevents a resource from ever being destroyed, regardless of configuration changes
- bIt prevents two concurrent Terraform operations from reading and writing the same state file at the same time, which could corrupt it✓
- cIt prevents the provider from making any API calls to the cloud platform
- dIt prevents engineers from viewing the state file's contents entirely
Explanation:State locking serializes access: while one operation (plan/apply) holds the lock, another concurrent operation targeting the same state is blocked from starting, which avoids two processes writing conflicting updates to the same state file. (a) is wrong — locking is about coordinating access to the state file, not about blocking destroy operations on resources.
Terraform State Backend LockingDifficulty 2
An engineer runs 'terraform apply' while a colleague's apply against the same remote state is already in progress and holding the lock. What is the expected default behavior?
- aBoth applies proceed simultaneously and Terraform automatically merges the two resulting states
- bThe second apply silently overwrites the first engineer's in-progress changes without any warning
- cThe second apply fails or waits, reporting that the state is locked by another operation✓
- dTerraform deletes the existing lock automatically so the newest command always wins
Explanation:Terraform's default behavior on encountering an active lock is to report the lock (who holds it, when it was created) and either wait or error out, rather than proceeding — this is exactly the coordination locking is meant to provide. (a) is wrong — Terraform has no state-merging capability for concurrent runs; that is precisely the corruption scenario locking prevents.