AWS provider setup in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the correct AWS provider configuration for a specific region

Which AWS provider configuration will correctly set the region to us-west-2 and use the default profile from your AWS credentials file?

A

provider "aws" {
  region = "us-west-2"
  profile = "default-profile"
}

B

}
"tluafed" = eliforp  
"2-tsew-su" = noiger  
{ "swa" redivorp

C

provider "aws" {
  region = "us-west-2"
  profile = "default"
}

D

provider "aws" {
  region = "us-west-2"
  access_key = "default"
}

💡 Hint

Remember that region and profile values must be strings enclosed in quotes.

Option C correctly sets the region and profile as strings. Option C misses quotes causing syntax errors. Option C incorrectly uses access_key instead of profile. Option C uses a wrong profile name.

❓ service_behavior

intermediate

Determine the effect of missing AWS provider region in Terraform

What happens if you configure the AWS provider in Terraform without specifying a region and no environment variables or default region are set?

A Terraform will deploy resources to a random AWS region.

B Terraform will default to us-east-1 region automatically.

C Terraform will use the region from the AWS CLI configuration file regardless of environment variables.

D Terraform will throw an error during plan/apply stating that region is not configured.

💡 Hint

Think about what Terraform requires to know where to deploy resources.

Terraform requires an explicit region setting either in provider config, environment variables, or default config. Without it, it errors out.

❓ security

advanced

Choose the safest way to provide AWS credentials to Terraform

Which option is the most secure and recommended way to provide AWS credentials to Terraform when running on a developer's local machine?

A Use AWS CLI configured profiles and specify the profile in the provider block.

B Use environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY set in the shell.

C Hardcode AWS access key and secret key directly in the Terraform provider block.

D Store credentials in a shared Terraform variables file checked into version control.

💡 Hint

Think about avoiding exposing secrets in code or version control.

Using AWS CLI profiles keeps credentials out of code and version control, making it safer. Environment variables are better than hardcoding but can leak. Hardcoding and storing in variables file are insecure.

❓ Architecture

advanced

Select the correct Terraform AWS provider configuration for multi-account setup

You manage multiple AWS accounts and want to deploy resources to two accounts using Terraform. Which provider configuration allows you to switch between accounts using profiles named 'dev' and 'prod'?

A

provider "aws" {
  profile = "dev"
  region = "us-east-1"
}

provider "aws" {
  profile = "prod"
  region = "us-east-1"
}

B

provider "aws" {
  alias = "dev"
  profile = "dev"
  region = "us-east-1"
}

provider "aws" {
  alias = "prod"
  profile = "prod"
  region = "us-east-1"
}

C

provider "aws" {
  profile = "dev,prod"
  region = "us-east-1"
}

D

provider "aws" {
  alias = "dev-prod"
  profile = "dev-prod"
  region = "us-east-1"
}

💡 Hint

Think about how Terraform handles multiple provider configurations with aliases.

Option B correctly defines two providers with aliases for different profiles. Option B tries to combine profiles in one provider which is invalid. Option B misses aliases so Terraform cannot distinguish providers. Option B uses a non-existent combined profile.

🧠 Conceptual

expert

Understand the impact of provider version constraints in Terraform AWS provider

Given the following Terraform provider block, what is the effect of the version constraint on provider installation and upgrades? provider "aws" { version = ">= 4.0, < 5.0" region = "us-east-1" }

A Terraform will install any AWS provider version from 4.0 up to but not including 5.0, allowing minor and patch upgrades but preventing major upgrades.

B Terraform will only install version 4.0 exactly, no other versions.

C Terraform will install the latest AWS provider version regardless of version number.

D Terraform will install any version including 5.0 and above.

💡 Hint

Think about semantic versioning and how version constraints work in Terraform.

The constraint ">= 4.0, < 5.0" means any version starting at 4.0 up to but not including 5.0 is allowed. This allows safe upgrades without breaking changes from major version bumps.