Courseiva

CCNA HCP Terraform Governance Questions

44 questions · HCP Terraform Governance · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQhard

If a Terraform run is stuck in a 'Policy Check' phase, which step should an administrator take?

A.Check the Policy Set configuration and execution logs.
B.Trigger a new plan.
C.Delete and recreate the workspace.
D.Disable the policy check.
AnswerA

A run stalled at Policy Check usually means Sentinel cannot evaluate the policy set, often through misconfiguration or an execution error. Reviewing the policy set configuration and its execution logs identifies the blocking cause so the run can proceed.

Why this answer

A run stuck in the Policy Check phase means the policy evaluation is either failing, erroring, or awaiting override. The administrator should inspect the Policy Set configuration and the run's policy execution logs to identify which policy is blocking and why. This is the direct diagnostic step before considering overrides or fixes.

Exam trap

The trap is reaching for destructive or bypass actions (recreate workspace, disable policy) instead of the diagnostic step — exams reward troubleshooting over circumvention.

How to eliminate wrong answers

Option B is wrong because triggering a new plan does not resolve a policy block — the same policy will evaluate the new plan and likely block again, wasting time and potentially creating duplicate runs. Option C is wrong because deleting and recreating the workspace destroys state history and configuration for no reason; the issue is policy-related, not workspace-related. Option D is wrong because disabling the policy check bypasses governance rather than diagnosing it, and may violate organizational controls; it should only be a last resort after understanding the failure.

Practice this question →
2
MCQhard

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?

A.Project Read
B.Organization Owner
C.Project Admin
D.Project Write
AnswerD

Project Write permission allows a team to create and manage workspaces within the project, including running applies and managing workspace variables, but it does not permit deleting the project or changing project-level settings. This aligns exactly with the requirement to delegate workspace management without granting project administration rights.

Why this answer

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.

Exam trap

The trap here is assuming that Project Admin is needed to create workspaces, when Project Write already provides that capability without project deletion rights.

Practice this question →
3
MCQhard

You want to trigger a run only when a specific file within a module path changes. How do you configure this?

A.Use the 'VCS Triggers' setting in the workspace.
B.Use a 'trigger_path' variable in the Terraform code.
C.Modify the '.terraform-version' file.
D.Use a Sentinel policy to filter changes.
AnswerA

VCS Triggers let you filter runs by file path patterns, so specifying the module path ensures a run triggers only when files within it change, satisfying the constraint of scoping runs to a specific module directory.

Why this answer

HCP Terraform (formerly Terraform Cloud) workspaces support VCS Triggers, which let you specify file or directory paths so that a run is only queued when changes are detected in those paths. This is the native mechanism for path-based run triggering tied to version control commits.

Exam trap

HCP Terraform exams often test the confusion between VCS Triggers (path-based run filtering) and run triggers (workspace-to-workspace dependencies), or invent non-existent variables like 'trigger_path'.

How to eliminate wrong answers

Option B is wrong because 'trigger_path' is not a Terraform variable or configuration primitive — there's no such built-in variable for controlling run triggers. Option C is wrong because '.terraform-version' specifies the Terraform CLI version to use, not run trigger behavior. Option D is wrong because Sentinel is a policy-as-code framework for enforcing compliance on plans, not for filtering which file changes trigger runs.

Practice this question →
4
Multi-Selecthard

Which TWO of the following are required to successfully integrate VCS with HCP Terraform?

Select 2 answers
A.A direct peering link.
B.A VPN connection between AWS and HCP Terraform.
C.A static IP address for the organization.
D.An OAuth application created in the VCS provider.
E.A configured VCS connection in the organization settings.
AnswersD, E

Creating an OAuth application in the VCS provider is mandatory: HCP Terraform uses its OAuth client ID and secret to obtain authorisation tokens, letting it read repositories and register webhooks for automatic runs. Without this OAuth handshake, no VCS connection can be established.

Why this answer

Option D is correct because integrating a VCS provider with HCP Terraform requires registering an OAuth application (OAuth client) in the VCS provider, such as GitHub, GitLab, or Bitbucket, so that HCP Terraform can be authorized to access repositories on the organization's behalf. Option E is correct because, after the OAuth credentials (OAuth app ID and secret) are supplied, you must create and configure a VCS connection within the HCP Terraform organization settings, which links the organization to the VCS provider and enables VCS-driven workspaces. Options A and B are incorrect because HCP Terraform communicates with VCS providers over the public internet via HTTPS APIs and webhooks; no direct peering link or AWS-to-HCP Terraform VPN is needed for VCS integration.

Option C is incorrect because a static IP address for the organization is not a prerequisite for VCS integration; HCP Terraform's agent and VCS communication do not depend on a fixed organization-level IP.

Exam trap

The trap is overcomplicating the requirements with network concepts like peering or VPN. Candidates might think a direct connection is needed, but VCS integration is purely API-based over the internet. The exam tests the specific components: OAuth app and VCS connection.

Practice this question →
5
MCQmedium

Your organization uses HCP Terraform with a private module registry. A developer wants to use a module from the registry in a new configuration. The module is versioned and published. What is the correct way to reference this module in the Terraform configuration?

A.Use a Git URL pointing to the module's repository.
B.Use the module source address in the format 'app.terraform.io/<namespace>/<module-name>/<provider>' with a version constraint.
C.Download the module manually and place it in a local 'modules' directory, then reference it with a relative path.
D.Use the module's API endpoint URL directly in the source argument.
AnswerB

Private modules in HCP Terraform are referenced using the registry's hostname, namespace, module name, and provider, followed by a version constraint. This allows Terraform to fetch the specified version from the registry, ensuring consistency and leveraging registry features like versioning and access control.

Why this answer

Private modules in HCP Terraform are consumed by specifying a source address that includes the registry hostname, namespace, module name, and provider, along with a version constraint. This ensures Terraform retrieves the correct version from the registry, enabling version pinning and access control.

Exam trap

The trap here is assuming that any URL or local path can substitute for the registry source address, ignoring the standardized format required for private module consumption.

Practice this question →
6
MCQmedium

You want to enforce a policy that prevents creating AWS EC2 instances larger than 't3.medium'. Where do you configure this?

A.By modifying the Terraform provider source.
B.Inside an HCP Terraform Policy Set.
C.In the Private Module Registry settings.
D.Within the workspace's variables.
AnswerB

HCP Terraform policy sets enforce Sentinel or OPA policies against Terraform runs, evaluating planned EC2 instance types before apply. This blocks instance sizes exceeding t3.medium at the Terraform layer, satisfying the stem's requirement to prevent creation of larger instances.

Why this answer

HCP Terraform (formerly Terraform Cloud) Policy Sets use Sentinel or OPA policies to enforce governance rules such as restricting EC2 instance types. You attach a policy set to workspaces or projects, and the policy evaluates the plan before apply, blocking non-compliant resources like instances larger than t3.medium. This is the correct place for cross-cutting, organization-wide enforcement.

