VA-003 Compare and configure secrets engines Practice Test 6 — 15 Questions

Question 1

A DevOps team needs to provide temporary database credentials to applications without storing long-lived passwords. Which secrets engine should they use?

Accepted Answer

Database secrets engine. The Database secrets engine is designed to generate dynamic, short-lived database credentials on demand, allowing applications to access databases without storing long-lived passwords. It creates unique credentials for each request and automatically revokes them after a configurable TTL, meeting the requirement for temporary access without persistent secrets.

Answer

KV v2 secrets engine

Answer

PKI secrets engine

Answer

Transit secrets engine

Question 2

An organization wants to use Vault to generate AWS IAM users with specific managed policies attached. They have configured the AWS secrets engine with the appropriate IAM credentials. What step is required to ensure each generated user gets the correct policies?

Accepted Answer

Configure a role in the AWS secrets engine that specifies the managed policies. The AWS secrets engine in Vault uses roles to define the exact permissions and policies for generated IAM users. By configuring a role that specifies the managed policies, Vault ensures that each dynamically generated IAM user is created with those policies attached, meeting the organization's requirement.

Answer

Enable the AWS secrets engine at a custom path

Answer

Set a high TTL on the AWS secrets engine mount

Answer

Use the transit secrets engine to encrypt the AWS credentials

Question 3

An application is failing to decrypt data using the transit secrets engine. The ciphertext was generated with key 'my-key' version 3, but the engine currently shows key version 5. What is the most likely cause of the failure?

Accepted Answer

The min_decryption_version is set to 4, preventing decryption with version 3. The transit secrets engine allows configuring a minimum decryption version (`min_decryption_version`) for each key. If this value is set to 4, the engine will refuse to decrypt any ciphertext generated with key version 3, even if version 3 still exists in the key ring. This is the most direct and likely cause of the failure, as the ciphertext was created with version 3 but the engine now enforces a higher minimum version.

Answer

The ciphertext was generated by a different transit key

Answer

The key was rotated, and automatic data re-encryption is required

Answer

The application is using the wrong encryption algorithm

Question 4

After migrating from an older version of Vault, the operator wants to replace the deprecated 'generic' secrets engine with a modern alternative. Which secrets engine should be used to store static key-value pairs?

Accepted Answer

KV v2 secrets engine. The KV v2 secrets engine is the modern replacement for the deprecated 'generic' secrets engine in Vault. It stores static key-value pairs with added features such as versioning, configurable delete and destroy behaviors, and check-and-set operations, making it the correct choice for this use case.

Answer

AWS secrets engine

Answer

Database secrets engine

Answer

Transit secrets engine

Question 5

Which TWO of the following are features of the AWS secrets engine compared to the Azure secrets engine?

Accepted Answer

Can generate IAM users with custom policies. Option D is correct because the Vault AWS secrets engine can dynamically create IAM users and attach custom IAM policies to them, giving fine-grained, per-credential permissions that the Azure secrets engine (which issues service principals/roles) does not provide in the same IAM-user form. Option E is correct because the AWS secrets engine can issue STS temporary credentials via AssumeRole, including cross-account access through role ARNs, a capability specific to AWS's STS model and not offered by the Azure secrets engine. Option A is incorrect because SAML federation with Microsoft Entra ID is an Azure/identity-provider feature, not a capability of the AWS secrets engine. Option B is incorrect because native Azure Key Vault integration belongs to the Azure secrets engine, not the AWS one. Option C is incorrect because IAM instance profiles are used by EC2 instances to obtain credentials from the instance metadata service, not a connection method exposed as a feature of the Vault AWS secrets engine.

Answer

Supports federation via SAML with Azure AD

Answer

Provides native integration with Azure Key Vault for key management

Answer

Allows connection to AWS via IAM instance profiles

Question 6

Which THREE steps are required to configure the database secrets engine for a MySQL database?

Accepted Answer

Enable the database secrets engine. Option A is correct because the database secrets engine must first be enabled at a mount path (e.g., `vault secrets enable database`) before any database configuration can occur. Option B is correct because a role defines the SQL statements Vault uses to create and revoke credentials, along with the associated connection and credential type, and is required for Vault to dynamically generate database credentials. Option E is correct because Vault needs a configured database connection specifying the MySQL plugin (e.g., `mysql-database-plugin`), connection URL, and credentials so it can communicate with the MySQL instance. Option C is not required because Vault's database secrets engine does not need a root certificate generated for the database; it authenticates using configured credentials. Option D is not required because TTLs can be set on the role itself, and tuning the mount's default TTL is optional rather than a mandatory configuration step.

Answer

Generate a root certificate for the database

Answer

Tune the mount to set default TTL for all roles

Question 7

Which TWO best practices should be followed when tuning secrets engine mounts?

