State disaster recovery in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Terraform State Backup

Which of the following best describes the purpose of backing up Terraform state files?

A To automatically update Terraform modules to their latest versions.

B To speed up Terraform plan operations by caching previous runs.

C To store user credentials securely for Terraform providers.

D To ensure infrastructure can be restored or recreated accurately after accidental deletion or corruption.

💡 Hint

Think about what happens if the state file is lost or damaged.

Backing up Terraform state files is critical because they hold the current infrastructure mapping. Losing them can cause Terraform to lose track of resources, leading to potential duplication or deletion.

❓ Configuration

intermediate

Configuring Remote State with Versioning

Which Terraform backend configuration snippet correctly enables remote state storage with versioning in AWS S3 for disaster recovery?

Terraform

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
    # Missing versioning configuration
  }
}

A Enable versioning on the S3 bucket outside Terraform; no config needed in backend block.

B Add 'versioning { enabled = true }' inside the backend block.

C Add 'enable_versioning = true' inside the backend block.

D Add 'versioning = true' inside the backend block.

💡 Hint

Think about how S3 versioning is managed.

S3 bucket versioning is a property set on the bucket itself, not configured inside Terraform backend. Terraform backend config does not support versioning flags.

❓ Architecture

advanced

Designing a Disaster Recovery Plan for Terraform State

You manage infrastructure with Terraform using a remote backend in AWS S3. Which architecture best supports disaster recovery for your Terraform state?

A Store state in a single S3 bucket with versioning enabled and replicate the bucket to another AWS region.

B Store state locally on developer machines and back up manually to external drives.

C Use Terraform Cloud remote backend without any additional backups or replication.

D Store state in an S3 bucket without versioning but enable lifecycle rules to delete old states.

💡 Hint

Consider geographic redundancy and automatic recovery options.

Enabling versioning and cross-region replication on S3 buckets ensures state files are protected against accidental deletion and regional failures, supporting disaster recovery.

❓ security

advanced

Securing Terraform State for Disaster Recovery

Which practice improves security and disaster recovery readiness for Terraform state stored in AWS S3?

A Disable encryption to improve performance and rely on network security only.

B Make the S3 bucket public for easy access and enable versioning.

C Enable server-side encryption with AWS KMS and restrict bucket access with IAM policies.

D Store state files in plaintext on an EC2 instance volume.

💡 Hint

Think about protecting sensitive data and controlling access.

Encrypting state files and restricting access ensures sensitive information is protected and reduces risk of unauthorized changes or data loss.

❓ service_behavior

expert

Terraform State Recovery Behavior After State File Corruption

After accidental corruption of the Terraform state file stored in a versioned S3 bucket, what is the expected behavior when you run terraform apply?

A Terraform will automatically detect and fix the corrupted state file without user intervention.

B Terraform will fail to apply changes due to state mismatch unless the corrupted state is restored from a previous version.

C Terraform will ignore the corrupted state and create all resources from scratch.

D Terraform will delete all existing resources to match the corrupted state.

💡 Hint

Consider how Terraform uses the state file to track resources.

Terraform relies on the state file to know current infrastructure. Corruption causes errors. Restoring a previous version is necessary to continue safely.

Practice

1. What is the main purpose of using remote state storage in Terraform for disaster recovery?

easy

A. To create backups of your source code

B. To speed up Terraform plan and apply commands

C. To safely store the Terraform state file and enable recovery if lost or corrupted

D. To automatically update Terraform providers

Solution

1. Step 1: Understand Terraform state role

   The Terraform state file tracks your infrastructure resources and their current status.

2. Step 2: Importance of remote storage for disaster recovery

   Storing state remotely protects it from local loss or corruption, enabling recovery.

3. Final Answer:

   To safely store the Terraform state file and enable recovery if lost or corrupted -> Option C

4. Quick Check:

   Remote state protects infrastructure info = D [OK]

Hint: Remote state stores your infra info safely for recovery [OK]

Common Mistakes:

• Confusing state storage with code backup
• Thinking remote state speeds up commands
• Assuming remote state updates providers

