AWS provider Practice Test 16 — 15 Questions

Question 1

Which TWO types of variables can be set in HCP Terraform?

Accepted Answer

Environment variables. In HCP Terraform (formerly Terraform Cloud), workspaces support two distinct categories of user-settable variables: environment variables (option A) and Terraform variables (option E). Environment variables (A) are injected into the Terraform run environment and are commonly used for provider credentials such as AWS_ACCESS_KEY_ID or TF_LOG, and they can optionally be marked sensitive. Terraform variables (E) correspond to input variables declared in the configuration (variable blocks) and are supplied as key/value pairs (e.g., via terraform.tfvars or the HCP Terraform UI/API) to parameterize a run, including HCL and sensitive variants. The other options are not valid HCP Terraform variable types: policy-level variables (B) do not exist as a settable category (Sentinel policies are managed separately), state-level variables (C) are not a Terraform concept since state stores resource data, and hardcoded module variables (D) are simply literal values written in code rather than a configurable variable type.

Answer

Policy-level variables

Answer

State-level variables

Answer

Hardcoded module variables

Question 2

Which THREE pieces of information are displayed in the HCP Terraform Run UI?

Accepted Answer

The user who initiated the run. Option A is correct because the HCP Terraform Run UI shows run metadata including the identity of the user or team that triggered the run, which is essential for audit and collaboration. Option C is correct because Sentinel policy checks (and other policy evaluations) are surfaced in the run's UI with their pass/fail status, so users can see whether policies were enforced before apply. Option D is correct because the run's plan output, including the proposed resource changes and the diff, is displayed in the UI for review and approval. Option B is not correct because the raw state file is not shown in plain text in the Run UI; state is stored securely and accessed via state versions or the API, not displayed as raw text. Option E is not correct because private cloud provider passwords are sensitive credentials and are never displayed in the Run UI; they are stored as sensitive variables and masked.

Answer

The raw state file in plain text

Answer

Private cloud provider passwords

Question 3

Which TWO actions can be taken to resolve issues where a resource must be replaced, but 'prevent_destroy' is enabled?

Accepted Answer

Run 'terraform state rm' to remove the resource from state and re-import.. Option B is correct because running 'terraform state rm <resource_address>' removes the resource from Terraform's state file, which detaches it from the 'prevent_destroy' lifecycle meta-argument (that constraint is only enforced when Terraform plans to destroy a resource it manages in state); the resource can then be re-imported with 'terraform import' or recreated without triggering the destroy protection. Option D is correct because 'prevent_destroy' is a lifecycle block setting in the resource configuration, so deleting that lifecycle block (or the specific prevent_destroy argument) from the .tf file removes the constraint and allows Terraform to plan and perform the replacement. Option A is wrong because '-auto-approve' only skips the interactive approval prompt; it does not override lifecycle constraints, and the plan will still fail with an error that the resource has prevent_destroy set. Option C is wrong because 'terraform refresh' only reconciles state with real infrastructure and has no effect on lifecycle meta-arguments. Option E is wrong because 'prevent_destroy' cannot be set or toggled via a CLI flag or argument; it is defined only in the resource's lifecycle block in configuration.

Answer

Use 'terraform apply -auto-approve'.

Answer

Use 'terraform refresh' to update the constraint.

Answer

Set the prevent_destroy argument to false in the CLI.

Question 4

If you use 'ignore_changes = [tags]', and you manually change the tags in the AWS Console, what will happen during the next 'terraform plan'?

Accepted Answer

Terraform will ignore the difference and perform no action on the tags.. The `ignore_changes` lifecycle meta-argument tells Terraform to disregard differences between the desired configuration and the actual remote state for the specified attributes. When `ignore_changes = [tags]` is set, Terraform will not plan any changes to the `tags` attribute even if the real-world resource has been modified outside of Terraform. Therefore, during the next `terraform plan`, Terraform will ignore the tag differences and perform no action on the tags.

Answer

Terraform will plan to revert the tags to the configuration state.

Answer

Terraform will fail with an attribute mismatch error.

Answer

Terraform will update the state file to match the console tags.

Question 5

What happens if a Sentinel policy results in an 'advisory' output?

Accepted Answer

The run logs display a warning, but the process continues.. In HashiCorp Sentinel, policies can be configured with different enforcement levels: advisory, soft-mandatory, and hard-mandatory. When a policy is set to advisory, a failed policy check does not block the run; instead, it logs a warning message and allows the run to proceed. This is by design to provide informational feedback without enforcing compliance. Thus, the correct answer is that the run logs display a warning but the process continues.

