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.