State encryption at rest in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Enable encryption for Terraform state in AWS S3 backend

You want to ensure your Terraform state file stored in an AWS S3 bucket is encrypted at rest using AWS-managed keys. Which backend configuration snippet correctly enables this?

A

backend "s3" {
  bucket = "my-terraform-state"
  key    = "state.tfstate"
  region = "us-east-1"
  server_side_encryption = "AES256"
}

B

backend "s3" {
  bucket = "my-terraform-state"
  key    = "state.tfstate"
  region = "us-east-1"
  sse_algorithm = "AES256"
}

C

backend "s3" {
  bucket = "my-terraform-state"
  key    = "state.tfstate"
  region = "us-east-1"
  encrypt = true
}

D

backend "s3" {
  bucket = "my-terraform-state"
  key    = "state.tfstate"
  region = "us-east-1"
  server_side_encryption = true
}

💡 Hint

Look for the correct attribute name and value to enable AWS S3 server-side encryption with AWS-managed keys.

In Terraform's S3 backend, the correct attribute to enable server-side encryption with AWS-managed keys is encrypt = true. The attribute server_side_encryption is not valid for the S3 backend configuration. The attribute sse_algorithm does not exist. Setting server_side_encryption to true is invalid because it expects a boolean.

❓ Architecture

intermediate

Choosing backend for encrypted Terraform state storage

You want to store Terraform state securely with encryption at rest and easy team access. Which backend choice best meets these requirements?

A Use S3 backend with server-side encryption enabled and DynamoDB for state locking.

B Use HTTP backend with a custom server that encrypts state files before saving.

C Use Terraform Cloud remote backend without additional encryption configuration.

D Use local backend storing state on your laptop's disk with filesystem encryption enabled.

💡 Hint

Consider managed services that provide encryption and locking out of the box.

The S3 backend with server-side encryption enabled ensures state files are encrypted at rest. Using DynamoDB for state locking prevents concurrent modifications. Local backend depends on your laptop's security and is not suitable for team access. HTTP backend requires custom setup and is less secure. Terraform Cloud encrypts state at rest by default but may require paid plans for team features.

❓ security

advanced

Impact of disabling encryption on Terraform state in S3

What is the most likely outcome if you disable server-side encryption on an existing S3 bucket storing Terraform state files?

A New state files will be stored unencrypted, exposing sensitive data at rest.

B S3 will automatically encrypt all objects regardless of bucket settings.

C Terraform will refuse to write state files due to missing encryption settings.

D Terraform state files will remain encrypted because existing objects keep their encryption metadata.

💡 Hint

Think about how S3 encryption settings affect new and existing objects.

Disabling server-side encryption on the bucket means new objects uploaded will not be encrypted unless specified. Existing objects remain encrypted until overwritten. Terraform will not refuse writes due to encryption settings. S3 does not automatically encrypt objects if encryption is disabled.

❓ service_behavior

advanced

Behavior of Terraform state encryption with KMS CMK

You configure your S3 backend to use a customer-managed AWS KMS key (CMK) for encrypting Terraform state. What happens if the KMS key is disabled?

A Terraform automatically switches to AWS-managed keys for encryption.

B Terraform can still read and write state files without issues.

C Terraform fails to write new state files but can read existing ones.

D Terraform fails to read and write state files until the key is enabled.

💡 Hint

Consider how KMS key status affects access to encrypted objects.

If the customer-managed KMS key is disabled, Terraform cannot decrypt existing state files or encrypt new ones. This causes read and write operations to fail. Terraform does not automatically switch keys.

✅ Best Practice

expert

Ensuring Terraform state encryption and access control in multi-account AWS setup

You manage Terraform state in a central AWS account's S3 bucket encrypted with a KMS key. Multiple AWS accounts need to access this state securely. Which approach best ensures encryption at rest and least privilege access?

A Use a KMS key policy granting only the central account access, and replicate state files to each account's bucket.

B Configure the KMS key policy to allow decrypt/encrypt only for specific IAM roles in each account, and restrict S3 bucket access similarly.

C Share the S3 bucket and KMS key policies to allow all accounts full access to the bucket and key.

D Disable KMS encryption and rely on S3 bucket policies to restrict access to all accounts.

💡 Hint

Think about how to limit encryption key usage and S3 access to only authorized roles.

Best practice is to restrict KMS key usage to specific IAM roles in each account that need access, and similarly restrict S3 bucket permissions. This enforces least privilege and maintains encryption at rest. Sharing full access or disabling encryption weakens security. Replicating state files increases complexity and risk.