Exam trap

The trap is confusing module registry governance with runtime policy enforcement — candidates pick the Private Module Registry because it sounds like a control point, but it only governs module distribution, not resource attributes.

How to eliminate wrong answers

Option A is wrong because modifying the provider source is not a supported governance mechanism — providers are versioned binaries, and forking them is impractical and unmaintainable. Option C is wrong because the Private Module Registry controls module distribution and versioning, not runtime policy enforcement on resource attributes. Option D is wrong because workspace variables only supply input values; they cannot inspect or block a plan based on resource attributes like instance type.

Practice this question →
7
Multi-Selecthard

Which THREE of the following items can be included in a Variable Set?

Select 3 answers
A.Terraform variables.
B.Environment variables.
C.Terraform provider configurations.
D.Sentinel policy sets.
E.Scope definition (Projects or Organization).
AnswersA, B, E

Variable sets hold Terraform input variables, including sensitive and HCL values, which are then applied across every workspace the set is assigned to. This satisfies the scenario because Terraform variables are precisely the reusable input values a set distributes.

Why this answer

In Terraform Cloud/Enterprise, a Variable Set is a reusable container of variables that can be applied across multiple workspaces, and it can hold Terraform variables (option A), which are the input variables (e.g., terraform.tfvars-style key/value pairs) consumed by the Terraform configuration during a run. It can also hold environment variables (option B), which are injected into the run environment as shell environment variables (for example, credentials like AWS_ACCESS_KEY_ID or TF_LOG). Additionally, a Variable Set includes a scope definition (option E) that determines whether it applies to the entire Organization or is limited to specific Projects, controlling which workspaces inherit the variables.

Terraform provider configurations (option C) are not stored in Variable Sets; providers are configured in the Terraform configuration or via environment variables/credentials, not as a Variable Set item type. Sentinel policy sets (option D) are a separate governance feature managed independently of Variable Sets and are not an includable item within them.

Exam trap

The trap is thinking that provider configurations or Sentinel policies can be part of a Variable Set — candidates may confuse Variable Sets with other HCP Terraform features that manage providers or policies.

Practice this question →
8
MCQmedium

You need to automate the publication of a module to the Private Module Registry. What should you do?

A.Run the 'terraform publish' command.
B.Push a release tag to the linked VCS repository.
C.Manually upload the zip file to the registry.
D.Configure a webhook in the workspace settings.
AnswerB

The Private Module Registry publishes a new module version when a semver release tag is pushed to the linked VCS repository. Tagging the commit triggers automatic publication, satisfying the stem's requirement to automate module publication without manual upload.

Why this answer

HCP Terraform's Private Module Registry is VCS-driven: publishing a module happens automatically when you push a new release tag (e.g., v1.0.0) to the repository linked to the registry. The tag triggers the registry to ingest and version the module.

Exam trap

The trap is looking for a CLI command to publish — candidates expect a 'terraform publish' verb, but HCP Terraform publication is entirely VCS-tag-driven.

How to eliminate wrong answers

Option A is wrong because there is no 'terraform publish' command in the Terraform CLI — publishing is handled by the registry integration, not a CLI verb. Option C is wrong because manual zip uploads are not supported for the Private Module Registry; modules are sourced from VCS. Option D is wrong because webhooks in workspace settings relate to run notifications and triggers, not module publication.

Practice this question →
9
MCQmedium

Your organization uses HCP Terraform with the AWS provider. A platform team wants to ensure that any workspace in the 'production' project can only use AWS credentials from a pre-approved OIDC role, and that no static AWS access keys are ever stored as workspace variables. Which HCP Terraform feature should you configure to enforce this requirement?

A.A team API token with read-only permissions on the production project.
B.Run triggers that automatically start a run whenever the AWS credentials in the workspace are modified.
C.Policy sets with a Sentinel policy that inspects the run's variables and blocks runs if any AWS access key variables are present.
D.Workspace variable sets with the 'sensitive' flag enabled for all AWS credential variables.
AnswerC

Sentinel policies can evaluate the plan and run metadata, including variables. A policy set attached to the production project can inspect for AWS access key variables and reject runs that include them, directly enforcing the no-static-keys requirement while allowing OIDC-based credentials.

Why this answer

Sentinel policy sets are the governance mechanism in HCP Terraform that can evaluate run context, including variables and plan data, and enforce rules such as disallowing static AWS access keys. Attaching the policy set to the production project ensures every run in that project is checked, providing the required guardrail without relying on manual review.

Exam trap

The trap here is assuming that marking variables as sensitive or using read-only tokens provides enforcement, when only a policy check can actively block non-compliant runs.

Practice this question →
10
MCQmedium

Your organization uses HCP Terraform to manage AWS infrastructure. The security team requires that all runs consuming AWS credentials must be evaluated against a policy that checks the CIDR blocks of any aws_security_group resource. They want the policy to block the run if a CIDR is 0.0.0.0/0. Where should you implement this policy so it is enforced across all workspaces in the organization?

A.Define an AWS IAM policy that denies the CreateSecurityGroup action when the CIDR is 0.0.0.0/0.
B.Create a Sentinel policy in the organization's policy sets and assign it to all workspaces.
C.Use Terraform's built-in validation blocks in the aws_security_group resource to reject 0.0.0.0/0.
D.Configure a pre-plan run task that runs a script to check the Terraform configuration for 0.0.0.0/0.
AnswerB

Sentinel policies in HCP Terraform are configured at the organization level via policy sets, which can be applied to all workspaces. This enforces governance centrally, ensuring every run that plans AWS resources is evaluated. The policy can inspect the plan for aws_security_group CIDR blocks and block non-compliant configurations, meeting the requirement without per-workspace configuration.

Why this answer

Sentinel policies in HCP Terraform are managed at the organization level and can be applied to all workspaces through policy sets. They evaluate the Terraform plan and can block runs that violate rules, such as allowing 0.0.0.0/0 in security group CIDRs. This provides centralized, consistent enforcement across the organization.

Exam trap

The trap here is assuming that AWS IAM policies or Terraform validation blocks can inspect Terraform plan data to enforce governance, when only Sentinel policies have that capability.

Practice this question →
11
MCQeasy

Where can you define variables that apply to all workspaces within an organization in HCP Terraform?

A.In the Private Module Registry.
B.In a Variable Set.
C.In the individual workspace configuration.
D.In the organization settings directly.
AnswerB

Variable Sets apply values across every workspace in an organisation, satisfying the requirement for organisation-wide variables. They are scoped at the organisation level rather than per-workspace, unlike workspace variables or Terraform input variables defined in configuration.

Why this answer

