AWS provider Dynamic HCL Configuration — Timed 20 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?

20 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)

Question 16

You are using a dynamic block to generate multiple ingress rules for an AWS security group. The dynamic block iterates over a list of objects containing port, protocol, and cidr_blocks. Which two statements are true regarding the use of dynamic blocks in this scenario? (Choose two.)

Accepted Answer

The dynamic block's content block can reference attributes of the current iteration using the iterator object, such as rule.value.port.. The iterator argument allows renaming the default iterator object, and the content block can reference the current iteration's value through that iterator. These two features are essential for writing flexible dynamic blocks. The other statements are incorrect because dynamic blocks can accept lists, can be conditionally included, and nested blocks do not always require unique iterator names unless there is a naming conflict.

Answer

Dynamic blocks can be nested arbitrarily deep, but each nested dynamic block must use a unique iterator name to avoid conflicts.

Answer

The for_each argument in a dynamic block must be a map or a set of strings; it cannot accept a list of objects directly.

Answer

The dynamic block can generate multiple instances of the nested block, but it cannot conditionally include the block based on a condition.

Question 17

A platform team stores environment definitions in a single variable "envs" typed as map(object({ region = string, instance_type = string, tags = map(string) })). They need to build locals for downstream modules. Which TWO local definitions correctly produce, respectively, a map of instance types keyed by environment name and a set of all distinct tag values across every environment? (Choose two.)

Accepted Answer

tag_values = distinct(flatten([for cfg in var.envs : values(cfg.tags)])). The two working definitions combine a map-preserving for expression for the keyed instance-type map with a nested for expression plus flatten() and distinct() for the tag-value collection. The map form requires name, cfg to retain environment keys, while flatten() collapses the per-environment value lists before deduplication. Together they satisfy both requested locals without losing keys or duplicating values.

Answer

tag_values = flatten([for cfg in var.envs : cfg.tags])

Answer

instance_types = [for name, cfg in var.envs : cfg.instance_type]

Answer

tag_values = setproduct([for cfg in var.envs : keys(cfg.tags)])

Question 18

A platform team stores environment configuration in a single Terraform variable `env_config` of type `map(object({ cidr_block = string, az_count = number }))`. They want to create one `aws_subnet` per availability zone in each environment, with the subnet CIDR computed by calling `cidrsubnet` on the environment's `cidr_block`. Which expression produces a flattened collection suitable for `for_each` on `aws_subnet`, where each element's key uniquely identifies the environment and AZ index?

Accepted Answer

flatten([for env, cfg in var.env_config : [for i in range(cfg.az_count) : { key = "${env}-${i}", cidr = cidrsubnet(cfg.cidr_block, 8, i) }]]). Building a unique key per subnet requires a nested `for` that expands each environment into its AZ indices, then `flatten` to produce a single list. Each element carries a composite key such as environment plus index, which can be converted to a map for `for_each`. This preserves per-environment CIDR math with `cidrsubnet` and yields stable keys across plans.

Answer

zipmap(keys(var.env_config), [for cfg in values(var.env_config) : cidrsubnet(cfg.cidr_block, 8, 0)])

Answer

for env, cfg in var.env_config : env => cfg.cidr_block

Answer

merge([for env, cfg in var.env_config : { env = env, cidr = cfg.cidr_block }]...)

Question 19

You are creating a Terraform module that must accept a list of objects representing AWS IAM policy statements. Each object has `effect`, `actions` (list of strings), and `resources` (list of strings). You want to validate that all `actions` and `resources` are non-empty lists and that `effect` is either "Allow" or "Deny". Which TWO of the following validation approaches are valid and correctly enforce these requirements? (Choose two.)

Accepted Answer

Use a precondition in a data source that references the variable, with condition = alltrue([for stmt in var.statements : contains(["Allow", "Deny"], stmt.effect) && length(stmt.actions) > 0 && length(stmt.resources) > 0]). The requirements demand validation of every statement's actions, resources, and effect. Using alltrue with a for expression that checks all three conditions per statement is correct. This can be placed in a variable validation block or a precondition. Approaches that only check the first element or omit content checks fail to enforce the rules for all statements.

Answer

Define the variable type as list(object({ effect = string, actions = list(string), resources = list(string) })) and add a validation block with condition = can(regex("^(Allow|Deny)$", var.statements[0].effect))

Answer

Use a validation block with condition = length(var.statements) > 0

Answer

Use a validation block with condition = alltrue([for stmt in var.statements : length(stmt.actions) > 0 && length(stmt.resources) > 0]) && contains(["Allow", "Deny"], var.statements[0].effect)

Question 20

A configuration builds a local "az_map" with local.az_map = { for idx, az in data.aws_availability_zones.available.names : az => idx } and then uses for_each = local.az_map on aws_subnet resources. A reviewer asks what the resulting resource instance keys and values look like, and what happens if AWS later reorders the availability zone list. Which statement is accurate?

Accepted Answer

Resource keys are the availability zone names and each instance's each.value is the zone's index in the data source list; reordering the list changes only the values, not the key set.. In a for expression over a list, the first symbol is the index and the second is the element. Here the element (zone name) becomes the map key and the index becomes the value, so for_each addresses each subnet by zone name. Reordering the source list preserves the key set and only shifts the numeric values, keeping resource addresses stable.

Answer

Resource keys are numeric indices and each instance's each.value is the availability zone name; reordering the list causes every resource to be replaced.

Answer

Resource keys are the availability zone names and each instance's each.value is the full data source object for that zone, so reordering has no effect on values.

Answer

Resource keys are the availability zone names and each instance's each.value is the zone's index in the data source list; reordering the list changes which zone maps to which key.