Advanced Module Usage and Registry Practices
TERRAFORM-PRO-002 · 43 questions
- An infrastructure team finds the same 200 lines defining a VPC, subnets and route tables copy-pasted into five root configurations, and the copies have started to drift as fixes land in only some of them. What is the best next step?
- During a design review, an engineer proposes a module that wraps a single storage bucket resource and exposes every one of the resource's arguments as an input variable with no added logic or defaults. How should the reviewer respond?
- An engineer moves an existing awsinstance.web resource block from the root module into a new child module called web, where it is now named awsinstance.this. The plan proposes destroying the old instance and creating a new one. What should the engineer add to keep the existing instance?
- A shared networking module has grown to 60 input variables, many of them feature flags, because every team asked for its own option. Upgrades now regularly break someone, and new users cannot tell which inputs matter. What is the best way to evolve the design?
- A configuration creates three instances with count = length(var.names). The team refactors it to foreach = toset(var.names) so removing one name no longer shifts the others. The plan now wants to destroy and recreate all three. What should the team add?
- A team is writing a reusable module that other teams will call, sometimes with count or foreach, and wants it to create resources in the AWS account and region the caller chooses. How should the module handle the AWS provider?
- Engineers struggle to trace where a value comes from because the root module calls a module that calls another module, four levels deep, and each level re-exports its child's outputs. Which refactoring does HashiCorp's module guidance favor?
- A platform team is building a shared storage bucket module for 30 application teams. Security requires that server-side encryption and public access blocking are always present on every bucket the module creates, with no way for a caller to turn them off. How should the module implement these guardrails?
- One root configuration holds a core network that changes about once a year and application services that are redeployed several times a day. Each application deploy plans and locks the network resources too, and network changes need a separate approval chain. How should the team restructure?
- A team refactors a large configuration by renaming resources and moving several into modules, adding moved blocks for each change. Before merging, reviewers want proof the refactor does not touch any real infrastructure. Which evidence is sufficient?
- A widely used internal module has accumulated about 30 moved blocks over eight minor releases as resources were renamed and regrouped. A maintainer proposes deleting them all in the next minor release to tidy the code. Several teams still pin versions from a year ago. What should the maintainer do?
- A module maintainer deletes an output named subnetids that looked unused inside the module and publishes the change as a patch release. Several root configurations reference module.network.subnetids. What happens to those callers, and how should such a removal be handled?
- A module maintainer adds a new input variable, logretentiondays, with no default value and publishes the change as minor version 2.3.0. Every caller that runs terraform init -upgrade then fails to plan. How should the maintainer have released the new input?
- A module maintainer plans to remove the input variable subnetid in the next major version in favor of subnetids. The team wants every caller that still passes subnetid to see a clear warning now, without breaking anyone's current plans. Which Terraform 1.15 feature should they use?
- A module accepts a bucketconfig input with name, retentiondays and versioning. Callers must always set name, and should be able to omit retentiondays and versioning and receive 30 and true, while Terraform still type-checks every attribute. How should the variable type be declared?
- Callers of a shared network module keep passing malformed values for the vpccidr input, and the error only appears deep in the cloud provider's API response during apply. The maintainer wants a clear, module-specific error at plan time. What should the maintainer add?
- A shared module starts using a language feature added in Terraform 1.11. Teams still running Terraform 1.9 now see confusing configuration errors instead of a clear message that their CLI is too old. What should the maintainer add to the module?
- A module is at version 1.4.2. Two changes are ready: first, a fix for a wrong default tag value with no interface change, released on its own; second, renaming the input instancesize to instancetype. Following semantic versioning, which versions should the two releases carry?
- A caller adds foreach to a module block to create one copy of a shared module per team. terraform init now fails, reporting that the module cannot be used with foreach because it contains its own provider configuration. What must change for the caller's design to work?
- A new team trying to adopt an internal module cannot tell from its files which inputs are required, what each one means, or how a typical call looks, and keeps asking the maintainers. What change best makes the module's contract self-documenting?
- A disaster-recovery module creates resources in a primary and a secondary AWS region. The maintainer wants callers to pass two separately configured AWS providers into the module, and wants the module to declare that requirement explicitly. What belongs in the module?
- A module's subnetids output used to return a list. A refactor wrapped the value in toset() and consumers that index subnetids[0] broke without any warning from the module itself. Which Terraform 1.15 capability makes the output's type an enforced part of the contract?
- An engineer wants to use the VPC module listed on the public Terraform Registry under the namespace terraform-aws-modules, the module name vpc and the target provider aws, and pin it with the version argument. Which source value is correct?
- An organization named acme-corp publishes an internal module named vpc for the aws provider to its HCP Terraform private registry. A team wants to call it from a configuration and pin a version. Which source value should the module block use?
- A production root configuration calls a registry module at version 3.2.1. CI checks out the repository fresh and runs terraform init on every run. The team requires that a newly published module release never reach production until someone deliberately changes the configuration. Which approach meets this?
- A team wants to publish a module that manages VPC endpoints for AWS to the public Terraform Registry. The code already follows the standard module structure. What must the GitHub repository look like before the registry can publish the first version?
- A platform team publishes modules to the HCP Terraform private registry. They want every Git release tag such as v2.4.0 to become a distinct, pinnable module version automatically, with no one typing a version number into HCP Terraform. Which publishing type should they choose?
- A configuration uses a public registry module pinned to version 4.x. The team wants to upgrade to 5.0, whose release notes say several resources were renamed and regrouped inside the module. What is the safest upgrade procedure?
- A security reviewer asks whether a third-party provider in a new configuration is maintained by HashiCorp, by a technology partner, or by an individual community contributor. Where is this information shown?
- Business analysts need to provision standard reporting environments themselves through HCP Terraform, choosing only a few approved settings, without writing or reviewing any Terraform configuration. The platform team already maintains the module in the private registry. What should they enable?
- A registry module named consul for the aws provider in the hashicorp namespace contains several submodules. A team needs only the submodule stored in the module's modules/consul-cluster directory. How should the module block's source reference it?
- An engineer is writing a module block for a public registry module for the first time and needs a reliable list of its required and optional inputs with their types and defaults, its outputs, and its provider dependencies. Which source should the engineer consult?
- A module computes resource names from several input variables. The maintainer wants a test in a .tftest.hcl file that checks the computed names without creating any real infrastructure. How should the run block be configured?
- A module test must fail with a message that tells the reader exactly what went wrong when the module's endpointurl output does not start with https. What belongs inside the run block in the .tftest.hcl file?
- A module's unit tests must run in a CI job that has no cloud credentials at all, yet the module's resources have computed attributes, such as IDs and ARNs, that other resources and outputs reference. What should the test files use?
- A module reads data.awsami.base and passes its id to awsinstance.web. The team's unit test uses mockprovider "aws" {} and a default apply-mode run block, and it must assert that awsinstance.web.ami equals ami-0123456789abcdef0 instead of a random generated string. Which addition to the test file makes the data source return that exact value?
- A test file uses mockprovider "aws" {} plus overrideresource { target = awss3bucket.logs, values = { arn = "arn:aws:s3:::logs" } }. A run block with command = plan asserts that output.bucketarn equals that ARN, but the assertion fails because the value is unknown. The run must remain a plan-only run. Which change fixes it?
- variable "environment" has a validation block that only allows dev, stage or prod. A module author wants a test that passes precisely because the value qa is rejected, and fails if the validation is ever removed. Which run block achieves this?
- A module repository contains main.tf, variables.tf and a tests directory holding networktest.hcl and defaultstest.hcl, each with run and assert blocks. Running terraform test from the module root reports that no tests were found. What is the cause?
- A test file has 30 run blocks. Each uses its own setup module or a distinct statekey, none references another run's outputs, and the whole file runs one run at a time and takes too long. The authors want the independent runs to execute concurrently without splitting the file. Which change does this?
- An integration test for an S3 module has run blocks with no command attribute and real AWS credentials. A new engineer asks what happens to the buckets the test creates once terraform test finishes. Which answer is correct?
- A module under test needs an existing VPC ID. The repository contains a helper configuration in ./testing/vpc that creates a VPC and outputs vpcid. The integration test must create that VPC first, then run the module under test against it. How should the test file be written?
- A test file sets bucketprefix = "test" and region = "us-east-1" in a file-level variables block, and six run blocks use those values. One run must check behaviour when bucketprefix is "audit" while still using the same region. What is the cleanest way to do this?