AWS provider Practice Test 13 — 15 Questions

Question 1

Your organization uses HCP Terraform with a VCS-driven workflow. A developer accidentally merges a change to the main branch that modifies a production workspace's Terraform code. The workspace is configured to auto-apply. Which mechanism can prevent the change from being applied immediately?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Enable 'Manual Apply' in the workspace settings.. Manual Apply is the workspace setting that forces a user to explicitly confirm an apply after a successful plan, even if auto-apply is enabled. It acts as an approval gate. The other options do not prevent an immediate apply: run triggers are for cross-workspace runs, soft-mandatory policies allow overrides, and version pinning is unrelated.

Answer

Use a Sentinel policy with 'soft-mandatory' enforcement.

Answer

Configure a run trigger to delay the apply.

Answer

Set the workspace's Terraform version to a specific version.

Question 2

Your team uses HCP Terraform with a workspace connected to a GitHub repository. You need to ensure that no changes can be applied to production unless a specific compliance policy passes. The policy should block the apply if it fails, but authorized users should be able to override the failure with a justification. Which Sentinel enforcement level should you use?

Accepted Answer

soft-mandatory. Soft-mandatory enforcement blocks an apply when a policy fails but permits authorized users to override the failure with a justification. This balances compliance with operational flexibility. Advisory does not block, hard-mandatory does not allow overrides, and 'mandatory' is not a valid enforcement level.

Answer

mandatory

Answer

advisory

Answer

hard-mandatory

Question 3

Your team uses HCP Terraform with a VCS-driven workflow. You have a workspace that deploys to AWS. A developer wants to test a change that modifies an IAM policy without affecting the main branch. They create a feature branch and push changes, but the workspace is configured to track the `main` branch. What is the most appropriate way to allow the developer to test their change in isolation?

Accepted Answer

Create a new workspace that tracks the feature branch and uses the same Terraform configuration.. Isolating feature branch testing requires a separate workspace that tracks the feature branch, providing independent state and variables. Changing the existing workspace's branch or using local targeted applies introduces risk of state corruption or bypasses governance. Run triggers are for chaining workspaces, not for branch isolation.

Answer

Change the existing workspace's VCS branch to the feature branch, run apply, then switch back to main.

Answer

Use the `-target` flag in a local `terraform apply` to apply only the IAM policy changes.

Answer

Create a run trigger from the main workspace to the feature branch workspace.

Question 4

Your team uses HCP Terraform with a VCS-connected workspace. A developer pushes a commit to the tracked branch while a plan is already running. What does HCP Terraform do with the newly triggered run by default?

Accepted Answer

It queues the new run, and the previous run continues until it finishes or is canceled.. By default, a commit that triggers a run while another run is active creates a queued run rather than interrupting the active one. The workspace serializes runs to protect state, so the new commit waits its turn. Teams can enable run discarding to drop stale queued runs, but the in-progress run is left to finish.

Answer

It discards the in-progress run and immediately starts the new run with the latest commit.

Answer

It merges the new commit into the running plan and re-plans automatically without user action.

Answer

It blocks the push from reaching the VCS provider until the running plan is approved.

Question 5

You are using a module from the public Terraform Registry in a production configuration. After running terraform init -upgrade, you notice that the module version changed unexpectedly and caused a breaking change in your infrastructure. You want to prevent this from happening again. Which approach should you take?

Accepted Answer

Pin the module to a specific version using the version argument in the module block.. Pinning the module to a specific version using the version argument ensures that Terraform always uses that exact version, preventing unexpected upgrades that could introduce breaking changes. While other methods like local copies or avoiding -upgrade might reduce risk, they do not provide the same level of control and are not enforced by Terraform. The version argument is the recommended and reliable way to lock a module version.

Answer

Run terraform init without the -upgrade flag after the initial installation.

Answer

Set the version argument to a range like ">= 1.0.0" to allow flexibility while avoiding major version changes.

Answer

Use a local path to a copy of the module that you maintain manually.

Question 6

A module uses for_each over a map to create several IAM roles, and the map keys are derived from a variable that callers may change. The team wants to avoid replacing roles when only the map's values change. Which change to the module is required?

