Resource arguments and attributes in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding resource attribute references

Given the Terraform resource below, what is the correct way to reference the id attribute of the aws_instance resource named web in another resource?

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

A aws_instance.web[0].id

B aws_instance["web"].id

C aws_instance.id.web

D aws_instance.web.id

💡 Hint

Think about how Terraform references resource attributes using dot notation.

Terraform references resource attributes using the syntax resource_type.resource_name.attribute. Here, aws_instance.web.id correctly accesses the id attribute of the web instance.

❓ Configuration

intermediate

Correctly setting resource arguments for an AWS S3 bucket

Which option correctly defines an AWS S3 bucket resource with versioning enabled in Terraform?

A

resource "aws_s3_bucket" "mybucket" {
  bucket = "my-unique-bucket"
  versioning {
    status = "Enabled"
  }
}

B

resource "aws_s3_bucket" "mybucket" {
  bucket = "my-unique-bucket"
  versioning = true
}

C

resource "aws_s3_bucket" "mybucket" {
  bucket = "my-unique-bucket"
  versioning {
    enabled = true
  }
}

D

resource "aws_s3_bucket" "mybucket" {
  bucket = "my-unique-bucket"
  versioning_enabled = true
}

💡 Hint

Versioning is a nested block with an enabled argument set to true.

The correct syntax for enabling versioning in an AWS S3 bucket resource is to use a nested versioning block with enabled = true. Option C follows this syntax exactly.

❓ Architecture

advanced

Choosing resource arguments for a secure AWS EC2 instance

You want to create an AWS EC2 instance that only allows SSH access from your office IP. Which resource argument configuration correctly achieves this?

A

resource "aws_security_group" "ssh_access" {
  name        = "ssh_access"
  description = "Allow SSH from office"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }
}

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  vpc_security_group_ids = [aws_security_group.ssh_access.id]
}

B

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }
}

C

resource "aws_security_group" "ssh_access" {
  name        = "ssh_access"
  description = "Allow SSH from office"
  egress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }
}

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  security_groups = [aws_security_group.ssh_access.name]
}

D

resource "aws_security_group" "ssh_access" {
  name        = "ssh_access"
  description = "Allow SSH from office"
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }
}

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  vpc_security_group_ids = [aws_security_group.ssh_access.id]
}

💡 Hint

Security groups control network access. SSH uses port 22 and ingress rules allow incoming traffic.

Option A correctly creates a security group with an ingress rule allowing TCP port 22 from the office IP range, then attaches it to the EC2 instance using vpc_security_group_ids. This setup restricts SSH access properly.

❓ service_behavior

advanced

Effect of changing resource arguments on infrastructure state

If you change the instance_type argument of an existing aws_instance resource in Terraform and apply the changes, what will happen?

A Terraform will update the instance in place without replacement.

B Terraform will destroy the existing instance and create a new one with the new type.

C Terraform will ignore the change and keep the old instance type.

D Terraform will throw a syntax error and stop.

💡 Hint

Consider how Terraform handles changes to immutable resource arguments.

Changing the instance_type of an AWS EC2 instance requires replacement because the instance type cannot be changed in place. Terraform will destroy the old instance and create a new one with the updated type.

❓ security

expert

Identifying the security risk in resource argument configuration

Review the following Terraform resource configuration for an AWS RDS instance. Which option correctly identifies the security risk present?

resource "aws_db_instance" "example" {
  allocated_storage    = 20
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = "db.t3.micro"
  name                 = "mydb"
  username             = "admin"
  password             = "password123"
  parameter_group_name = "default.mysql8.0"
  skip_final_snapshot  = true
}

A The password is hardcoded in the configuration, risking exposure in version control.

B The instance_class is too small for production workloads, causing performance issues.

C The skip_final_snapshot set to true will cause data loss on deletion.

D The engine_version is outdated and unsupported.

💡 Hint

Think about sensitive data handling best practices in Terraform.

Hardcoding sensitive information like passwords in Terraform files risks exposure if the files are stored in version control. Best practice is to use secure methods like environment variables or secret managers.

Practice

1. In Terraform, what is the main purpose of resource arguments inside a resource block?

easy

A. To delete the resource from the cloud provider

B. To display information about the resource after creation

C. To output the resource's ID automatically