In HCP Terraform (formerly Terraform Cloud), a Variable Set is a named collection of variables that can be applied to multiple workspaces across an organization. Variable Sets are designed specifically to share variables globally or across selected workspaces, making them the correct mechanism for organization-wide variable definitions. They can contain both Terraform variables and environment variables, and can be scoped to all workspaces or a subset.

Exam trap

The trap is assuming that organization settings provide a direct variable configuration interface — candidates often overlook Variable Sets as the dedicated mechanism for cross-workspace variables and instead pick the more obvious-sounding 'organization settings' option.

How to eliminate wrong answers

Option A is wrong because the Private Module Registry stores reusable Terraform modules, not variables — it has no mechanism for injecting variables into workspaces. Option C is wrong because individual workspace configuration only applies variables to that single workspace, not to all workspaces in the organization. Option D is wrong because organization settings in HCP Terraform do not include a direct variable definition area; variables must be defined in workspaces or variable sets, not at the org level itself.

Practice this question →
12
MCQmedium

Your organization uses HCP Terraform with remote runs. A workspace named 'prod-network' has its execution mode set to Remote. A platform engineer runs `terraform apply` locally after running `terraform plan` on their laptop, but the apply fails with an error because the workspace's state is locked by an active remote run. What is the most likely explanation for this error?

A.The workspace's state is stored locally because the backend configuration is missing, causing a lock conflict with the remote run.
B.The local CLI is not authenticated to HCP Terraform, so it cannot acquire the state lock.
C.A remote run is currently in progress in the workspace, holding the state lock, so a local apply cannot proceed until it finishes or is canceled.
D.The workspace's execution mode is set to Local, so HCP Terraform cannot accept remote applies.
AnswerC

When execution mode is Remote, HCP Terraform runs plan and apply remotely. If a remote run is active, it holds the state lock. A local apply attempted against the same workspace will fail because the state is locked. The engineer must wait for the remote run to complete or cancel it before applying locally, though best practice is to avoid local applies in remote-mode workspaces.

Why this answer

With remote execution mode, all runs occur in HCP Terraform and the workspace state is locked during an active run. A local apply cannot acquire the lock while a remote run is in progress. The engineer must coordinate with the remote run, typically by waiting or canceling, rather than attempting a local apply.

Exam trap

The trap here is assuming that local CLI operations can bypass remote run locks, when in fact the remote workspace state lock applies to all operations against that workspace.

Practice this question →
13
MCQmedium

What is the purpose of 'Project' in HCP Terraform?

A.To define the Sentinel policies for an environment.
B.To store Terraform state files securely.
C.To group workspaces and manage access control for teams.
D.To define the cloud provider budget.
AnswerC

Projects provide a grouping layer above workspaces, letting teams organise related workspaces and apply team access permissions across the whole collection. This satisfies the scenario by centralising access control instead of managing permissions workspace by workspace.

Why this answer

Projects are used to group workspaces, allowing for easier team permission management and organization.

Practice this question →
14
MCQhard

You are configuring run triggers in HCP Terraform to orchestrate a multi-workspace deployment on AWS. Workspace A provisions a VPC and outputs the VPC ID. Workspace B needs to consume that VPC ID to deploy subnets. You want Workspace B to automatically start a run after Workspace A successfully applies. Which configuration should you implement?

A.In Workspace B, add a run trigger that references Workspace A as the source workspace.
B.In Workspace A, add a run trigger that references Workspace B as the destination workspace.
C.Use a Terraform data source in Workspace B to read the remote state of Workspace A.
D.Configure a webhook in Workspace A that calls the HCP Terraform API to start a run in Workspace B.
AnswerA

Run triggers are configured on the destination workspace. By adding a run trigger in Workspace B that references Workspace A, you ensure that a successful apply in Workspace A automatically queues a run in Workspace B. This is the correct way to set up a dependency between workspaces.

Why this answer

Run triggers are defined on the destination workspace, specifying the source workspace whose successful apply will trigger a run. This enables dependency chains between workspaces. Reading remote state does not trigger runs, and webhooks are for notifications, not native orchestration.

Exam trap

The trap here is thinking that run triggers are configured on the source workspace to push to a destination, when they are actually configured on the destination to pull from a source.

Practice this question →
15
MCQhard

If an organization wants to allow teams to manage their own workspaces but prevent them from viewing other teams' workspaces, how should they configure HCP Terraform?

A.Assign teams access at the Project level rather than the Organization level.
B.Enable 'Organization-wide' access for all teams.
C.Use individual workspace permissions instead of projects.
D.Create a separate organization for each team.
AnswerA

Project-level permissions in HCP Terraform scope a team's access to only the workspaces within that project, so each team manages its own workspaces without seeing others. Organisation-level access would grant visibility across all projects, violating the isolation requirement. This satisfies the constraint of per-team workspace management with enforced separation.

Why this answer

HCP Terraform projects group workspaces and let you assign team permissions at the project level, so a team can manage its own workspaces without seeing workspaces in other projects. This scopes access narrowly and satisfies the least-privilege requirement. Organization-level access would grant visibility across all projects, which is exactly what must be prevented.

Exam trap

The trap is reaching for the most extreme isolation (separate organizations) or the most granular (per-workspace) when HCP Terraform's project-level permissions are the designed answer for team-scoped workspace management.

How to eliminate wrong answers

Option B is wrong because organization-wide access grants teams visibility and permissions across all workspaces in the organization, directly violating the isolation requirement. Option C is wrong because per-workspace permissions are more granular but do not scale and do not provide the project-level grouping that HCP Terraform recommends for team isolation; projects are the intended abstraction. Option D is wrong because creating a separate organization per team is operationally heavy, breaks centralized governance and billing, and is not the recommended pattern when projects already provide the needed isolation.

Practice this question →
16
MCQeasy

Which of the following can be used to monitor costs in an HCP Terraform workspace?

A.Terraform State inspection.
B.Sentinel Policy sets.
C.Cost Estimation feature.
D.VCS commit logs.
AnswerC

Cost Estimation parses the plan against cloud provider pricing to project monthly spend before apply, satisfying the requirement to monitor costs within an HCP Terraform workspace. It surfaces projected deltas per resource, unlike run notifications or state inspection, which report activity rather than monetary impact.

Why this answer

HCP Terraform's Cost Estimation feature analyzes the planned resources in a run and estimates the monthly cost using cloud pricing data, displaying it in the run's UI. It is the built-in mechanism for monitoring the financial impact of infrastructure changes before they are applied.

Exam trap

The trap is confusing governance features (Sentinel) or state inspection with cost visibility — only the Cost Estimation feature produces per-run spend projections.

How to eliminate wrong answers

Option A is wrong because state inspection shows resource attributes, not cost projections. Option B is wrong because Sentinel policy sets enforce governance rules (e.g., allowed instance types) but do not produce cost estimates. Option D is wrong because VCS commit logs track code changes, not infrastructure spend.

