AWS provider Dynamic HCL Configuration — Timed 15 Questions

Question 1

You are using a dynamic block to define multiple 'tag' blocks inside an AWS resource. The dynamic block is failing because it expects a set of objects but receives a flat list. Which function best prepares your data?

15 minute time limit — choose an answer to begin.

Accepted Answer

toset(). `toset()` converts a list into a set, which is the collection type dynamic blocks expect when you want to iterate over unique elements without index-based ordering. If the dynamic block's `for_each` receives a flat list where a set of objects is required, wrapping it in `toset()` normalizes the type and removes duplicates. This is the idiomatic fix for type-mismatch errors in dynamic blocks.

Answer

keys()

Answer

distinct()

Answer

compact()

Question 2

You have a list of strings that you want to convert into a set to use with for_each. Which function is preferred?

Accepted Answer

toset(). toset() converts a list into a set, which is required for for_each because for_each needs a map or set of strings to iterate deterministically. Sets deduplicate values and have no defined order, which is exactly what for_each requires to track instances by key. Using toset() on a list of strings is the standard pattern for dynamic resource creation.

Answer

tomap()

Answer

distinct()

Answer

distinct()

Answer

tolist()

Question 3

In HCL, how do you handle a scenario where a variable might be null but you need to provide a non-null default value for a resource argument?

Accepted Answer

using coalesce(). The coalesce() function returns the first non-null, non-empty string argument. When a variable might be null, coalesce(var.maybe_null, "default") ensures a non-null value is passed to the resource argument. try() is used to catch errors from invalid expressions, not to provide defaults for null values.

Answer

using try()

Answer

using count

Answer

using for_each

Question 4

When defining a variable with a complex type, which keyword allows you to define a flexible schema where keys are strings and values are a specific type?

Accepted Answer

map. The map() type constraint is used for collections where keys are arbitrary strings and values share a common type.

Answer

object

Answer

list

Answer

tuple

Question 5

You are using a 'for' expression to transform a map. How do you ensure the resulting object is a map and not a list?

Accepted Answer

Wrap in {}. By wrapping the 'for' expression in curly braces {} and including a colon after the key-value pair, you tell Terraform to output a map object.

Answer

Wrap in ()

Answer

Wrap in []

Question 6

Which of the following is true regarding the 'content' block inside a dynamic block?

Accepted Answer

It defines the attributes of the nested block. The 'content' block is mandatory inside a dynamic block; it specifies the body of the nested resource being generated.

Answer

It is optional

Answer

It is not allowed inside a dynamic block

Answer

It must be empty

Question 7

You are writing a module that accepts a list of objects. You want to validate that the 'port' attribute in each object is a number. How can you enforce this?

Accepted Answer

Use the type constraint. The type constraint in a variable block (e.g., `type = list(object({ port = number }))`) enforces that the `port` attribute is a number. Additionally, a validation block within the variable can enforce custom conditions, such as checking that the port is within a valid range. Both are valid ways to enforce the type.

Answer

Use a local variable

Answer

Use the any type

Question 8

Which TWO of the following are valid meta-arguments for managing resource instances?

Accepted Answer

count. In Terraform, count and for_each are the two meta-arguments specifically designed to manage multiple resource instances from a single resource block: count takes a whole number and creates that many indexed instances (resource.type.name[0], [1], ...), while for_each takes a map or set of strings and creates one instance per key (resource.type.name["key"]). Both are valid meta-arguments for managing resource instances, which is exactly what this question asks for. The dynamic meta-argument (A) is used to generate nested configuration blocks dynamically, not to manage resource instances, and it is not marked correct. lifecycle (B) is a meta-argument that controls instance behavior such as create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by, but it does not manage instance multiplicity. depends_on (D) is a meta-argument that establishes explicit dependency ordering between resources, not instance management.

Answer

dynamic

Answer

lifecycle

Answer

depends_on

Question 9

Which THREE of the following are valid HCL collection types?

Accepted Answer

set. HCL supports three collection types: list, map, and set, so options C, D, and E are correct. A list (E) is an ordered sequence of values of the same type, written with square brackets, e.g. ["a", "b"]. A map (D) is a collection of key-value pairs where all values share the same type, written with braces, e.g. {name = "web"}. A set (C) is an unordered collection of unique values of the same type, e.g. toset(["a", "b"]). Options A (queue) and B (table) are not HCL collection types; queue is a data structure in some programming languages, and table is not an HCL construct.