Accepted Answer

Configure 'max_lease_ttl' to limit the maximum duration secrets can be valid. Option B is correct because configuring 'max_lease_ttl' on a secrets engine mount caps the absolute lifetime of any secret issued by that mount, preventing clients from renewing or holding credentials indefinitely and thereby limiting exposure if a secret leaks. Option C is correct because setting 'default_lease_ttl' to a low value appropriate for the engine ensures that, absent an explicit request, issued secrets expire quickly, which is a core Vault best practice for reducing the blast radius of compromised credentials. Option A is not a mount-tuning best practice in this context; audit logging is enabled at the audit device level and records requests globally rather than being a per-mount tuning parameter. Option D is incorrect because a high default lease TTL increases the window in which a leaked secret remains valid, contradicting the goal of tight lease lifetimes. Option E is incorrect because the 'default' policy is a global Vault policy attached to tokens, not something that is disabled per secrets engine mount.

Answer

Enable audit logging on the mount to track secret access

Answer

Set a high default lease TTL to reduce renewals

Answer

Disable the 'default' policy for the mount to restrict access

Question 8

An e-commerce application integrates with Vault's transit secrets engine to encrypt sensitive customer data before storing it in a database. The operations team regularly rotates the encryption key (my-key) for compliance. Recently, after a rotation, some old ciphertexts could not be decrypted, causing data retrieval failures. The team checked the key configuration and found that the key version used for encryption (version 2) is still present, but decryption fails with an error: 'decryption key version is not available for decryption'. They verified that the ciphertext includes the key version. What is the most likely cause and resolution?

Accepted Answer

The 'min_decryption_version' is set to 3, preventing decryption with version 2. Set it to 2 to allow decryption.. The error 'decryption key version is not available for decryption' indicates that the key version used to encrypt the data (version 2) is present but not allowed for decryption. In Vault's transit secrets engine, the `min_decryption_version` parameter controls the lowest key version that can decrypt data. If it is set to 3, version 2 ciphertexts cannot be decrypted. Setting `min_decryption_version` to 2 resolves the issue by permitting decryption with version 2.

Answer

The 'suppress_decryption' parameter was enabled on the transit mount, blocking decryption. Disable it.

Answer

The key was exported and reimported, losing the version history. Re-create the key from scratch.

Answer

The ciphertext was corrupted during storage. The only solution is to re-encrypt all data with the current key version.

Question 9

A startup wants to use Vault to manage MySQL database credentials for their development environment. They have a single MySQL database and require that each application gets unique, short-lived credentials that are automatically rotated. The operations team enabled the database secrets engine, configured the MySQL connection, and created a role with a TTL of 1 hour. However, when an application requests credentials using the role, Vault returns an error: 'No more available leases on this role'. The team checks the role's configuration and sees that the 'max_ttl' is set to 1 hour and 'default_ttl' is also 1 hour. What is the most likely cause of this error?

Accepted Answer

The role has a 'max_leases' parameter set to a low value (e.g., 5) that has been exceeded. Increase the 'max_leases' on the role.. The error 'No more available leases on this role' indicates that the role has a finite number of leases it can issue, controlled by the 'max_leases' parameter. When this limit is reached, Vault refuses to issue new credentials until existing leases expire or are revoked. The role's TTL and max_ttl being both 1 hour does not cause this error; rather, the exhaustion of the lease count does.

Answer

The database secrets engine is not enabled at the expected path; the role is pointing to a different engine.

Answer

The application is not using a valid token to authenticate to Vault, so the request is rejected.

Answer

The TTL values are too short; applications are requesting new credentials too frequently and exhausting a hidden limit. Increase the TTL.

Question 10

Refer to the exhibit. A user has a token with a policy that grants 'read' on 'secret/*'. The user attempts to read the secret at 'secret/data/app' using `vault kv get secret/data/app` but receives a '404 Not Found' error. The user can successfully list the engine at 'secret/' with `vault secrets list`. What is the most likely cause of the 404 error?

Accepted Answer

The secrets engine is KV v1, but the user is using the KV v2 path format with '/data/'.. The KV v2 secrets engine requires the path format `secret/data/` for reading secret data, while KV v1 uses `secret/` directly. The user is using `vault kv get secret/data/app`, which is the correct command for KV v2, but the error indicates the engine is actually KV v1. Since KV v1 does not have a `/data/` prefix, the path `secret/data/app` does not exist, resulting in a 404 Not Found error. The successful `vault secrets list` confirms the engine is enabled at `secret/`, ruling out option D.

Answer

The user's policy does not cover the sub-path 'secret/data/app'.

Answer

The secret path is mistyped; it should be 'secret/application'.

Answer

The secret engine at 'secret/' is not enabled.

Question 11