Practice this question →
17
Multi-Selectmedium

Which TWO of the following are true regarding Private Module Registry versioning?

Select 2 answers
A.Versions can be deleted at any time without restriction.
B.Versions must follow Semantic Versioning (SemVer).
C.You can only have one version per module.
D.Versions are created manually by uploading files.
E.The Registry automatically detects new tags as module versions.
AnswersB, E

Terraform Cloud's private module registry enforces Semantic Versioning, requiring the MAJOR.MINOR.PATCH format for every published module version. This satisfies the stem's versioning constraint directly: the registry rejects tags that deviate from SemVer, so teams must increment versions accordingly when releasing module updates.

Why this answer

Option B is correct because the Private Module Registry enforces Semantic Versioning (SemVer) in the MAJOR.MINOR.PATCH format, so every published module version must be a valid SemVer string. Option E is correct because when a module is connected to a VCS repository, the Registry automatically detects new Git tags that match SemVer and publishes them as module versions without manual upload. Option A is wrong because published versions cannot be freely deleted; deletion is restricted (for example, a version cannot be deleted while it is the only version or is in use).

Option C is wrong because a module can have many versions, each identified by its SemVer tag. Option D is wrong because versions are normally created by tagging the linked VCS repository, not by manually uploading files.

Practice this question →
18
MCQeasy

Which type of Sentinel policy is used to block a run without possibility of override?

A.Advisory.
B.Policy-Override.
C.Soft-mandatory.
D.Hard-mandatory.
AnswerD

Hard-mandatory policies in HashiCorp Sentinel halt a run immediately and cannot be overridden by any user, satisfying the stem's "without possibility of override" constraint. Soft-mandatory permits privileged override, while advisory only logs warnings. Hard-mandatory is therefore the only policy type enforcing an absolute, non-bypassable block.

Why this answer

Sentinel policies in Terraform Cloud/Enterprise have three enforcement levels: advisory, soft-mandatory, and hard-mandatory. A hard-mandatory policy blocks the run outright and cannot be overridden by any user, including organization owners, making it the correct answer for 'block without possibility of override'.

Exam trap

The trap is confusing 'soft-mandatory' with 'hard-mandatory' — candidates remember that soft-mandatory blocks runs but forget it can be overridden, so they pick it for a question that explicitly says 'without possibility of override'.

How to eliminate wrong answers

Option A is wrong because advisory policies only log a warning and never block a run. Option B is wrong because 'Policy-Override' is not a Sentinel enforcement level — it is a permission that allows certain users to override soft-mandatory policies. Option C is wrong because soft-mandatory policies can be overridden by users with the 'Manage Policy Overrides' permission, so they do not meet the 'without possibility of override' requirement.

Practice this question →
19
MCQhard

How can you view the detailed breakdown of cost estimates for a specific Terraform plan?

A.Run the 'terraform show' command on the state file.
B.Check the cloud provider's billing dashboard.
C.Use the Sentinel CLI tool.
D.Open the run page in the HCP Terraform UI.
AnswerD

HCP Terraform's run page presents the cost estimate broken down per resource, with monthly and hourly deltas, alongside the plan itself. Opening that page satisfies the requirement to inspect detailed estimate line items rather than a single aggregate figure, which the CLI alone cannot display.

Why this answer

The run details page in the HCP Terraform UI displays the cost estimation summary, which can be expanded for details.

Practice this question →
20
MCQmedium

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?

A.The policy is written in Sentinel but the workspace is using Terraform 0.11, which does not support Sentinel.
B.The policy is attached to the organization but not to the specific workspace.
C.The Sentinel policy is using the wrong import, such as tfplan/v2 instead of tfplan/v3.
D.The policy set is configured with an enforcement level of advisory.
AnswerD

Advisory enforcement only logs policy failures and does not block or pause runs. If the policy set is advisory, the run will proceed even if the policy fails. To block runs, the policy set must be hard-mandatory or soft-mandatory (with override).

Why this answer

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.

Exam trap

The trap here is assuming that any policy failure will block a run, when actually the enforcement level controls the behavior.

Practice this question →
21
MCQeasy

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

A.The plan is marked as failed.
B.The run logs display a warning, but the process continues.
C.The policy is treated as a hard-mandatory failure.
D.The run is paused for manual intervention.
AnswerB

An advisory result in Sentinel produces a warning in the run logs while allowing the run to proceed, satisfying the requirement that execution continues despite the policy outcome. Unlike soft-mandatory, which blocks and prompts for override, advisory never halts the operation, so the plan or apply completes normally with the warning recorded.

Why this answer

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.

Exam trap

The trap here is confusing the three enforcement levels of Sentinel policies—advisory, soft-mandatory, and hard-mandatory—and their respective outcomes. Candidates often mistakenly think any policy failure blocks the run, but advisory only warns.

How to eliminate wrong answers

Option A is wrong because an advisory policy does not mark the plan as failed; that would occur with a hard-mandatory policy. Option C is wrong because advisory is the opposite of hard-mandatory; hard-mandatory blocks the run, while advisory only warns. Option D is wrong because the run is not paused for manual intervention; that behavior is associated with soft-mandatory policies, which require an authorized user to override the failure.

Practice this question →
22
MCQhard

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?

A.The run proceeds to apply, but the policy failure is recorded in the audit log.
B.The run is paused, and an organization owner must manually override the policy to proceed.
C.The run continues, but the policy failure is logged as an advisory warning.
D.The run is halted immediately, and the apply cannot proceed.
AnswerD

Hard-mandatory enforcement blocks the run entirely when a policy fails. No override is possible, and the apply is prevented. This ensures that unencrypted S3 buckets are never provisioned, aligning with strict compliance requirements. The developer must fix the configuration and trigger a new run.

Why this answer

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.

Exam trap

The trap here is assuming that any policy failure can be overridden or that hard-mandatory behaves like soft-mandatory.

Practice this question →
23
MCQmedium

When configuring team permissions, what does the 'Workspace: Settings' permission allow?

A.Viewing plan and apply logs only.
B.Triggering runs manually.
C.Modifying workspace settings like variable sets and execution modes.
D.Deleting the workspace.
AnswerC

Modifying variable sets and execution modes requires the workspace-level Settings permission, which governs configuration scoped to a single workspace rather than organisation-wide policy. This satisfies the stem's constraint by granting exactly the administrative control needed over workspace-specific variables and run behaviour, without broader access.

Why this answer

The 'Workspace: Settings' permission in HCP Terraform grants the ability to modify workspace-level configuration, including variable sets, execution modes (remote/local/agent), and other workspace settings. It does not grant run execution or deletion rights. This permission is typically assigned to workspace admins who need to tune how runs behave.

Exam trap

