Dynamic HCL Configuration practice questions

keys()

Why it fails: keys() returns only the attribute names of a map, discarding the associated values, so it cannot build the object set the dynamic block requires. It is tempting when iterating map structures, but converting a flat list into objects needs a function that constructs each object, such as a for expression.

distinct()

Why it fails: distinct() removes duplicate values from a list, returning a list of unique primitives, so it cannot restructure flat strings into the object shape a dynamic block's for_each requires. It is tempting because it does manipulate collections, and would be correct when deduplicating a list of simple values before iteration.

compact()

Why it fails: compact() only strips null and empty-string elements from a list, leaving the flat structure intact, so the dynamic block still receives strings rather than objects. It is tempting because it tidies lists, and would be correct when removing blank entries from a list of strings before passing them elsewhere.

tomap()

Why it fails: This would require keys to be defined.

distinct()

Why it fails: distinct is for filtering, not type conversion.

distinct()

Why it fails: distinct removes duplicates but doesn't guarantee the same type constraints for iteration as toset.

tolist()

Why it fails: This keeps it a list, which is not recommended for for_each.

using try()

Why it fails: try() is for error handling, though possible, it is not the standard way for null coalescing.

using count

Why it fails: count creates multiple instances of a resource and cannot substitute a default value for a null argument; the null still reaches the provider. count is tempting because it conditionally creates resources, which suits optional infrastructure, but it does not evaluate or replace argument values.

using for_each

Why it fails: for_each iterates over a map or set to create resource instances; it performs no null-coalescing on argument values, so a null variable remains null. for_each is tempting because it handles dynamic collections, which is its real purpose, but defaulting a single argument requires coalesce().

object

Why it fails: object is for fixed schemas with known keys.

list

Why it fails: list is for ordered sequences of a single type.

tuple

Why it fails: tuple is for ordered lists of fixed types.

Wrap in ()

Why it fails: Parentheses are for grouping expressions.

Wrap in []

Why it fails: Brackets [] create a list.

It is optional

Why it fails: The content block is required.

It is not allowed inside a dynamic block

Why it fails: It is the core component of a dynamic block.

It must be empty

Why it fails: It must contain the configuration attributes.

Use a local variable

Why it fails: Local variables compute intermediate values within a module; they cannot declare or constrain an input's type, so a string port would pass through unvalidated. They are tempting for deriving or transforming values, and would be correct if you needed to combine inputs before use, not to enforce a schema.

Use the any type

Why it fails: The any type accepts every value without constraint, so a string port would satisfy it and no validation occurs. It is tempting when the input's shape is genuinely unknown or varies, and would be correct for a truly polymorphic argument, but here you know the attribute must be a number.

dynamic

Why it fails: For nested blocks only.

lifecycle

Why it fails: For resource lifecycle hooks.

depends_on

Why it fails: For lifecycle and dependency management.

queue

Why it fails: HCL's collection types are list, map, set, object and tuple; queue is not among them, so it cannot be declared as a variable type. It is tempting because queues are a familiar data structure in general programming, but HCL models ordered collections with list, not queue.

table

Why it fails: HCL's collection types are list, map, set, object and tuple; table is not one, so a variable cannot be typed as table. It is tempting because tables appear in databases and configuration formats, but HCL has no tabular type — map or object covers key-value grouping.

A count argument

Why it fails: Dynamic blocks do not use count.

A provider argument

Why it fails: Not related to dynamic blocks.

An iterator argument

Why it fails: Optional, not required.

Using map(any)

Why it fails: Too loose for schema validation.

Using count = null

Why it fails: Not valid syntax.

list(map(string))

Why it fails: This accepts a list of maps with string values, which does not enforce the presence of a name attribute or restrict keys to name and tags. It would allow arbitrary keys and would not validate that each element has a name, failing the schema requirement.

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

Why it fails: This makes tags required rather than optional, so callers must always provide tags even when not needed. The requirement states tags is optional, so this constraint is too strict and would reject valid configurations that omit tags.

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

Why it fails: A tuple type expects a fixed-length sequence where each element has a specific type, not a list of objects with named attributes. This would require each element to be a two-element list, not an object with name and tags, so it does not match the intended structure.

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

Why it fails: Provider configurations cannot be indexed by arbitrary expressions in the `providers` map. Aliases are static identifiers declared with `alias` in a `provider` block. Terraform will not evaluate `each.value` here, and `aws.by_region` is not a valid provider reference unless a matching alias exists, which it cannot per-instance. This fails at validation.

providers = { aws = aws.region }

Why it fails: This references a provider alias named `region`, which is not declared in the configuration. Terraform resolves provider aliases statically and will not substitute `each.key` or any expression inside a provider configuration block. The plan fails with an undeclared provider error, and no module instance receives a valid provider. It also ignores the per-instance region mapping entirely.

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

Why it fails: The `providers` meta-argument is evaluated statically, before `for_each` expansion, so `each.key` and other instance-specific expressions are not available there. Terraform rejects this with an error stating that `each` is not defined. Even if it were accepted, provider instances must be named aliases, not dynamic lookups on a provider object.

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

Why it fails: This is incorrect because self is used in provisioners and connection blocks to refer to the parent resource, not in dynamic blocks. Inside a dynamic block, self is not defined and will cause an error. The correct way is to use the iterator object.

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

