VA-003 Compare and configure secrets engines — Timed 30 Questions

Question 1

A SaaS startup uses Vault to manage secrets for their microservices architecture. They have enabled the KV v2 secrets engine at 'secret/' and the database secrets engine at 'database/'. Developers often need to read application configuration from 'secret/app/config' and database credentials from 'database/creds/app-role'. Recently, the security team mandated that all secrets must be encrypted at rest using Vault's seal mechanism. They configured Vault to use AWS KMS as the seal. After enabling the seal, they noticed that reading from 'secret/app/config' still works, but reading from 'database/creds/app-role' returns an error: 'Error making API request: Code: 500. Errors: * 1 error occurred: * failed to decrypt data'. What is the most likely cause?

30 minute time limit — choose an answer to begin.

Accepted Answer

The AWS KMS key has been rotated and Vault cannot access the old key.. If the AWS KMS key used for the seal has been rotated, Vault may still be able to decrypt the master key (using the old key) and thus read static secrets like those in KV v2. However, the database secrets engine requires decrypting its stored configuration (e.g., database password) each time a new credential is generated. If that configuration was encrypted before the key rotation and the old key is no longer available (e.g., disabled or deleted), Vault will fail to decrypt it, resulting in the observed error. The KV v2 engine may succeed because its data was read after the rotation or was cached, or the key rotation did not affect the specific ciphertext.

Answer

The database engine requires a separate seal configuration.

Answer

The database engine configuration is stored in a different location that is not sealed.

Answer

The database engine uses a separate encryption key that was not re-wrapped after changing the seal configuration.

Question 2

A DevOps team is configuring the AWS secrets engine to generate IAM users with dynamic credentials. They want to ensure that each Vault-generated IAM user is automatically deleted when its lease expires. Which TWO configuration steps are required to achieve this? (Choose two.)

Accepted Answer

Set the role's 'ttl' parameter to a finite duration.. Setting the role's 'ttl' parameter to a finite duration ensures that the Vault-generated IAM user credentials expire after that time, triggering the lease expiration and automatic deletion. Option E is incorrect because including the 'delete' operation in 'policy_arns' or a custom inline policy grants permissions to the IAM user itself, not to Vault. Vault uses its own AWS credentials to perform the deletion, which must be configured separately in the AWS secrets engine's configuration.

Answer

Set the role's 'initial_lease_status' to 'expired' to trigger immediate deletion.

Answer

Set the role's 'rotate' parameter to 'true' to rotate credentials on lease renewal.

Answer

Set the mount's 'default_lease_ttl' to a finite duration.

Answer

Set the role's 'credential_type' to 'iam_user' and include the 'delete' operation in 'policy_arns' or use a custom inline policy allowing deletion.

Question 3

Refer to the exhibit. A Vault administrator ran the commands shown. What is the result?

Accepted Answer

The AWS secrets engine is enabled at path internal/aws and will generate IAM users with admin access. The command `vault secrets enable -path=internal/aws aws` enables the AWS secrets engine at the custom path `internal/aws`. The subsequent configuration sets up a role with `credential_type=iam_user` and `policy_arn=arn:aws:iam::aws:policy/AdministratorAccess`, which means the engine will generate IAM users with full admin access. The path is custom, and the engine is enabled successfully.

Answer

The AWS secrets engine is enabled at path aws/ and will generate IAM users with full admin access

Answer

The commands will fail because the AWS secrets engine cannot be enabled at a custom path

Answer

The AWS secrets engine is enabled at path internal/aws and will generate STS credentials

Question 4

A DevOps team uses Vault to store database credentials via the database secrets engine. They notice that after the default lease duration, applications receive errors when trying to connect. The team wants to ensure that applications automatically renew leases before expiration. What should they do?

Accepted Answer

Use Vault Agent to renew the secret.. Vault Agent is designed to automatically handle secret renewal and lifecycle management. It runs as a sidecar or daemon that periodically checks the lease duration and renews it before expiration, ensuring applications always have valid credentials without manual intervention or custom scripting.

Answer

Schedule a cron job to periodically read new credentials.

Answer

Set a longer default TTL on the role.

Answer

Set a longer max TTL on the mount.