The trap is assuming that 'Settings' includes all administrative actions like deletion or run triggering — candidates often conflate workspace settings with full workspace administration.

How to eliminate wrong answers

Option A is wrong because viewing plan and apply logs is covered by read-level permissions, not Settings. Option B is wrong because triggering runs manually is a separate 'Queue Plan' or 'Apply' permission. Option D is wrong because deleting a workspace requires a higher-level administrative permission, not just Settings.

Practice this question →
24
MCQhard

You are managing an HCP Terraform organization with multiple workspaces. A security requirement mandates that all workspaces use a specific version of the AWS provider (5.0.0 or later) and that any deviation triggers a notification to the security team. You have configured a Sentinel policy to check the provider version. Which enforcement level should you set for this policy to meet the requirement while allowing developers to proceed with their work if they acknowledge the risk?

A.advisory
B.hard-mandatory
C.disabled
D.soft-mandatory
AnswerD

soft-mandatory allows a run to proceed only if a user with permission to override policies acknowledges the failure. This meets the requirement by allowing developers to continue after acknowledgment. The override action is logged, and notifications can be configured separately. It balances security with flexibility, unlike hard-mandatory which blocks entirely.

Why this answer

soft-mandatory enforcement requires an authorized user to explicitly override a policy failure before the run can continue. This matches the need to allow developers to proceed after acknowledging the risk. The override is recorded, and notifications can be set up via HCP Terraform's notification features. hard-mandatory would block all non-compliant runs, advisory would not require acknowledgment, and disabled would ignore the policy.

Exam trap

The trap here is confusing advisory with soft-mandatory: advisory does not require acknowledgment and does not block the run, while soft-mandatory requires an explicit override by a user with appropriate permissions, which is necessary when acknowledgment is required.

Practice this question →
25
MCQmedium

Your organization uses HCP Terraform to manage AWS infrastructure. A platform engineer has been assigned the 'Write' permission on a workspace but is still unable to modify the AWS credentials stored as workspace variables. Which HCP Terraform permission level is required to manage sensitive workspace variables?

A.Write
B.Admin
C.Plan
D.Read
AnswerB

Admin permission on a workspace grants full control, including the ability to create, edit, and delete workspace variables, including sensitive ones such as AWS access keys. Write permission allows runs and state operations but does not permit variable management, so the engineer must be elevated to Admin to modify the credentials.

Why this answer

Managing workspace variables, particularly sensitive ones like AWS credentials, requires Admin permission on the workspace. Write permission allows runs and applies but not variable management. Plan and Read are view-only levels.

Therefore, the engineer must be granted Admin to edit the credentials.

Exam trap

The trap here is assuming that Write permission includes the ability to manage all workspace settings, including sensitive variables.

Practice this question →
26
MCQeasy

Which of the following is an advantage of using Variable Sets?

A.They centralize variable management to avoid duplication across workspaces.
B.They allow for secret rotation in AWS.
C.They automatically run Terraform plans.
D.They provide encryption for state files.
AnswerA

Variable Sets in Terraform Cloud let you define values once and apply them across multiple workspaces, eliminating per-workspace duplication. This directly satisfies the scenario's requirement for centralised management, since shared credentials, provider tokens, or environment values need updating in only one place rather than being replicated and maintained individually.

Why this answer

Variable Sets allow you to define variables once and apply them across multiple workspaces, eliminating duplication and ensuring consistency. They are ideal for shared credentials, common tags, or provider configurations that many workspaces need. This centralization reduces drift and simplifies updates.

Exam trap

The trap is confusing Variable Sets with other HCP Terraform features like Sentinel policies or run triggers — candidates may think Variable Sets can automate runs or rotate secrets, but they are purely for variable management.

How to eliminate wrong answers

Option B is wrong because secret rotation is handled by Vault or AWS Secrets Manager, not by Terraform Variable Sets. Option C is wrong because Variable Sets do not trigger runs; runs are triggered by VCS commits, CLI, or API calls. Option D is wrong because state file encryption is a backend feature (e.g., S3 SSE, HCP Terraform encryption), not a function of Variable Sets.

Practice this question →
27
MCQeasy

Which of the following is a primary benefit of using a Private Module Registry?

A.It encrypts all Terraform state files.
B.It allows central management and version control of reusable modules.
C.It forces all workspaces to use the same module versions.
D.It automatically generates cost estimates for all modules.
AnswerB

A Private Module Registry stores modules within your own organisation, giving centralised publishing, semantic versioning and access control. This satisfies the need for central management and version control of reusable modules, unlike the public registry where you cannot govern or curate shared code.

Why this answer

A Private Module Registry (available in Terraform Cloud/Enterprise and as a self-hosted registry) provides a centralized, versioned catalog of reusable modules that teams can publish, discover, and consume. It enforces versioning and access control, so consumers pin module versions and get consistent, auditable infrastructure patterns across the organization. This is its primary benefit over ad-hoc Git-based module sourcing.

Exam trap

The trap is conflating the Private Module Registry with unrelated Terraform Cloud features like state encryption or cost estimation, or assuming it forces uniform versions across workspaces.

How to eliminate wrong answers

Option A is wrong because state file encryption is handled by the backend (e.g., S3 SSE, Terraform Cloud encryption), not by the module registry. Option C is wrong because the registry supports multiple module versions simultaneously — it does not force all workspaces onto the same version; consumers choose versions via constraints. Option D is wrong because cost estimation is a separate Terraform Cloud feature (cost estimation runs), not a function of the Private Module Registry.

Practice this question →
28
MCQmedium

Your team uses HCP Terraform to manage AWS infrastructure. You need to allow a specific team of developers to apply changes in a workspace, but you do not want them to be able to modify workspace settings or delete the workspace. Which team permission should you assign to the developers?

A.Write
B.Read
C.Plan
D.Admin
AnswerA

Write permission allows team members to read and write to the workspace, including queuing runs and applying changes, but does not permit modifying workspace settings or deleting the workspace. This exactly matches the requirement: developers can apply changes but cannot alter settings or delete.

Why this answer

Write permission in HCP Terraform allows users to perform runs, including apply, but restricts administrative actions like changing settings or deleting the workspace. This provides the necessary operational access while protecting the workspace configuration. Admin would give too much control, and Read would not allow applies.

Exam trap

The trap here is assuming that Write permission includes workspace deletion or settings modification, when in fact those actions require Admin permission.

Practice this question →
29
MCQeasy

Your organization uses HCP Terraform with the AWS provider. You want to share a set of AWS region and tagging variables across all workspaces in a specific project without duplicating them in each workspace. Which HCP Terraform feature should you use?

A.Terraform input variables with default values in the root module.
B.Variable sets applied to the project.
C.Workspace-specific variables defined in each workspace's variables tab.
D.Environment variables set in the run's execution environment.
AnswerB

