Block syntax and structure in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the output of this Terraform resource block

Given the following Terraform resource block, what will be the value of the instance_type attribute after deployment?

Terraform

resource "aws_instance" "example" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
  tags = {
    Name = "ExampleInstance"
  }
}

A "t2.micro"

B "ami-12345678"

C "ExampleInstance"

D "aws_instance.example"

💡 Hint

Look at the attribute assigned to instance_type inside the resource block.

The instance_type attribute is explicitly set to "t2.micro" in the resource block, so after deployment, its value will be "t2.micro".

❓ Architecture

intermediate

Determine the number of blocks in this Terraform configuration

How many top-level blocks are defined in the following Terraform configuration snippet?

Terraform

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

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

variable "bucket_name" {
  type = string
}

A 2

B 3

C 4

D 1

💡 Hint

Count each block that starts at the left margin with a block type keyword.

There are three top-level blocks: provider, resource, and variable.

❓ security

advanced

Identify the security risk in this Terraform block structure

Which option correctly identifies the security risk in the following Terraform block?

Terraform

resource "aws_security_group" "example" {
  name        = "example-sg"
  description = "Allow SSH"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

A The security group name is not unique, causing deployment failure.

B Missing egress block will block all outbound traffic, causing connectivity issues.

C The protocol value "tcp" is invalid and will cause a syntax error.

D Ingress rule allows SSH from any IP address, which is a security risk.

💡 Hint

Consider what allowing SSH from everywhere means for security.

Allowing SSH (port 22) from any IP address (0.0.0.0/0) exposes the instance to the entire internet, increasing risk of unauthorized access.

✅ Best Practice

advanced

Choose the correct block structure to define multiple tags in Terraform

Which option correctly defines multiple tags inside a resource block in Terraform?

A

tags = {
  Environment = "Production"
  Owner       = "TeamA"
}

B

tags = [
  "Environment=Production",
  "Owner=TeamA"
]

C

tags = {
  "Environment": "Production",
  "Owner": "TeamA"
}

D tags = ("Environment" = "Production", "Owner" = "TeamA")

💡 Hint

Terraform uses maps for tags, not lists or tuples.

Terraform expects tags as a map with key-value pairs using = without quotes around keys. Option A uses correct syntax.

❓ service_behavior

expert

Predict the behavior of nested blocks in this Terraform configuration

What will be the effect of the nested lifecycle block inside this resource block?

Terraform

resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"

  lifecycle {
    prevent_destroy = true
  }
}

A Terraform will throw a syntax error due to incorrect lifecycle block placement.

B Terraform will ignore the lifecycle block and destroy the bucket normally.

C Terraform will prevent the bucket from being destroyed unless the lifecycle block is removed.

D Terraform will automatically recreate the bucket if destroyed outside Terraform.

💡 Hint

Consider what the prevent_destroy setting does in Terraform lifecycle blocks.

The lifecycle block with prevent_destroy = true tells Terraform to block any destroy action on the resource unless the block is removed or changed.

Practice

1. What is the main purpose of a block in Terraform configuration?

easy

A. To store secret values securely

B. To write comments in the code

C. To execute commands on the cloud provider

D. To group related settings and resources together

Solution

1. Step 1: Understand Terraform block role

   Blocks in Terraform group related configuration settings and resources logically.

2. Step 2: Differentiate from other uses

   Blocks are not for comments, commands, or secrets but for organizing configuration.

3. Final Answer:

   To group related settings and resources together -> Option D

4. Quick Check:

   Blocks = Group related settings [OK]

Hint: Blocks group settings inside braces {} [OK]

Common Mistakes:

• Thinking blocks run commands
• Confusing blocks with comments
• Assuming blocks store secrets

2. Which of the following is the correct syntax to start a Terraform block named resource with label aws_instance and name web?

easy

