Skip to content
Cheat sheets

002 · Domain 4: CI/CD and Automation Workflows · 10% of the exam

Task 4.3: Manage multiple sets of dynamic provider credentials across teams, projects, and workspaces

Workload identity in HCP Terraform at scale: the TFC_* variables, variable sets per project, trust policies on token claims, and multiple configurations with tags for more than one account.

Study it

Sample questions

Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.

Question 1 · choose 1

Every current and future workspace in the payments project must get AWS credentials through dynamic provider credentials. Plans must run with a read-only role and applies with a write role, and no workspace outside the organization's payments project may assume either role. Which setup meets all three requirements?

  1. AA global variable set covering the project, with TFC_DEFAULT_AWS_PROVIDER_AUTH and TFC_DEFAULT_AWS_RUN_ROLE_ARN
  2. BA project-scoped variable set with TFC_AWS_PROVIDER_AUTH and one TFC_AWS_RUN_ROLE_ARN whose trust policy matches run_phase:*
  3. CA project-scoped variable set with plan and apply role ARNs, each role trusting only the aud claim
  4. DA project-scoped variable set with plan and apply role ARNs; each role trusts aud and a sub naming the org, project and its run phase
Show the answer and why

  • AA global variable set covering the project, with TFC_DEFAULT_AWS_PROVIDER_AUTH and TFC_DEFAULT_AWS_RUN_ROLE_ARN

    Incorrect

    TFC_AWS_PROVIDER_AUTH has no default variant, a global set reaches every project, and one run role cannot separate plan from apply.

  • BA project-scoped variable set with TFC_AWS_PROVIDER_AUTH and one TFC_AWS_RUN_ROLE_ARN whose trust policy matches run_phase:*

    Incorrect

    A single role trusted for every run phase gives plans the same write access as applies.

  • CA project-scoped variable set with plan and apply role ARNs, each role trusting only the aud claim

    Incorrect

    Checking only the audience lets workspaces in other projects and other organizations assume the roles.

  • DA project-scoped variable set with plan and apply role ARNs; each role trusts aud and a sub naming the org, project and its run phase

    Correct

    The project-scoped set reaches all current and future workspaces in the project, and separate roles matched on run_phase give plan and apply different permissions.

Share credentials configuration through a project-scoped variable set, separate TFC_AWS_PLAN_ROLE_ARN and TFC_AWS_APPLY_ROLE_ARN roles, and trust policies whose sub condition names the organization, the project and the run phase.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 2 · choose 1

Dynamic AWS credentials worked for every workspace in a project until an administrator renamed the project from "Default Project" to "platform". Since then, runs fail when assuming the role. What should the team change?

  1. ARegenerate the OIDC provider's thumbprint in AWS after the rename rotates HCP Terraform's signing key
  2. BSet TFC_AWS_WORKLOAD_IDENTITY_AUDIENCE to the new project name in the workspaces
  3. CUpdate the role's trust policy sub condition to the new project name
  4. DCreate a new team API token scoped to the renamed project
Show the answer and why

  • ARegenerate the OIDC provider's thumbprint in AWS after the rename rotates HCP Terraform's signing key

    Incorrect

    Renaming a project does not change HCP Terraform's signing keys; the token is still verified correctly.

  • BSet TFC_AWS_WORKLOAD_IDENTITY_AUDIENCE to the new project name in the workspaces

    Incorrect

    The audience is a separate claim and must keep matching the value the role trusts; it does not hold the project name.

  • CUpdate the role's trust policy sub condition to the new project name

    Correct

    The sub claim contains the organization, project and workspace names, and HashiCorp notes that these names can change, so the condition must follow the rename.

  • DCreate a new team API token scoped to the renamed project

    Incorrect

    Dynamic credentials do not use team API tokens; the run receives a workload identity token.

Trust policies usually match on names in the sub claim. Renaming an organization, project or workspace changes those names, so update the conditions, or match on claims that suit how often names change.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 3 · choose 1

A platform team enables dynamic AWS credentials for private registry module tests. The role trusts sub values matching organization:acme:project:*:workspace:*:run_phase:*, which works for workspace runs, but test runs cannot assume the role. Why?

  1. ATest runs request tokens for the apply phase, which the policy blocks
  2. BModule tests cannot use dynamic provider credentials in HCP Terraform at all
  3. CTest tokens are valid only after terraform login on a workstation
  4. DTest tokens use sub organization:acme:module:<NAME>:operation:test_run
