Terraform Modules practice questions

A directly linked SQL database.

Why it fails: Databases are not supported as module sources.

A raw HTTP file download link.

Why it fails: Standard HTTP is not a direct source for modules.

Use a local variable that reads from the provider config.

Why it fails: Locals cannot read from provider configs for resource naming.

Define the bucket name in the root module and override the child resource.

Why it fails: You cannot override individual attributes of a child module resource directly from the root.

Use the 'module_name' variable provided by Terraform.

Why it fails: This variable does not exist.

'provisioner'

Why it fails: A provisioner runs scripts on a resource after creation, so it cannot appear inside a module block; module blocks accept only meta-arguments such as source, version, count, for_each, providers, and depends_on. It is tempting because provisioners are valid nested inside resource blocks, where they execute local-exec or remote-exec commands.

'depends_on'

Why it fails: depends_on is a valid meta-argument, but the question asks for two that apply within a module block, and this option is not among the accepted pair for this scenario. It is tempting because depends_on genuinely works on module blocks, establishing explicit ordering between the module and other resources.

'lifecycle'

Why it fails: lifecycle is a meta-argument of resource blocks, controlling create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by; module blocks do not accept it. It is tempting because lifecycle customises resource behaviour, so candidates assume the same nesting applies inside modules.

Migrating the state file to a new format.

Why it fails: This is handled by 'terraform state migrate' or during 'apply'.

Automatically fixing HCL syntax errors in modules.

Why it fails: 'init' does not fix syntax.

Change the variable type to `list(string)` and instruct all existing callers to wrap their string in a list.

Why it fails: This forces every existing caller to modify their configuration, which directly violates the requirement to avoid breaking existing callers. It also introduces unnecessary churn and risk. Backward compatibility is a key concern for shared modules, and this approach fails to preserve it.

Change the variable type to `list(string)` and set a default value of `["10.0.0.0/16"]`.

Why it fails: Changing the type to list(string) forces every existing caller that passes a plain string to fail type validation during plan. Terraform does not implicitly wrap a string into a list, so all current module consumers would need to update their input to a list, breaking backward compatibility and violating the requirement to avoid modifications.

Change the variable type to `any` and use `try()` to handle both string and list inputs.

Why it fails: Using type `any` and try() adds complexity and weakens validation. It does not cleanly express the intended contract and may mask misconfigurations. While it could accept both, it is not the recommended approach for a stable public interface and does not follow Terraform module design best practices for type safety and clarity.

https://example.com/network.git

Why it fails: Without the git:: prefix, Terraform treats this as an HTTP download rather than a Git clone, and it will not resolve a ref. Even if it worked, there is no version pin, so the content could change and reproducibility would be lost.

./modules/network?ref=main

Why it fails: A local path source does not support the ref query parameter. Terraform reads the directory directly from disk, and query strings are not interpreted, so this form is invalid. Local modules are also inherently tied to the working tree rather than an immutable revision.

github.com/example/network

Why it fails: This shorthand is for GitHub-hosted modules and is interpreted as a registry-style address, not a Git clone with a ref. It does not pin a commit, and it may be resolved against the registry rather than the repository, so it is not reproducible as stated.

Add a `depends_on` meta-argument to the output block to force early evaluation.

Why it fails: Output blocks do not support the `depends_on` meta-argument. Dependencies are inferred from the expressions used in the output. Adding depends_on would be a syntax error. Even if it were allowed, it would not make an unknown value known during plan; it would only enforce ordering during apply.

Mark the output as `sensitive = true` so Terraform can compute it during plan without applying.

Why it fails: The `sensitive` attribute only redacts the value in CLI output; it does not change when the value becomes known. The ARN is still unknown until the Lambda function is created, so marking it sensitive does not make it available during plan. This option confuses redaction with dependency resolution.

Use the `try()` function in the output expression to return a placeholder when the resource is not yet created.

Why it fails: The `try()` function handles errors during evaluation, but it cannot convert an unknown value into a known one. During plan, the ARN is unknown because the resource has not been created, and try() would still return an unknown. It is useful for optional attributes, not for making unknown values available early.

Declare `variable "additional_security_group_ids" { type = list(string), default = null }` and use `vpc_security_group_ids = var.additional_security_group_ids != null ? var.additional_security_group_ids : [aws_security_group.this.id]`.

