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

Question 1

An organization needs to store secrets with versioning support, allowing rollback to previous secret values. Which KV secrets engine version should be enabled?

Accepted Answer

KV v2. KV v2 is the correct choice because it provides versioning support for secrets, allowing users to retrieve and rollback to previous secret values. KV v1 stores secrets without versioning, and the Transit secrets engine is designed for encryption/decryption operations, not secret storage with versioning.

Answer

KV v3

Answer

KV v1

Answer

Transit secrets engine

Question 2

Which TWO of the following are benefits of using dynamic secrets engines (e.g., database, AWS) over static secrets?

Accepted Answer

Provides automatic rotation of credentials upon lease expiry. Dynamic secrets engines generate credentials on-demand with a predefined Time-To-Live (TTL). When the lease expires, Vault automatically revokes the credentials, forcing the client to request new ones. This automatic rotation eliminates the need for manual credential rotation and reduces the window of exposure if a credential is compromised.

Answer

Simplifies the management of service accounts because credentials never change

Answer

Secrets are persistent and do not expire

Answer

Secrets are stored in plaintext in the Vault data store

Question 3

Which THREE steps are required to configure the database secrets engine for generating dynamic credentials?

Accepted Answer

Create a role that maps to the database user and permissions. Creating a role is the step that maps a named role in Vault to a database user template and its associated permissions (e.g., SQL statements for creation and revocation). This role definition is what Vault uses to dynamically generate a unique username and password when credentials are requested, ensuring each lease gets a dedicated database account with the specified privileges.

Answer

Configure a policy to allow users to read credentials from the role

Answer

Tune the engine's default TTL

Question 4

Which THREE operations does the transit secrets engine support?

Accepted Answer

Encrypt data using a named key. The transit secrets engine in Vault is designed to perform cryptographic operations on data in transit, and encrypting data using a named key is one of its primary supported operations. The engine allows you to encrypt plaintext with a specified key, returning ciphertext that can later be decrypted using the same key.

Answer

Generate a new key in an external KMS

Answer

Generate a hash using SHA256

Question 5

An operator needs to enable the KV v2 secrets engine at the path 'team-alpha'. Which command should they run?

Accepted Answer

vault secrets enable -path=team-alpha kv-v2. The `vault secrets enable` command with the `-path` flag specifies the mount path as 'team-alpha', and `kv-v2` is the correct engine type for the KV v2 secrets engine. This command mounts the KV v2 engine at the desired path, enabling versioned key-value storage.

Answer

vault secrets enable kv-v2 team-alpha

Answer

vault secrets enable -path=team-alpha kv

Answer

vault secrets mount -path=team-alpha kv

Question 6

A development team wants to encrypt sensitive data before storing it in a database. They don't want to manage encryption keys themselves. Which secrets engine should they use?

Accepted Answer

Transit. The Transit secrets engine is designed to encrypt data in transit or at rest without exposing the encryption keys to the client. It performs cryptographic operations (encrypt/decrypt) on data sent to Vault, so the development team never manages or stores the keys themselves. This matches the requirement to avoid key management while encrypting sensitive data before database storage.

Answer

PKI

Answer

AWS

Answer

KV v2

Question 7

An organization uses a PostgreSQL database. They configure a database secrets engine with a role that grants read-only access. However, after revoking the lease, the database user still exists. What is the most likely cause?

Accepted Answer

The revocation statement is not configured in the database connection. When a database secrets engine role is configured in Vault, the revocation statement (e.g., `ALTER USER "{{name}}" NOLOGIN;` or `DROP USER IF EXISTS "{{name}}";`) must be explicitly defined in the database connection's `rotation_statements` or `revocation_statements`. If no revocation statement is set, Vault will successfully create and manage the database user but will not execute any SQL to disable or drop that user when the lease is revoked, leaving the user active in PostgreSQL.

Answer

The database secrets engine does not support revocation

Answer

The role's default_ttl is set too high

Answer

The lease duration is too long

Question 8

Which TWO of the following are valid paths for reading and writing data in the KV v2 secrets engine? (Choose two.)

Accepted Answer

secret/data/myapp. In the KV v2 secrets engine, the `/data/` path is the only endpoint for reading and writing actual secret data. The `/metadata/` path is used for managing metadata (e.g., versions, deletion), not for reading and writing data. Therefore, only option B is correct.