2. Which of the following is the correct syntax to configure an S3 backend for Terraform state with versioning enabled?

easy

A. backend "s3" { bucket = "mybucket" key = "state.tfstate" region = "us-east-1" versioning = true }

B. backend "s3" { bucket = "mybucket" key = "state.tfstate" region = "us-east-1" }

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

D. backend "s3" { bucket = "mybucket" key = "state.tfstate" region = "us-east-1" versioning = "enabled" }

Solution

1. Step 1: Review S3 backend configuration syntax

   The S3 backend block supports bucket, key, region, and encrypt but not versioning directly.

2. Step 2: Understand versioning setup

   Versioning is enabled on the S3 bucket itself, not via Terraform backend config.

3. Final Answer:

   backend "s3" { bucket = "mybucket" key = "state.tfstate" region = "us-east-1" } -> Option B

4. Quick Check:

   Versioning is bucket setting, not backend config = C [OK]

Hint: Versioning is set on S3 bucket, not in Terraform backend block [OK]

Common Mistakes:

• Trying to set versioning inside backend block
• Confusing encrypt with versioning
• Using wrong data types for versioning

3. Given this Terraform backend configuration snippet, what will happen if the local state file is deleted but the remote backend is intact?

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-west-2"
  }
}

medium

A. Terraform will prompt to reinitialize the backend and then sync state

B. Terraform will fail because the local state file is missing

C. Terraform will create a new empty state file and overwrite remote state

D. Terraform will automatically download the remote state and continue

Solution

1. Step 1: Understand backend initialization behavior

   Terraform requires backend initialization to connect local config with remote state.

2. Step 2: Effect of missing local state file

   If local state is missing, Terraform prompts to reinitialize backend to sync remote state locally.

3. Final Answer:

   Terraform will prompt to reinitialize the backend and then sync state -> Option A

4. Quick Check:

   Missing local state triggers reinit and sync = B [OK]

Hint: Missing local state triggers backend reinit and sync prompt [OK]

Common Mistakes:

• Assuming Terraform fails immediately
• Thinking Terraform overwrites remote state blindly
• Believing Terraform auto-downloads without reinit

4. You configured an S3 backend for Terraform state but forgot to enable bucket versioning. What problem might you face during disaster recovery?

medium

A. Terraform will create duplicate state files

B. Terraform will refuse to initialize the backend

C. State file will be encrypted automatically

D. You cannot recover previous versions of the state file if it gets corrupted

Solution

1. Step 1: Role of versioning in disaster recovery

   Versioning allows keeping multiple versions of the state file to recover from mistakes or corruption.

2. Step 2: Consequence of missing versioning

   Without versioning, if the state file is overwritten or corrupted, previous versions are lost permanently.

3. Final Answer:

   You cannot recover previous versions of the state file if it gets corrupted -> Option D

4. Quick Check:

   No versioning means no state history recovery = A [OK]

Hint: No versioning means lost state history on corruption [OK]

Common Mistakes:

• Thinking Terraform blocks backend init without versioning
• Assuming encryption is automatic
• Believing duplicate state files are created

5. You want to ensure your Terraform state is protected against accidental deletion and corruption. Which combination of practices provides the best disaster recovery setup?

hard

A. Use remote backend with S3 bucket having versioning and server-side encryption enabled

B. Use local state files with manual backups on your computer

C. Use remote backend with S3 bucket without versioning but with encryption enabled

D. Use remote backend with local file copy enabled

Solution

1. Step 1: Identify best remote backend features for disaster recovery

   Remote backend with S3 bucket versioning keeps multiple state versions; encryption protects data confidentiality.

2. Step 2: Compare options

   Local files lack safety; no versioning risks losing history; local copy doesn't protect against corruption.

3. Final Answer:

   Use remote backend with S3 bucket having versioning and server-side encryption enabled -> Option A

4. Quick Check:

   Versioning + encryption on remote backend = best recovery [OK]

Hint: Combine versioning and encryption on remote backend for best safety [OK]

Common Mistakes:

• Relying on local files only
• Skipping versioning on S3 bucket
• Confusing local copy with remote backup