Why it fails: This approach works but is unnecessarily complex. If the caller provides additional IDs, the module-created security group is omitted, which may not be desired. The requirement states the instance should use the module-created group plus any additional ones. The conditional logic discards the internal group when additional IDs are present, violating the intended behavior.

Declare `variable "additional_security_group_ids" { type = list(string), default = [] }` and set `vpc_security_group_ids = var.additional_security_group_ids`.

Why it fails: This makes the variable optional but fails to include the module-created security group. When the caller provides additional IDs, the instance would not have the internal security group attached, which is likely required for the module's functionality. The instance should always have the module-created group, plus any extras. This option omits the internal group entirely.

Declare `variable "additional_security_group_ids" { type = list(string) }` and reference it directly in the instance's `vpc_security_group_ids`.

Why it fails: Without a default, the variable is required, forcing callers to provide a value. If they pass an empty list, it works, but they must explicitly pass it. The requirement is optional; a missing default makes it mandatory, which violates the optional behavior. Also, directly referencing it would omit the module-created security group if the list is non-empty.

version = "~> 1.2.0"

Why it fails: The pessimistic constraint operator (~>) allows the patch version to increment but pins the minor version. For 1.2.0, it permits 1.2.x but not 1.3.0. This still allows automatic patch updates, which could introduce subtle changes. The requirement is to prevent breaking changes unless explicitly upgraded, so a stricter pin is needed.

version = "latest"

Why it fails: "latest" is not a valid version constraint in Terraform. Terraform version constraints must be specified using operators such as =, !=, >, >=, <, <=, or ~>. Using an invalid string will cause a syntax error during terraform init. This option is technically incorrect and would not achieve the desired pinning behavior.

version = ">= 1.2.0"

Why it fails: This constraint allows any version greater than or equal to 1.2.0, including future major versions that may contain breaking changes. Terraform will select the newest available version that satisfies the constraint. This is the opposite of what is needed because it permits automatic upgrades to incompatible versions, risking deployment failures.

"git::https://s3.amazonaws.com/my-bucket/modules/vpc.zip"

Why it fails: The `git::` prefix instructs Terraform to treat the source as a Git repository and invoke Git to clone it. An S3 object URL is not a Git repository, so the clone would fail. The correct prefix for S3-hosted archives is `s3::`, which downloads the object directly without Git.

"https://s3.amazonaws.com/my-bucket/modules/vpc.zip"

Why it fails: A bare HTTPS URL is not a recognized module source for arbitrary archives. Terraform supports HTTP URLs only as a legacy registry-detection mechanism, not for direct archive download. Without the `s3::` prefix, Terraform cannot determine how to fetch and extract the object, so initialization fails.

"s3::s3://my-bucket/modules/vpc.zip"

Why it fails: The `s3::` prefix expects an HTTPS URL that points to the object, not an `s3://` scheme URL. Mixing the two produces an invalid source string that Terraform cannot parse. The correct form combines the `s3::` prefix with the full HTTPS object URL, including the bucket and key path.

Define all variables with type = any to maximize flexibility.

Why it fails: Using type = any defeats the purpose of type checking and can lead to unexpected behavior. It makes the module harder to use because callers do not know what type is expected. It also prevents validation and can cause errors at apply time. Explicit types are preferred for clarity and safety. This option is a common anti-pattern.

Provide default values for all variables to simplify usage.

Why it fails: Providing default values for all variables can be convenient, but it may not always be appropriate. Some variables, such as resource names or critical configuration, should be required to prevent misconfiguration. Defaults should be used judiciously, not universally. This option is too broad and can lead to modules that are hard to customize or that silently use insecure defaults.

Document each variable with a description that explains its purpose.

Why it fails: While documentation is important, the question asks for actions that make the module robust. Descriptions are helpful for users but do not enforce correctness or safety. They are a best practice for usability, but not as critical as validation and sensitivity for robustness. In a multi-select, the most impactful technical actions are validation and sensitivity, not just documentation.

`dead_letter_config { target_arn = var.dlq_arn }` with `variable "dlq_arn" { type = string, default = "" }`