Answer

queue

Answer

table

Question 10

Which TWO of the following are requirements when using a 'dynamic' block?

Accepted Answer

A content block. In Terraform, a dynamic block requires a content block (Option A), which defines the body of the nested block that will be generated for each element of the collection; without it, Terraform has nothing to render per iteration. It also requires a for_each argument (Option C), which supplies the collection (map or set) that drives how many instances of the nested block are produced. The count argument (Option B) is used at the resource/module level, not inside a dynamic block, so it is not a requirement here. A provider argument (Option D) is configured on resources or modules, not on dynamic blocks. An iterator argument (Option E) is optional — it only lets you rename the default iterator name (the block label) and is not mandatory.

Answer

A count argument

Answer

A provider argument

Answer

An iterator argument

Question 11

Which THREE of the following are valid ways to define optional resource attributes in an object type?

Accepted Answer

Using coalesce() in a local variable. While this question is tricky, modern Terraform uses 'optional' in type constraints. Prior to that, people used defaults in locals or null checks.

Answer

Using map(any)

Answer

Using count = null

Question 12

You are defining an input variable for a module that must accept a list of objects, each with a required `name` (string) and an optional `tags` attribute (map of strings). You want Terraform to reject any object that includes additional unexpected attributes. Which type constraint correctly enforces this?

Accepted Answer

list(object({ name = string, tags = optional(map(string)) })). The object type with optional attributes is designed to enforce a specific schema while allowing certain attributes to be omitted. By default, object types are closed, meaning any extra attributes cause an error. The optional modifier on tags makes it non-mandatory. The other type constraints either lack the required structure or incorrectly make tags mandatory.

Answer

list(map(string))

Answer

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

Answer

list(tuple([string, map(string)]))

Question 13

You maintain a root module that instantiates a child module `network` for each AWS region defined in a local variable `regions` map. The module call uses `for_each = local.regions`. During a plan, Terraform reports that the module's `providers` argument references `each.key` in the `aws` provider alias. You want each module instance to use the AWS provider aliased to its own region. Which configuration correctly passes the region-specific provider instance into the module?

Accepted Answer

Declare multiple provider aliases and pass a static alias per module, using one module block per region.. Terraform evaluates the `providers` meta-argument during configuration graph construction, before `for_each` creates instances, so expressions depending on `each` are invalid there. The reliable approach is to define one aliased provider per region and instantiate the module once per region with a static alias. This keeps provider selection deterministic and avoids invalid references during plan.

Answer

providers = { aws = aws.by_region[each.value] }

Answer

providers = { aws = aws.region }

Answer

providers = { aws = aws[each.key] }

Question 14

You are using a dynamic block to generate multiple ingress rules for an aws_security_group resource. The dynamic block iterates over a list of objects, each containing 'from_port', 'to_port', and 'cidr_blocks'. You need to access the current iteration's values inside the dynamic block. Which TWO of the following are valid ways to reference the current iteration object? (Choose two.)

Accepted Answer

Explicitly define an iterator argument in the dynamic block, e.g., iterator = rule, and then reference rule.value.from_port.. Inside a dynamic block, the current iteration object is accessed via an iterator. By default, the iterator is named after the dynamic block's label (e.g., ingress for a dynamic "ingress" block). You can also explicitly set the iterator argument to a custom name, such as rule, and then use rule.value to access the current element. The each object is not available in dynamic blocks, count.index is unrelated, and self is for provisioners. Thus, the two valid methods are using the default iterator name or defining a custom iterator.

Answer

Use the self object to refer to the current iteration, e.g., self.from_port.

Answer

Use the special variable each.value, which is automatically available inside dynamic blocks.

Answer

Reference the list directly using the dynamic block's label and the index, e.g., ingress[count.index].from_port.

Question 15

You are authoring a module whose main configuration must merge a caller-supplied map of tags with a set of mandatory tags defined inside the module, giving the mandatory tags precedence when keys collide. The merged result is passed to the tags argument of an aws_instance resource. Which expression should you use?

Accepted Answer

merge(var.tags, local.mandatory_tags). The merge function takes any number of maps and resolves duplicate keys in favour of the rightmost argument, so listing the module's mandatory tags last guarantees they take precedence. The result remains a map of strings, which is exactly the type the tags argument expects.

Answer

concat(var.tags, local.mandatory_tags)

Answer

zipmap(var.tags, local.mandatory_tags)

Answer

merge(local.mandatory_tags, var.tags)