HashiCorp HCVA0-003 Practice Exams
Last updated on Oct 21,2026- Exam Code: HCVA0-003
- Exam Name: HashiCorp Certified: Vault Associate (003)Exam
- Certification Provider: HashiCorp
- Latest update: Oct 21,2026
Question #1
Which of the following actions can be performed if you only had access to a token’s accessor? (Select four)
- A . Look up a token’s properties
- B . Renew the token
- C . Retrieve the actual token ID
- D . Revoke the token
- E . Look up a token’s capabilities on a path
Correct Answer: A, B, D, E
A, B, D, E
Explanation:
Comprehensive and Detailed In-Depth
A token accessor allows:
A, B, D, E: "This accessor can only be used to perform limited actions: Look up a token’s properties, Look up a token’s capabilities on a path, Renew the token, Revoke the token." The calling token needs permissions.
Incorrect Option:
C: "Not including the actual token ID."
Reference: https://developer.hashicorp.com/vault/docs/concepts/tokens#token-accessors
A, B, D, E
Explanation:
Comprehensive and Detailed In-Depth
A token accessor allows:
A, B, D, E: "This accessor can only be used to perform limited actions: Look up a token’s properties, Look up a token’s capabilities on a path, Renew the token, Revoke the token." The calling token needs permissions.
Incorrect Option:
C: "Not including the actual token ID."
Reference: https://developer.hashicorp.com/vault/docs/concepts/tokens#token-accessors
Question #2
Which of the following statements are true about Vault policies? Choose two correct answers.
- A . The default policy can not be modified
- B . You must use YAML to define policies
- C . Policies provide a declarative way to grant or forbid access to certain paths and operations in Vault
- D . Vault must be restarted in order for a policy change to take an effect
- E . Policies deny by default (empty policy grants no permission)
Correct Answer: CE
CE
Explanation:
Vault policies are written in HCL or JSON format and are attached to tokens or roles by name. Policies define the permissions and restrictions for accessing and performing operations on certain paths and secrets in Vault. Policies are deny by default, which means that an empty policy grants no permission in the system, and any request that is not explicitly allowed by a policy is implicitly denied1.
Some of the features and benefits of Vault policies are:
Policies are path-based, which means that they match the request path to a set of rules that specify the allowed or denied capabilities, such as create, read, update, delete, list, sudo, etc2.
Policies are additive, which means that if a token or a role has multiple policies attached, the effective policy is the union of all the individual policies. The most permissive capability is granted if there is a conflict3.
Policies can use glob patterns, such as * and +, to match multiple paths or segments with a single rule. For example, path “secret/*” matches any path starting with secret/, and path “secret/+/config” matches any path with two segments after secret/ and ending with config4.
Policies can use templating to interpolate certain values into the rules, such as identity information, time, randomness, etc. For example, path “secret/{{identity.entity.id}}/*” matches any path starting with secret/ followed by the entity ID of the requester5.
Policies can be managed by using the vault policy commands or the sys/policy API endpoints. You can write, read, list, and delete policies by using these interfaces6.
The default policy is a built-in policy that is attached to all tokens by default and cannot be deleted. However, the default policy can be modified by using the vault policy write command or the sys/policy API endpoint. The default policy provides common permissions for tokens, such as renewing themselves, looking up their own information, creating and managing response-wrapping tokens, etc7.
You do not have to use YAML to define policies, as Vault supports both HCL and JSON formats. HCL is a human-friendly configuration language that is also JSON compatible, which means that JSON can be used as a valid input for policies as well8.
Vault does not need to be restarted in order for a policy change to take effect, as policies are stored and evaluated in memory. Any change to a policy is immediately reflected in the system, and any token or role that has that policy attached will be affected by the change.
Reference:
1(https://developer.hashicorp.com/vault/docs/concepts/policies), 2(https://developer.hashicorp.com/vault/docs/concepts/policies), 3(https://developer.hashicorp.com/vault/docs/concepts/policies), 4(https://developer.hashicorp.com/vault/docs/concepts/policies), 5(https://developer.hashicorp.com/vault/docs/concepts/policies), 6(https://developer.hashicorp.com/vault/docs/commands/lease), 7(https://developer.hashicorp.com/vault/docs/concepts/policies), 8(https://developer.hashicorp.com/vault/docs/concepts/policies),
(https://developer.hashicorp.com/vault/docs/concepts/policies#policy-updates)
CE
Explanation:
Vault policies are written in HCL or JSON format and are attached to tokens or roles by name. Policies define the permissions and restrictions for accessing and performing operations on certain paths and secrets in Vault. Policies are deny by default, which means that an empty policy grants no permission in the system, and any request that is not explicitly allowed by a policy is implicitly denied1.
Some of the features and benefits of Vault policies are:
Policies are path-based, which means that they match the request path to a set of rules that specify the allowed or denied capabilities, such as create, read, update, delete, list, sudo, etc2.
Policies are additive, which means that if a token or a role has multiple policies attached, the effective policy is the union of all the individual policies. The most permissive capability is granted if there is a conflict3.
Policies can use glob patterns, such as * and +, to match multiple paths or segments with a single rule. For example, path “secret/*” matches any path starting with secret/, and path “secret/+/config” matches any path with two segments after secret/ and ending with config4.
Policies can use templating to interpolate certain values into the rules, such as identity information, time, randomness, etc. For example, path “secret/{{identity.entity.id}}/*” matches any path starting with secret/ followed by the entity ID of the requester5.
Policies can be managed by using the vault policy commands or the sys/policy API endpoints. You can write, read, list, and delete policies by using these interfaces6.
The default policy is a built-in policy that is attached to all tokens by default and cannot be deleted. However, the default policy can be modified by using the vault policy write command or the sys/policy API endpoint. The default policy provides common permissions for tokens, such as renewing themselves, looking up their own information, creating and managing response-wrapping tokens, etc7.
You do not have to use YAML to define policies, as Vault supports both HCL and JSON formats. HCL is a human-friendly configuration language that is also JSON compatible, which means that JSON can be used as a valid input for policies as well8.
Vault does not need to be restarted in order for a policy change to take effect, as policies are stored and evaluated in memory. Any change to a policy is immediately reflected in the system, and any token or role that has that policy attached will be affected by the change.
Reference:
1(https://developer.hashicorp.com/vault/docs/concepts/policies), 2(https://developer.hashicorp.com/vault/docs/concepts/policies), 3(https://developer.hashicorp.com/vault/docs/concepts/policies), 4(https://developer.hashicorp.com/vault/docs/concepts/policies), 5(https://developer.hashicorp.com/vault/docs/concepts/policies), 6(https://developer.hashicorp.com/vault/docs/commands/lease), 7(https://developer.hashicorp.com/vault/docs/concepts/policies), 8(https://developer.hashicorp.com/vault/docs/concepts/policies),
(https://developer.hashicorp.com/vault/docs/concepts/policies#policy-updates)
Question #3
You are using Vault’s Transit secrets engine to encrypt your data. You want to reduce the amount of content encrypted with a single key in case the key gets compromised.
How would you do this?
- A . Use 4096-bit RSA key to encrypt the data
- B . Upgrade to Vault Enterprise and integrate with HSM
- C . Periodically re-key the Vault’s unseal keys
- D . Periodically rotate the encryption key
Correct Answer: D
D
Explanation:
The Transit secrets engine supports the rotation of encryption keys, which allows you to change the key that is used to encrypt new data without affecting the ability to decrypt data that was already encrypted. This reduces the amount of content encrypted with a single key in case the key gets compromised, and also helps you comply with the NIST guidelines for key rotation. You can rotate the encryption key manually by invoking the /transit/keys/<name>/rotate endpoint, or you can configure the key to automatically rotate based on a time interval or a number of encryption operations. When you rotate a key, Vault generates a new key version and increments the key’s latest_version metadata. The new key version becomes the encryption key used for encrypting any new data. The previous key versions are still available for decrypting the existing data, unless you specify a minimum decryption version to archive the old key versions. You can also delete or disable old key versions if you want to revoke access to the data encrypted with those versions.
Reference: https://developer.hashicorp.com/vault/docs/secrets/transit1, https://developer.hashicorp.com/vault/api-docs/secret/transit2
D
Explanation:
The Transit secrets engine supports the rotation of encryption keys, which allows you to change the key that is used to encrypt new data without affecting the ability to decrypt data that was already encrypted. This reduces the amount of content encrypted with a single key in case the key gets compromised, and also helps you comply with the NIST guidelines for key rotation. You can rotate the encryption key manually by invoking the /transit/keys/<name>/rotate endpoint, or you can configure the key to automatically rotate based on a time interval or a number of encryption operations. When you rotate a key, Vault generates a new key version and increments the key’s latest_version metadata. The new key version becomes the encryption key used for encrypting any new data. The previous key versions are still available for decrypting the existing data, unless you specify a minimum decryption version to archive the old key versions. You can also delete or disable old key versions if you want to revoke access to the data encrypted with those versions.
Reference: https://developer.hashicorp.com/vault/docs/secrets/transit1, https://developer.hashicorp.com/vault/api-docs/secret/transit2
Question #4
Vault is configured with the oidc auth method and you need to log in using the CLI.
What command would you use to authenticate so you can make configuration changes to Vault?
- A . vault login -method=oidc username=bryan
- B . vault auth oidc
- C . vault login auth/oidc/users/bryan
- D . vault login username=bryan
Correct Answer: A
A
Explanation:
Comprehensive and Detailed In-Depth
To authenticate via the OIDC auth method using the CLI, the vault login command with the -method
flag is used. The Vault documentation states:
"To authenticate using the CLI, you could use the command vault login and specify the auth method you wish to use by using the -method flag. For example, if you wanted to authenticate using OIDC, you could use vault login -method=oidc [options]."
― Vault Commands: login
A: vault login -method=oidc username=bryan is correct, specifying the OIDC method and username: "The correct command to authenticate using the oidc auth method in Vault is vault login – method=oidc username=bryan."
― Vault Auth: OIDC
B: vault auth oidc is invalid; auth is not a login command.
C: vault login auth/oidc/users/bryan is incorrect syntax; it mimics an API path, not a CLI command.
D: vault login username=bryan lacks the method specification, defaulting to token auth.
Reference: Vault Commands: login
Vault Auth: OIDC
A
Explanation:
Comprehensive and Detailed In-Depth
To authenticate via the OIDC auth method using the CLI, the vault login command with the -method
flag is used. The Vault documentation states:
"To authenticate using the CLI, you could use the command vault login and specify the auth method you wish to use by using the -method flag. For example, if you wanted to authenticate using OIDC, you could use vault login -method=oidc [options]."
― Vault Commands: login
A: vault login -method=oidc username=bryan is correct, specifying the OIDC method and username: "The correct command to authenticate using the oidc auth method in Vault is vault login – method=oidc username=bryan."
― Vault Auth: OIDC
B: vault auth oidc is invalid; auth is not a login command.
C: vault login auth/oidc/users/bryan is incorrect syntax; it mimics an API path, not a CLI command.
D: vault login username=bryan lacks the method specification, defaulting to token auth.
Reference: Vault Commands: login
Vault Auth: OIDC
Question #5
An application has authenticated to Vault and has obtained dynamic database credentials with a lease of 4 hours. Four hours later, the credentials expire, and the application can no longer communicate with the backend database, so the application goes down.
What should the developers instruct the application to do to prevent this from happening again while maintaining the same level
of security?
- A . Go back to using static credentials
- B . Renew the lease before expiration
- C . Revoke the lease before expiration
- D . Use a different auth method
Correct Answer: B
B
Explanation:
Comprehensive and Detailed in Depth
To prevent application downtime due to expired dynamic credentials while maintaining security, the application should renew the lease before it expires. The HashiCorp Vault documentation states: "The application should frequently ‘check-in’ with Vault and renew the lease to prevent the lease from expiring." It adds: "A lease must be renewed before it has expired. Once it has expired, it is permanently revoked and a new secret must be requested."
The docs elaborate: "Dynamic secrets are designed to be short-lived and automatically rotated or
revoked when their lease expires. Renewing the lease extends its validity, ensuring continuous access
without compromising the security benefits of short-lived credentials." A (Static credentials) reduces
security by eliminating rotation. C (Revoke) ends access early. D (Different auth method) doesn’t
address lease management. Thus, B is correct.
Reference: HashiCorp Vault Documentation – Leases: Lease Renew and Revoke
B
Explanation:
Comprehensive and Detailed in Depth
To prevent application downtime due to expired dynamic credentials while maintaining security, the application should renew the lease before it expires. The HashiCorp Vault documentation states: "The application should frequently ‘check-in’ with Vault and renew the lease to prevent the lease from expiring." It adds: "A lease must be renewed before it has expired. Once it has expired, it is permanently revoked and a new secret must be requested."
The docs elaborate: "Dynamic secrets are designed to be short-lived and automatically rotated or
revoked when their lease expires. Renewing the lease extends its validity, ensuring continuous access
without compromising the security benefits of short-lived credentials." A (Static credentials) reduces
security by eliminating rotation. C (Revoke) ends access early. D (Different auth method) doesn’t
address lease management. Thus, B is correct.
Reference: HashiCorp Vault Documentation – Leases: Lease Renew and Revoke
Question #6
Which of the following policies would permit a user to generate dynamic credentials on a database?
- A . path "database/creds/read_only_role" { capabilities = ["generate"] }
- B . path "database/creds/read_only_role" { capabilities = ["update"] }
- C . path "database/creds/read_only_role" { capabilities = ["list"] }
- D . path "database/creds/read_only_role" { capabilities = ["read"] }
Correct Answer: D
D
Explanation:
Comprehensive and Detailed in Depth
The Database secrets engine generates dynamic credentials for database access. The endpoint database/creds/<role> (e.g., read_only_role) provides these credentials via a read operation. Let’s analyze:
Option A: capabilities = ["generate"]
There’s no generate capability in Vault policies. Capabilities are create, read, update, delete, list, etc.
This is invalid. Incorrect.
Option B: capabilities = ["update"]
update (PUT) modifies existing data, not generates credentials. The creds endpoint uses GET.
Incorrect.
Option C: capabilities = ["list"]
list retrieves metadata or paths, not credential data. Incorrect.
Option D: capabilities = ["read"]
Generating dynamic credentials involves a GET request to database/creds/<role>, mapped to the
read capability. This policy allows it. Correct.
Detailed Mechanics:
For a role read_only_role defined with vault write database/roles/read_only_role db_name=my-db creation_statements="CREATE USER…", a user with read on database/creds/read_only_role can run
vault read database/creds/read_only_role to get temporary credentials. Vault’s policy system aligns
HTTP verbs to capabilities: GET = read, PUT = update. This counterintuitive mapping (GET for
creation) is specific to dynamic secrets.
Overall Explanation from Vault Docs:
“Generating database credentials requires read capability on database/creds/<role>… Despite creating credentials, the HTTP request is a GET.”
Reference: https://developer.hashicorp.com/vault/tutorials/db-credentials/database-secrets
D
Explanation:
Comprehensive and Detailed in Depth
The Database secrets engine generates dynamic credentials for database access. The endpoint database/creds/<role> (e.g., read_only_role) provides these credentials via a read operation. Let’s analyze:
Option A: capabilities = ["generate"]
There’s no generate capability in Vault policies. Capabilities are create, read, update, delete, list, etc.
This is invalid. Incorrect.
Option B: capabilities = ["update"]
update (PUT) modifies existing data, not generates credentials. The creds endpoint uses GET.
Incorrect.
Option C: capabilities = ["list"]
list retrieves metadata or paths, not credential data. Incorrect.
Option D: capabilities = ["read"]
Generating dynamic credentials involves a GET request to database/creds/<role>, mapped to the
read capability. This policy allows it. Correct.
Detailed Mechanics:
For a role read_only_role defined with vault write database/roles/read_only_role db_name=my-db creation_statements="CREATE USER…", a user with read on database/creds/read_only_role can run
vault read database/creds/read_only_role to get temporary credentials. Vault’s policy system aligns
HTTP verbs to capabilities: GET = read, PUT = update. This counterintuitive mapping (GET for
creation) is specific to dynamic secrets.
Overall Explanation from Vault Docs:
“Generating database credentials requires read capability on database/creds/<role>… Despite creating credentials, the HTTP request is a GET.”
Reference: https://developer.hashicorp.com/vault/tutorials/db-credentials/database-secrets
Question #7
Select the policies below that permit you to create a new entry of environment=prod at the path /secrets/apps/my_secret (select three).
- A . path "secrets/+/my_secret" { capabilities = ["create"] allowed_parameters = { "*" = [] } }
- B . path "secrets/apps/my_secret" { capabilities = ["update"] }
- C . path "secrets/apps/my_secret" { capabilities = ["create"] allowed_parameters = { "environment" = []}}
- D . path "secrets/apps/*" { capabilities = ["create"] allowed_parameters = { "environment" = ["dev", "test", "qa", "prod"] } }
Correct Answer: A, C, D
A, C, D
Explanation:
Comprehensive and Detailed in Depth
This question requires identifying Vault policies that allow creating a new entry with environment=prod at the specific path /secrets/apps/my_secret. Vault policies define permissions using paths, capabilities, and parameter constraints.
Let’s evaluate each option:
Option A: path "secrets/+/my_secret" { capabilities = ["create"] allowed_parameters = { "*" = [] } } The + wildcard matches any single segment in the path, so this policy applies to /secrets/apps/my_secret. The create capability permits creating new entries at this path. The allowed_parameters = { "*" = [] } means any parameter (including environment) can be set to any value. This satisfies the requirement to create an entry with environment=prod. Thus, this policy is correct.
Option B: path "secrets/apps/my_secret" { capabilities = ["update"] }
This policy targets the exact path /secrets/apps/my_secret but only grants the update capability. According to Vault’s documentation, update allows modifying existing entries, not creating new ones. Since the question specifies creating a new entry, this policy does not meet the requirement and is incorrect.
Option C: path "secrets/apps/my_secret" { capabilities = ["create"] allowed_parameters = { "environment" = [] } }
This policy explicitly matches /secrets/apps/my_secret and grants the create capability, which allows new entries to be written. The allowed_parameters = { "environment" = [] } specifies that the environment parameter can take any value (an empty list means no restriction on values). This permits setting environment=prod, making this policy correct.
Option D: path "secrets/apps/*" { capabilities = ["create"] allowed_parameters = { "environment" = ["dev", "test", "qa", "prod"] } }
The * wildcard matches any path under secrets/apps/, including /secrets/apps/my_secret. The create capability allows new entries, and the allowed_parameters restricts environment to dev, test, qa, or prod. Since prod is an allowed value, this policy permits creating an entry with environment=prod and is correct.
Overall Explanation from Vault Docs:
Vault policies control access via paths and capabilities (create, read, update, delete, list). The create capability is required to write new data. Parameter constraints (allowed_parameters) further restrict what key-value pairs can be written. An empty list ([]) allows any value, while a populated list restricts values to those specified. A deny takes precedence over any allow, but no deny is present here.
Reference: https://developer.hashicorp.com/vault/docs/concepts/policies#parameter-constraints
A, C, D
Explanation:
Comprehensive and Detailed in Depth
This question requires identifying Vault policies that allow creating a new entry with environment=prod at the specific path /secrets/apps/my_secret. Vault policies define permissions using paths, capabilities, and parameter constraints.
Let’s evaluate each option:
Option A: path "secrets/+/my_secret" { capabilities = ["create"] allowed_parameters = { "*" = [] } } The + wildcard matches any single segment in the path, so this policy applies to /secrets/apps/my_secret. The create capability permits creating new entries at this path. The allowed_parameters = { "*" = [] } means any parameter (including environment) can be set to any value. This satisfies the requirement to create an entry with environment=prod. Thus, this policy is correct.
Option B: path "secrets/apps/my_secret" { capabilities = ["update"] }
This policy targets the exact path /secrets/apps/my_secret but only grants the update capability. According to Vault’s documentation, update allows modifying existing entries, not creating new ones. Since the question specifies creating a new entry, this policy does not meet the requirement and is incorrect.
Option C: path "secrets/apps/my_secret" { capabilities = ["create"] allowed_parameters = { "environment" = [] } }
This policy explicitly matches /secrets/apps/my_secret and grants the create capability, which allows new entries to be written. The allowed_parameters = { "environment" = [] } specifies that the environment parameter can take any value (an empty list means no restriction on values). This permits setting environment=prod, making this policy correct.
Option D: path "secrets/apps/*" { capabilities = ["create"] allowed_parameters = { "environment" = ["dev", "test", "qa", "prod"] } }
The * wildcard matches any path under secrets/apps/, including /secrets/apps/my_secret. The create capability allows new entries, and the allowed_parameters restricts environment to dev, test, qa, or prod. Since prod is an allowed value, this policy permits creating an entry with environment=prod and is correct.
Overall Explanation from Vault Docs:
Vault policies control access via paths and capabilities (create, read, update, delete, list). The create capability is required to write new data. Parameter constraints (allowed_parameters) further restrict what key-value pairs can be written. An empty list ([]) allows any value, while a populated list restricts values to those specified. A deny takes precedence over any allow, but no deny is present here.
Reference: https://developer.hashicorp.com/vault/docs/concepts/policies#parameter-constraints
Question #8
Your company’s security policies require that all encryption keys must be rotated at least once per year. After using the Transit secrets engine for a year, the Vault admin issues the proper command to rotate the key named ecommerce that was used to encrypt your data.
What command can be used to easily re-encrypt the original data with the new version of the key?
- A . vault write -f transit/keys/ecommerce/rotate <old data>
- B . vault write -f transit/keys/ecommerce/update <old data>
- C . vault write transit/encrypt/ecommerce v1:v2 <old data>
- D . vault write transit/rewrap/ecommerce ciphertext=<old data>
Correct Answer: D
D
Explanation:
Comprehensive and Detailed in Depth
The Transit secrets engine in Vault manages encryption keys and supports key rotation. After rotating the ecommerce key, existing ciphertext (encrypted with the old key version) must be re-encrypted (rewrapped) with the new key version without exposing plaintext. Let’s evaluate: A: vault write -f transit/keys/ecommerce/rotate <old data>
This command rotates the key, creating a new version, but does not re-encrypt existing data. It’s for key management, not data rewrapping. Incorrect.
B: vault write -f transit/keys/ecommerce/update <old data>
There’s no update endpoint in Transit for re-encrypting data. This is invalid and incorrect.
C: vault write transit/encrypt/ecommerce v1: v2 <old data>
The transit/encrypt endpoint encrypts new plaintext, not existing ciphertext. The v1:v2 syntax is invalid. Incorrect.
D: vault write transit/rewrap/ecommerce ciphertext=<old data>
The transit/rewrap endpoint takes existing ciphertext, decrypts it with the old key version, and re-encrypts it with the latest key version (post-rotation). This is the correct command. For example, if <old data> is vault: v1:cZNHVx+…, the output might be vault:v2:kChHZ9w4…. Overall Explanation from Vault Docs:
“Vault’s Transit secrets engine supports key rotation… The rewrap endpoint allows ciphertext encrypted with an older key version to be re-encrypted with the latest key version without exposing the plaintext.” This operation is secure and efficient, using the keyring internally.
Reference: https://developer.hashicorp.com/vault/tutorials/encryption-as-a-service/eaas-transit-rewrap
D
Explanation:
Comprehensive and Detailed in Depth
The Transit secrets engine in Vault manages encryption keys and supports key rotation. After rotating the ecommerce key, existing ciphertext (encrypted with the old key version) must be re-encrypted (rewrapped) with the new key version without exposing plaintext. Let’s evaluate: A: vault write -f transit/keys/ecommerce/rotate <old data>
This command rotates the key, creating a new version, but does not re-encrypt existing data. It’s for key management, not data rewrapping. Incorrect.
B: vault write -f transit/keys/ecommerce/update <old data>
There’s no update endpoint in Transit for re-encrypting data. This is invalid and incorrect.
C: vault write transit/encrypt/ecommerce v1: v2 <old data>
The transit/encrypt endpoint encrypts new plaintext, not existing ciphertext. The v1:v2 syntax is invalid. Incorrect.
D: vault write transit/rewrap/ecommerce ciphertext=<old data>
The transit/rewrap endpoint takes existing ciphertext, decrypts it with the old key version, and re-encrypts it with the latest key version (post-rotation). This is the correct command. For example, if <old data> is vault: v1:cZNHVx+…, the output might be vault:v2:kChHZ9w4…. Overall Explanation from Vault Docs:
“Vault’s Transit secrets engine supports key rotation… The rewrap endpoint allows ciphertext encrypted with an older key version to be re-encrypted with the latest key version without exposing the plaintext.” This operation is secure and efficient, using the keyring internally.
Reference: https://developer.hashicorp.com/vault/tutorials/encryption-as-a-service/eaas-transit-rewrap
Question #9
Based on the output below, how many policies have been added to Vault?
$ vault policy list
base
default
root
web-app-1
automation-team
- A . 3
- B . 4
- C . 1
- D . 2
Correct Answer: A
A
Explanation:
Comprehensive and Detailed In-Depth
The vault policy list command displays all policies in Vault. The output lists five policies: "base",
"default", "root", "web-app-1", and "automation-team". However, "root" and "default" are built-in
policies:
Built-in Policies:
"root": A superuser policy created by default.
"default": Provides common permissions, also default. "Vault has two default policies, root and
default."
Added Policies:
"base", "web-app-1", "automation-team" are not built-in, meaning they were added. Thus, 3 policies
were added.
Incorrect Options:
B. 4: Overcounts by including one built-in.
C. 1,
D. 2: Undercounts the added policies.
Reference: https://developer.hashicorp.com/vault/docs/concepts/policies#built-in-policies
A
Explanation:
Comprehensive and Detailed In-Depth
The vault policy list command displays all policies in Vault. The output lists five policies: "base",
"default", "root", "web-app-1", and "automation-team". However, "root" and "default" are built-in
policies:
Built-in Policies:
"root": A superuser policy created by default.
"default": Provides common permissions, also default. "Vault has two default policies, root and
default."
Added Policies:
"base", "web-app-1", "automation-team" are not built-in, meaning they were added. Thus, 3 policies
were added.
Incorrect Options:
B. 4: Overcounts by including one built-in.
C. 1,
D. 2: Undercounts the added policies.
Reference: https://developer.hashicorp.com/vault/docs/concepts/policies#built-in-policies
Question #10
Which of these is not a benefit of dynamic secrets?
- A . Supports systems which do not natively provide a method of expiring credentials
- B . Minimizes damage of credentials leaking
- C . Ensures that administrators can see every password used
- D . Replaces cumbersome password rotation tools and practices
Correct Answer: C
C
Explanation:
Dynamic secrets are generated on-demand by Vault and have a limited time-to-live (TTL). They do not ensure that administrators can see every password used, as they are often encrypted and ephemeral. The benefits of dynamic secrets are:
They support systems that do not natively provide a method of expiring credentials, such as databases, cloud providers, SSH, etc. Vault can revoke the credentials when they are no longer needed or when the lease expires.
They minimize the damage of credentials leaking, as they are short-lived and can be easily rotated or revoked. If a credential is compromised, the attacker has a limited window of opportunity to use it before it becomes invalid.
They replace cumbersome password rotation tools and practices, as Vault can handle the generation and revocation of credentials automatically and securely. This reduces the operational overhead and complexity of managing secrets.
Reference: https://developer.hashicorp.com/vault/tutorials/getting-started/getting-started-dynamic-secrets1, https://developer.hashicorp.com/vault/docs/concepts/lease2
C
Explanation:
Dynamic secrets are generated on-demand by Vault and have a limited time-to-live (TTL). They do not ensure that administrators can see every password used, as they are often encrypted and ephemeral. The benefits of dynamic secrets are:
They support systems that do not natively provide a method of expiring credentials, such as databases, cloud providers, SSH, etc. Vault can revoke the credentials when they are no longer needed or when the lease expires.
They minimize the damage of credentials leaking, as they are short-lived and can be easily rotated or revoked. If a credential is compromised, the attacker has a limited window of opportunity to use it before it becomes invalid.
They replace cumbersome password rotation tools and practices, as Vault can handle the generation and revocation of credentials automatically and securely. This reduces the operational overhead and complexity of managing secrets.
Reference: https://developer.hashicorp.com/vault/tutorials/getting-started/getting-started-dynamic-secrets1, https://developer.hashicorp.com/vault/docs/concepts/lease2