Accepted Answer

Ensure the for_each keys are stable and derived only from values that should not change. for_each instances are addressed by their map keys, so key stability is what determines whether Terraform updates or replaces resources. When only values change, in-place updates occur. count and lifecycle rules do not change instance identity, and sensitivity is unrelated to addressing, so ensuring stable keys is the correct approach.

Answer

Replace for_each with count and index into the list

Answer

Add lifecycle { create_before_destroy = true } to the role resource

Answer

Mark the for_each map as sensitive in the variable definition

Question 7

You are updating a shared Terraform module that provisions an Amazon RDS instance. The module currently defines an input variable `engine_version` with `default = "14.7"`. Your team wants to ensure that any consumer who does not explicitly set `engine_version` still gets a valid value, but you also want to prevent consumers from accidentally passing a null value that would cause an API error. Which change should you make to the variable definition?

Accepted Answer

Add `nullable = false` to the variable block so Terraform rejects null values and uses the default instead.. The `nullable` argument, introduced in Terraform 1.1, controls whether a variable can be set to null. When `nullable = false`, a null value passed by a caller is treated as if the variable were omitted, so the default is used. This is the precise mechanism for ensuring a fallback to the default while still allowing callers to omit the variable.

Answer

Add a validation block that checks `var.engine_version != null` and returns an error message if the value is null.

Answer

Use a `sensitive = true` attribute on the variable to mask null values and fall back to the default.

Answer

Remove the default and mark the variable as required so callers must always provide a value.

Question 8

A platform team maintains a shared module in a private Terraform registry. They want to ensure that any configuration consuming this module always pulls the exact same version, even if a newer version is published. The module source is specified as "app.terraform.io/example-corp/vpc/aws". Which source argument change should be applied?

Accepted Answer

Add a version argument to the module block, e.g., version = "1.2.0".. Registry modules require a version argument within the module block to select a specific release. By setting version = "1.2.0", the consumer always retrieves that exact version, preventing unintended upgrades. Other methods such as query parameters or environment variables are not supported for registry modules and would not enforce version pinning. This is the standard practice for reproducible deployments.

Answer

Use a Git-style ref in the source string, such as ?ref=1.2.0.

Answer

Append ?version=latest to the source string to pin the latest version.

Answer

Set the environment variable TF_MODULE_VERSION to 1.2.0 before running terraform init.

Question 9

You maintain a Terraform module that provisions an AWS Application Load Balancer and its target groups. Consumers frequently need to attach additional security groups to the ALB, but the module currently hardcodes a single security group. You want to allow consumers to supply a list of security group IDs without breaking existing module calls. Which change should you make to the module's variables and resource configuration?

Accepted Answer

Add a new variable `additional_security_group_ids` of type `list(string)` with a default of `[]`, then merge it with the module's internally created security group ID using `concat()` in the `security_groups` argument.. Adding an optional input variable with a sensible default and composing it with the module's internal resource preserves backward compatibility. Existing consumers continue to work unchanged, while new consumers can pass extra security group IDs. Concatenating the internally managed security group with the additional ones ensures the ALB retains its baseline security posture and gains the requested extra groups.

Answer

Add a new variable `security_group_ids` of type `list(string)` with no default, and replace the existing hardcoded security group with this variable.

Answer

Use the `for_each` meta-argument on the `aws_lb` resource to iterate over a map of security group IDs provided by the consumer.

Answer

Change the existing `security_group_id` variable to type `list(string)` and update the `security_groups` argument to reference it directly.

Question 10

A module accepts a variable 'environment' used only to build a name prefix. The team wants to prevent callers from passing values outside a fixed set without duplicating validation in every caller. What is the correct approach?

Accepted Answer

Add a validation block inside the variable definition in the module. Validation blocks inside a variable definition enforce constraints at the point of declaration, so all callers are checked consistently and errors surface during plan. Preconditions, type constraints, and provisioners either require duplication, do not restrict values, or run too late to be reliable for this requirement.

Answer

Declare the variable with type = string and rely on callers to pass correct values

Answer

Use a precondition block on each resource that consumes the variable