Variable sets allow you to define variables once and apply them to multiple workspaces, projects, or the entire organization. Applying a variable set to a project automatically makes those variables available to all workspaces within that project, satisfying the need for shared configuration.

Why this answer

Variable sets in HCP Terraform are designed to share variables across multiple workspaces. You can create a variable set containing the AWS region and tagging variables and apply it to the entire project, ensuring all current and future workspaces in that project inherit the variables. This centralizes management and reduces duplication.

Exam trap

The trap here is confusing variable sets with workspace-specific variables or Terraform input variables, which do not provide centralized sharing across a project.

Practice this question →
30
MCQhard

You are configuring a Sentinel policy for your HCP Terraform organization. The policy must prevent any Terraform run from creating an AWS S3 bucket without server-side encryption enabled. The policy should block the run if such a bucket is detected, but you want to allow administrators to override the policy in emergency situations. Which enforcement level should you set for the policy?

A.advisory
B.hard-mandatory
C.soft-mandatory
D.mandatory
AnswerC

Soft-mandatory policies block a run when the policy fails, but users with permission to manage policies can override the failure and allow the run to proceed. This matches the requirement to block non-compliant S3 buckets while allowing administrators to override in emergencies. It provides both enforcement and flexibility.

Why this answer

Soft-mandatory enforcement blocks a run when the policy fails but allows users with appropriate permissions to override the failure. This provides the necessary guardrail against unencrypted S3 buckets while still permitting emergency overrides. Hard-mandatory would block without override, and advisory would not block at all.

Exam trap

The trap here is assuming that hard-mandatory is the only way to block a run, overlooking that soft-mandatory also blocks but includes an override path, which is explicitly required.

Practice this question →
31
MCQhard

You are using HCP Terraform with the AWS provider and have configured a policy set with Sentinel policies. A policy fails during a run, and the run is paused. You have the necessary permissions to override the policy. What is the effect of overriding a soft-mandatory policy failure?

A.The policy is automatically changed to advisory for all future runs.
B.The run continues, and the override is recorded in the audit log.
C.The policy is permanently disabled for the workspace.
D.The run is cancelled and must be restarted after the policy is fixed.
AnswerB

When a soft-mandatory policy fails and a user with override permissions chooses to override, the run proceeds, and the override action is logged in the audit trail. This ensures accountability while allowing flexibility. The policy remains in effect for future runs.

Why this answer

Overriding a soft-mandatory policy failure permits the current run to proceed, and the override is captured in the audit log for traceability. This mechanism balances enforcement with operational flexibility. The policy itself remains unchanged and will be enforced in subsequent runs.

Exam trap

The trap here is thinking that an override disables or alters the policy for future runs, when it only affects the current run and is logged.

Practice this question →
32
MCQhard

Your organization uses HCP Terraform with Sentinel policies. A policy set is configured with enforcement level 'hard-mandatory' and includes a policy that checks for the presence of a 'CostCenter' tag on all AWS resources. During a run, the policy fails because a newly added aws_s3_bucket lacks the tag. What happens to the run?

A.The policy failure is recorded as an advisory and the run continues automatically.
B.The run is queued for manual review by an organization owner before apply.
C.The run pauses and waits for a user with override permissions to approve continuation.
D.The run fails immediately and cannot proceed to apply.
AnswerD

Hard-mandatory policies enforce strict compliance; if the policy fails, the run is halted and cannot continue to apply. There is no override option. In this scenario, the missing tag causes the policy to fail, so the run fails immediately. The user must fix the configuration and start a new run to proceed.

Why this answer

Hard-mandatory Sentinel policies enforce strict compliance and cannot be overridden. If the policy fails, the run is immediately halted and cannot proceed to apply. The user must correct the configuration to include the required tag and trigger a new run.

This ensures no non-compliant infrastructure is deployed.

Exam trap

The trap here is mixing up hard-mandatory with soft-mandatory; hard-mandatory fails the run outright, while soft-mandatory pauses for possible override.

Practice this question →
33
MCQmedium

You are configuring RBAC in HCP Terraform. A user needs to trigger runs and view plan logs but should not be allowed to modify workspace variables. Which permission set is appropriate?

A.Grant Admin access.
B.Grant 'Read' and 'Queue Plan' permissions.
C.Grant 'Manage Variables' permission.
D.Grant 'Write' permission to the workspace.
AnswerB

Granting Read plus Queue Plan satisfies the least-privilege requirement: Read exposes plan logs and workspace state, while Queue Plan permits triggering runs. Neither permission includes the variables:write capability, so the user cannot modify workspace variables. This precisely matches the stem's constraint of triggering runs and viewing logs without variable edit rights.

Why this answer

The 'Read' and 'Queue Plan' permissions allow a user to view workspaces and trigger runs, but not modify variables. This follows the principle of least privilege for the required actions.

Exam trap

The trap is granting 'Write' permission thinking it's needed to trigger runs. Candidates might confuse 'Write' with 'Queue Plan'. The exam tests understanding of the specific permission needed for triggering runs without variable modification.

How to eliminate wrong answers

Option A is wrong because Admin access grants full control, including modifying variables, which is excessive. Option C is wrong because 'Manage Variables' permission specifically allows modifying variables, which the user should not have. Option D is wrong because 'Write' permission allows modifying workspace settings and variables, which is more than needed.

Practice this question →
34
MCQhard

A Sentinel policy is failing on a cost estimation result. What is the most likely cause if the cost estimation feature is enabled but the policy still fails?

A.The cost estimation provider is not configured for AWS.
B.The workspace does not have Sentinel enabled.
C.The API key for AWS is invalid.
D.The policy attempts to access cost data before the estimation has completed.
AnswerD

Cost estimation runs asynchronously after plan, so a policy evaluating cost data during the plan phase may execute before estimation finishes. The policy then reads an empty or incomplete result and fails, despite cost estimation being enabled.

Why this answer

Cost estimation in Terraform Cloud runs asynchronously after the plan. If a Sentinel policy references cost data (e.g., 'tfrun.cost_estimate') before the estimation has completed, the policy will fail because the data is not yet populated. This is the most likely cause when cost estimation is enabled but the policy still fails.

Exam trap

The trap is assuming that enabling cost estimation guarantees the data is available to Sentinel — candidates overlook the asynchronous timing and pick infrastructure-related causes (API key, provider config) instead of the race condition.

How to eliminate wrong answers

Option A is wrong because cost estimation is a Terraform Cloud feature that works with the AWS provider out of the box — there is no separate 'cost estimation provider' to configure for AWS. Option B is wrong because if Sentinel were not enabled, the policy would not run at all rather than fail on cost data. Option C is wrong because an invalid AWS API key would cause the plan itself to fail, not a Sentinel policy failure on cost estimation.

Practice this question →
35
MCQmedium

