AWS provider Collaborative Workflows — Timed 10 Questions

Question 1

You have a team-based collaboration project. Where should you store sensitive credentials like AWS secret keys so they are not hardcoded in your Terraform files?

Accepted Answer

In environment variables marked as 'sensitive'. Environment variables are the recommended way to supply sensitive credentials to Terraform because they are read at runtime by the AWS provider (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) and never written into configuration or state. Marking them sensitive in the shell or CI system keeps them out of version control and out of plan output. This satisfies the requirement that secrets not be hardcoded in .tf files.

Answer

In a .tfvars file

Answer

In a version-controlled .env file

Answer

In the state file

Question 2

Which organization-level setting in HCP Terraform governs who can create new workspaces?

Accepted Answer

Team permissions. Team permissions in HCP Terraform are the organization-level mechanism that controls workspace creation rights. By default, only users with the 'Owner' or 'Admin' team permissions can create workspaces, but this can be delegated to other teams via custom permissions. This setting is managed at the organization level under 'Teams' and directly governs who can create new workspaces.

Answer

Global settings

Answer

Agent pool settings

Answer

Workspace settings

Question 3

You need to enforce that only specific VM sizes are used in your infrastructure. Which Sentinel feature provides this capability?

Accepted Answer

Policy enforcement. Policy enforcement in HCP Terraform (formerly Terraform Cloud) Sentinel is the feature that evaluates infrastructure plans against policy rules and blocks non-compliant changes. By writing a Sentinel policy that checks the instance_type attribute of AWS instances against an allow-list, you enforce that only approved VM sizes can be provisioned. This is the core purpose of Sentinel policy enforcement.

Answer

Run trigger

Answer

Workspaces

Answer

Policy Set

Question 4

When implementing OPA policies, what is the 'soft-mandatory' enforcement level?

Accepted Answer

It allows the run if overridden. In OPA (Open Policy Agent) policy enforcement, 'soft-mandatory' is a level that allows a policy violation to be overridden by an authorized user, typically with a justification. This means the run is not blocked outright; instead, it proceeds if the override is applied. This is in contrast to 'hard-mandatory', which blocks the run completely, and 'advisory', which only logs the event. The correct answer is B because soft-mandatory enforcement permits the run when overridden.

Answer

It blocks the run completely

Answer

It is a deprecated feature

Answer

It only logs the event

Question 5

Which protocol does HCP Terraform use to communicate with Terraform CLI?

Accepted Answer

HCP Terraform API. Terraform uses the 'Terraform Cloud API' for all communication between the CLI and HCP Terraform.

Answer

gRPC

Answer

FTP

Answer

SSH

Question 6

Which HCP Terraform feature allows you to manage infrastructure across multiple cloud accounts using a single organization?

Accepted Answer

Projects. HCP Terraform Projects allow you to organize workspaces and their associated infrastructure into logical groupings that can span multiple cloud accounts, all under a single organization. This feature provides a way to manage access control, policy enforcement, and cost allocation across different teams or environments without needing separate organizations. By using projects, you can delegate administration and apply consistent governance across disparate cloud accounts, which is exactly what the question describes.

Answer

Shared modules

Answer

Provider aliases

Answer

Remote execution

Question 7

You have accidentally committed a secret to your VCS repository. After rotating the secret, what is the best practice to ensure it is not used in your workspace?

Accepted Answer

Use HCP Terraform sensitive variables. HCP Terraform sensitive variables are the recommended mechanism for injecting secrets into runs without storing them in VCS. After rotating a leaked secret, you mark the new value as sensitive in the workspace's variable set, so it is encrypted at rest, masked in logs, and never written to the repository. This ensures the workspace uses the rotated secret while the compromised value remains useless.

Answer

Delete the repository

Answer

Disable VCS integration

Answer

Run terraform destroy

Question 8

Which THREE actions occur when you execute a Terraform run in HCP Terraform?

Accepted Answer

Policy evaluation. In an HCP Terraform (formerly Terraform Cloud) run, the workspace first performs plan generation (D), where Terraform creates an execution plan showing the proposed changes to reach the desired state defined in configuration. Policy evaluation (B) then occurs via Sentinel or OPA policy sets attached to the workspace, enforcing governance rules such as cost limits or required tags before any apply is permitted. Manual approval (C) is a standard stage in the run workflow when the workspace uses the default 'Manual apply' setting, requiring a user to confirm the apply after the plan and policies pass. The remaining options do not belong: immediate infrastructure destruction (A) is not an automatic run action—destruction only happens if the plan explicitly calls for it and is approved—and local environment cleanup (E) is not performed by HCP Terraform, since runs execute on remote runners rather than the user's local machine.

Answer

Immediate infrastructure destruction

Answer

Local environment cleanup

Question 9

You have a workspace configured for 'CLI-driven' workflow. What does this mean for how you apply changes?

Accepted Answer

The user triggers operations via the CLI. A CLI-driven workspace in HCP Terraform means the user runs `terraform plan` and `terraform apply` from their local terminal, with the run executing remotely in HCP Terraform's infrastructure. The CLI authenticates to the workspace and streams logs back, but the user remains the trigger for every operation. This is distinct from VCS-driven and API-driven workflows.

Answer

Operations are always automatic

Answer

It disables remote state

Answer

The plan happens locally, apply remotely

Question 10

Which TWO ways can you connect a workspace to your version control provider?

Accepted Answer

Direct VCS integration. Option A (Direct VCS integration) is correct because connecting a workspace directly to a supported version control provider (such as GitHub, GitLab, Bitbucket, or Azure DevOps) via OAuth or a VCS connection lets Terraform automatically ingest the repository and trigger runs on commits, which is a first-class supported method. Option B (CLI-driven workflow) is also correct because you can run Terraform CLI commands from your local machine or CI/CD pipeline against a workspace, using the remote backend or API-driven runs to associate and push configuration from your version control provider without a direct VCS link. Option C (Manual UI file upload) is not a supported way to connect a workspace to a VCS provider, since the UI does not provide a mechanism to upload files as a version control connection. Option D (FTP upload) is incorrect because FTP is not a supported protocol for connecting workspaces to version control. Option E (Emailing code to Terraform support) is incorrect because support cannot ingest code via email to establish a VCS connection.

Answer

Manual UI file upload

Answer

FTP upload

Answer

Emailing code to Terraform support