Data source block syntax in Terraform - Time & Space Complexity

Time Complexity: Data source block syntax

O(n)

Understanding Time Complexity

When Terraform runs, it often reads existing cloud resources using data sources.

We want to know how the time to read these resources changes as we ask for more data.

Scenario Under Consideration

Analyze the time complexity of this data source usage.

data "aws_ami" "example" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

This block fetches the latest Amazon Linux 2 AMI matching a name pattern.

Identify Repeating Operations

Look at what happens when Terraform runs this data source.

• Primary operation: API call to AWS to list AMIs matching filters.
• How many times: Once per data source block during plan or apply.

How Execution Grows With Input

As the number of matching AMIs grows, the API call returns more data to process.

Input Size (n)	Approx. API Calls/Operations
10	1 API call returning 10 items
100	1 API call returning 100 items
1000	1 API call returning 1000 items

Pattern observation: The number of API calls stays the same, but processing time grows with the number of items returned.

Final Time Complexity

Time Complexity: O(n)

This means the time grows linearly with the number of matching resources returned by the data source.

Common Mistake

[X] Wrong: "The data source always takes the same time no matter how many resources match."

[OK] Correct: Even though the API call count is one, processing more returned items takes more time.

Interview Connect

Understanding how data source calls scale helps you design efficient Terraform configurations and explain your choices clearly.

Self-Check

"What if we added multiple data source blocks each fetching different AMIs? How would the time complexity change?"

Practice

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

easy

A. To create new cloud resources from scratch

B. To define variables for Terraform configuration

C. To delete existing cloud resources

D. To read information about existing cloud resources without creating new ones

Solution

1. Step 1: Understand the role of data sources

   Data sources in Terraform are used to fetch information about existing resources, not to create or delete them.

2. Step 2: Compare options with this role

   Only To read information about existing cloud resources without creating new ones describes reading existing resource info without creation, matching the data source purpose.

3. Final Answer:

   To read information about existing cloud resources without creating new ones -> Option D

4. Quick Check:

   Data source = read existing info [OK]

Hint: Data sources read existing resources, not create or delete [OK]

Common Mistakes:

• Confusing data sources with resource blocks
• Thinking data sources create resources
• Assuming data sources delete resources

2. Which of the following is the correct syntax to define a data source block for an AWS AMI in Terraform?

easy

A. data "aws_ami" example { filter { name = "name" values = ["my-ami"] } }

B. resource "aws_ami" "example" { filter { name = "name" values = ["my-ami"] } }

C. data "aws_ami" "example" { filter { name = "name" values = ["my-ami"] } }

D. data aws_ami example { filter { name = "name" values = ["my-ami"] } }

Solution

1. Step 1: Identify correct block type and syntax

   Data source blocks start with data, followed by resource type and local name in quotes.

2. Step 2: Check each option

   data "aws_ami" "example" { filter { name = "name" values = ["my-ami"] } } uses correct quotes and block structure. resource "aws_ami" "example" { filter { name = "name" values = ["my-ami"] } } uses resource instead of data. Options A and C miss quotes around local name or resource type.

3. Final Answer:

   data "aws_ami" "example" { filter { name = "name" values = ["my-ami"] } } -> Option C

4. Quick Check:

   Data source syntax = data "type" "name" { ... } [OK]

Hint: Data source block uses data "type" "name" with quotes [OK]

Common Mistakes:

• Using resource instead of data
• Omitting quotes around type or name
• Incorrect block nesting or missing braces

3. Given this Terraform data source block:

data "aws_vpc" "selected" {
  filter {
    name   = "tag:Name"
    values = ["main-vpc"]
  }
}

What will data.aws_vpc.selected.id return?

medium

A. The ID of the VPC tagged with Name=main-vpc

B. The name tag value main-vpc

C. A list of all VPC IDs in the AWS account

D. An error because filter syntax is invalid

Solution

1. Step 1: Understand the filter block

   The filter selects the VPC resource with tag Name equal to main-vpc.

2. Step 2: Identify the returned attribute

   data.aws_vpc.selected.id accesses the ID of the matched VPC, not the tag value or a list.

3. Final Answer:

   The ID of the VPC tagged with Name=main-vpc -> Option A

4. Quick Check:

   Filter selects resource, .id returns its ID [OK]

Hint: Filter narrows resource, .id returns its unique ID [OK]

Common Mistakes:

• Confusing tag value with resource ID
• Expecting a list instead of single ID
• Assuming filter syntax is wrong

4. Identify the error in this Terraform data source block:

data "aws_subnet" "example" {
  filter {
    name = "availability-zone"
    values = "us-west-2a"
  }
}

medium

A. The values attribute should be a list, not a string

B. The filter block is missing a closing brace

C. The data source type aws_subnet does not support filters

D. The local name example must be uppercase

Solution

1. Step 1: Check the values attribute type

   In Terraform, filter values must be a list, even if only one value is given.

2. Step 2: Verify the given values

   The code uses a string instead of a list, which causes a syntax error.

3. Final Answer:

   The values attribute should be a list, not a string -> Option A

4. Quick Check:

   Filter values = list, not string [OK]

Hint: Always use list syntax ["value"] for filter values [OK]

Common Mistakes:

• Using string instead of list for values
• Assuming filter block needs no braces
• Thinking local name case matters

5. You want to use a data source block to get the latest Amazon Linux 2 AMI ID filtered by owner and name pattern. Which of these blocks correctly achieves this?

hard

A. resource "aws_ami" "latest" {
most_recent = true
owners = ["amazon"]
filter {
name = "name"
values = ["amzn2-ami-hvm-*-x86_64-gp2"]
}
}

B. data "aws_ami" "latest" {
most_recent = true
owners = ["amazon"]
filter {
name = "name"
values = ["amzn2-ami-hvm-*-x86_64-gp2"]
}
}

C. data "aws_ami" "latest" {
filter {
name = "owner"
values = ["amazon"]
}
filter {
name = "name"
values = ["amzn2-ami-hvm-*-x86_64-gp2"]
}
}

D. data "aws_ami" "latest" {
most_recent = true
owner = "amazon"
filter {
name = "name"
values = ["amzn2-ami-hvm-*-x86_64-gp2"]
}
}

Solution

1. Step 1: Confirm correct block type and attributes

   Use data block for reading AMI info, with most_recent = true and owners as a list.

2. Step 2: Check filter and owner syntax

   data "aws_ami" "latest" { most_recent = true owners = ["amazon"] filter { name = "name" values = ["amzn2-ami-hvm-*-x86_64-gp2"] } } correctly uses owners list and a filter for name pattern. data "aws_ami" "latest" { filter { name = "owner" values = ["amazon"] } filter { name = "name" values = ["amzn2-ami-hvm-*-x86_64-gp2"] } } incorrectly filters owner as a filter. resource "aws_ami" "latest" { most_recent = true owners = ["amazon"] filter { name = "name" values = ["amzn2-ami-hvm-*-x86_64-gp2"] } } uses resource block instead of data. data "aws_ami" "latest" { most_recent = true owner = "amazon" filter { name = "name" values = ["amzn2-ami-hvm-*-x86_64-gp2"] } } uses singular owner instead of owners list.

3. Final Answer:

   data "aws_ami" "latest" { most_recent = true owners = ["amazon"] filter { name = "name" values = ["amzn2-ami-hvm-*-x86_64-gp2"] } } -> Option B

4. Quick Check:

   Use data block, owners list, most_recent true [OK]

Hint: Use owners list and most_recent true in data block [OK]

Common Mistakes:

• Using resource block instead of data
• Filtering owner instead of using owners attribute
• Using singular owner instead of owners list