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

Question 1

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?

30 minute time limit — choose an answer to begin.

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 2

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 3

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 4

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 5

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

Accepted Answer

Active Directory. Option A (Active Directory) is correct because Vault ships a built-in Active Directory secrets engine that dynamically generates and rotates AD domain credentials. Option C (SSH) is correct because Vault provides an SSH secrets engine that can act as a certificate authority or generate one-time SSH credentials for hosts. Option B (AWS) is not a secrets engine but rather an auth method (and also a secrets engine for dynamic IAM credentials — however, in this question's intended answer set it is not marked correct). Option D (LDAP) is an auth method, not a secrets engine. Option E (Transit) is a secrets engine for encryption-as-a-service, but it is not marked correct in this question.

Answer

AWS

Answer

LDAP

Answer

Transit

Question 6

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 7

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?

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 8

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 9

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 10

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 11

A DevOps engineer creates the configuration above. After testing, they notice that the generated database credentials are not being revoked after the TTL expires. What is the most likely cause?

Accepted Answer

The database configuration uses a connection_url with template variables but provides static admin credentials, not root rotation. The database secrets engine requires root credential rotation to enable automatic revocation of generated credentials. When the `connection_url` uses template variables like `{{username}}` and `{{password}}` but the admin credentials are static (not rotated via `rotate_root`), Vault cannot track the actual root password. Without root rotation, Vault lacks the ability to execute `REVOKE` commands after TTL expiry because it cannot authenticate to the database with the current root credentials to perform cleanup.

Answer

The creation_statements do not include the REVOKE command

Answer

The role definition has a syntax error in the creation_statements

Answer

The secrets engine is enabled at a path other than 'database/'

Question 12

Match each Vault storage backend to its description.

Accepted Answer

Consul: Stores data in a highly available key-value store, commonly used for Vault's backend.. Vault supports multiple storage backends. Consul and Integrated Raft are both highly available, while File is for single-node setups. Common confusions include mixing Consul's distributed KV nature with file-based storage or incorrectly attributing external dependencies to Raft.

Answer

Consul: Stores data in encrypted files on disk with manual replication.

Answer

Integrated Raft: Stores data in an external key-value store like etcd.

Question 13

A team wants to store static secrets like database passwords and rotate them periodically. Which secrets engine should they enable?

Accepted Answer

KV v2 secrets engine. The KV v2 secrets engine is designed for static secrets like database passwords, offering versioning, configurable deletion, and periodic rotation via lease management or external automation. It stores secrets as key-value pairs with metadata, making it ideal for static credentials that need controlled lifecycle management.

Answer

AWS secrets engine

Answer

PKI secrets engine

Answer

Transit secrets engine

Question 14

A security team wants to ensure that secrets stored in Vault are encrypted in transit and at rest, and that even Vault administrators cannot read the plaintext secret values. Which configuration is required?

Accepted Answer

Enable the Transit secrets engine and encrypt secrets before writing them to KV. The Transit secrets engine allows clients to encrypt data (including secrets) using Vault-managed encryption keys before writing the ciphertext to a storage backend like KV. This ensures that even Vault administrators with access to the raw storage backend cannot read plaintext secret values, as the encryption key is never exposed to them. The Transit engine also supports encryption in transit via TLS and at rest via the encrypted ciphertext stored in the KV engine, meeting the full requirement.

Answer

Set a strong master key for the Vault cluster

Answer

Configure storage backend encryption using a KMS

Answer

Both A and B

Question 15

A team is evaluating which secrets engines to use for different use cases. Which TWO statements about secrets engines are true?

Accepted Answer

The KV v2 secrets engine supports versioning and can store metadata like TTL. Option C is correct because the KV v2 secrets engine is Vault's versioned key-value store: it retains multiple versions of each secret, supports soft delete/undelete and destroy, and stores associated metadata including a configurable max_versions and delete_version_after (TTL) per secret or per mount. Option E is correct because the PKI secrets engine acts as a certificate authority that issues X.509 certificates from configured roles, and Vault can manage the certificate lifecycle by generating certificates with a specified TTL and, via the PKI engine's ACME or cert-auth integration, renewing/reissuing them before expiry. Option A is wrong because the AWS secrets engine primarily generates dynamic, short-lived IAM credentials (access key/secret key pairs) via STS AssumeRole or federation, not only static keys. Option B is wrong because the Database secrets engine does not require a root database user for all configurations; it can use a privileged user with the necessary grants, and some databases support alternative credential-creation paths. Option D is wrong because dynamic database credentials are produced by the Database secrets engine, whereas the Transit secrets engine provides encryption-as-a-service (encrypt/decrypt, sign/verify, HMAC, key rotation) and does not issue database credentials.

Answer

The AWS secrets engine can only generate static access keys

Answer

The Database secrets engine requires a root database user for all configurations

Answer

The Transit secrets engine can generate dynamic database credentials

Question 16

An administrator is configuring the Transit secrets engine for encryption as a service. Which TWO configuration options are valid?

Accepted Answer

Enabling automatic key derivation per context. Option C is correct because the Transit secrets engine supports convergent encryption and key derivation, where a `context` value supplied with encrypt/decrypt requests is used to derive a unique key from the base key, enabling per-context key derivation without storing separate keys. Option D is correct because Transit allows configuring a key's `rotation_period` (e.g., via `vault write -f transit/keys/<name>/rotate` or by setting `rotation_period` on key creation), after which Vault automatically rotates the encryption key on that schedule. Option A is not a Transit feature; one-time passwords are generated by the TOTP secrets engine, not Transit. Option B is invalid because Transit is designed so keys never leave Vault — exportable keys must be explicitly enabled with `exportable=true` and even then export is a controlled operation, not a standard configuration option for encryption as a service. Option E is incorrect because Transit keys do not have a TTL; keys persist until deleted or rotated, and TTLs apply to leases/tokens rather than to Transit encryption keys.

Answer

Using the engine to generate one-time passwords

Answer

Configuring the engine to export the key in plaintext

Answer

Setting a TTL on the key itself

Question 17

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 18

Refer to the exhibit. After executing these commands, what is the expected behavior?

Accepted Answer

The decryption command requires the key version to be specified. In the Vault Transit secrets engine, when a key has multiple versions (e.g., after rotation), the decryption command requires the key version to be specified to ensure the correct key is used. If the version is not specified, Vault defaults to the latest version, which may not match the version used for encryption, leading to decryption failure. Therefore, option C is correct.

Answer

The key is automatically rotated every 30 days

Answer

The ciphertext is base64 encoded, and the plaintext is base64 decoded automatically

Answer

The encryption operation will fail because the key type 'aes256-gcm96' is incorrect

Question 19

A Vault instance was upgraded from version 1.9 to 1.13. After the upgrade, a secrets engine mounted at 'transit/' is unresponsive and returns an error. The engine type is transit. What is the most likely cause?

Accepted Answer

The engine was accidentally disabled during the upgrade. During a Vault upgrade, there is a possibility that the upgrade process inadvertently disables certain secrets engines if there are configuration conflicts or if the engine was enabled using deprecated methods. This is especially likely in major version jumps like from 1.9 to 1.13, where significant changes in the engine management code could lead to such issues. Options B, C, and D are incorrect: namespaces are not altered during upgrades, the transit engine can be mounted at any path, and since transit is built-in, plugin incompatibility does not apply.

Answer

The namespace was changed during the upgrade

Answer

The transit engine can only be mounted at the default path 'transit/'

Answer

The plugin version is incompatible with the new Vault version

Question 20

An administrator wants to view all currently enabled secrets engines and their mount paths. Which command provides this information?

Accepted Answer

vault secrets list. The correct command to list all enabled secrets engines and their mount paths is `vault secrets list` (option B). Option D, `vault read sys/mounts`, is not a valid command in the Vault CLI; the endpoint `sys/mounts` is accessed via `vault secrets list` or by directly reading the path with `vault read sys/mounts` in some contexts, but the CLI command `vault read sys/mounts` does not exist. Options A and C are incorrect: `vault list sys/mounts` is not valid, and `vault secrets show` is not a real command.

Answer

vault list sys/mounts

Answer

vault secrets show

Answer

vault read sys/mounts