Partial backend configuration in Terraform - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a partial backend configuration in Terraform?

A partial backend configuration means you set some backend settings in your Terraform code but provide the rest later, often during initialization. It helps keep sensitive info out of code.

beginner

Why use partial backend configuration instead of full configuration?

Partial configuration lets you avoid storing sensitive data like access keys in code. You can enter them securely when running 'terraform init'.

intermediate

How do you provide missing backend settings in Terraform?

You provide missing backend settings interactively when running 'terraform init' or by passing a backend config file or command-line options.

intermediate

What happens if you run 'terraform init' with partial backend config?

Terraform asks you to enter the missing backend settings. Once complete, it configures the backend and stores state accordingly.

beginner

Give an example of a partial backend configuration block in Terraform.

Example: terraform { backend "s3" { bucket = "mybucket" # region and key will be provided later } }

What is the main benefit of using partial backend configuration in Terraform?

A To speed up Terraform plan execution

B To disable state storage

C To avoid writing any backend configuration

D To keep sensitive backend details out of code

Partial backend configuration allows you to keep sensitive info like access keys out of your code by providing them later.

When using partial backend config, how do you provide missing settings?

A During 'terraform init' interactively or via command-line options

B By editing the Terraform state file

C By running 'terraform apply' first

D By modifying the provider block

Terraform prompts for missing backend settings during 'terraform init' or you can pass them as command-line options.

Which command initializes Terraform and configures the backend?

A terraform plan

B terraform init

C terraform validate

D terraform apply

'terraform init' initializes the working directory and configures the backend.

If you omit a backend setting in your Terraform code, what happens?

A Terraform uses a default value automatically

B Terraform fails with an error immediately

C Terraform asks for the missing value during initialization

D Terraform ignores the backend

Terraform prompts you to enter missing backend settings during 'terraform init'.

Which backend is commonly used with partial configuration for remote state in AWS?

A s3

B local

C azurerm

D gcs

The 's3' backend is commonly used in AWS and supports partial configuration.

Explain what partial backend configuration is and why it is useful in Terraform.

Think about how you keep secrets safe when sharing code.

Describe the steps Terraform takes when you run 'terraform init' with a partial backend configuration.

Focus on the initialization process and user interaction.

Practice

1. What is the main purpose of using a partial backend configuration in Terraform?

easy

A. To disable backend configuration completely

B. To store all backend secrets directly in the Terraform code

C. To automatically generate backend settings without user input

D. To split backend settings between code and runtime for flexibility and security

Solution

1. Step 1: Understand partial backend config concept

   Partial backend config allows some backend settings to be defined in code and others provided at runtime.

2. Step 2: Identify benefits

   This approach improves security by not hardcoding secrets and increases reusability of configs.

3. Final Answer:

   To split backend settings between code and runtime for flexibility and security -> Option D

4. Quick Check:

   Partial backend config = split settings [OK]

Hint: Partial config splits settings for safety and reuse [OK]

Common Mistakes:

• Thinking partial config disables backend
• Assuming all settings are auto-generated
• Storing secrets directly in code

2. Which of the following is the correct syntax to declare a partial backend configuration in Terraform code?

easy

A. terraform { backend "s3" { bucket = my-bucket } }

B. terraform { backend "s3" {} }

C. terraform { backend "s3" { bucket = "my-bucket" region = us-east-1 } }

D. terraform { backend "s3" { bucket = "my-bucket" key = state.tfstate } }

Solution

1. Step 1: Identify partial backend syntax

   Partial backend config uses empty braces to declare backend type without settings in code.

2. Step 2: Compare options

   terraform { backend "s3" {} } shows empty braces, meaning settings will be provided at runtime. Others have syntax errors (missing quotes around string values), so only A is valid.

3. Final Answer:

   terraform { backend "s3" {} } -> Option B

4. Quick Check:

   Empty braces = partial config [OK]

Hint: Empty braces mean partial backend config [OK]

Common Mistakes:

• Including settings inside backend block means full config
• Missing backend block entirely
• Using incorrect syntax for backend

3. Given this partial backend config:

terraform {
  backend "azurerm" {}
}

Which command do you run to provide missing backend settings?

medium

A. terraform validate -backend-config=storage_account_name=example

B. terraform apply -backend-config=storage_account_name=example

C. terraform init -backend-config=storage_account_name=example

D. terraform plan -backend-config=storage_account_name=example

Solution

1. Step 1: Understand partial backend config usage

   Partial backend requires missing settings at init time using -backend-config flag.

2. Step 2: Identify correct command

   Only terraform init accepts -backend-config to supply backend settings.

3. Final Answer:

   terraform init -backend-config=storage_account_name=example -> Option C

4. Quick Check:

   Init + -backend-config = provide missing settings [OK]

Hint: Use terraform init with -backend-config for missing settings [OK]

Common Mistakes:

• Using apply or plan with -backend-config
• Not providing missing backend settings before init
• Confusing validate command with init

4. You wrote this partial backend config:

terraform {
  backend "gcs" {
    bucket = "my-bucket"
  }
}

When running terraform init, you get an error about missing backend settings. What is the likely cause?

medium

A. You must provide missing settings like credentials or prefix at runtime

B. The bucket name is invalid and must be removed

C. Partial backend config cannot include any settings in code

D. Terraform does not support partial backend for GCS

Solution

1. Step 1: Analyze partial backend with some settings

   Partial backend can include some settings but missing required ones must be provided at runtime.

2. Step 2: Identify missing required settings

   Credentials or prefix may be missing, causing init error until supplied via CLI or env vars.

3. Final Answer:

   You must provide missing settings like credentials or prefix at runtime -> Option A

4. Quick Check:

   Missing settings provided via -backend-config at init [OK]

Hint: Partial config needs all required settings before init [OK]

Common Mistakes:

• Assuming bucket name alone is enough
• Thinking partial backend disallows any settings in code
• Believing GCS backend doesn't support partial config

5. You want to reuse the same Terraform code for multiple environments but keep backend secrets safe. Which partial backend config approach is best?

hard

A. Declare backend type with empty braces in code, supply secrets via CLI or env vars at init

B. Hardcode all backend settings including secrets in Terraform code

C. Use full backend config in code and commit secrets to version control

D. Avoid backend config and store state locally for all environments

Solution

1. Step 1: Understand goal of reusability and secret safety

   Reusing code means backend config should be generic; secrets must not be in code.

2. Step 2: Choose partial backend with empty braces

   Empty braces let you specify backend type but provide secrets securely at runtime.

3. Step 3: Evaluate other options

   Hardcoding secrets or committing them risks exposure; local state is not scalable.

4. Final Answer:

   Declare backend type with empty braces in code, supply secrets via CLI or env vars at init -> Option A

5. Quick Check:

   Partial config + runtime secrets = reusable & safe [OK]

Hint: Use empty backend block and supply secrets at init [OK]

Common Mistakes:

• Hardcoding secrets in code
• Committing secrets to version control
• Using local state for multiple environments