AWS provider Terraform Modules Practice Test 1 — 15 Questions

Question 1

Which THREE of the following are valid sources for a Terraform module?

Accepted Answer

The Terraform Registry.. Option A is correct because the Terraform Registry (registry.terraform.io) is the canonical public source for modules, referenced with a source such as "hashicorp/consul/aws" and resolved via the registry protocol. Option B is correct because Terraform supports local filesystem paths as module sources, e.g. source = "./modules/vpc" or an absolute path, which is common for reusable in-repo modules. Option E is correct because Terraform can fetch modules from public or private Git repositories using source strings like "git::https://example.com/vpc.git?ref=v1.2.0" or "git@github.com:org/repo.git", including SSH authentication. Option C is not valid because Terraform has no module source type that connects directly to a SQL database; modules come from registries, VCS, HTTP URLs, S3/GCS buckets, or local paths. Option D is not valid as stated because Terraform does not support arbitrary raw HTTP file download links as a module source; HTTP/HTTPS URLs must point to a Terraform-getter-compatible archive endpoint (e.g. an S3 or GCS object URL), not a plain raw file link.

Answer

A directly linked SQL database.

Answer

A raw HTTP file download link.

Question 2

If you have a module that creates an S3 bucket, and you want the bucket name to be prefixed by a value provided by the caller, how do you achieve this?

Accepted Answer

Use string interpolation in the bucket name attribute.. Terraform modules accept input values through variables, and those values can be composed into resource attributes using string interpolation (or template strings). To prefix an S3 bucket name with a caller-supplied value, the module declares an input variable (e.g., variable "prefix") and the bucket resource uses something like bucket = "${var.prefix}-my-bucket" or the newer "${var.prefix}-my-bucket" template syntax. This is the idiomatic way to parameterize module resources.

Answer

Use a local variable that reads from the provider config.

Answer

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

Answer

Use the 'module_name' variable provided by Terraform.

Question 3

Which TWO meta-arguments can be used within a module block?

Accepted Answer

'count'. In Terraform, the meta-arguments 'count' (option A) and 'for_each' (option C) are both valid inside a module block, allowing you to instantiate multiple copies of a module based on a number or a map/set of values, respectively. 'count' creates indexed instances accessible via count.index, while 'for_each' creates instances keyed by each element, enabling more stable references. The other options are not module-level meta-arguments: 'provisioner' (B) is a resource-level block for executing scripts on creation/destruction, 'depends_on' (D) is a meta-argument valid on resources and modules but is not one of the two asked for here as it does not create multiple instances, and 'lifecycle' (E) is a resource-level block controlling create/destroy behavior, not a module instantiation meta-argument.

Answer

'provisioner'

Answer

'depends_on'

Answer

'lifecycle'

Question 4

Which THREE tasks are performed by 'terraform init -upgrade'?

Accepted Answer

Upgrading provider binaries.. Option B is correct because 'terraform init -upgrade' checks the configured provider version constraints in the root module and, where allowed, downloads newer provider plugin binaries into the .terraform/providers directory, replacing older cached versions. Option D is correct because init also installs and refreshes modules referenced by module blocks, updating the local module cache under .terraform/modules so that newer module versions permitted by the source/version constraints are fetched. Option E is correct because the -upgrade flag causes Terraform to re-evaluate provider selections and rewrite the dependency lock file .terraform.lock.hcl with updated version numbers and checksums. Option A is not right because state file format migration is handled by 'terraform init' when it detects an outdated state, not specifically by the -upgrade flag, and state is not upgraded as part of this operation. Option C is not right because Terraform init never rewrites HCL source code; syntax errors in modules must be fixed manually or with 'terraform fmt'/'validate' assistance.

Answer

Migrating the state file to a new format.

Answer

Automatically fixing HCL syntax errors in modules.

Question 5