D. To specify the settings needed to create the resource

Solution

1. Step 1: Understand resource arguments

   Resource arguments define the configuration details needed to create the resource, like size or name.

2. Step 2: Differentiate arguments from attributes

   Attributes provide info after creation, but arguments tell Terraform what to build.

3. Final Answer:

   To specify the settings needed to create the resource -> Option D

4. Quick Check:

   Arguments configure resources = C [OK]

Hint: Arguments set resource details; attributes show info after creation [OK]

Common Mistakes:

• Confusing arguments with attributes
• Thinking arguments output resource info
• Assuming arguments delete resources

2. Which of the following is the correct syntax to define a resource argument in Terraform?

easy

A. resource "aws_instance" "example" { name = "my-instance" }

B. resource aws_instance example { name: "my-instance" }

C. resource "aws_instance" "example" (name = "my-instance")

D. resource "aws_instance" "example" [name = "my-instance"]

Solution

1. Step 1: Review Terraform resource block syntax

   Terraform uses curly braces {} to define resource arguments inside a resource block.

2. Step 2: Check correct key-value assignment

   Arguments use equals sign (=) with quoted strings for values inside the braces.

3. Final Answer:

   resource "aws_instance" "example" { name = "my-instance" } -> Option A

4. Quick Check:

   Curly braces and = sign = A [OK]

Hint: Use braces {} and = for arguments in resource blocks [OK]

Common Mistakes:

• Using parentheses or brackets instead of braces
• Using colon (:) instead of equals (=)
• Omitting quotes around strings

3. Given this Terraform resource snippet:

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

output "instance_id" {
  value = aws_instance.web.id
}

What will the output value show after deployment?

medium

A. The instance type of the created instance

B. The unique ID assigned to the created instance

C. The AMI ID used to create the instance

D. An error because output cannot access resource attributes

Solution

1. Step 1: Identify the output value expression

   The output uses aws_instance.web.id which is the attribute for the instance's unique ID.

2. Step 2: Understand resource attributes

   Attributes like id provide info about the created resource, here the instance ID.

3. Final Answer:

   The unique ID assigned to the created instance -> Option B

4. Quick Check:

   Output shows resource attribute id = A [OK]

Hint: Output value = resource.attribute (id is unique ID) [OK]

Common Mistakes:

• Confusing arguments with attributes
• Thinking output shows argument values
• Assuming output cannot access resource attributes

4. You wrote this Terraform resource:

resource "aws_s3_bucket" "mybucket" {
  bucket = my-bucket-name
  acl    = "private"
}

Terraform plan fails with an error. What is the problem?

medium

A. The bucket name must be in quotes as a string

B. The acl argument is invalid for S3 buckets

C. Resource type aws_s3_bucket is incorrect

D. Missing required provider block

Solution

1. Step 1: Check argument value types

   The bucket argument value my-bucket-name is not quoted, so Terraform treats it as a variable or error.

2. Step 2: Confirm correct string syntax

   Bucket names must be strings, so they need quotes like "my-bucket-name".

3. Final Answer:

   The bucket name must be in quotes as a string -> Option A

4. Quick Check:

   String values need quotes = D [OK]

Hint: Always quote string argument values in resource blocks [OK]

Common Mistakes:

• Forgetting quotes around string values
• Assuming acl is invalid for S3 buckets
• Thinking provider block is always required in snippet

5. You want to create multiple AWS EC2 instances with different names and instance types using a single resource block. Which Terraform feature lets you define arguments dynamically for each instance?

hard

A. Defining multiple resource blocks manually

B. Using output blocks to set arguments

C. Using resource count with indexed arguments

D. Using provider alias for each instance

Solution

1. Step 1: Understand dynamic resource creation

   Terraform's count argument allows creating multiple instances of a resource with indexed arguments.

2. Step 2: Apply count with argument interpolation

   You can use count.index to assign different names and types dynamically in one resource block.

3. Final Answer:

   Using resource count with indexed arguments -> Option C

4. Quick Check:

   Count enables multiple dynamic resources = B [OK]

Hint: Use count and count.index to create multiple resources dynamically [OK]

Common Mistakes:

• Manually duplicating resource blocks instead of using count
• Trying to set arguments via outputs
• Misusing provider aliases for resource count