Answer

secret/delete/myapp

Answer

secret/destroy/myapp

Answer

secret/myapp

Answer

secret/metadata/myapp

Question 9

Which THREE of the following are capabilities of the PKI secrets engine? (Choose three.)

Accepted Answer

Revoke certificates. The PKI secrets engine in Vault supports certificate revocation via Certificate Revocation Lists (CRLs) or by directly marking a certificate as revoked in its storage backend. This is a core PKI lifecycle management capability, allowing operators to invalidate compromised or expired certificates immediately.

Answer

Automatically rotate certificates

Answer

Generate one-time pads

Question 10

Which TWO statements are true about the AWS secrets engine? (Choose two.)

Accepted Answer

It can generate AWS session tokens. The AWS secrets engine can generate temporary AWS session tokens via the AWS Security Token Service (STS). These tokens provide short-term, limited-privilege credentials for accessing AWS resources, which is a core feature of the engine for dynamic credential management.

Answer

It can manage EC2 key pairs

Answer

It supports STS federation

Answer

It only supports static IAM users

Question 11

Refer to the exhibit. A Vault policy allows 'list' on 'secret/data/*'. A user tries to list keys under 'secret/data/' and gets a permission denied error. What is the most likely reason?

Accepted Answer

The path must be 'secret/metadata/*' for list. C is correct because in Vault, listing keys under a KV v2 secrets engine requires the 'list' capability on the 'secret/metadata/*' path, not 'secret/data/*'. The 'data' path is used for reading and writing actual secret values, while 'metadata' is the correct path for listing and deleting metadata (including key names). The policy only grants 'list' on 'secret/data/*', which does not cover the list operation on the metadata endpoint, resulting in a permission denied error.

Answer

The user's token has no default policy

Answer

The policy lacks 'read' capability

Answer

The secrets engine is not enabled

Question 12

Refer to the exhibit. An operator issues a certificate using this intermediate CA. The resulting certificate uses SHA1 signature algorithm. The operator wants SHA256. What should they do?

Accepted Answer

Generate a new intermediate with signature_bits=256. The signature algorithm used by an intermediate CA is determined by the `signature_bits` parameter set when the intermediate CA's certificate is generated. To issue end-entity certificates with SHA256, the intermediate CA itself must be created with `signature_bits=256`. Simply changing a role or issuer after the intermediate exists does not retroactively alter the CA's signing key algorithm.

Answer

Set the issuer's signature_bits to 256 using vault write

Answer

Use a different issuer_name that already has SHA256

Answer

Change the role's signature_bits to 256

Question 13

Refer to the exhibit. A user deletes the current version of 'secret/myapp' using 'vault kv delete secret/myapp'. What happens to the version?

Accepted Answer

It is deleted and can be undeleted if not destroyed. With default delete_version_after=0s and max_versions=0, deleting a version marks it as deleted but does not destroy it. The version can be undeleted. The cas_required setting affects write operations, not delete. Permanent destruction requires a separate 'destroy' command or automatic cleanup if delete_version_after is set.

Answer

It is destroyed because cas_required is true

Answer

It is permanently deleted immediately

Answer

It is marked as deleted but can be undeleted because cas_required is true

Question 14

An admin needs to store a configuration value that is unique to each Vault client and must not be shared. Which secrets engine should they use?

Accepted Answer

Cubbyhole. The Cubbyhole secrets engine creates a private, ephemeral storage space that is scoped to the requesting token. Each token gets its own isolated cubbyhole, and no other client or token can read or write to it, even with root privileges. This makes it the only built-in engine that guarantees a configuration value is unique to each Vault client and cannot be shared.

Answer

AWS

Answer

KV v2 at a client-specific path

Answer

Transit

Question 15

A company needs to automatically generate short-lived database credentials for developers. Which secrets engine should they use?

Accepted Answer

Database. The Database secrets engine is specifically designed to generate short-lived, dynamic database credentials on demand. It connects to a database and creates unique user accounts with configurable time-to-live (TTL) values, which are automatically revoked when the lease expires. This directly meets the requirement for automatically generating temporary database credentials for developers.

Answer

KV v2

Answer

AWS

Answer

Cubbyhole