20+ practice questions focused on Terraform Modules — one of the most tested topics on the HashiCorp Certified: Terraform Authoring and Operations Professional (AWS provider) (AWS provider) exam. Each question includes a detailed explanation so you learn why the right answer is correct.
Start Terraform Modules PracticeWhich THREE of the following are valid sources for a Terraform module?
Explanation: 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.
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?
Explanation: 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.
Which TWO meta-arguments can be used within a module block?
Explanation: 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.
Which THREE tasks are performed by 'terraform init -upgrade'?
Explanation: 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.
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?
Explanation: 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.
+15 more Terraform Modules questions available
Practice all Terraform Modules questions1. Baseline your knowledge
Start with 10 questions to gauge your current understanding of Terraform Modules. This tells you whether you need a concept refresher or just practice.
2. Review every explanation
For each question — right or wrong — read the full explanation. Understanding why an answer is correct is more valuable than knowing the answer itself.
3. Focus on exam traps
Terraform Modules questions on the AWS provider frequently use trap wording. Look for subtle differences in answers that test your precision, not just general knowledge.
4. Reach 80% consistently
Do repeated sessions until you score 80%+ three times in a row. Then move to mixed-mode practice to test cross-topic recall under realistic conditions.
The exact number varies per candidate. Terraform Modules is tested as part of the HashiCorp Certified: Terraform Authoring and Operations Professional (AWS provider) (AWS provider) blueprint. Practicing with targeted Terraform Modules questions ensures you can handle any format or difficulty that appears.
Yes. Courseiva provides free AWS provider practice questions across all exam topics and domains. The platform includes topic-based practice, mock exams, missed-question review, bookmarked questions, and readiness tracking — no account required.
Difficulty is subjective, but Terraform Modules is a high-priority exam concept tested in multiple ways — direct recall, scenario analysis, and command-output interpretation. Consistent practice is the best way to build confidence.
Launch a full Terraform Modules practice session with instant scoring and detailed explanations.
Start Terraform Modules Practice →