A. resource aws_instance web {

B. resource "aws_instance" "web" {

C. resource: aws_instance: web {

D. resource(aws_instance, web) {

Solution

1. Step 1: Recall Terraform block syntax

   Terraform blocks start with block type, then labels in quotes, then braces.

2. Step 2: Match correct syntax

   resource "aws_instance" "web" { uses quotes and braces correctly: resource "aws_instance" "web" {

3. Final Answer:

   resource "aws_instance" "web" { -> Option B

4. Quick Check:

   Block type + "label" + "name" + braces [OK]

Hint: Use quotes around labels and braces to start block [OK]

Common Mistakes:

• Omitting quotes around labels
• Using colons or commas instead of spaces
• Using parentheses instead of braces

3. Given this Terraform block snippet:

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

What does this block define?

medium

A. A provider configuration for AWS S3

B. A variable named mybucket for S3 bucket name

C. An AWS S3 bucket named mybucket with private access

D. A local file named mybucket with private permissions

Solution

1. Step 1: Identify block type and labels

   The block is a resource of type aws_s3_bucket with name mybucket.

2. Step 2: Understand block arguments

   Arguments set bucket name and access control list (acl) to private.

3. Final Answer:

   An AWS S3 bucket named mybucket with private access -> Option C

4. Quick Check:

   resource block creates AWS S3 bucket [OK]

Hint: resource blocks define cloud resources with settings [OK]

Common Mistakes:

• Confusing resource with variable
• Thinking acl is file permission
• Assuming provider config instead of resource

4. Which of the following Terraform blocks has a syntax error?

medium

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

B. provider "aws" {
region = "us-east-1"
}

C. variable "region" {
default = "us-west-2"
}

D. output "instance_ip" {
value = aws_instance.web.public_ip
}

Solution

1. Step 1: Check block opening and braces

   resource "aws_instance" "web" ami = "ami-123456" instance_type = "t2.micro" } misses the opening brace '{' after the block header.

2. Step 2: Confirm other blocks are correct

   Options B, C, and D have proper braces and syntax.

3. Final Answer:

   Missing opening brace in resource block -> Option A

4. Quick Check:

   Blocks need opening and closing braces [OK]

Hint: Always check for matching braces after block header [OK]

Common Mistakes:

• Forgetting opening or closing braces
• Misplacing block labels without quotes
• Incorrect indentation causing confusion

5. You want to create a Terraform configuration that defines a resource block for an AWS EC2 instance named app_server and inside it, add a nested tags block with key-value pairs. Which is the correct way to structure this?

hard

A. resource "aws_instance" "app_server" {
ami = "ami-abc123"
instance_type = "t3.micro"
tags = {
Name = "AppServer"
Environment = "Production"
}
}

B. resource "aws_instance" "app_server" {
ami = "ami-abc123"
instance_type = "t3.micro"
tags {
Name = "AppServer"
Environment = "Production"
}
}

C. resource "aws_instance" "app_server" {
ami = "ami-abc123"
instance_type = "t3.micro"
tags: {
Name = "AppServer"
Environment = "Production"
}
}

D. resource "aws_instance" "app_server" {
ami = "ami-abc123"
instance_type = "t3.micro"
tags = [
Name = "AppServer",
Environment = "Production"
]
}

Solution

1. Step 1: Understand tags argument type

   In Terraform, tags are a map (key-value pairs) assigned with = and braces { }.

2. Step 2: Identify correct syntax for nested map

   resource "aws_instance" "app_server" { ami = "ami-abc123" instance_type = "t3.micro" tags = { Name = "AppServer" Environment = "Production" } } correctly uses tags = { ... } with key-value pairs inside.

3. Step 3: Check other options

   resource "aws_instance" "app_server" { ami = "ami-abc123" instance_type = "t3.micro" tags { Name = "AppServer" Environment = "Production" } } wrongly uses a nested block for tags (not supported). resource "aws_instance" "app_server" { ami = "ami-abc123" instance_type = "t3.micro" tags: { Name = "AppServer" Environment = "Production" } } uses colon instead of =. resource "aws_instance" "app_server" { ami = "ami-abc123" instance_type = "t3.micro" tags = [ Name = "AppServer", Environment = "Production" ] } uses list syntax which is invalid for tags.

4. Final Answer:

   Use tags = { ... } map syntax inside resource block -> Option A

5. Quick Check:

   Tags = map with = and braces [OK]

Hint: Use tags = { key = value } map syntax, not nested block [OK]

Common Mistakes:

• Using nested block instead of map for tags
• Using colon instead of equals sign
• Using list syntax for key-value pairs