Question 5

A security team wants to store static secrets like API keys in Vault. They need the secrets to be versioned and support rollback. Which secrets engine should they use?

Accepted Answer

KV v2. KV v2 is the correct choice because it is designed specifically for storing static secrets with built-in versioning and rollback capabilities. Unlike KV v1, which overwrites data without preserving history, KV v2 retains a configurable number of secret versions, allowing administrators to undelete or roll back to a previous version using the `vault kv rollback` command or API calls.

Answer

Cubbyhole

Answer

KV v1

Answer

Transit

Question 6

An organization uses the AWS secrets engine to generate IAM users dynamically. They notice that the generated IAM user is not immediately available for use in AWS. What is the most likely reason?

Accepted Answer

AWS IAM is eventually consistent and the user may take a few seconds to propagate.. AWS IAM is an eventually consistent system. When Vault uses the AWS secrets engine to create an IAM user via the CreateUser API call, the user is not immediately available across all AWS services due to propagation delays. This eventual consistency means the generated IAM user may take a few seconds to be fully usable, which is a known behavior of AWS IAM.

Answer

The Vault write operation failed due to network latency.

Answer

The TTL on the role is too short.

Answer

Vault must wait for the AWS secret key to be rotated before returning the user.

Question 7

A company is using the PKI secrets engine to issue certificates for internal services. They want to ensure that certificates are automatically revoked if a service is decommissioned. What should they implement?

Accepted Answer

Use Vault's built-in lifecycle management and revocation capabilities.. Vault's PKI secrets engine includes built-in lifecycle management that can automatically revoke certificates when a lease expires or when a secret is deleted via the API. This allows you to tie certificate validity to the service's lifecycle in Vault, ensuring decommissioned services have their certificates revoked without manual intervention.

Answer

Implement certificate pinning in all services.

Answer

Set a very short TTL on certificates so they expire quickly.

Answer

Configure a Certificate Revocation List (CRL) that clients check.

Question 8

A developer wants to use Vault to encrypt sensitive data before storing it in a database. They need to perform encryption and decryption operations without ever exposing the encryption key. Which secrets engine should they use?

Accepted Answer

Transit. The Transit secrets engine is designed specifically for encryption-as-a-service workflows, allowing applications to encrypt and decrypt data using keys managed entirely within Vault. The encryption key never leaves Vault, satisfying the requirement to avoid exposing the key. In contrast, other engines like KV v2 store raw secrets but do not perform cryptographic operations without exposing the key material.

Answer

PKI

Answer

KV v2

Answer

Database

Question 9

A company has multiple Vault clusters in different regions. They want to use the replication feature to synchronise secrets across clusters. However, they want to exclude a specific secrets engine from replication for compliance reasons. What should they do?

Accepted Answer

Use performance replication and configure a mount filter.. Performance replication in Vault allows you to replicate secret data across clusters while using mount filters to include or exclude specific secrets engines. This is the correct approach because mount filters are designed precisely for this use case, enabling selective replication to meet compliance requirements without creating separate infrastructure.

Answer

Create a separate Vault cluster for that secrets engine.

Answer

Disable replication on that specific mount.

Answer

Use disaster recovery (DR) replication and exclude the mount.

Question 10

An administrator configured the database secrets engine with PostgreSQL. When an application requests credentials, Vault returns a username and password. However, the application reports that the credentials are not working. What is the most likely cause?

Accepted Answer

The database user used by Vault does not have sufficient privileges to create users.. The most likely cause is that the database user configured in Vault lacks the necessary privileges to create new database users. When Vault generates dynamic credentials, it uses its own database connection (the root or management user) to execute `CREATE USER` and `GRANT` statements. If that user does not have the `CREATEROLE` or `SUPERUSER` attribute (or equivalent `CREATE USER` privilege in PostgreSQL), the credential creation fails silently or produces unusable credentials, even though Vault returns a username and password.

Answer

The TTL on the role is set too low.

Answer

The connection string provided to Vault is incorrect.

Answer

The generated credentials were revoked by Vault before the application used them.

Question 11

A team wants to store configuration data such as feature flags in Vault. They need to be able to list all keys under a path. Which secrets engine supports listing?