Answer

The plan is marked as failed.

Answer

The policy is treated as a hard-mandatory failure.

Answer

The run is paused for manual intervention.

Question 6

You have a module `terraform-aws-modules/vpc/aws` version `3.14.0` from the public Terraform Registry. You want to ensure that your configuration always uses this exact version and does not automatically upgrade to newer versions. Which version constraint should you specify in the module block?

Accepted Answer

version = "3.14.0". To pin a module to an exact version, specify the version string without any operators or wildcards. This ensures Terraform uses only that version. Other constraints like `~>`, `>=`, or wildcards allow some degree of version flexibility, which can lead to unexpected changes. Exact pinning is appropriate when stability is paramount.

Answer

version = "~> 3.14.0"

Answer

version = "3.14.*"

Answer

version = ">= 3.14.0"

Question 7

You are writing a reusable module that creates an AWS S3 bucket and an associated bucket policy. The module will be consumed by multiple teams. Which TWO practices should you follow to make the module robust and maintainable? (Choose two.)

Accepted Answer

Define all input variables with explicit types and provide sensible defaults for optional ones.. Exposing outputs and defining typed variables with defaults are core practices for reusable modules. Outputs allow consumers to integrate the module's resources into their own configurations, while typed variables with defaults make the module predictable and easy to use. Together they form a clear contract between the module and its consumers, which is essential for maintainability across teams.

Answer

Use the `terraform-aws-modules/s3-bucket/aws` public module internally and wrap it without exposing any of its variables.

Answer

Store the bucket policy as a separate JSON file and load it with `file()` so it can be edited without changing Terraform code.

Answer

Hardcode the AWS region in the provider configuration inside the module to ensure consistency.

Question 8

Your organization uses HCP Terraform with Sentinel policies. A policy is configured with an enforcement level of 'hard-mandatory' and checks that all AWS S3 buckets have server-side encryption enabled. A developer runs a plan that includes an unencrypted bucket. What happens when the policy fails?

Accepted Answer

The run is halted immediately, and the apply cannot proceed.. Hard-mandatory Sentinel policies block a run immediately upon failure, preventing any apply. No manual override is possible. Advisory policies only warn, and soft-mandatory allows override by authorized users. In this scenario, the unencrypted S3 bucket would be blocked, and the developer must remediate the configuration.

Answer

The run proceeds to apply, but the policy failure is recorded in the audit log.

Answer

The run is paused, and an organization owner must manually override the policy to proceed.

Answer

The run continues, but the policy failure is logged as an advisory warning.

Question 9

You are designing a reusable Terraform module that will be consumed by multiple teams. To ensure the module is maintainable and follows best practices, which TWO of the following should you implement? (Choose two.)

Accepted Answer

Use a consistent naming convention and tag all resources with a module identifier.. The correct practices are providing thorough documentation and using consistent naming and tagging. Documentation ensures consumers can use the module effectively, while naming and tagging aid in management and identification. These practices enhance maintainability, reduce errors, and support operational excellence in reusable modules.

Answer

Hardcode the AWS region and account ID to simplify configuration for consumers.

Answer

Expose all internal resources as outputs so consumers can reference them directly.

Answer

Include a `terraform.tfstate` file in the module repository to track state.

Question 10

Your organization uses HCP Terraform to manage AWS infrastructure. You need to grant a team the ability to create and manage workspaces within a specific project, but prevent them from deleting the project itself or modifying project-level settings. Which HCP Terraform team permission should you assign?

Accepted Answer

Project Write. Project Write permission is designed for teams that need to manage workspaces within a project without administrative control over the project itself. It allows workspace creation, configuration, and runs, but not project deletion or settings changes. Project Admin and Organization Owner grant excessive privileges, while Project Read is too limited.

Answer

Project Read

Answer

Organization Owner

Answer

Project Admin

Question 11

When defining a provider in Terraform, what does the 'alias' meta-argument signify?

Accepted Answer

It allows using multiple configurations of the same provider.. The 'alias' meta-argument lets you declare multiple configurations of the same provider within a single configuration, each with different settings (e.g., different AWS regions or accounts). Resources then reference the aliased provider to control which configuration they use.

Answer

It links to a different provider type.

Answer