Your team uses HCP Terraform to manage AWS infrastructure. You need to ensure that all workspaces in a specific project automatically inherit a set of environment variables containing AWS credentials. These variables must be available to all runs in those workspaces without manual configuration. What is the most efficient way to achieve this?

A.Create a variable set with the environment variables and assign it to the project.
B.Define the variables in each workspace's Terraform configuration using a shared module.
C.Use the HCP Terraform API to create the variables in each workspace via a script.
D.Configure a run trigger that copies variables from a template workspace to the target workspaces.
AnswerA

Variable sets can be scoped to projects, and all workspaces within that project automatically inherit the variables. This eliminates the need to configure each workspace individually. It is the intended feature for sharing variables across multiple workspaces, and it supports environment variables, including sensitive ones.

Why this answer

Variable sets are designed to share variables across multiple workspaces. When assigned to a project, all workspaces in that project inherit the variables automatically, including new workspaces. This is the most efficient and maintainable solution.

Other options require manual intervention or do not provide automatic inheritance.

Exam trap

The trap here is overlooking the project-level scoping of variable sets and instead considering per-workspace configuration or API scripting, which are more labor-intensive and error-prone.

Practice this question →
36
MCQhard

What is the result of a 'soft-mandatory' Sentinel policy failing during a run?

A.The run is immediately aborted.
B.The policy is skipped automatically.
C.The run pauses and waits for an override.
D.The run completes but triggers an alert.
AnswerC

Soft-mandatory sits between advisory and hard-mandatory on the enforcement scale: failure blocks the run but permits a privileged user to override, resuming it. Hard-mandatory cannot be overridden, and advisory only logs, so pausing for override matches the stem.

Why this answer

A soft-mandatory Sentinel policy, when it fails, causes the run to pause and wait for an override. This allows an authorized user to manually approve the run and continue, providing a balance between enforcement and flexibility. This is in contrast to hard-mandatory, which aborts the run immediately.

Exam trap

The trap is confusing soft-mandatory with hard-mandatory or advisory enforcement levels. Candidates might think soft-mandatory aborts the run or is skipped, but it actually pauses for override.

How to eliminate wrong answers

Option A is wrong because immediate abortion is the behavior of a hard-mandatory policy, not soft-mandatory. Option B is wrong because the policy is not skipped; it fails and requires intervention. Option D is wrong because the run does not complete; it pauses, and no alert is triggered by default.

Practice this question →
37
MCQhard

Your organization uses HCP Terraform with projects to group workspaces by business unit. A compliance rule states that any workspace in the 'finance' project must have a cost estimation check that fails the run if the monthly cost increase exceeds $500. You have enabled cost estimation in the organization settings. What should you do next to enforce this rule?

A.Configure a run trigger from a cost monitoring workspace to the finance workspaces to automatically reject runs that exceed the threshold.
B.Create a Sentinel policy that uses the tfrun import to access the cost estimation data and enforce a hard-mandatory policy when the delta exceeds $500.
C.Enable the 'Cost Estimation' setting on each finance workspace and manually review the cost estimate before applying.
D.Set a workspace variable named COST_THRESHOLD to 500 and rely on Terraform's AWS provider to enforce it during plan.
AnswerB

Sentinel policies can access cost estimation results through the tfrun import, specifically the cost_estimate data. A hard-mandatory policy can evaluate the monthly cost delta and fail the run if it exceeds the threshold, providing the required enforcement for the finance project.

Why this answer

Cost estimation in HCP Terraform provides data that Sentinel policies can evaluate. By writing a hard-mandatory policy that checks the monthly cost delta from the cost estimate and fails if it exceeds $500, you enforce the compliance rule automatically for all runs in the finance project. This leverages the existing cost estimation feature and the policy-as-code framework.

Exam trap

The trap here is thinking that enabling cost estimation alone enforces a threshold, when it only provides data that must be acted upon by a policy or manual process.

Practice this question →
38
MCQmedium

You need to ensure that all workspaces use a specific set of tags. How can this be enforced?

A.Using an HCP Terraform Sentinel policy.
B.Using a VCS branch protection rule.
C.Using a variable validation block.
D.Enabling 'Strict Mode' in the organization settings.
AnswerA

Sentinel is HCP Terraform's policy-as-code engine, evaluating plans against rules before apply. A policy can require specific tag keys on every workspace resource, blocking non-compliant runs, which directly enforces the mandated tag set across all workspaces.

Why this answer

HCP Terraform Sentinel policies are policy-as-code rules that are evaluated during the plan phase of a run. Sentinel policies can inspect the planned state of resources and enforce constraints such as requiring specific tags on all taggable resources. Because Sentinel operates at the organization level and can be applied to all workspaces, it is the correct way to enforce a consistent tagging standard across every workspace.

Exam trap

The trap is confusing Terraform-native validation (variable validation blocks) with organization-level policy enforcement — candidates often pick variable validation because it sounds like a validation mechanism, but it cannot inspect resource tags.

How to eliminate wrong answers

Option B is wrong because VCS branch protection rules control who can merge code into branches — they have no visibility into Terraform resource attributes like tags and cannot enforce tagging at plan time. Option C is wrong because a variable validation block only validates the value of a single input variable within a module; it cannot inspect resource-level tags or enforce them across all workspaces. Option D is wrong because HCP Terraform does not have a 'Strict Mode' organization setting for enforcing tags — this is a fabricated feature.

Practice this question →
39
Multi-Selecteasy

Which TWO of the following are standard stages of an HCP Terraform run pipeline?

Select 2 answers
A.Policy Check.
B.Code linting.
C.Plan.
D.Automatic refactoring.
E.State migration.
AnswersA, C

Policy Check is a distinct pipeline stage where Sentinel policies evaluate the plan before apply, enforcing governance. It runs after Plan and before Apply, so it satisfies the requirement for a standard HCP Terraform run stage.

Why this answer

Option A (Policy Check) is correct because HCP Terraform's run pipeline includes a Policy Check stage where Sentinel or OPA policies are evaluated against the plan before it can be applied, enforcing governance and compliance. Option C (Plan) is correct because the Plan stage is a core phase of every run, where Terraform generates an execution plan comparing the current state to the desired configuration. The pipeline stages are typically Plan, Policy Check, and Apply, so these two fit the standard sequence.

Option B (Code linting) is not a pipeline stage; linting is done externally by tools like tflint or pre-commit hooks, not by HCP Terraform's run workflow. Option D (Automatic refactoring) is not a feature of the run pipeline; Terraform does not automatically rewrite configurations. Option E (State migration) is not a pipeline stage; state migration occurs when changing backends or workspaces, not as a standard run phase.

Exam trap

HCP Terraform exams often test whether candidates confuse real pipeline stages (Plan, Policy Check, Apply) with generic software practices like linting or refactoring.