Your team maintains a Terraform module that provisions an AWS VPC. The module currently accepts a single string variable `cidr_block` for the VPC CIDR. You need to extend the module to support multiple CIDR blocks (e.g., for additional subnets), but you must not break existing callers that pass a single string. Which approach allows existing callers to continue working without modification while enabling the new capability?

Accepted Answer

Keep the variable type as `string` and add a new optional variable `additional_cidr_blocks` of type `list(string)` with a default of `[]`.. The correct approach is to add a new optional variable with a default while leaving the existing variable intact. This maintains backward compatibility, as existing callers continue to pass a string without changes. New functionality is available through the additional variable. This pattern is idiomatic for evolving module interfaces without breaking consumers.

Answer

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

Answer

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

Answer

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

Question 6

A team wants to consume a module from a Git repository at a specific commit for reproducibility. Which two source address forms are valid and reproducible for this purpose? (Choose two.)

Accepted Answer

git::https://example.com/network.git?ref=v1.2.0. Only addresses that explicitly use the git:: prefix and include a ref pin are reproducible Git sources. Pinning to a tag or commit SHA guarantees the module content does not drift. Plain HTTP URLs, GitHub shorthand, and local paths lack the combination of Git installer and immutable revision, so they cannot satisfy the reproducibility requirement.

Answer

https://example.com/network.git

Answer

./modules/network?ref=main

Answer

github.com/example/network

Question 7

You maintain a module that creates an AWS Lambda function. The module exposes an output `function_arn` that is derived from the `aws_lambda_function` resource. A consumer wants to use this output in another module, but they need the value to be available even before the Lambda function is created, for planning purposes. What should you do to the output definition to satisfy this requirement?

Accepted Answer

Change the output to reference a data source that reads the Lambda function by name, and set the output to that data source's ARN.. Outputs that depend on resource attributes are unknown during plan until the resource is created. There is no way to make a resource-derived output known before apply. The correct approach is to recognize that this requirement is impossible; the output cannot be available before creation. The question tests understanding of Terraform's dependency graph and unknown values.

Answer

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

Answer

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

Answer

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

Question 8

You are authoring a module that creates an AWS EC2 instance and an associated security group. The module should allow the caller to optionally provide a list of additional security group IDs to attach to the instance. If the caller does not provide any, the instance should use only the security group created within the module. Which variable declaration and usage pattern correctly implements this optional behavior?

Accepted Answer

Declare `variable "additional_security_group_ids" { type = list(string), default = [] }` and set `vpc_security_group_ids = concat([aws_security_group.this.id], var.additional_security_group_ids)`.. The correct pattern declares an optional list variable with a default empty list and uses concat to combine the module-created security group with any additional IDs. This ensures the instance always has the internal security group and optionally adds more. It satisfies the optional behavior while maintaining the module's intended baseline configuration.