Answer

Add a null_resource with a local-exec provisioner that validates the value at apply time

Question 11

A team is designing a reusable Terraform module that provisions an AWS VPC. They want to ensure the module is flexible and follows best practices for input variables. Which two practices should they implement? (Choose two.)

Accepted Answer

Mark variables that contain sensitive information with sensitive = true.. Marking sensitive variables with sensitive = true and using validation blocks are both best practices for reusable modules. Sensitivity prevents secret leakage, while validation enforces input constraints and improves error handling. Avoiding defaults for critical variables, using explicit types, and documenting variables are also important. These practices collectively make the module more secure, robust, and user-friendly.

Answer

Provide default values for all input variables to simplify usage.

Answer

Avoid documenting variables in README to keep the module concise.

Answer

Define all variables as type = any to maximize flexibility.

Question 12

You are configuring a new HCP Terraform workspace that uses a VCS connection to a GitHub repository. You want runs to be automatically triggered when changes are pushed to the main branch. Which setting should you enable?

Accepted Answer

Automatic run triggering. HCP Terraform's VCS integration includes an 'Automatic run triggering' setting. When enabled, any commit to the tracked branch (e.g., main) queues a new run. This is the correct setting to achieve automatic runs on code pushes. Other options like run triggers, auto-apply, and speculative plans serve different purposes and do not initiate runs on VCS changes.

Answer

Speculative plans

Answer

Run triggers

Answer

Auto-apply

Question 13

You are developing a module that creates an AWS Lambda function. The module accepts a variable `environment` and must set the Lambda function's `environment` block with variables `LOG_LEVEL` and `STAGE`. The values for these should be derived from the `environment` variable. How should you define the variable and use it within the module?

Accepted Answer

Define variable "environment" { type = object({ log_level = string, stage = string }) } and set environment { variables = { LOG_LEVEL = var.environment.log_level, STAGE = var.environment.stage } }. Using an object type for the environment variable allows the caller to specify both log_level and stage explicitly, ensuring each Lambda environment variable receives the correct value. This approach is type-safe, self-documenting, and flexible. It also enables validation rules if needed. The other options either hardcode values, use overly permissive types, or incorrectly assign the same value to both settings.

Answer

Define variable "environment" { type = map(string) } and set environment { variables = var.environment }

Answer

Define variable "environment" { type = string } and inside the resource, set environment { variables = { LOG_LEVEL = var.environment, STAGE = var.environment } }

Answer

Define variable "environment" { type = string } and set environment { variables = { LOG_LEVEL = "debug", STAGE = var.environment } }

Question 14

You have written a Terraform module that outputs the ARN of an AWS S3 bucket. A user of the module wants to reference this output in their root configuration. How should they access it?

Accepted Answer

module..bucket_arn. Module outputs are exposed as attributes on the module object. The correct reference is module... This allows the root configuration to consume the output value seamlessly. Other options represent incorrect syntax or refer to different mechanisms like remote state.

Answer

data.terraform_remote_state.<MODULE_NAME>.bucket_arn

Answer

output.<MODULE_NAME>.bucket_arn

Answer

module.<MODULE_NAME>.outputs.bucket_arn

Question 15

Your team uses HCP Terraform to manage AWS infrastructure. You have a workspace that provisions an Amazon RDS instance. You want to ensure that the RDS instance is not publicly accessible. You have written a Sentinel policy that checks the 'publicly_accessible' attribute. However, after enabling the policy, you notice that runs are not being blocked even when the attribute is set to true. What is the most likely reason for the policy not blocking the run?

Accepted Answer

The policy set is configured with an enforcement level of advisory.. The enforcement level determines whether a failing policy blocks a run. Advisory only logs, soft-mandatory allows override, and hard-mandatory blocks. Since the policy is not blocking, the enforcement level is likely set to advisory.

Answer

The policy is written in Sentinel but the workspace is using Terraform 0.11, which does not support Sentinel.

Answer

The policy is attached to the organization but not to the specific workspace.

Answer

The Sentinel policy is using the wrong import, such as tfplan/v2 instead of tfplan/v3.