Bird
Raised Fist0
Terraformcloud~10 mins

State file sensitivity and security in Terraform - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to specify the backend type for storing Terraform state remotely.

Terraform
terraform {
  backend "[1]" {}
}
Drag options to blanks, or click blank then click option'
Afile
Blocal
Chttp
Ds3
Attempts:
3 left
💡 Hint
Common Mistakes
Using 'local' backend stores state on the local machine, which is not secure for team environments.
Using 'file' is not a valid backend type in Terraform.
2fill in blank
medium

Complete the code to enable state locking using DynamoDB to prevent concurrent modifications.

Terraform
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "state.tfstate"
    region         = "us-east-1"
    dynamodb_table = "[1]"
  }
}
Drag options to blanks, or click blank then click option'
Aterraform-locks
Bstate-lock
Clock-table
Dterraform-state-lock
Attempts:
3 left
💡 Hint
Common Mistakes
Using a table name unrelated to locking can cause locking to fail.
Leaving this attribute empty disables state locking, risking concurrent state changes.
3fill in blank
hard

Fix the error in the backend configuration to encrypt the state file at rest.

Terraform
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "state.tfstate"
    region         = "us-east-1"
    encrypt        = [1]
  }
}
Drag options to blanks, or click blank then click option'
Atrue
B"true"
CTrue
Dyes
Attempts:
3 left
💡 Hint
Common Mistakes
Using quotes around true makes it a string, which is invalid.
Using capitalized True is not valid in Terraform HCL.
4fill in blank
hard

Fill both blanks to configure remote state with S3 backend and enable encryption for state file safety.

Terraform
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "state.tfstate"
    region         = "us-east-1"
    [1] = true
    [2] = "arn:aws:kms:us-east-1:123456789012:key/abcd-1234"
  }
}
Drag options to blanks, or click blank then click option'
Aversioning
Bkms_key_id
Cencrypt
Ddynamodb_table
Attempts:
3 left
💡 Hint
Common Mistakes
Using 'versioning' is not a valid backend attribute in Terraform.
Confusing 'dynamodb_table' with encryption settings.
5fill in blank
hard

Fill all three blanks to define a secure backend with S3 bucket, DynamoDB locking, and encryption enabled.

Terraform
terraform {
  backend "s3" {
    bucket         = "[1]"
    key            = "terraform.tfstate"
    region         = "us-west-2"
    dynamodb_table = "[2]"
    encrypt        = [3]
  }
}
Drag options to blanks, or click blank then click option'
Asecure-terraform-state
Bterraform-locks
Ctrue
Dfalse
Attempts:
3 left
💡 Hint
Common Mistakes
Setting encrypt to false disables encryption, which is insecure.
Using incorrect or missing DynamoDB table disables locking.

Practice

(1/5)
1. What is the main reason to keep the Terraform state file secure?
easy
A. It holds your Terraform installation files
B. It stores your Terraform version history
C. It contains sensitive information about your cloud resources
D. It contains your Terraform provider plugins

Solution

  1. Step 1: Understand the role of the state file

    The Terraform state file records details about your cloud resources, including IDs and configurations.
  2. Step 2: Identify sensitive content in the state file

    Because it stores resource details, it may include secrets or private data that must be protected.
  3. Final Answer:

    It contains sensitive information about your cloud resources -> Option C
  4. Quick Check:

    State file holds sensitive info = A [OK]
Hint: State file stores resource info, so protect it [OK]
Common Mistakes:
  • Thinking state file stores Terraform software files
  • Confusing state file with version control
  • Assuming state file only has public info
2. Which Terraform configuration snippet correctly marks a variable as sensitive?
easy
A. variable "password" { type = sensitive }
B. variable "password" { hidden = true }
C. variable "password" { secret = true }
D. variable "password" { sensitive = true }

Solution

  1. Step 1: Recall Terraform variable syntax for sensitivity

    Terraform uses the attribute sensitive = true inside variable blocks to mark secrets.
  2. Step 2: Check each option's correctness

    Only variable "password" { sensitive = true } uses the correct attribute sensitive = true. Others use invalid or unsupported attributes.
  3. Final Answer:

    variable "password" { sensitive = true } -> Option D
  4. Quick Check:

    sensitive = true marks secrets = B [OK]
Hint: Use sensitive = true inside variable block [OK]
Common Mistakes:
  • Using 'type = sensitive' instead of 'sensitive = true'
  • Using 'secret' or 'hidden' which are invalid
  • Omitting the sensitive attribute
3. Given this Terraform output block:
output "db_password" {
  value     = var.db_password
  sensitive = true
}
What will happen when you run terraform apply?
medium
A. The password will be hidden in the output and logs
B. The password will be shown in the output after apply
C. Terraform will throw a syntax error
D. The password will be stored in plain text in the state file

Solution

  1. Step 1: Understand the effect of sensitive output

    Marking an output as sensitive = true hides its value from CLI output and logs.
  2. Step 2: Check if syntax is correct and state file behavior

    The syntax is valid, so no error occurs. The value is still stored in the state file but hidden from output.
  3. Final Answer:

    The password will be hidden in the output and logs -> Option A
  4. Quick Check:

    sensitive output hides value in CLI = A [OK]
Hint: sensitive output hides value from CLI, not state file [OK]
Common Mistakes:
  • Thinking sensitive outputs cause syntax errors
  • Assuming sensitive outputs are not stored in state
  • Expecting sensitive outputs to show in CLI
4. You accidentally committed your Terraform state file with secrets to a public GitHub repo. What is the best immediate action to secure your infrastructure?
medium
A. Remove the state file from GitHub and continue as usual
B. Rotate all secrets and credentials stored in the state file
C. Change the Terraform version to encrypt the state file automatically
D. Delete the GitHub repo and do nothing else

Solution

  1. Step 1: Understand the risk of leaked secrets

    Once secrets are public, they can be compromised, so immediate rotation is needed.
  2. Step 2: Evaluate other options

    Deleting repo or removing files does not guarantee secrets are safe. Changing Terraform version does not fix leaked secrets.
  3. Final Answer:

    Rotate all secrets and credentials stored in the state file -> Option B
  4. Quick Check:

    Leaked secrets require rotation = D [OK]
Hint: Rotate secrets immediately if state file leaks [OK]
Common Mistakes:
  • Thinking deleting repo removes leaked secrets
  • Assuming Terraform version change encrypts old state
  • Ignoring secret rotation after leak
5. You want to securely store your Terraform state file remotely with encryption and access control. Which setup is the best practice?
hard
A. Use a remote backend like AWS S3 with server-side encryption and IAM policies
B. Store the state file locally and encrypt it manually with a password
C. Commit the state file to a private Git repository with limited access
D. Use Terraform Cloud free tier without enabling state encryption

Solution

  1. Step 1: Identify secure remote state storage options

    Using a remote backend like AWS S3 with encryption and access control protects the state file effectively.
  2. Step 2: Compare other options

    Local storage with manual encryption is error-prone. Private Git repos are not designed for state files. Terraform Cloud free tier may not encrypt state by default.
  3. Final Answer:

    Use a remote backend like AWS S3 with server-side encryption and IAM policies -> Option A
  4. Quick Check:

    Remote backend with encryption = C [OK]
Hint: Use remote backend with encryption and access control [OK]
Common Mistakes:
  • Relying on local manual encryption
  • Storing state in Git repos
  • Assuming free tiers always encrypt state