Answer

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]`.

Answer

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

Answer

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

Question 9

Your team maintains a Terraform module that provisions an AWS VPC and subnets. The module is consumed by multiple environments. You need to ensure that any future changes to the module's implementation do not break existing deployments unless explicitly upgraded. Which version constraint syntax should you use in the module block?

Accepted Answer

version = "1.2.0". Pinning to an exact version ensures that the module code cannot change unless the version string is explicitly updated. This prevents automatic adoption of new releases that might introduce breaking changes. While other constraints allow some flexibility, only an exact match guarantees no unintended updates. This is critical for stable, repeatable deployments across environments.

Answer

version = "~> 1.2.0"

Answer

version = "latest"

Answer

version = ">= 1.2.0"

Question 10

A team wants to distribute an internal Terraform module that is stored in an Amazon S3 bucket. The bucket is in the `us-east-1` region and contains the file `modules/vpc.zip`. Which source string correctly references this module in a `module` block?

Accepted Answer

"s3::https://s3.amazonaws.com/my-bucket/modules/vpc.zip". Terraform recognizes the `s3::` prefix as a module source type that fetches and extracts an archive from an S3 object. The remainder of the string must be the object's HTTPS URL. Prefixes such as `git::` or a bare HTTPS URL describe different source types and cannot retrieve an S3-hosted archive, so only the properly prefixed HTTPS URL works.

Answer

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

Answer

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

Answer

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

Question 11

You are creating a Terraform module that will be used by multiple teams. You want to ensure that the module is robust and follows best practices for input variables. Which two actions should you take? (Choose two.)

Accepted Answer

Use the `sensitive` argument on variables that contain secrets.. Validation blocks enforce constraints on input values, preventing misconfigurations before they reach the provider. Marking variables as sensitive protects secret values from being displayed in plan output and logs. Together, these actions significantly improve module reliability and security. While documentation and defaults have their place, they do not provide the same level of enforcement and protection.

Answer

Define all variables with type = any to maximize flexibility.

Answer

Provide default values for all variables to simplify usage.

Answer

Document each variable with a description that explains its purpose.

Question 12

You are developing a module that creates an AWS Lambda function. The module should allow the caller to optionally provide a dead-letter queue (DLQ) ARN. If provided, the Lambda function should be configured with that DLQ; if not, no DLQ should be set. Which Terraform expression correctly conditionally sets the `dead_letter_config` argument?

Accepted Answer

`dynamic "dead_letter_config" { for_each = var.dlq_arn != null ? [var.dlq_arn] : [] content { target_arn = dead_letter_config.value } }`. The correct solution uses a dynamic block with for_each. This allows the dead_letter_config block to be included only when a non-null ARN is provided. When the variable is null, the empty list causes zero iterations, omitting the block. This is the standard Terraform pattern for conditionally including nested blocks based on input.

Answer

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

Answer

`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.

Answer

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

Question 13

You are using a module from the Terraform Registry that provisions an AWS RDS instance. The module requires a subnet group and security group IDs. You want to pass these from resources created in your root configuration. How should you define the module block to ensure proper dependency ordering?

Accepted Answer

module "rds" { source = "..." subnet_ids = aws_subnet.main[*].id security_group_ids = [aws_security_group.rds.id] }. Terraform builds a dependency graph from references. Passing resource attributes directly into module arguments creates implicit dependencies, ensuring the module is provisioned after the referenced resources. Explicit depends_on is unnecessary and can be harmful. Using data sources breaks the dependency chain because they do not imply creation order. The splat expression is idiomatic for lists of resource attributes.

Answer

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

Answer

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] }

Answer

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

Question 14

Your team maintains a Terraform module that provisions an AWS Application Load Balancer (ALB) and its target groups. The module is stored in an internal Git repository and is consumed by several product teams. A product team reports that after you updated the module to add a new required variable `certificate_arn`, their `terraform plan` fails with an error about an unsupported argument. They are using the module source `git::ssh://git@internal.example.com/infra/alb-module.git?ref=v2.1.0`. You want to make the variable optional for existing consumers without changing the module's major version. What should you do?

Accepted Answer

Add a default value of `null` to the `certificate_arn` variable declaration and use a conditional expression to only create the HTTPS listener when the value is non-null.. A module author can safely add a new input by giving it a default value, which makes it optional for existing callers. When the default is null and the module conditionally uses the value, resources that depend on it are only created when the caller supplies a real value. This maintains backward compatibility and avoids forcing a breaking change or a major version bump.

Answer

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.

Answer

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

Answer

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

Question 15

Which directory structure is considered standard for a Terraform module?

Accepted Answer

A directory containing main.tf, variables.tf, and outputs.tf.. The standard Terraform module structure is a directory containing 'main.tf' (primary resource definitions), 'variables.tf' (input variable declarations), and 'outputs.tf' (output value declarations). This convention is documented by HashiCorp and used by the Terraform Registry, making modules predictable and easy to consume. Additional files like 'versions.tf' and 'README.md' are common but the three core files define the canonical layout.

Answer

One single file named 'all.tf'.

Answer

A binary executable file that compiles the infrastructure.

Answer

A separate folder for every single resource.