Why complex types matter in Terraform - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding complex types in Terraform variables

Which of the following Terraform variable declarations correctly defines a variable that expects a list of maps, where each map contains a string key and a number value?

A variable "example" { type = list(map(number)) }

B variable "example" { type = map(list(number)) }

C variable "example" { type = list(object({ key = string, value = number })) }

D variable "example" { type = map(object({ key = string, value = number })) }

💡 Hint

Think about the structure: a list of maps means the outer container is a list, and each item is a map with string keys and number values.

Option A correctly defines a list of maps with string keys and number values. Option A reverses the structure. Options A and D use object types which are more specific but do not match the requested type.

❓ Configuration

intermediate

Outputting a complex type in Terraform

Given the following Terraform variable declaration, which output block correctly outputs the first map's value for the key "port"?

variable "servers" {
  type = list(map(number))
  default = [
    { port = 8080, id = 1 },
    { port = 9090, id = 2 }
  ]
}

A output "first_port" { value = var.servers[0].port }

B output "first_port" { value = var.servers["port"][0] }

C output "first_port" { value = var.servers.port[0] }

D output "first_port" { value = var.servers[0]["port"] }

💡 Hint

Remember that var.servers is a list of maps, so you access the first element by index, then the map key.

Option A uses correct syntax: index first, then dot notation for map key (valid for identifier keys like "port"). Option D uses bracket notation, also valid. Options B and C have incorrect indexing or key access.

❓ Architecture

advanced

Choosing complex types for modular Terraform design

You are designing a Terraform module that manages multiple cloud resources. You want to pass a variable that holds a list of resources, each with a name (string), count (number), and tags (map of strings). Which variable type best fits this requirement?

A object({ name = string, count = number, tags = map(string) })

B list(object({ name = string, count = number, tags = map(string) }))

C list(map(string))

D map(object({ name = string, count = number, tags = list(string) }))

💡 Hint

Consider the structure: multiple resources means a list, each resource has multiple attributes including a map for tags.

Option B correctly defines a list of objects with the required fields. Option B uses a map instead of a list and incorrectly defines tags as a list. Option B is too simple and does not capture the structure. Option B is a single object, not a list.

❓ security

advanced

Security implications of complex types in Terraform variables

Which of the following statements about using complex types in Terraform variables is true regarding security best practices?

A Complex types automatically encrypt sensitive data stored in variables without additional configuration.

B Using simple string variables is always safer than complex types because they are easier to audit.

C Terraform variables with complex types cannot be marked as sensitive, so they should not be used for secrets.

D Using complex types like objects allows you to enforce strict schemas, reducing the risk of misconfiguration that could expose sensitive data.

💡 Hint

Think about how strict typing helps prevent mistakes that could lead to security issues.

Option D is correct because complex types enforce structure, helping prevent errors. Option D is false; encryption requires explicit configuration. Option D is false; simplicity does not guarantee safety. Option D is false; complex types can be marked sensitive.

❓ service_behavior

expert

Behavior of Terraform when complex type variable input is invalid

Given a Terraform variable declared as variable "config" { type = object({ host = string, ports = list(number) }) }, what happens if you provide the following input?

{ host = "example.com", ports = ["80", 443] }

A Terraform plan fails with a type mismatch error because "80" is a string, not a number.

B Terraform plan succeeds and converts "80" string to number automatically.

C Terraform plan ignores the invalid port and uses only 443.

D Terraform plan succeeds but warns about the string in the ports list.

💡 Hint

Terraform enforces strict typing and does not perform automatic type conversion.

Option A is correct because Terraform requires the ports list to contain only numbers. The string "80" causes a type mismatch error. Terraform does not convert types automatically or ignore invalid entries.