A company uses Vault to store application configuration secrets for multiple teams. The Vault cluster is running in production and has the KV secrets engine enabled at the path 'secret/' using version 2. A DevOps engineer, using a Vault token with full admin access, creates a new secret at 'secret/data/team-a/app-config' using the CLI command 'vault kv put secret/team-a/app-config key=value'. The secret is intended for the CI/CD pipeline, which uses a token with a policy that grants 'read' capability on 'secret/data/*'. The pipeline is configured to read the secret by calling the Vault API at the path 'v1/secret/team-a/app-config'. The pipeline reports a 404 Not Found error. The pipeline engineer verifies that the token is valid and has the correct policy attached. All other secrets in the same path can be read successfully by the pipeline. What is the most likely cause of the 404 error?

Accepted Answer

The pipeline is using the wrong API path: for KV v2, the path must include '/data/' before the secret path.. The KV secrets engine version 2 (v2) requires the '/data/' segment in the API path for reading secret data. The pipeline is calling 'v1/secret/team-a/app-config', which omits the mandatory '/data/' prefix, causing a 404 Not Found error. The CLI command 'vault kv put' automatically handles this path translation, but the direct API call does not.

Answer

The secret engine at 'secret/' is not enabled.

Answer

The secret was written to a different path than expected.

Answer

The token's policy does not cover the path 'secret/team-a/app-config'.

Question 12

A platform team runs Vault 1.15 with an integrated storage backend. They have enabled the KV v2 secrets engine at the path 'apps/'. A developer deletes the secret at 'apps/data/webapp/db-creds' using `vault kv delete apps/webapp/db-creds`, then immediately reads it back with `vault kv get apps/webapp/db-creds`. What does the developer observe?

Accepted Answer

The read returns a 404 with 'no value found' because the latest version is soft-deleted and no data is returned by default.. KV v2 separates delete from destroy. The `vault kv delete` command performs a soft delete on the latest version, so a normal read returns 404 and no data. The data is still present in storage and can be recovered with `vault kv undelete` or by reading a specific version that was not deleted. Understanding this distinction is essential for safe secret lifecycle management.

Answer

The read returns the previous version of the secret because soft-delete only marks the latest version as deleted.

Answer

The read returns a permission denied error because the developer lacks the 'undelete' capability on the path.

Answer

The read returns the data normally because soft delete only takes effect after a subsequent write operation.

Question 13

A security engineer enables the Transit secrets engine at 'transit/' and creates an encryption key named 'payments' with `vault write -f transit/keys/payments`. The engineer then wants to rotate the key so that new data is encrypted with a new key version while existing ciphertext can still be decrypted. Which command accomplishes this without invalidating existing ciphertext?

Accepted Answer

vault write -f transit/keys/payments/rotate. Transit key rotation creates a new key version and designates it for future encryption, while retaining prior versions so existing ciphertext can still be decrypted. The rotate endpoint performs this immediately. Automatic rotation via a rotation period is a separate configuration and does not trigger an instant new version. Rewrap and trim serve different purposes and do not create a new key version.

Answer

vault write -f transit/keys/payments/trim min_available_version=2

Answer

vault write transit/keys/payments/config rotation_period=24h

Answer

vault write transit/keys/payments/rewrap ciphertext=<ciphertext>

Question 14

A cloud operations team needs Vault to issue short-lived credentials for an external MySQL database. They want Vault to create and revoke users dynamically based on a role. Which secrets engine should they enable and configure?

Accepted Answer

The database secrets engine. Dynamic database credentials are the core use case of the database secrets engine. It connects to the database with configured credentials, creates users per role using creation statements, and revokes them when the lease expires. KV v2 stores static secrets, Transit performs cryptographic operations, and PKI issues certificates, so none of those provide dynamic database users.

Answer

The PKI secrets engine

Answer

The Transit secrets engine

Answer

The KV v2 secrets engine

Question 15

An administrator is configuring a new PKI secrets engine at pki/ to issue TLS certificates for internal services. The security team requires that the intermediate CA certificate and its private key are generated inside Vault, and that the root CA remains offline. Which command should the administrator run to create the intermediate CA and generate a CSR for signing by the offline root?

Accepted Answer

vault write pki/intermediate/generate/internal common_name="Internal Intermediate CA". Generating the intermediate inside Vault with the internal variant keeps the private key within Vault's storage barrier while returning only a CSR, which the offline root can sign. Importing the signed certificate afterward completes the chain. This workflow satisfies both the key-containment policy and the offline-root requirement without ever exposing the intermediate private key.

Answer

vault write pki/root/generate/internal common_name="Internal Intermediate CA"

Answer

vault write pki/intermediate/set-signed certificate=@intermediate.crt

Answer

vault write pki/intermediate/generate/exported common_name="Internal Intermediate CA"