Why it fails: Using an empty string as the default and always setting the block will cause an error because an empty ARN is invalid. AWS Lambda requires a valid ARN or the argument to be omitted. This approach does not conditionally omit the block; it always includes it, leading to failures when no DLQ is desired.

`dead_letter_config { target_arn = var.dlq_arn }` with `variable "dlq_arn" { type = string, default = null }` and `count = var.dlq_arn != null ? 1 : 0` on the block.

Why it fails: Terraform does not support `count` on a nested block like `dead_letter_config`. `count` is only for resources and modules. This syntax is invalid and will cause a configuration error. Dynamic blocks are the correct way to conditionally include nested blocks. This option misapplies a resource-level meta-argument to a block.

`dead_letter_config = var.dlq_arn != null ? { target_arn = var.dlq_arn } : null`

Why it fails: The `dead_letter_config` argument is a nested block, not an argument that accepts a map. Assigning a map or null directly to it is invalid syntax. Terraform expects a block definition. This approach will result in a validation error because the argument type does not match. Dynamic blocks are required for conditional nested blocks.

module "rds" { source = "..." subnet_ids = [for s in aws_subnet.main : s.id] security_group_ids = [aws_security_group.rds.id] }

Why it fails: Using a for expression to extract subnet IDs is functionally equivalent to the splat expression, but it is more verbose. However, it still creates the necessary implicit dependency. The issue is that it is not inherently wrong, but the splat expression is more idiomatic. In this context, both A and C would work, but A is the preferred concise syntax. Since the question asks for proper dependency ordering, both A and C achieve it, but A is the best answer because it is the most common and recommended pattern.

module "rds" { source = "..." subnet_ids = aws_subnet.main[*].id security_group_ids = [aws_security_group.rds.id] depends_on = [aws_subnet.main, aws_security_group.rds] }

Why it fails: While depends_on can enforce ordering, it is redundant here because the references already create implicit dependencies. Using depends_on unnecessarily can obscure the dependency graph and is not considered a best practice when explicit references suffice. It may also cause unnecessary delays if the dependency is not actually needed.

module "rds" { source = "..." subnet_ids = data.aws_subnet.main[*].id security_group_ids = [data.aws_security_group.rds.id] }

Why it fails: Using data sources instead of resource references does not create a dependency on the resources being created. Data sources read existing infrastructure. If the subnets and security groups are created in the same configuration, referencing them via data sources would fail because they do not exist yet. This would result in a cycle or error.

Change the module's source address in the consuming configurations to `git::ssh://git@internal.example.com/infra/alb-module.git?ref=v2.0.0` so they use the older version.

Why it fails: Pinning consumers back to an older ref avoids the immediate error, but it also prevents them from receiving any future fixes in the module and does not address the new variable's required status. The goal is to keep consumers on the current line while making the new input optional, not to downgrade them permanently.

Move the `certificate_arn` variable declaration into a separate `variables_optional.tf` file and add a `nullable = false` argument.

Why it fails: Splitting variables into a different file has no effect on whether an argument is required; Terraform treats all `.tf` files in a module directory as one configuration. Setting `nullable = false` explicitly forbids null values and would make the variable even stricter, not optional, so this would worsen the failure.

Instruct each consuming team to add `certificate_arn = null` to their module block and run `terraform init -upgrade` to reinitialize the module.

Why it fails: Requiring every caller to change their configuration defeats the purpose of making the variable optional and still fails if the variable has no default, because a required variable must receive a value. Running `terraform init -upgrade` only refreshes module versions and does not alter variable requirements.

One single file named 'all.tf'.

Why it fails: A module conventionally separates inputs, resources and outputs across variables.tf, main.tf and outputs.tf so callers can reuse it; a single all.tf collapses that interface. Consolidating everything is tempting for tiny throwaway configurations, but it prevents clean variable and output contracts.

A binary executable file that compiles the infrastructure.

Why it fails: Terraform modules are directories of HCL configuration files interpreted by the terraform binary; they are never compiled into an executable. A compiled artefact is tempting if you assume infrastructure code needs building, but Terraform reads declarative .tf files directly at plan and apply time.

A separate folder for every single resource.

