A cloud architect is creating a Terraform configuration to deploy resources in AWS. The architect needs to store the state file in a remote backend that supports state locking and encryption at rest. Which backend should the architect configure?
Trap 1: Local file system with Terraform Cloud
A local file system stores state on the architect's machine, providing no remote sharing, no locking for concurrent runs and no server-side encryption at rest. It is tempting for simple single-operator setups, but it would be correct only for local experimentation, not a team AWS deployment requiring remote locking and encryption.
Trap 2: Azure Blob Storage with a lease blob for locking
Azure Blob is for Azure, not AWS.
Trap 3: Google Cloud Storage with object versioning
Google Cloud Storage's gcs backend supports encryption at rest but does not provide native state locking, relying instead on object versioning for consistency. It is tempting because versioning appears to guard concurrent writes, but it would be correct for Terraform managing GCP resources where locking is handled differently.
- A
Local file system with Terraform Cloud
Why it fails: A local file system stores state on the architect's machine, providing no remote sharing, no locking for concurrent runs and no server-side encryption at rest. It is tempting for simple single-operator setups, but it would be correct only for local experimentation, not a team AWS deployment requiring remote locking and encryption.
- B
S3 with DynamoDB for state locking
S3 with DynamoDB satisfies both constraints: S3 provides server-side encryption at rest for the state file, while DynamoDB supplies the conditional-write locking mechanism Terraform requires to prevent concurrent state modifications. Native S3 locking via `use_lockfile` exists, but DynamoDB remains the established, exam-recognised pairing for state locking.
- C
Azure Blob Storage with a lease blob for locking
Why it fails: Azure Blob is for Azure, not AWS.
- D
Google Cloud Storage with object versioning
Why it fails: Google Cloud Storage's gcs backend supports encryption at rest but does not provide native state locking, relying instead on object versioning for consistency. It is tempting because versioning appears to guard concurrent writes, but it would be correct for Terraform managing GCP resources where locking is handled differently.