Block syntax and structure in Terraform - Step-by-Step Execution

Process Flow - Block syntax and structure

Start Terraform File

↓

Read Block Type

↓

Read Block Label(s) if any

↓

Parse Block Body

↓

Store Block Configuration

↓

Repeat for Next Block or End

Terraform files are made of blocks. Each block has a type, optional labels, and a body with settings. Terraform reads each block in order and stores its configuration.

Execution Sample

Terraform

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

Defines an AWS instance resource block with type, label, and settings inside.

Process Table

Step	Action	Block Type	Labels	Body Parsed	Result
1	Start reading file	N/A	N/A	N/A	Ready to parse blocks
2	Read block type	resource	N/A	N/A	Identified resource block
3	Read block labels	resource	aws_instance, web	N/A	Labels assigned
4	Parse block body	resource	aws_instance, web	{ami = "ami-123456", instance_type = "t2.micro"}	Settings stored
5	End of block	resource	aws_instance, web	N/A	Block complete
6	Check for more blocks	N/A	N/A	N/A	No more blocks, finish parsing

💡 All blocks parsed, file reading complete

Status Tracker

Variable	Start	After Step 3	After Step 4	Final
block_type	N/A	resource	resource	resource
labels	N/A	["aws_instance", "web"]	["aws_instance", "web"]	["aws_instance", "web"]
body	N/A	N/A	{"ami": "ami-123456", "instance_type": "t2.micro"}	{"ami": "ami-123456", "instance_type": "t2.micro"}

Key Moments - 2 Insights

Why do blocks sometimes have labels and sometimes not?

Labels identify specific instances of a block type, like resource names. See step 3 in execution_table where labels are read after the block type.

What happens if the block body is empty?

Terraform stores an empty configuration for that block. The body parsing step (step 4) would parse no settings but still complete the block.

Visual Quiz - 3 Questions

Look at the execution table, what labels are assigned at step 3?

A ["web"]

B ["aws_instance", "web"]

C No labels

D ["resource"]

💡 Hint

Check the 'Labels' column in row for step 3

At which step is the block body parsed and stored?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Body Parsed' and 'Result' columns in the execution_table

If a block had no labels, which step would show empty labels?

A Step 3

B Step 4

C Step 2

D Step 5

💡 Hint

Labels are read at step 3; check the 'Labels' column there

Concept Snapshot

Terraform blocks have this structure:
block_type "label1" "label2" {
  key = value
}

- Block type is required
- Labels are optional identifiers
- Body contains key-value settings
- Terraform reads blocks top to bottom
- Each block configures part of infrastructure

Full Transcript

Terraform files are made of blocks. Each block starts with a block type, like resource or variable. Some blocks have labels to identify them, like resource "aws_instance" "web". Inside the block is the body with settings, such as ami and instance_type. Terraform reads the file line by line, identifies the block type, then reads any labels, then parses the body. It stores this configuration to build infrastructure. This flow repeats for each block until the file ends. Understanding this structure helps you write valid Terraform code.

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