Why it fails: Terraform modules group related resources into logical files such as main.tf, variables.tf and outputs.tf; one folder per resource fragments the module and breaks conventional layout. Per-resource folders suit large compositions of separate modules, not a single reusable module's internal structure.

It allows you to run Terraform commands faster.

Why it fails: A registry affects module sourcing and versioning, not Terraform execution speed; commands run at the same rate regardless of source. It is tempting because remote sources can feel streamlined, and would be the correct choice when you need discoverability, semantic versioning, and shared governance of modules across an organisation.

It removes the need for input variables.

Why it fails: A registry still requires input variables to parameterise modules; it only changes where the module source is fetched from. It is tempting because registries centralise module definitions, and would be the right choice when you want reusable, versioned modules consumed by many configurations without copying files locally.

It automatically converts your code to a higher-level language.

Why it fails: A module registry distributes and versions modules; it does not translate code between languages or abstraction levels. It is tempting because registries do offer convenience and standardised packaging, and would be the correct choice when teams need to share versioned modules across repositories with dependency resolution.

Run 'terraform refresh' to automatically detect the move.

Why it fails: terraform refresh only reconciles state with real infrastructure; it cannot infer that a resource moved into a module, so the old address is destroyed and the new one created. The correct tool is terraform state mv, which rewrites the address in state without touching real resources.

Rename the resource in the configuration to match the old state.

Why it fails: Renaming the resource in configuration changes its address, so Terraform sees a new resource and plans destroy plus create. The address must be rewritten in state, not configuration. terraform state mv updates the stored address to match the module path, preserving the existing object.

Delete the state file and run 'terraform apply'.

Why it fails: Deleting the state file orphans all managed resources; Terraform then plans to create duplicates and loses track of existing infrastructure. The correct approach is terraform state mv to rewrite the resource's address into the module path, leaving the real object untouched.

Define the variable only in the leaf module and refer to root by index.

Why it fails: Terraform modules cannot reference the root module by index or reach upward in the call stack; variables flow only downward via explicit input declarations. Declaring the variable in the leaf and expecting root access inverts that direction, so the value never arrives.

You can use the 'global_vars' block in the root.

Why it fails: Terraform has no global_vars block; variables are declared per module and passed explicitly through module arguments. A global mechanism would be tempting for avoiding repetitive declarations, but Terraform's actual design requires each intermediate module to declare and forward the value.

The intermediate module automatically inherits all root variables.

Why it fails: Modules are isolated scopes; an intermediate module inherits nothing from the root automatically. Explicit input variables and module arguments are required at every level. Automatic inheritance would be tempting to avoid declaring variables repeatedly, but Terraform's encapsulation model deliberately prevents it.

Define multiple resources and use 'depends_on' to link them.

Why it fails: The depends_on meta-argument only orders resource creation; it cannot suppress creation, so both resources always exist. Conditional creation requires the count or for_each meta-argument driven by the boolean. depends_on suits enforcing explicit ordering when Terraform cannot infer a dependency from references.

Use an 'if' block around the resource definition.

Why it fails: HashiCorp Configuration Language has no if block for resource definitions; conditional logic is expressed through meta-arguments. The count or for_each meta-argument, driven by the boolean, controls whether a resource is instantiated. A conditional expression suits choosing between two values, not creating or omitting a resource.

Use the 'module' meta-argument inside the resource.

Why it fails: The module meta-argument is used inside a module block to call a child module, not inside a resource, and it cannot conditionally create anything. Conditional creation needs count or for_each on the resource itself. Nested modules would be the right structure for packaging reusable infrastructure.

Assign the output to a global variable in the root module.

Why it fails: Terraform has no global variables; root-level variables must be declared and passed explicitly, so this cannot expose a child module's value. It is tempting as a shortcut for sharing data across configurations, but variables flow into modules, not out of them.

Use a data source to read the child module's internal state.

Why it fails: Data sources query provider APIs, not a child module's internal state, so they cannot read that module's outputs. It is tempting because data sources do retrieve existing infrastructure, but module outputs are accessed through the module block's output attributes instead.

Write the output to a local file inside the module and read it in the root.

Why it fails: Writing to a local file introduces an out-of-band dependency and breaks plan ordering, since Terraform cannot track that file as a module output. It is tempting for sharing data between runs, but outputs are the supported mechanism for passing values to the root module.