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

Question 1

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.. Option C is correct because 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 2

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 3

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.. Option D is correct because 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 4

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.. Option B is correct because 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 5

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 6

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 7

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 8

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 9

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 10

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.. Option B is correct because 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 11

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

Accepted Answer

Active Directory. Option A (Active Directory) is a valid secrets engine in Vault that allows Vault to rotate and manage AD service account passwords, leveraging LDAP internally but with AD-specific features like password rotation and management of the built-in AD credential store. Option E (Transit) is a valid secrets engine that provides encryption-as-a-service, allowing data to be encrypted/decrypted without leaving the client's environment, using Vault's cryptographic functions without storing the data.

Answer

AWS

Answer

SSH

Answer

LDAP

Question 12

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 13

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 database engine uses a separate encryption key that was not re-wrapped after changing the seal configuration.. Option D is correct because when the seal configuration is changed (e.g., from the default Shamir seal to AWS KMS), the database secrets engine's encrypted storage (which includes its own encryption key used to protect dynamic credentials) must be re-wrapped with the new seal. Vault's KV v2 engine stores data encrypted with the same seal, but reading existing static secrets works because they are decrypted on-the-fly using the new seal. However, the database engine's internal key material was encrypted under the old seal and was not re-wrapped, causing decryption failures when Vault attempts to use it to generate credentials.

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 AWS KMS key has been rotated and Vault cannot access the old key.

Question 14

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.. Option B is correct because increasing the default lease TTL to 2 hours ensures all credentials generated by this engine are valid for the maximum required duration, without requiring code changes. Option A is wrong because setting max_ttl alone does not extend the default TTL; the application must still request a longer TTL. Option C is wrong because the lease duration is determined at creation time; manually renewing each lease is inefficient and error-prone. Option D is wrong because changing the system TTL affects all secrets in Vault, not just database credentials, and may reduce security.

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 15

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.. Option D is correct because 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 process. Option E is correct because setting 'credential_type' to 'iam_user' tells Vault to create an IAM user, and including the 'delete' operation in 'policy_arns' (or using a custom inline policy) grants Vault the permission to delete that IAM user when the lease expires, enabling automatic cleanup.

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.

Question 16

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. Option C is correct because '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 17

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"] }'.. Option D is correct because 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 18

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 19

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

Accepted Answer

vault secrets enable -path=my-aws aws. Option C is correct because the `vault secrets enable` command uses the `-path` flag to specify a custom mount path for a secrets engine, overriding the default path that matches the engine type. This is the standard CLI syntax for enabling a secrets engine at a non-default location, as documented by HashiCorp.

Answer

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

Answer

vault write sys/mounts/my-aws type=aws

Answer

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

Question 20

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. Option C is correct because 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/'