Practice this question →
40
MCQhard

Your organization uses HCP Terraform with the AWS provider. A Sentinel policy set is attached to the 'production' project with a soft-mandatory policy that checks for required tags on all AWS resources. During a run, the policy fails because a developer forgot to add a 'CostCenter' tag to an EC2 instance. What is the outcome of the run, and what can the developer do?

A.The run is paused, and a user with permission to override policies can choose to override the failure and continue the apply.
B.The run continues automatically but logs a warning, and the apply proceeds without any intervention.
C.The run fails immediately and cannot be overridden; the developer must modify the configuration and push a new commit.
D.The run is paused, and an organization owner must approve an override before the apply can proceed.
AnswerA

Soft-mandatory policies pause the run when they fail, allowing a user with the 'manage policy overrides' permission to override the failure. This enables the run to continue to apply after the override, which is the expected behavior for a soft-mandatory policy.

Why this answer

A soft-mandatory Sentinel policy failure pauses the run and requires an authorized user to override the failure before the apply can proceed. This provides a balance between enforcement and flexibility, allowing developers to address issues or override when justified. The developer can override if they have the necessary permissions, and the run will then continue.

Exam trap

The trap here is confusing soft-mandatory with advisory or hard-mandatory policies; soft-mandatory pauses and allows override, while advisory only warns and hard-mandatory blocks without override.

Practice this question →
41
MCQeasy

Your team uses HCP Terraform to manage AWS resources. You need to ensure that all workspaces in a project automatically inherit a set of AWS region and tagging variables. What is the most efficient way to achieve this?

A.Use a Terraform module to set the variables in each workspace.
B.Create a variable set and assign it to the project.
C.Define the variables in each workspace individually.
D.Store the variables in a version control system and reference them via a remote backend.
AnswerB

Variable sets allow you to define variables once and apply them to multiple workspaces or entire projects. Assigning a variable set to a project ensures all current and future workspaces in that project inherit the variables, reducing duplication and manual effort. This is the most efficient method for consistent AWS region and tagging variables.

Why this answer

Variable sets are designed to share variables across multiple workspaces. Assigning a variable set to a project ensures all workspaces in that project inherit the variables, including future ones. This is more efficient than per-workspace definitions and is the recommended practice for organization-wide or project-wide variables.

Exam trap

The trap here is confusing Terraform module variables with HCP Terraform workspace variables, or assuming that version control can directly populate workspace variables.

Practice this question →
42
MCQhard

You are designing a governance strategy for your HCP Terraform organization. You need to enforce that all AWS resources are tagged with a 'CostCenter' tag. The policy should block any run that creates resources without this tag, but you also want to allow a temporary exception for a migration project. Which combination of Sentinel enforcement level and policy set scoping should you use?

A.Use a hard-mandatory policy set scoped to all workspaces except the migration project, and a separate advisory policy set for the migration project.
B.Use a hard-mandatory policy set scoped to all workspaces, and create a separate policy set with an advisory policy for the migration project.
C.Use a soft-mandatory policy set scoped to all workspaces, and rely on developers to override when necessary.
D.Use a hard-mandatory policy set scoped only to the migration project, and an advisory policy set for all other workspaces.
AnswerA

Scoping the hard-mandatory policy set to exclude the migration project ensures that only the migration project is exempt, while all other workspaces are strictly enforced. The advisory policy set for the migration project logs violations without blocking, providing visibility. This achieves the required exception while maintaining governance elsewhere.

Why this answer

To block non-compliant runs everywhere except the migration project, the hard-mandatory policy set must be scoped to all workspaces except that project. The migration project can then have an advisory policy set to log violations without blocking. This combination enforces the tagging requirement broadly while allowing the migration project to proceed with visibility.

Exam trap

The trap here is assuming that adding a separate advisory policy set can override an existing hard-mandatory policy, or that scoping a hard-mandatory policy to all workspaces can be excepted by another policy set; instead, scoping must exclude the project.

Practice this question →
43
MCQmedium

Your organization uses HCP Terraform with the AWS provider. You need to ensure that all workspaces in the organization automatically use a specific set of AWS credentials for runs, without manually configuring variables in each workspace. The credentials must be available as environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) and should be centrally managed. What should you do?

A.Create a Variable Set at the organization level containing the AWS credentials as environment variables, and apply it to all workspaces.
B.Configure the AWS provider to use the default credential chain, which will automatically retrieve credentials from HCP Terraform's environment.
C.Create a Sentinel policy that injects the AWS credentials into each run's environment before execution.
D.Store the AWS credentials in a Terraform Cloud API token and reference it in the provider configuration using var.token.
AnswerA

Variable Sets allow you to define variables once and apply them to multiple workspaces. Organization-level variable sets can be applied to all current and future workspaces, ensuring consistent AWS credentials. This centralizes management and avoids manual per-workspace configuration, directly meeting the requirement.

Why this answer

Organization-level Variable Sets are designed to share variables across multiple workspaces, including sensitive credentials. By defining AWS access keys as environment variables in a variable set and applying it to all workspaces, you ensure every run has the necessary credentials without manual intervention. This approach centralizes management and reduces configuration drift.

Exam trap

The trap here is confusing HCP Terraform's own authentication tokens with cloud provider credentials, or assuming that Sentinel can manage secrets, when in fact variable sets are the correct mechanism for shared credentials.

Practice this question →
44
MCQhard

Your organization has a Sentinel policy with enforcement level 'soft-mandatory' that checks for required tags on AWS resources. During a run, the policy fails because an EC2 instance is missing the 'Environment' tag. The workspace allows users with write access to override policies. What is the immediate outcome of the run?

A.The policy failure is logged as an advisory and the run continues automatically without any intervention.
B.The run is paused and a user with appropriate permissions can choose to override the policy and continue the apply.
C.The run fails immediately and cannot be overridden, requiring the configuration to be fixed and a new run to be queued.
D.The run is canceled and the workspace is locked until the policy is updated to pass.
AnswerB

A soft-mandatory policy failure pauses the run and allows a user with override permissions to bypass the policy. In this scenario, the user can override and proceed with the apply despite the missing tag. This is the designed behavior for soft-mandatory enforcement, balancing governance with flexibility for authorized users.

Why this answer

When a soft-mandatory Sentinel policy fails, the run pauses and users with override permissions can choose to bypass the policy and continue. This allows for exceptions while still enforcing governance. Hard-mandatory policies cannot be overridden, and advisory policies do not block.

The scenario specifies soft-mandatory, so the run is paused for possible override.

Exam trap

The trap here is confusing soft-mandatory with hard-mandatory or advisory enforcement levels; soft-mandatory pauses for override, while hard-mandatory fails and advisory only warns.

Practice this question →

Ready to test yourself?

Try a timed practice session using only HCP Terraform Governance questions.

Start 20-question session