Skip to content
Cheat sheets

002 · Domain 5: Terraform Security and Governance · 13% of the exam

Task 5.2: Use secret rotation and integration with secrets management tools

Rotating secrets without drift or downtime: write-only argument versions, ephemeral resources that read from a secrets manager, replace_triggered_by, and refresh behavior.

Study it

  • Rotating secrets with write-only versions and ephemeral resources

    Lesson coming

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

A database password is generated and stored without ever entering state: ephemeral "random_password" "db" { length = 24 } resource "aws_secretsmanager_secret_version" "db" { secret_id = aws_secretsmanager_secret.db.id secret_string_wo = ephemeral.random_password.db.result secret_string_wo_version = 1 } ephemeral "aws_secretsmanager_secret_version" "db" { secret_id = aws_secretsmanager_secret_version.db.secret_id } resource "aws_db_instance" "main" { password_wo = ephemeral.aws_secretsmanager_secret_version.db.secret_string password_wo_version = aws_secretsmanager_secret_version.db.secret_string_wo_version # ... } How does the team rotate the password so that the secret and the database change together in one apply, without replacing the database?

  1. AChange the random_password length and keep secret_string_wo_version, which makes Terraform update both resources
  2. BRun terraform apply -replace=aws_db_instance.main, leaving password_wo_version as it is
  3. CIncrease secret_string_wo_version to 2; the database's password_wo_version follows it
  4. DAdd lifecycle { replace_triggered_by = [aws_secretsmanager_secret_version.db] } to the database
Show the answer and why

  • AChange the random_password length and keep secret_string_wo_version, which makes Terraform update both resources

    Incorrect

    Ephemeral values and write-only arguments are not stored, so Terraform has nothing to compare and plans no update from them alone.

  • BRun terraform apply -replace=aws_db_instance.main, leaving password_wo_version as it is

    Incorrect

    Replacing the database destroys and recreates it, which the team must avoid.

  • CIncrease secret_string_wo_version to 2; the database's password_wo_version follows it

    Correct

    Version arguments are stored in state, so the change triggers an update of the secret, and the database reads the new secret through the ephemeral resource with its version changed as well.

  • DAdd lifecycle { replace_triggered_by = [aws_secretsmanager_secret_version.db] } to the database

    Incorrect

    That replaces the database whenever the secret version changes instead of updating its password in place.

Terraform never compares write-only values, so rotation is driven by the version arguments it does store. Linking the database's version to the secret's version keeps one change in one place.

HashiCorp documentation

Task 5.2Report a problem with this question

Question 2 · choose 1

A configuration reads a Vault secret through an ephemeral resource. What does Terraform do with the Vault lease during a run?

  1. AStores the lease in state and renews it on each later run
  2. BOpens it, renews it if needed, and closes it after use
  3. CLeaves the lease to expire on its own schedule
  4. DReads it once during init and caches it
Show the answer and why

  • AStores the lease in state and renews it on each later run

    Incorrect

    Ephemeral resources are never stored in state.

  • BOpens it, renews it if needed, and closes it after use

    Correct

    Terraform opens the resource, asks the provider to renew it if the run outlasts the expiry, and closes it when dependent providers finish.

  • CLeaves the lease to expire on its own schedule

    Incorrect

    Terraform explicitly ends the lease when it closes the resource.

  • DReads it once during init and caches it

    Incorrect

    Ephemeral resources are opened during operations that need them.

Closing the resource ends the lease early, shortening how long the secret stays valid.

HashiCorp documentation

Task 5.2Report a problem with this question

Question 3 · choose 1

An ephemeral resource fetches a database credential, and its secret_id input refers to a secret that the same run creates. When does Terraform open it?

  1. AAt apply time, after the value is known
  2. BDuring plan, with a placeholder secret_id value
  3. CNever; ephemeral inputs must be known at init
  4. DDuring the following run only
Show the answer and why

  • AAt apply time, after the value is known

    Correct

    When an input references a value Terraform learns during or after the plan, it defers the ephemeral resource to the apply stage.

  • BDuring plan, with a placeholder secret_id value

    Incorrect

    Terraform does not open it with unknown inputs.

  • CNever; ephemeral inputs must be known at init

    Incorrect

    Deferral to apply handles unknown inputs.

  • DDuring the following run only

    Incorrect

    It runs in the same run's apply stage.

Anything that depends on the credential is planned as known after apply.

HashiCorp documentation

Task 5.2Report a problem with this question

Question 4 · choose 1

A security team wants every HCP Terraform workspace's AWS credentials to be short-lived and issued by its central Vault. Which feature fits?

  1. AStatic AWS keys in a sensitive variable set
  2. BA static Vault token stored in each workspace
  3. CDynamic credentials with AWS directly, no Vault
  4. DVault-backed dynamic credentials
Show the answer and why

  • AStatic AWS keys in a sensitive variable set

    Incorrect

    Static keys are long-lived and outside Vault.

  • BA static Vault token stored in each workspace

    Incorrect

    A static token is long-lived, the opposite of the goal.

  • CDynamic credentials with AWS directly, no Vault

    Incorrect

    That skips the central Vault the team wants.

  • DVault-backed dynamic credentials

    Correct

    Workload identity tokens authenticate to Vault, and its secrets engines generate short-lived AWS credentials.

Configure the AWS secrets engine in Vault first, then set the Vault-backed variables in the workspace or a variable set.

HashiCorp documentation

Task 5.2Report a problem with this question

Question 5 · choose 1

A workspace uses Vault-backed dynamic credentials for AWS with the iam_user auth type. The first API calls of each run fail with invalid credentials, and the same calls succeed a little later. Which setting addresses this?

  1. ATFC_VAULT_BACKED_AWS_MOUNT_PATH, set to the secrets engine path
  2. BA longer lease for the IAM user in Vault
  3. CTFC_VAULT_BACKED_AWS_SLEEP_SECONDS, of 1500 seconds at most
  4. DA plan-phase role through TFC_VAULT_BACKED_AWS_PLAN_VAULT_ROLE
Show the answer and why

  • ATFC_VAULT_BACKED_AWS_MOUNT_PATH, set to the secrets engine path

    Incorrect

    The mount path tells HCP Terraform where the AWS secrets engine is mounted; it does not delay first use.

  • BA longer lease for the IAM user in Vault

    Incorrect

    A longer lease does not help credentials that are not usable yet.

  • CTFC_VAULT_BACKED_AWS_SLEEP_SECONDS, of 1500 seconds at most

    Correct

    It sets how long to wait after obtaining temporary credentials from Vault, which mitigates eventual consistency issues in AWS with the iam_user auth type.

  • DA plan-phase role through TFC_VAULT_BACKED_AWS_PLAN_VAULT_ROLE

    Incorrect

    A separate plan role changes permissions, not when new credentials become usable.

New IAM user credentials take a moment to become usable across AWS. A short wait after HCP Terraform obtains them avoids failing the first calls; self-managed agents need v1.12.0 or later for this variable.

HashiCorp documentation

Task 5.2Report a problem with this question

Practice domain 5 →Practice all domains →