Show the answer and why

  • ATest runs request tokens for the apply phase, which the policy blocks

    Incorrect

    Test run tokens always use the plan phase, and the condition already allows any phase.

  • BModule tests cannot use dynamic provider credentials in HCP Terraform at all

    Incorrect

    HCP Terraform generates workload identity tokens specifically for module test runs.

  • CTest tokens are valid only after terraform login on a workstation

    Incorrect

    HCP Terraform issues the tokens for the test run itself; no workstation login is involved.

  • DTest tokens use sub organization:acme:module:<NAME>:operation:test_run

    Correct

    Module test tokens have a different subject format and carry no project or workspace claims, so a condition written for workspace runs does not match them.

Add a trust condition for the module test subject, scoped to the organization and the module, next to the conditions for workspace runs.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 4 · choose 1

A workspace needs two Vault configurations for two aliased provider blocks. How does HCP Terraform define the second configuration?

  1. AA second workspace, linked to the first by a run trigger
  2. BTagged variables, such as TFC_VAULT_ADDR_ALIAS1
  3. CA second token pasted into a sensitive variable
  4. DA list of roles in TFC_VAULT_RUN_ROLE
Show the answer and why

  • AA second workspace, linked to the first by a run trigger

    Incorrect

    Multiple configurations live in one workspace.

  • BTagged variables, such as TFC_VAULT_ADDR_ALIAS1

    Correct

    Additional configurations append a tag to the required variables; on self-hosted agents this needs v1.12.0 or later.

  • CA second token pasted into a sensitive variable

    Incorrect

    Dynamic credentials replace static tokens.

  • DA list of roles in TFC_VAULT_RUN_ROLE

    Incorrect

    Each configuration has its own tagged variables.

Tags may contain letters, numbers and underscores, and each configuration gets its own workload identity token.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 5 · choose 1

Three tagged Vault configurations in a workspace all use the same Vault address. How can the team set the address only once?

  1. ASet TFC_VAULT_ADDR in a variable set; tags inherit it
  2. BSet the address in the provider block of each alias
  3. CSet TFC_DEFAULT_VAULT_ADDR
  4. DLeave it unset; the address is read from the token
Show the answer and why

  • ASet TFC_VAULT_ADDR in a variable set; tags inherit it

    Incorrect

    Untagged variables apply to the default configuration only.

  • BSet the address in the provider block of each alias

    Incorrect

    The address must come from the dynamic credentials variables.

  • CSet TFC_DEFAULT_VAULT_ADDR

    Correct

    TFC_DEFAULT_ variables give every configuration a value, and a tagged variable such as TFC_VAULT_ADDR_ALIAS2 overrides it.

  • DLeave it unset; the address is read from the token

    Incorrect

    The workload identity token does not carry the Vault address.

Default variables cut duplication when several configurations share settings.

HashiCorp documentation

Task 4.3Report a problem with this question

Question 6 · choose 1

With a second Vault configuration tagged ALIAS1, how does the aliased provider block get its credentials?

  1. AIt reads var.tfc_vault_dynamic_credentials.aliases["ALIAS1"]
  2. BIt sets alias = "ALIAS1" in the provider block and nothing else
  3. CIt reads var.tfc_vault_dynamic_credentials.default
  4. DIt reads the VAULT_TOKEN environment variable
Show the answer and why

  • AIt reads var.tfc_vault_dynamic_credentials.aliases["ALIAS1"]

    Correct

    HCP Terraform exposes each extra configuration under the variable's aliases map, keyed by the tag.

  • BIt sets alias = "ALIAS1" in the provider block and nothing else

    Incorrect

    The provider must be pointed at the token file for that tag.

  • CIt reads var.tfc_vault_dynamic_credentials.default

    Incorrect

    default holds the untagged configuration.

  • DIt reads the VAULT_TOKEN environment variable

    Incorrect

    Tagged configurations are wired through the variable object.

Declare the tfc_vault_dynamic_credentials variable with default and aliases attributes, then index aliases by tag.

HashiCorp documentation

Task 4.3Report a problem with this question

Practice domain 4 →Practice all domains →