Accepted Answer

KV v1. The KV v1 secrets engine stores key-value pairs and supports listing all keys under a path via the LIST operation (e.g., `vault list secret/`). This is because KV v1 maintains a flat, non-versioned directory structure that allows enumeration of keys. The team's requirement to list all keys under a path is directly satisfied by KV v1's inherent listing capability.

Answer

Transit

Answer

Cubbyhole

Answer

PKI

Question 12

Which TWO of the following are valid use cases for the Transit secrets engine? (Select exactly 2.)

Accepted Answer

Signing and verifying data. The Transit secrets engine is designed to perform cryptographic operations on data without exposing the encryption keys to the client. Option A is correct because the engine supports signing and verifying data using HMAC or asymmetric keys, allowing clients to verify integrity and authenticity without handling the private key. Option B is correct because the engine can encrypt data in transit (e.g., via API calls) while the encryption key remains securely stored within Vault, never leaving the server.

Answer

Storing encryption keys

Answer

Storing encrypted data at rest

Answer

Managing X.509 certificates

Question 13

Which THREE of the following are true about the KV v2 secrets engine? (Select exactly 3.)

Accepted Answer

It supports check-and-set operations for concurrent updates.. KV v2 supports check-and-set (CAS) operations via the `cas` parameter in the write path. CAS ensures that a write only succeeds if the current version matches the expected value, preventing concurrent overwrites and providing optimistic locking for secret updates.

Answer

It does not support deletion of secrets.

Answer

It does not support undoing changes.

Question 14

Which TWO of the following are valid secrets engines in Vault? (Select exactly 2.)

Accepted Answer

Active Directory. Options A (Active Directory) and C (SSH) are both valid secrets engines in Vault. Option B (AWS) is also a secrets engine but not one of the two required answers. Option D (LDAP) is an auth method, not a secrets engine. Option E (Transit) is also a valid secrets engine, but the question expects the two that are most directly related to credential management, hence A and C are correct.

Answer

AWS

Answer

LDAP

Answer

Transit

Question 15

A financial services company runs a mixed environment of on-premises and cloud workloads. They use Vault Enterprise with performance replication across two data centers: primary in us-east and secondary in eu-west. The secrets engine configuration includes KV v2 for static secrets, database engine for PostgreSQL credentials, and transit for encryption. Recently, the operations team noticed that after a network partition between the data centers, the secondary cluster stopped serving read requests for database credentials, although other secrets like KV v2 were still accessible. The team confirmed that the replication status shows 'secondary' and the cluster is healthy. The Vault configuration uses a single replication path filter that includes all mounts. What is the most likely reason for the database credentials not being available on the secondary?

Accepted Answer

Dynamic secrets are not replicated; the secondary cannot generate credentials if the primary is unreachable.. In Vault Enterprise, performance replication replicates static data (like KV v2 secrets) but does not replicate dynamic secrets such as database credentials. Dynamic secrets are generated on-demand by the primary cluster; the secondary cluster cannot generate them if the primary is unreachable because it lacks the ability to create new leases or credentials. This is why database credentials were unavailable on the secondary after the network partition, while static KV v2 secrets remained accessible.

Answer

The replication path filter excludes the database engine mount.

Answer

The secondary cluster has a network issue preventing it from connecting to the database.

Answer

The secondary cluster is configured to only serve static secrets.

Question 16

A company uses Vault to manage database credentials for a production PostgreSQL cluster. The application team reports that dynamic credentials generated from the database secrets engine are being revoked before the application has finished using them. The Vault lease TTL is set to 1 hour, but the application workload sometimes runs for up to 2 hours. What is the MOST efficient way to ensure credentials remain valid for the full workload duration?

Accepted Answer

Increase the default_lease_ttl on the database secrets engine mount to 2 hours.. Increasing the default_lease_ttl on the database secrets engine mount ensures that all credentials generated by that engine have a TTL of 2 hours, matching the maximum workload duration without requiring application changes. Option A is wrong because setting max_ttl on the role alone does not change the default TTL; the application would still need to request a longer TTL when generating credentials. Option B is wrong because changing the server's default_lease_ttl affects all secrets in Vault, not just database credentials, which could reduce security unnecessarily. Option D is wrong because manually renewing leases adds complexity and overhead; it's more efficient to adjust the lease TTL at the engine level.