Why it fails: This is incorrect because each.value is used with the for_each meta-argument on resources and modules, not within dynamic blocks. Inside a dynamic block, the iterator is a different object; using each.value will result in an error because each is not defined in that context.

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

Why it fails: This is incorrect because count.index is only available when using the count meta-argument, and dynamic blocks do not use count. The dynamic block's iterator provides the current element directly; there is no index-based access unless you explicitly include an index in the iterated collection.

concat(var.tags, local.mandatory_tags)

Why it fails: The concat function joins lists, not maps, and produces a list that cannot be assigned to the tags argument, which expects a map of strings. Even if the inputs were lists, concatenation would not resolve duplicate keys with precedence, so this fails both the type and behaviour requirements.

zipmap(var.tags, local.mandatory_tags)

Why it fails: The zipmap function pairs a list of keys with a list of values to build a map, which is unrelated to combining two existing maps. Passing maps as its arguments produces an error, and even the intended use would not merge overlapping tag sets with defined precedence.

merge(local.mandatory_tags, var.tags)

Why it fails: The arguments are reversed, so caller-supplied tags would override the module's mandatory tags whenever keys collide. The syntax is valid and the result is still a map, but the precedence is backwards relative to the requirement that mandatory tags win.

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

Why it fails: While dynamic blocks can be nested, the iterator name must be unique only if you need to reference both iterators simultaneously. You can nest dynamic blocks without specifying an iterator if the default names do not conflict. The statement that each must use a unique iterator name is too absolute; it is only necessary when the default names would shadow each other.

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.

Why it fails: The for_each argument in a dynamic block accepts any collection or structural value that Terraform can iterate over, including a list of objects. Terraform will iterate over the list, and the iterator's value will be the object. It is not restricted to maps or sets; lists are perfectly valid, though using a map or set can provide stable keys for for_each on resources, but dynamic blocks do not require that.

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

Why it fails: Dynamic blocks can conditionally include the nested block by using a for_each expression that evaluates to an empty collection when the condition is false. For example, for_each = var.enabled ? var.rules : []. This effectively omits the block when the condition is not met, so conditional inclusion is possible.

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

Why it fails: Iterating a map with a single symbol is invalid syntax; the two-symbol form name, cfg is required, so this fails during evaluation. Additionally, even corrected, flatten() over a list of maps does not merge maps into a flat list of their values, so the result would not be a set of distinct tag values as required. The expression never reaches the distinct step correctly.

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

Why it fails: Square brackets produce a tuple, not a map keyed by environment name, so downstream lookups by environment name would fail. It also discards the original keys entirely, which the requirement explicitly needs. While the values themselves are correct instance types, the container type and keying are wrong for the stated purpose of a name-keyed map.

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

Why it fails: setproduct() computes the Cartesian product of its arguments and returns a list of tuples, not a flat set of tag values. It also operates on tag keys rather than values, and passing a single argument list does not collapse anything. This produces nested tuples of key names, which is unrelated to the requirement of collecting distinct tag values across environments.

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

Why it fails: `zipmap` pairs environment names with a single subnet CIDR each, yielding one entry per environment. It ignores `az_count` beyond index zero and cannot represent multiple subnets per environment. The resulting map has one element per environment, so `for_each` would create at most one subnet per environment, which contradicts the requirement.

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

Why it fails: This produces a map from environment name to a single CIDR string, not a collection of subnets. It collapses each environment to one entry and loses the per-AZ expansion. Applying `for_each` to this map would attempt to create one subnet per environment, and the CIDR value would not be a valid per-subnet CIDR. It does not satisfy the AZ count requirement.

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

Why it fails: `merge` combines maps, and the spread `...` expands the list of maps into arguments. This produces a single map of environment attributes, not a per-AZ structure. It also fails because duplicate keys across environments collide. The result cannot drive `for_each` for subnets and does not compute any subnet CIDRs with `cidrsubnet`.

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

Why it fails: This validation only checks the first statement's effect, not all statements. It also does not validate that actions and resources are non-empty. The type constraint ensures the structure but not the content rules. Therefore, it fails to enforce the requirements for all elements.

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

Why it fails: This only checks that the list of statements is not empty. It does not validate the contents of each statement, such as non-empty actions and resources or valid effect values. It is insufficient to meet the stated requirements.

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)

Why it fails: This condition checks non-empty actions and resources for all statements, but only validates the effect of the first statement. It does not ensure that every statement has a valid effect. Therefore, it does not fully enforce the requirements.

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.

Why it fails: The for expression's key is the first symbol after for, which here is the zone name, not the index, so keys are names rather than numbers. Values are the indices, not the names. Because keys are names, reordering would not replace resources, making the replacement claim incorrect as well.

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.

Why it fails: The for expression yields idx as the value, which is a number, not the full object from the data source. Only the index is stored. Reordering the source list would still change those stored index values even though the keys remain stable, so the assertion that values are unaffected is incorrect.

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.

Why it fails: The for expression maps zone name to index, so keys are names and values are indices, which is stated correctly. However, because the key is the zone name rather than the index, reordering the source list does not change which key exists; only the value stored under each key would change. The claim about key reassignment is therefore wrong.