It defines the provider's short name.

Answer

The provider is deprecated.

Question 12

Your team maintains a Terraform configuration that uses the AWS provider with an S3 backend. A security review requires that provider credentials never be stored in plaintext in the configuration or state. You currently use a shared credentials file referenced by the `profile` argument. Which change best satisfies this requirement while keeping the configuration portable across CI and developer machines?

Accepted Answer

Remove credential arguments and rely on the standard AWS credential provider chain, such as environment variables, IAM roles, or SSO profiles.. The AWS provider integrates with the standard AWS credential provider chain when no explicit credentials are supplied. This allows credentials to be sourced from environment variables, shared files, IAM roles, or SSO, keeping secrets out of Terraform configuration and state. It also supports portability, since CI systems and developer machines can use their own credential mechanisms without changing the Terraform code.

Answer

Create a `terraform.tfvars` file containing the access key and secret key as variables and reference them in the provider block.

Answer

Hardcode the access key and secret key as arguments in the `provider "aws"` block and mark them `sensitive = true`.

Answer

Store the credentials in the S3 backend configuration using the `access_key` and `secret_key` arguments.

Question 13

You are authoring a Terraform module that must accept a map of environment names to instance counts. The map is provided by callers and may contain up to 20 entries. You need to derive a flat list of instance names in the form "-" (e.g., "prod-0", "prod-1") so that a downstream resource can use `for_each` with stable keys. Which expression correctly produces this list?

Accepted Answer

flatten([for env, count in var.instance_counts : [for i in range(count) : "${env}-${i}"]]). The requirement is to expand each environment's count into individual instance names and then combine them into one flat list. A nested for expression with flatten achieves this by generating a list of names per environment and then merging them. The other options either produce the wrong data shape or fail to expand the count into multiple entries.

Answer

concat([for env, count in var.instance_counts : "${env}-${count}"])

Answer

[for env, count in var.instance_counts : "${env}-${count}"]

Answer

[for env, count in var.instance_counts : { name = "${env}-${count}" }]

Question 14

An operations engineer runs `terraform init` and notices Terraform downloads the AWS provider from `registry.terraform.io`. The organization requires all provider packages to come from an internal mirror at `mirror.example.com` for compliance. The engineer adds a `provider_installation` block to the CLI configuration file. Which CLI configuration file location and block structure will make Terraform use the mirror for the AWS provider while still allowing other providers from the public registry?

Accepted Answer

Place a `provider_installation` block with a `filesystem_mirror` or `network_mirror` directive in the `.terraformrc` file in the user's home directory, or in `terraform.rc` on Windows.. Provider install sources are controlled by the CLI configuration file, which lives at `~/.terraformrc` on Unix-like systems and `terraform.rc` under `%APPDATA%` on Windows. A `provider_installation` block there can declare a `network_mirror` or `filesystem_mirror` and include or exclude specific provider source addresses, so the AWS provider resolves from the internal mirror while others continue to use the public registry.

Answer

Create a `.terraform.lock.hcl` entry mapping the AWS provider to the mirror hostname so `terraform init` reads the source from the lock file.

Answer

Set the `TF_REGISTRY_CLIENT_TIMEOUT` environment variable to the mirror URL so Terraform prefers the mirror over the public registry.

Answer

Add a `provider_installation` block inside the root module's `terraform` block so it applies to every workspace using that configuration.

Question 15

Which TWO factors must be considered when using 'replace_triggered_by' with multiple resources?

Accepted Answer

The trigger cannot cause a circular dependency loop.. Option C is correct because replace_triggered_by creates a dependency edge from the referencing resource to the referenced resource, so if the referenced resource already depends on the referencing one (directly or transitively), Terraform will detect a circular dependency and fail the plan. Option D is correct because replace_triggered_by can only reference resources (or attributes) that Terraform knows about within the same configuration/state; cross-state references are not resolvable as trigger sources, so the referenced resource must live in the same state file. Option A is wrong because replace_triggered_by works against any resource or attribute reference, not just the tags attribute. Option B is wrong because replace_triggered_by has no requirement that create_before_destroy be false; the two settings are independent. Option E is wrong because replace_triggered_by is provider-agnostic and works with any Terraform resource, not only AWS resources.

Answer

The trigger only works on the 'tags' attribute.

Answer

The trigger requires 'create_before_destroy' to be false.

Answer

The trigger only works with AWS resources.