Answer

Set max_ttl to 2 hours on the database role.

Answer

Set the Vault server's default_lease_ttl to 2 hours in the server configuration.

Answer

Have the application manually renew the lease every 30 minutes.

Question 17

An administrator runs the commands shown in the exhibit. Later, they run 'vault kv delete kv-v2/secret' and then 'vault kv undelete -versions=1 kv-v2/secret' to recover the secret. Which command must the administrator run to verify that the secret is now readable?

Accepted Answer

vault kv get kv-v2/secret. 'vault kv get' is the standard command to read and display the latest version of a secret from a KV v2 secrets engine. After running 'vault kv undelete -versions=1', version 1 is restored from a deleted state, and 'vault kv get kv-v2/secret' will retrieve and show that version's data, confirming it is readable.

Answer

vault kv list kv-v2/secret

Answer

vault read kv-v2/data/secret

Answer

vault kv metadata get kv-v2/secret

Question 18

A financial services company runs a microservices application on Kubernetes. Each service needs to authenticate to Vault using Kubernetes auth and then read secrets from a shared KV v2 engine mounted at 'shared-kv'. The security team requires that Service-A can only read secrets under 'shared-kv/team-alpha/*' and Service-B can only read secrets under 'shared-kv/team-beta/*'. The Vault administrator has already configured the Kubernetes auth method and created roles for each service with bound service account names. However, both services are currently able to read all paths under 'shared-kv/'. The administrator wants to enforce the least privilege access. Which course of action should the administrator take?

Accepted Answer

Review and update the policy attached to the Kubernetes auth roles to restrict capabilities to the specific paths, e.g., 'path "shared-kv/data/team-alpha/*" { capabilities = ["read"] }'.. The issue is that the policy attached to the Kubernetes auth roles grants read access to the entire 'shared-kv/*' path. By updating the policy to restrict capabilities to specific paths like 'shared-kv/data/team-alpha/*' and 'shared-kv/data/team-beta/*', the administrator enforces least privilege. The 'data' prefix is required for KV v2 engines to access secret data, and the wildcard ensures only the respective team's secrets are readable.

Answer

Configure the Kubernetes auth role to use 'token_policies' with a restrictive policy and ensure the bound service account names are correct.

Answer

Create a new secrets engine for each team and mount them at 'team-alpha' and 'team-beta', then assign each service to its respective engine.

Answer

Add a 'path_deny' capability in the policy for the disallowed paths.

Question 19

A company wants to securely store database credentials for a dynamic application that spins up new instances frequently. They need to ensure each instance gets a unique, time-limited username/password pair with minimal operational overhead. Which approach should they use?

Accepted Answer

Enable the database secrets engine and configure role-based dynamic credential generation. The database secrets engine in HashiCorp Vault is designed specifically for dynamic credential generation, creating unique, time-limited username/password pairs on-demand for each instance. This approach minimizes operational overhead by automating credential lifecycle management, including automatic revocation after the TTL expires, which aligns perfectly with the requirement for frequently spinning up instances.

Answer

Use the transit secrets engine to encrypt the static credentials and distribute them

Answer

Use the PKI secrets engine to issue certificates for database authentication

Answer

Store the credentials in KV v2 and have each instance read them

Question 20

Which TWO of the following are valid methods to enable a secrets engine at a non-default path in Vault?

Accepted Answer

vault write sys/mounts/my-aws type=aws. Options B and C are both valid methods to enable a secrets engine at a non-default path in Vault. Option B uses the raw API endpoint via 'vault write sys/mounts/my-aws type=aws', which is a valid low-level approach. Option C uses the higher-level 'vault secrets enable -path=my-aws aws' command, which is the standard CLI method. Option E ('vault secrets enable my-aws aws') is invalid because it incorrectly places the path before the engine type; the correct syntax for a default path is 'vault secrets enable aws', but for a non-default path the '-path' flag is required.

Answer

vault secrets enable -custom-path=my-aws aws

Answer

vault secrets enable -mount-path=my-aws aws

Answer

vault secrets enable my-aws aws