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

Question 1

An organization uses the Transit secrets engine to encrypt sensitive files. They want to rotate the encryption key regularly without re-encrypting all existing files. Which feature allows this?

Accepted Answer

Key versioning. The Transit secrets engine in Vault supports key versioning, which allows you to rotate the encryption key by creating a new version while keeping older versions available for decryption of existing ciphertext. This means you can regularly rotate the key without needing to re-encrypt all previously encrypted files, as each ciphertext is tagged with the key version used to encrypt it.

Answer

Key derivation

Answer

Key ttl

Answer

Convergent encryption

Question 2

A Vault administrator configures an AWS secrets engine role with credential_type=iam_user and attaches a policy that allows creating EC2 instances. A developer generates credentials and uses them to launch an EC2 instance. Later the lease expires and Vault revokes the IAM user. What happens to the EC2 instance?

Accepted Answer

The instance continues to run because IAM user revocation does not affect running instances. When Vault revokes an IAM user, it deletes the IAM user credentials, but this does not affect resources already launched by that user. The EC2 instance runs under its own instance profile and is not tied to the IAM user's session after launch. AWS does not retroactively terminate or stop instances based on IAM user revocation; the instance continues to run until explicitly stopped or terminated.

Answer

The instance fails with a permission error

Answer

The instance is immediately terminated

Answer

The instance is stopped after a grace period

Question 3

A Vault operator runs 'vault secrets list' and sees 'cubbyhole/' mounted. What is the purpose of this engine?

Accepted Answer

Store secrets that are isolated per token. The cubbyhole secrets engine creates a private, ephemeral storage space that is scoped to a single Vault token. Secrets written to cubbyhole are only readable by the same token that wrote them and are automatically destroyed when the token expires or is revoked, making it ideal for token-specific secrets like a one-time password or a temporary key.

Answer

Store secrets encrypted by the Transit engine

Answer

Store secrets that are replicated across clusters

Answer

Store secrets with high availability

Question 4

An operator configures a PKI role with allow_any_name=true and max_ttl=72h. A user requests a certificate with common_name='admin.example.com' and ttl=48h. What is the resulting TTL?

Accepted Answer

48h. Option C is correct because the `max_ttl` setting on the PKI role defines the upper bound for certificate validity, but the user-requested TTL (48h) is within that bound (72h). The `allow_any_name=true` parameter permits any common name without restriction, so the certificate is issued with the requested TTL of 48h. The resulting TTL is the lesser of the requested TTL and the role's `max_ttl`, which in this case is 48h.

Answer

24h

Answer

72h

Answer

48h if allowed_domains matches, else error

Question 5

An administrator configures a database secrets engine with a role that uses 'creation_statements' and 'revocation_statements'. However, when a lease expires, the database user is not revoked. What is the most likely cause?

Accepted Answer

The revocation statement is incorrect. The most likely cause is that the revocation statement is incorrect. When a lease expires, Vault executes the SQL statement defined in `revocation_statements` to delete or disable the database user. If this statement has a syntax error, references a non-existent table, or fails to match the user created by `creation_statements`, the revocation will silently fail, leaving the user active in the database.

Answer

The connection string is invalid

Answer

The database user has been manually deleted

Answer

The lease duration is set too high

Question 6

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 7

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

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 9

A company needs to issue short-lived TLS certificates for internal microservices. They want to set up a private CA using Vault. Which steps are required to configure the PKI secrets engine?

Accepted Answer

Enable PKI, generate root CA, create a role, issue certificates. Option D is correct because the correct order to configure the Vault PKI secrets engine is: first enable the PKI secrets engine at a path, then generate a root CA certificate (which creates the CA's key pair and self-signed certificate), then create a role that defines certificate issuance parameters (such as allowed domains and TTL), and finally issue certificates using that role. This sequence ensures the CA exists before roles reference it, and roles exist before certificates are issued.

Answer

Enable PKI, create a role, generate root CA, issue certificates

Answer

Generate root CA, enable PKI, create a role, issue certificates

Answer

Enable PKI, generate intermediate CA, generate root CA, issue certificates

Question 10

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 11

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 AWS secrets engine can dynamically generate IAM users with custom policies attached, allowing fine-grained access control for applications. Option E is correct because the engine can generate STS temporary credentials for cross-account access, enabling secure, time-limited access to AWS resources in different accounts.

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 12

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

Accepted Answer

Enable the database secrets engine. Enabling the database secrets engine is the first required step because Vault secrets engines must be explicitly enabled at a mount path before they can be used. Without enabling the engine, no subsequent configuration (such as configuring connections or roles) is possible. This is done via the `vault secrets enable database` command or the equivalent API call.

Answer

Generate a root certificate for the database

Answer

Tune the mount to set default TTL for all roles

Question 13

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. Setting a low default lease TTL and enforcing maximum TTL per mount helps control secret lifetimes and reduce risk. Disabling using default policy is not a mount tuning best practice, and audit logging is a system-wide setting.

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 14

A team is using Vault's KV v2 secrets engine to store API keys for multiple microservices. They have enabled versioning and need to ensure that when a secret is deleted, it can be recovered within 30 days. Additionally, they want to keep a history of all versions for compliance. The team has noticed that some secrets are being permanently removed immediately instead of moving to a deleted state. Which configuration change should they make to enforce this behavior?

Accepted Answer

Set the 'delete_version_after' parameter to 30 days on the KV v2 mount. Option B is correct because the 'delete_version_after' parameter on a KV v2 secrets engine mount specifies the time window (in seconds or as a duration like '30d') during which a deleted version remains in a soft-deleted state and can be recovered via the 'undelete' endpoint. Setting this to 30 days ensures that when a secret is deleted, it is not permanently removed until after that period, preserving the ability to restore it and maintaining a full version history for compliance.

Answer

Enable 'check-and-set' on the secrets path to prevent unintended overwrites

Answer

Write a custom script that calls the 'undelete' endpoint immediately after deletion

Answer

Set 'max_versions' to 1 to limit the number of retained versions

Question 15

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.