Courseiva

CCNA Compare and configure secrets engines Questions

61 questions · Compare and configure secrets engines · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

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?

A.PKI
B.Transit
C.AWS
D.KV v2
AnswerB

The transit secrets engine encrypts plaintext supplied by the application and returns ciphertext for database storage, while Vault retains and rotates the keys. This satisfies the requirement that the development team never manages encryption keys themselves.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between 'storing secrets' (KV v2) and 'encrypting data without managing keys' (Transit), leading candidates to mistakenly choose KV v2 because they associate it with 'secrets' rather than the specific encryption workflow.

How to eliminate wrong answers

Option A (PKI) is wrong because PKI generates and manages X.509 certificates for TLS/SSH authentication, not for encrypting arbitrary data payloads. Option C (AWS) is wrong because the AWS secrets engine generates dynamic AWS IAM credentials or manages static AWS secrets, but it does not provide encryption-as-a-service for application data. Option D (KV v2) is wrong because KV v2 stores plaintext secrets (like passwords or API keys) in a key-value store; it does not encrypt data on behalf of clients or offload key management.

Practice this question →
2
MCQhard

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?

A.The 'suppress_decryption' parameter was enabled on the transit mount, blocking decryption. Disable it.
B.The key was exported and reimported, losing the version history. Re-create the key from scratch.
C.The ciphertext was corrupted during storage. The only solution is to re-encrypt all data with the current key version.
D.The 'min_decryption_version' is set to 3, preventing decryption with version 2. Set it to 2 to allow decryption.
AnswerD

Setting `min_decryption_version` to 3 archives versions below it, so version 2 ciphertexts fail with exactly that error despite the version still existing. Lowering it to 2 restores decryption of older data while retaining rotation, satisfying the compliance requirement without re-encrypting existing records.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between key version presence and decryption permission, where candidates mistakenly assume that if the key version exists, decryption should always work, overlooking the `min_decryption_version` constraint.

How to eliminate wrong answers

Option A is wrong because `suppress_decryption` is not a valid parameter on the transit mount; the correct parameter is `disable_decryption` on the key, but that would block all decryption, not just for a specific version. Option B is wrong because exporting and reimporting a key would create a new key with a fresh version history, but the existing ciphertexts would still reference the old key version, and the error would be about missing key material, not a decryption version restriction. Option C is wrong because ciphertext corruption would typically produce a different error (e.g., 'invalid ciphertext' or HMAC mismatch), not a specific message about decryption key version unavailability.

Practice this question →
3
Multi-Selectmedium

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

Select 3 answers
A.Enable the database secrets engine
B.Create a role that specifies the SQL statements for credential creation
C.Generate a root certificate for the database
D.Tune the mount to set default TTL for all roles
E.Configure a connection with the MySQL plugin and connection details
AnswersA, B, E

Enabling the database secrets engine at a path mounts it so Vault can generate dynamic database credentials. This is the mandatory first step before configuring a MySQL connection and a role, which the remaining required steps then build upon.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between required configuration steps and optional tuning or security enhancements, leading candidates to include steps like tuning TTL or generating certificates as mandatory when they are not.

Practice this question →
4
Multi-Selecthard

Which THREE of the following are true about the KV v2 secrets engine? (Select exactly 3.)

Select 3 answers
A.It does not support deletion of secrets.
B.It supports check-and-set operations for concurrent updates.
C.It does not support undoing changes.
D.It supports metadata like created_time and deletion_time.
E.It supports versioning of secrets.
AnswersB, D, E

KV v2 implements check-and-set semantics: writes supply a version number, and Vault rejects the write if the stored version differs, preventing lost updates. This satisfies the concurrency requirement by detecting conflicting concurrent modifications rather than silently overwriting them.

Why this answer

Option B is correct because the KV v2 secrets engine supports check-and-set (CAS) operations: when writing a secret you can supply the cas parameter with the expected current version, and the write fails if the version has changed, preventing lost updates during concurrent modifications. Option D is correct because KV v2 stores rich metadata for each secret version, including fields such as created_time, deletion_time, destroyed, and version, retrievable via the metadata endpoint (e.g., GET secret/metadata/<path>). Option E is correct because KV v2's defining feature is versioning: each write creates a new numbered version, allowing retrieval of specific versions and configuration of max_versions.

Option A is wrong because KV v2 does support deletion, including soft deletion (delete) and permanent destruction (destroy) of specific versions. Option C is wrong because KV v2 supports undoing changes through versioning: you can read an earlier version and write it back, or use the undelete operation to restore a soft-deleted version.

Exam trap

HashiCorp often tests the misconception that KV v2 cannot delete or undo changes, when in fact it supports soft delete, destroy, and version rollback, and the trap is that candidates confuse KV v2 with the older KV v1 engine which lacks versioning and CAS.

Practice this question →
5
MCQhard

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?

A.The revocation statement is incorrect
B.The connection string is invalid
C.The database user has been manually deleted
D.The lease duration is set too high
AnswerA

Vault executes the role's revocation statement when a lease expires; if that statement is malformed or targets the wrong user, revocation silently fails. This satisfies the stem's scenario where the database user persists after lease expiry despite creation working correctly.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that lease duration or connection health is the root cause of revocation failures, when in reality the revocation SQL statement itself is the most common point of failure.

How to eliminate wrong answers

Option B is wrong because an invalid connection string would prevent Vault from connecting to the database entirely, causing both creation and revocation to fail, not just revocation on lease expiry. Option C is wrong because if the database user was manually deleted, revocation would have nothing to revoke, but the question states the user is not revoked, implying the user still exists. Option D is wrong because a lease duration set too high would only delay the revocation event; it would not prevent revocation from occurring when the lease eventually expires.

Practice this question →
6
MCQmedium

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?

A.Schedule a cron job to periodically read new credentials.
B.Set a longer default TTL on the role.
C.Use Vault Agent to renew the secret.
D.Set a longer max TTL on the mount.
AnswerC

Vault Agent runs alongside the application, authenticating to Vault and automatically renewing the database credential lease before expiry, so connections no longer fail at the default lease duration. This satisfies the requirement for automatic renewal without embedding renewal logic in application code.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse extending the TTL (options B and D) with automating renewal, but Vault requires explicit renewal logic or a tool like Vault Agent to handle the renewal process automatically.

How to eliminate wrong answers

Option A is wrong because scheduling a cron job to read new credentials does not renew the existing lease; it creates a new lease each time, which can lead to orphaned leases and does not address the automatic renewal requirement. Option B is wrong because setting a longer default TTL on the role only extends the initial lease duration but does not automate renewal; the application would still need to handle renewal logic or risk expiration after the longer TTL. Option D is wrong because setting a longer max TTL on the mount only defines the upper limit for lease durations, not the actual renewal behavior; it does not automate the renewal process and may still result in expiration if the application does not renew.

Practice this question →
7
MCQeasy

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

A.KV v2 secrets engine
B.PKI secrets engine
C.Database secrets engine
D.Transit secrets engine
AnswerC

The database secrets engine dynamically generates short-lived credentials on demand, eliminating stored passwords. It satisfies the temporary-credentials constraint by issuing unique usernames and passwords per request with a lease TTL, after which Vault automatically revokes them. This removes long-lived static secrets entirely, unlike static key-value storage.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between static secret storage (KV v2) and dynamic secret generation (Database engine), leading candidates to mistakenly choose KV v2 because they think of it as the default secrets engine for any credential.

How to eliminate wrong answers

Option A is wrong because the KV v2 secrets engine stores static secrets (like passwords or API keys) in a key-value store; it does not generate dynamic, temporary credentials or enforce automatic rotation/revocation. Option B is wrong because the PKI secrets engine generates X.509 certificates for TLS/SSL authentication, not database credentials. Option D is wrong because the Transit secrets engine provides encryption-as-a-service (encrypt/decrypt data in transit or at rest) but does not generate or manage database credentials.

Practice this question →
8
MCQeasy

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?

A.Cubbyhole
B.KV v1
C.Transit
D.KV v2
AnswerD

KV v2 stores secrets under a versioned key structure, retaining configurable historical versions so any prior value can be retrieved or rolled back. This directly satisfies the stem's versioning and rollback requirements for static API keys, unlike dynamic engines that generate short-lived credentials and keep no version history.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2, trapping candidates who assume all KV engines support versioning, or who confuse the Transit engine's encryption capabilities with secret storage versioning.

How to eliminate wrong answers

Option A is wrong because Cubbyhole is a per-token secrets engine that stores secrets scoped to a single token's lifetime and does not support versioning or rollback. Option B is wrong because KV v1 stores secrets without versioning; each write overwrites the previous value, making rollback impossible. Option C is wrong because Transit is a cryptographic engine for encryption/decryption operations on data in transit or at rest, not for storing static secrets with versioning.

Practice this question →
9
Multi-Selecthard

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

Select 2 answers
A.Enable audit logging on the mount to track secret access
B.Configure 'max_lease_ttl' to limit the maximum duration secrets can be valid
C.Set 'default_lease_ttl' to a low value appropriate for the secrets engine
D.Set a high default lease TTL to reduce renewals
E.Disable the 'default' policy for the mount to restrict access
AnswersB, C

Setting max_lease_ttl caps how long any credential issued by the mount can remain valid, forcing periodic renewal or reissuance. This satisfies the tuning requirement by bounding exposure if a secret leaks, rather than letting leases persist indefinitely.

Why this answer

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.

Exam trap

VA-003 often tests the confusion between per-mount lease tuning parameters (default_lease_ttl, max_lease_ttl) and server-wide audit/policy settings, tempting candidates to pick audit logging or policy changes as 'tuning' best practices.

Practice this question →
10
MCQeasy

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?

A.The user's token has no default policy
B.The policy lacks 'read' capability
C.The path must be 'secret/metadata/*' for list
D.The secrets engine is not enabled
AnswerC

For KV version 2, list operations are served by the metadata path, not the data path. Granting list on secret/data/* cannot authorise listing, so the policy must instead allow list on secret/metadata/* for the keys to be enumerable.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 path structures, specifically that 'list' operations in KV v2 require the 'metadata' path, not the 'data' path, which candidates frequently confuse because they assume the same path works for both reading and listing.

How to eliminate wrong answers

Option A is wrong because the default policy is not required for listing; the user's token only needs a policy that grants 'list' on the correct path. Option B is wrong because 'read' capability is not needed for listing keys; 'list' is a distinct capability that must be explicitly granted on the appropriate path. Option D is wrong because if the secrets engine were not enabled, the error would be 'path not found' or 'no handler', not a permission denied error.

Practice this question →
11
MCQeasy

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

A.vault secrets enable -path=team-alpha kv-v2
B.vault secrets enable kv-v2 team-alpha
C.vault secrets enable -path=team-alpha kv
D.vault secrets mount -path=team-alpha kv
AnswerA

The -path flag sets the mount point while kv-v2 selects the versioned key-value engine, enabling it at team-alpha. This satisfies the scenario by mounting KV v2 at the exact requested path rather than the default secret/ location.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between `kv` (v1) and `kv-v2` (v2) engines, and the requirement to use the `-path` flag for custom mount points, causing candidates to confuse the engine type or omit the flag.

How to eliminate wrong answers

Option B is wrong because it omits the `-path` flag, causing the engine to be mounted at the default path 'kv-v2' instead of 'team-alpha'. Option C is wrong because `kv` refers to the KV v1 secrets engine (non-versioned), not the KV v2 engine required. Option D is wrong because `vault secrets mount` is a legacy command; the correct modern command is `vault secrets enable`, and `kv` again specifies the wrong engine type.

Practice this question →
12
MCQeasy

A company needs to generate short-lived, dynamic database credentials for its MySQL instances. Which secrets engine should be configured?

A.KV secrets engine
B.AWS secrets engine
C.Database secrets engine
D.PKI secrets engine
AnswerC

The database secrets engine dynamically generates unique, short-lived MySQL credentials on demand, eliminating static passwords. It satisfies the stem's requirement for dynamic, short-lived database credentials by issuing them through a configured database role, with automatic revocation on lease expiry. Static or KV engines cannot generate per-request credentials tied to a lease.

Why this answer

The Database secrets engine is specifically designed to generate short-lived, dynamic credentials for databases like MySQL. It creates unique, time-bound usernames and passwords on demand, which aligns with the requirement for temporary database access without manual credential management.

Exam trap

HashiCorp often tests the distinction between static and dynamic secrets engines, and the trap here is confusing the Database secrets engine with the KV secrets engine because both can store database passwords, but only the Database engine generates them on-the-fly with automatic expiration.

How to eliminate wrong answers

Option A is wrong because the KV secrets engine stores static secrets (e.g., passwords, API keys) and does not support dynamic credential generation or automatic rotation. Option B is wrong because the AWS secrets engine generates dynamic credentials for AWS services (e.g., IAM users, STS tokens), not for MySQL databases. Option D is wrong because the PKI secrets engine issues X.509 certificates for TLS/SSL authentication, not database credentials.

Practice this question →
13
MCQmedium

A Vault administrator has enabled the PKI secrets engine and configured a root CA. They now need to issue certificates for multiple internal services, each with its own common name (CN). Which is the most efficient way to issue certificates while maintaining security?

A.Create a separate role for each service with specific allowed domains
B.Create one role with the allow_any_name parameter set to true
C.Create one role with a wildcard allowed domain and use the common_name parameter when issuing
D.Create one role without any allowed domains and specify the common name in the request
AnswerA

PKI roles bind issuance to permitted domains and key parameters, so a per-service role with its own allowed domains lets each service obtain only its own CN certificate. This satisfies the requirement for multiple CNs while enforcing least privilege at issuance.

Why this answer

Creating a separate role for each service allows you to enforce least-privilege by restricting each role to specific allowed domains (e.g., via `allowed_domains` and `allow_subdomains`). This ensures that each service can only request certificates for its own CN, preventing cross-service impersonation while maintaining efficient, role-based issuance. The PKI secrets engine uses roles to define TTL, key type, and domain constraints, making per-service roles the most secure and manageable approach.

Exam trap

The trap here is that candidates assume a single wildcard role is more efficient, but they overlook that Vault's role-based access control (RBAC) and domain restrictions are designed for granularity, and that `allow_any_name` or missing allowed domains create security holes or request failures.

How to eliminate wrong answers

Option B is wrong because setting `allow_any_name` to true removes all domain restrictions, allowing any CN to be issued from a single role, which violates security best practices and could lead to unauthorized certificate generation. Option C is wrong because a wildcard allowed domain (e.g., `*.example.com`) would allow any subdomain under that domain, but it does not restrict the CN to a specific service; additionally, the `common_name` parameter in the issue request must still match the allowed domain, so it does not provide per-service isolation. Option D is wrong because creating a role without any allowed domains (i.e., `allowed_domains` empty) will cause the issue request to fail unless `allow_any_name` is true, as Vault requires at least one allowed domain or the wildcard flag to validate the CN.

Practice this question →
14
MCQeasy

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?

A.KV v2 secrets engine
B.AWS secrets engine
C.Database secrets engine
D.Transit secrets engine
AnswerA

KV v2 stores static key-value pairs and replaces the deprecated generic engine, satisfying the migration constraint. It adds versioning, metadata and soft-delete, letting the operator retain prior secret versions and recover deleted data. Enable it at a chosen path, then migrate existing generic secrets into it.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that the 'generic' secrets engine is still valid or that any secrets engine can store static key-value pairs, leading candidates to overlook the specific deprecation and the KV v2 replacement.

How to eliminate wrong answers

Option B is wrong because the AWS secrets engine dynamically generates AWS IAM credentials or STS tokens, not static key-value pairs. Option C is wrong because the Database secrets engine dynamically generates short-lived database credentials, not static key-value pairs. Option D is wrong because the Transit secrets engine performs encryption/decryption operations on data in transit and does not store key-value pairs.

Practice this question →
15
MCQhard

A DevOps engineer configures the AWS secrets engine to assume a specific IAM role for generating dynamic credentials. The engine is enabled and the root configuration is set. Which parameter is essential in the role configuration to allow assuming the IAM role?

A.role_type
B.credential_type
C.inline_policy
D.arn
AnswerD

The `arn` parameter specifies the Amazon Resource Name of the IAM role that Vault assumes via STS to generate dynamic credentials. Without it, the AWS secrets engine cannot identify which role to assume, so role creation fails. This directly satisfies the stem's requirement for the essential parameter enabling IAM role assumption.

Why this answer

The `arn` parameter is essential in the role configuration for the AWS secrets engine because it specifies the Amazon Resource Name (ARN) of the IAM role that Vault will assume to generate dynamic credentials. Without this parameter, Vault cannot identify which IAM role to assume via AWS STS AssumeRole API, making dynamic credential generation impossible.

Exam trap

HashiCorp often tests the misconception that `credential_type` (Option B) is the essential parameter for assuming a role, but it only defines the credential generation method, not the target role ARN, which is the actual requirement for the AssumeRole operation.

How to eliminate wrong answers

Option A is wrong because `role_type` is not a valid parameter in the AWS secrets engine role configuration; the engine uses the `credential_type` parameter to define whether credentials are IAM users or STS-based, but `role_type` does not exist. Option B is wrong because `credential_type` defines the type of credential (e.g., `iam_user` or `assumed_role`) but does not specify which IAM role to assume; it is a separate configuration parameter. Option C is wrong because `inline_policy` is used to attach an inline policy to the generated IAM user credentials, not to specify the IAM role to assume; it is optional and unrelated to the AssumeRole action.

Practice this question →
16
MCQmedium

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

A.It is destroyed because cas_required is true
B.It is deleted and can be undeleted if not destroyed
C.It is permanently deleted immediately
D.It is marked as deleted but can be undeleted because cas_required is true
AnswerB

A KV v2 delete marks the version as deleted by writing a deletion marker, removing it from reads. The underlying data remains, so the version can be undeleted unless it is destroyed or its metadata removed.

Why this answer

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.

Practice this question →
17
MCQhard

An administrator enables the database secrets engine for PostgreSQL. After configuring the connection, running `vault write database/config/someconfig` yields error: 'x509: certificate signed by unknown authority'. What is the most likely cause?

A.The connection string is incorrect
B.The PostgreSQL server's TLS certificate is not trusted by Vault's CA bundle
C.The database engine is not enabled
D.The Vault server's TLS certificate is self-signed
AnswerB

Vault verifies the PostgreSQL server's TLS certificate against its own CA bundle during connection setup. An untrusted or self-signed certificate produces exactly this x509 error, satisfying the stem's failure at config-write time, before any credential or role logic executes.

Why this answer

The error 'x509: certificate signed by unknown authority' indicates that Vault, when connecting to the PostgreSQL database, received a TLS certificate from the server that was not signed by any Certificate Authority (CA) present in Vault's trusted CA bundle. Vault uses its system's CA pool or a custom CA bundle configured in the connection string to verify the database server's certificate. If the PostgreSQL server uses a self-signed certificate or one issued by an internal CA not trusted by Vault, this error occurs.

Option B correctly identifies that the PostgreSQL server's TLS certificate is not trusted by Vault's CA bundle.

Exam trap

HashiCorp often tests the distinction between TLS errors related to the target server's certificate (outbound connection) versus the Vault server's own certificate (inbound connection), causing candidates to confuse the direction of the TLS handshake.

How to eliminate wrong answers

Option A is wrong because an incorrect connection string typically results in a connection timeout, refused connection, or authentication failure, not an x509 certificate validation error. Option C is wrong because if the database engine were not enabled, the `vault write` command would fail with a 'path not found' or 'no handler' error, not a TLS certificate error. Option D is wrong because the error refers to the PostgreSQL server's certificate not being trusted, not Vault's own TLS certificate; Vault's server certificate is used for client-facing HTTPS, not for outbound connections to databases.

Practice this question →
18
MCQhard

A database secrets engine is configured at database/ with a connection to PostgreSQL and a role named app-readonly. The role uses creation_statements to create a user with a random password and a TTL of one hour. An application retrieves credentials and uses them successfully, but after the lease expires the database user still exists and can log in. Which configuration change should the administrator make to ensure the user is removed when the lease ends?

A.Enable the database secrets engine with a root rotation schedule to force user cleanup.
B.Set the role's credential_type to static_role and rely on automatic revocation.
C.Increase the default_ttl on the role to match the maximum_ttl so the lease never expires.
D.Add revocation_statements to the role that drop the user, and ensure the connection user has permission to execute them.
AnswerD

Revocation is driven by revocation_statements on the role, which Vault executes when the lease expires or is revoked. If they are missing or the connection user lacks privileges, the database user persists. Adding appropriate DROP USER statements and granting the connection user permission resolves the lingering-user problem.

Why this answer

Dynamic database credentials are cleaned up by executing the role's revocation_statements when the lease is revoked or expires. If those statements are absent or the connection user lacks the privilege to run them, the created user remains. Supplying correct DROP USER statements and ensuring the connection user can execute them restores proper lifecycle management.

Exam trap

The trap here is assuming that lease expiration alone deletes the database user, when Vault depends on revocation_statements and the connection user's privileges to perform the cleanup.

Practice this question →
19
MCQhard

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?

A.The min_decryption_version is set to 4, preventing decryption with version 3
B.The ciphertext was generated by a different transit key
C.The key was rotated, and automatic data re-encryption is required
D.The application is using the wrong encryption algorithm
AnswerA

Vault's min_decryption_version blocks decryption of ciphertext produced by any key version below it. With version 3 ciphertext and the floor set to 4, the engine refuses the operation, directly explaining the failure despite version 5 being current.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that key rotation automatically invalidates older ciphertext, but the actual mechanism is the `min_decryption_version` setting, which explicitly controls which versions are allowed for decryption.

How to eliminate wrong answers

Option B is wrong because the ciphertext was explicitly generated with key 'my-key', and the failure is tied to version mismatch, not a different key name. Option C is wrong because key rotation does not automatically re-encrypt existing ciphertext; the transit engine never re-encrypts data automatically, and decryption with older versions is allowed unless `min_decryption_version` blocks it. Option D is wrong because the encryption algorithm is set at key creation time and does not change with version bumps; the algorithm remains consistent across versions of the same key.

Practice this question →
20
MCQhard

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?

A.The Vault write operation failed due to network latency.
B.The TTL on the role is too short.
C.Vault must wait for the AWS secret key to be rotated before returning the user.
D.AWS IAM is eventually consistent and the user may take a few seconds to propagate.
AnswerD

AWS IAM uses eventually consistent replication across its infrastructure. A newly created IAM user or access key may not be usable for several seconds until that change propagates, so immediate authentication attempts can fail even though the credentials were generated successfully.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse eventual consistency with a Vault-side failure or misconfiguration, such as a short TTL or a write failure, rather than recognizing it as an inherent property of AWS IAM.

How to eliminate wrong answers

Option A is wrong because a Vault write operation failure due to network latency would result in an error response from Vault, not a delayed availability of the IAM user; the user would simply not be created. Option B is wrong because the TTL on the role controls how long the generated credentials are valid, not the time it takes for the IAM user to become available after creation. Option C is wrong because Vault does not wait for AWS secret key rotation before returning the user; the AWS secrets engine creates the IAM user and returns credentials immediately, with propagation delay being an AWS-side behavior.

Practice this question →
21
MCQeasy

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

A.KV v2
B.AWS
C.Cubbyhole
D.Database
AnswerD

The Database secrets engine dynamically generates short-lived credentials on demand, eliminating static passwords. It satisfies the stem's requirement for automatic generation by creating unique database users per request and revoking them at lease expiry, rather than storing long-lived secrets in Microsoft Entra ID or a static key-value store.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (like Database, AWS) versus those that only store static secrets (like KV v2), leading candidates to mistakenly choose KV v2 because it is the most commonly used engine for general secret storage.

How to eliminate wrong answers

Option A is wrong because KV v2 is a static key-value store that does not generate dynamic credentials; it stores secrets as-is and does not support automatic credential rotation or TTL-based expiration. Option B is wrong because the AWS secrets engine generates dynamic credentials for AWS services (e.g., IAM users, STS tokens), not for databases. Option C is wrong because Cubbyhole is a per-token private storage space that is tied to the lifetime of the token itself and cannot be used to generate or manage database credentials for other users.

Practice this question →
22
Multi-Selecthard

A security architect is designing a secrets management solution with Vault. Which THREE secrets engines are most appropriate for dynamically generating credentials for external systems?

Select 3 answers
A.PKI secrets engine
B.KV v2 secrets engine
C.AWS secrets engine
D.Transit secrets engine
E.Database secrets engine
AnswersA, C, E

The PKI secrets engine dynamically issues X.509 certificates with short lifetimes, satisfying the requirement for on-demand credentials for external systems. Unlike static secrets, each certificate is generated per request and expires automatically, removing manual rotation. It therefore directly addresses dynamic credential generation for external endpoints.

Why this answer

The PKI secrets engine (A) is correct because it dynamically generates X.509 certificates and private keys on demand from configured roles, issuing short-lived credentials rather than storing static ones. The AWS secrets engine (C) is correct because it dynamically generates AWS IAM credentials (access key ID and secret access key) or STS tokens based on IAM policies, providing on-demand, lease-bound cloud credentials. The Database secrets engine (E) is correct because it dynamically creates unique database usernames and passwords for supported databases (e.g., MySQL, PostgreSQL) tied to a lease, eliminating shared static credentials.

The KV v2 secrets engine (B) is not appropriate here because it only stores and versions static key-value secrets and does not generate credentials. The Transit secrets engine (D) is not appropriate because it provides encryption-as-a-service (encrypt/decrypt/sign/verify) and does not issue credentials for external systems.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (PKI, AWS, Database) versus those that store or process static data (KV v2, Transit), leading candidates to incorrectly select KV v2 for its familiarity or Transit for its security focus.

Practice this question →
23
MCQmedium

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?

A.Enable the AWS secrets engine at a custom path
B.Set a high TTL on the AWS secrets engine mount
C.Use the transit secrets engine to encrypt the AWS credentials
D.Configure a role in the AWS secrets engine that specifies the managed policies
AnswerD

The AWS secrets engine role binds the managed policy ARNs to credentials it generates, so Vault attaches those policies to each IAM user it creates. Without a role specifying the policies, generated users receive no managed policy attachments.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse the purpose of the AWS secrets engine role with other Vault features like mount paths or encryption engines, assuming policy attachment is handled automatically or through unrelated configurations.

How to eliminate wrong answers

Option A is wrong because enabling the AWS secrets engine at a custom path does not affect policy assignment; it only changes the mount point for API access. Option B is wrong because setting a high TTL on the AWS secrets engine mount controls credential lease duration, not the policies attached to generated users. Option C is wrong because the transit secrets engine is used for encryption of data in transit or at rest, not for defining IAM policies; it is unrelated to AWS IAM user generation.

Practice this question →
24
Multi-Selectmedium

A security team is configuring the AWS secrets engine to issue dynamic IAM credentials. They want to allow Vault to assume an IAM role and generate temporary credentials for consumers. Which TWO configuration elements are required to enable this workflow? (Choose two.)

Select 2 answers
A.Create a role of type 'assumed_role' that specifies the ARN of the IAM role Vault should assume.
B.Configure the AWS secrets engine with credentials that have permissions to call sts:AssumeRole and iam:CreateAccessKey as needed.
C.Enable the AWS auth method and bind an IAM principal to a Vault policy before creating the role.
D.Enable the KV v2 secrets engine and store the AWS access key and secret key as a static secret.
E.Create a Vault policy that grants 'sudo' capability on the AWS secrets engine role path.
AnswersA, B

An AWS secrets engine role of type assumed_role tells Vault to call sts:AssumeRole against the specified role ARN and return temporary credentials. This role configuration is what binds the Vault path to the AWS IAM role. Without this role, Vault has no target role to assume and cannot issue credentials for the requested path.

Why this answer

To issue dynamic IAM credentials with the AWS secrets engine, Vault needs AWS credentials with the right permissions and a role that defines what to create or assume. For assumed_role, the role specifies the target IAM role ARN and Vault calls sts:AssumeRole. AWS auth, sudo policies, and KV v2 storage are not prerequisites for this secrets engine workflow.

Exam trap

The trap here is conflating the AWS auth method, which authenticates clients to Vault, with the AWS secrets engine, which issues AWS credentials to clients.

Practice this question →
25
MCQmedium

An operator wants to enable the database secrets engine at a custom path 'db-creds'. Which command should be used?

A.vault secrets enable database
B.vault secrets enable -path=db-creds database
C.vault write sys/mounts/db-creds type=database
D.vault secrets tune -path=db-creds database
AnswerB

The -path flag on vault secrets enable mounts the engine at the specified custom path, so 'db-creds' becomes the API prefix instead of the default 'database'. This directly satisfies the operator's requirement to enable the database secrets engine at a non-default path.

Why this answer

The `vault secrets enable` command with the `-path` flag allows you to mount the database secrets engine at a custom path. The syntax `vault secrets enable -path=db-creds database` correctly specifies the custom path and the engine type, enabling the database secrets engine at the desired location.

Exam trap

HashiCorp often tests the distinction between enabling a secrets engine (`vault secrets enable`) and tuning an existing mount (`vault secrets tune`), trapping candidates who confuse the two or think `vault write` can be used to enable engines directly.

How to eliminate wrong answers

Option A is wrong because `vault secrets enable database` mounts the engine at the default path (`database/`), not at the custom path `db-creds`. Option C is wrong because `vault write sys/mounts/db-creds type=database` is not a valid command; the correct API endpoint for enabling a secrets engine is `sys/mounts/<path>` with a POST request, but the CLI does not use `vault write` for this purpose—it uses `vault secrets enable`. Option D is wrong because `vault secrets tune` is used to modify configuration of an existing mount, not to enable a new secrets engine; it cannot create a new mount at a custom path.

Practice this question →
26
MCQmedium

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?

A.The secrets engine is KV v1, but the user is using the KV v2 path format with '/data/'.
B.The user's policy does not cover the sub-path 'secret/data/app'.
C.The secret path is mistyped; it should be 'secret/application'.
D.The secret engine at 'secret/' is not enabled.
AnswerA

KV v2 inserts a 'data/' segment into the API path, so 'secret/data/app' addresses a v2 mount. Against a KV v1 engine that path does not exist, producing 404, while 'vault secrets list' still succeeds because the mount itself is present.

Why this answer

The KV v2 secrets engine requires the path format `secret/data/<path>` for reading secret data, while KV v1 uses `secret/<path>` 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.

Exam trap

HashiCorp Vault often tests the distinction between KV v1 and KV v2 path formats, and the trap here is that candidates assume a 404 error always means the secret doesn't exist or permissions are wrong, rather than recognizing the `/data/` prefix is only valid for KV v2 engines.

How to eliminate wrong answers

Option B is wrong because the policy grants 'read' on 'secret/*', which covers all sub-paths including 'secret/data/app', so the 404 is not a permissions issue. Option C is wrong because the error is not about a mistyped path name; the user's path 'secret/data/app' is syntactically valid for KV v2 but fails due to engine version mismatch. Option D is wrong because the user can list the engine with `vault secrets list`, proving the engine is enabled at 'secret/'.

Practice this question →
27
Multi-Selectmedium

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

Select 2 answers
A.Provides automatic rotation of credentials upon lease expiry
B.Simplifies the management of service accounts because credentials never change
C.Secrets are persistent and do not expire
D.Secrets are stored in plaintext in the Vault data store
E.Reduces the risk of credential leakage since secrets are short-lived
AnswersA, E

Dynamic secrets engines generate credentials on demand with a defined lease, then revoke them automatically when that lease expires. This satisfies the stem's rotation constraint without manual intervention, unlike static secrets that persist until changed by hand. Each request yields unique, short-lived credentials, sharply limiting exposure if leaked.

Why this answer

Option A is correct because dynamic secrets engines issue credentials with a defined lease/TTL, and when that lease expires (or is revoked), Vault automatically revokes and regenerates the credentials, delivering automatic rotation without manual intervention. Option E is correct because dynamic secrets are short-lived by design—each request generates unique, time-bound credentials—so any leaked credential has a limited window of usefulness, reducing the blast radius and risk of credential leakage. Options B, C, and D are incorrect: dynamic credentials do change (they are generated per lease and expire), they are not persistent or non-expiring, and Vault does not store dynamic secrets in plaintext in its data store—they are generated on demand and tracked by lease, not persisted as static plaintext values.

Exam trap

HashiCorp often tests the misconception that dynamic secrets are persistent or that Vault stores secrets in plaintext, tempting candidates to select options C or D, but the core benefit is the automatic, short-lived nature of credentials that reduces leakage risk.

Practice this question →
28
MCQhard

An organization uses the KV v2 secrets engine mounted at 'kv/'. They need to permanently delete all versions of a secret at path 'kv/apps/prod/db' and also remove all associated metadata, including custom metadata and version history. Which command should they run?

A.vault kv metadata delete kv/apps/prod/db
B.vault kv delete kv/apps/prod/db
C.vault kv undelete -versions=1,2,3 kv/apps/prod/db
D.vault kv destroy -versions=1,2,3 kv/apps/prod/db
AnswerA

The 'vault kv metadata delete' command deletes the secret and all its versions, along with all metadata. This is the only command that completely removes the secret from the KV v2 engine. It is irreversible and should be used with caution. It satisfies the requirement to permanently delete all versions and remove metadata.

Why this answer

In KV v2, deleting all versions and metadata requires the 'vault kv metadata delete' command. This operation removes the secret entirely, including all version data and custom metadata. Other commands like 'delete' only soft-delete the latest version, 'destroy' removes specific versions but leaves metadata, and 'undelete' restores data.

The metadata delete is the only one that fully purges the secret.

Exam trap

The trap here is assuming that a regular delete command removes all traces of the secret, when in fact it only performs a soft delete that can be undone.

Practice this question →
29
MCQeasy

A cloud operations team wants to use Vault to generate dynamic credentials for an AWS RDS MySQL database. They have configured the database secrets engine and created a role named 'app-role' that maps to a database creation statement. A developer needs to obtain a username and password to connect to the database. Which command should the developer run to retrieve the dynamic credentials?

A.vault read database/static-creds/app-role
B.vault kv get database/creds/app-role
C.vault read database/creds/app-role
D.vault write database/roles/app-role
AnswerC

The 'vault read database/creds/<role>' command generates and returns dynamic credentials for the specified role. It calls the database secrets engine's creds endpoint, which executes the role's creation statements against the database and returns a unique username and password with a limited lease. This is the standard way to obtain dynamic database credentials from Vault.

Why this answer

Dynamic database credentials are generated by reading from the 'creds' endpoint of the database secrets engine for a specific role. The 'vault read database/creds/app-role' command triggers Vault to execute the role's creation statements and return a new username and password. Other commands either configure the role, target static roles, or use the wrong secrets engine.

Exam trap

The trap here is confusing the role configuration endpoint with the credential generation endpoint, or mistakenly using the KV command for a dynamic secrets engine.

Practice this question →
30
MCQmedium

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?

A.Configure the Kubernetes auth role to use 'token_policies' with a restrictive policy and ensure the bound service account names are correct.
B.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.
C.Add a 'path_deny' capability in the policy for the disallowed paths.
D.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"] }'.
AnswerD

Vault authorises requests through the token's attached policy, not the auth role itself. Editing each role's policy to grant read only on shared-kv/data/team-alpha/* or team-beta/* enforces least privilege, since the existing broad policy currently allows both services to read every path.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that 'path_deny' is a valid capability in Vault ACL policies, when in fact Vault uses default-deny and explicit allow, so candidates incorrectly choose Option C instead of updating the allowed paths.

How to eliminate wrong answers

Option A is wrong because 'token_policies' are already used; the problem is the policy content, not the binding or the policy assignment mechanism. Option B is wrong because creating separate engines is unnecessary and violates the requirement to use the shared 'shared-kv' engine; it also adds administrative overhead without addressing the policy misconfiguration. Option C is wrong because 'path_deny' capabilities are not a valid Vault policy construct; Vault uses explicit allow with 'deny' capabilities only via Sentinel or ACL path-based denial, but the correct approach is to restrict the allowed paths, not add deny rules.

Practice this question →
31
MCQeasy

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?

A.PKI
B.KV v2
C.Transit
D.Database
AnswerC

The transit secrets engine performs cryptographic operations in Vault itself, so plaintext keys never leave the server. Applications submit data for encryption or decryption and receive only the ciphertext or plaintext, satisfying the requirement to never expose the encryption key.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that KV v2 can perform encryption operations because it stores encrypted data, but KV v2 does not provide server-side encryption/decryption APIs—it only stores and retrieves secrets as-is.

How to eliminate wrong answers

Option A is wrong because the PKI secrets engine generates and manages X.509 certificates and private keys, not for encrypting arbitrary data with a hidden key. Option B is wrong because KV v2 stores secrets as plaintext or encrypted at rest, but the client must retrieve the raw secret to use it, exposing the key material. Option D is wrong because the Database secrets engine generates dynamic database credentials (usernames/passwords) and does not provide encryption/decryption operations.

Practice this question →
32
MCQmedium

A security engineer configures the Transit secrets engine at transit/ to encrypt application data. The application must be able to decrypt data but must not be able to create new encryption keys or rotate existing ones. Which policy snippet correctly grants only the required capability for the application's token?

A.path "transit/decrypt/app-key" { capabilities = ["read"] }
B.path "transit/encrypt/app-key" { capabilities = ["update"] }
C.path "transit/keys/app-key" { capabilities = ["read"] }
D.path "transit/decrypt/app-key" { capabilities = ["update"] }
AnswerD

Transit decrypt is a write operation, so the capability must be update (or create, which is also accepted for write operations). Granting update on the decrypt path allows the application to decrypt without granting key creation or rotation, which are separate paths like transit/keys/app-key/rotate.

Why this answer

In the Transit secrets engine, decryption is invoked as a write operation, so the policy must grant update on the transit/decrypt/<key> path. This allows the application to decrypt without granting capabilities on key creation or rotation paths, which are separate and can be restricted independently.

Exam trap

The trap here is assuming that decrypt is a read operation because it returns plaintext, when Vault treats it as a write because the ciphertext travels in the request body.

Practice this question →
33
MCQhard

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?

A.The secret engine at 'secret/' is not enabled.
B.The secret was written to a different path than expected.
C.The token's policy does not cover the path 'secret/team-a/app-config'.
D.The pipeline is using the wrong API path: for KV v2, the path must include '/data/' before the secret path.
AnswerD

KV v2 inserts a mandatory `/data/` segment between the mount and the secret path, so the API endpoint must be `v1/secret/data/team-a/app-config`. The pipeline's request omitted it, hitting a non-existent route and returning 404, despite the policy granting `read` on `secret/data/*`.

Why this answer

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.

Exam trap

The trap here is that candidates confuse the CLI path (which abstracts away the '/data/' prefix) with the raw API path, leading them to think the secret was written to a different path or that the policy is wrong, when the actual issue is the missing '/data/' segment in the API call.

How to eliminate wrong answers

Option A is wrong because the secret engine at 'secret/' is enabled (the DevOps engineer successfully wrote the secret), and the pipeline can read other secrets in the same path, confirming the engine is active. Option B is wrong because the CLI command 'vault kv put secret/team-a/app-config key=value' writes to the correct path under 'secret/data/team-a/app-config', as KV v2 automatically prepends '/data/'. Option C is wrong because the token's policy grants 'read' on 'secret/data/*', which covers the actual path 'secret/data/team-a/app-config', and the pipeline can read other secrets in that path, so the policy is sufficient.

Practice this question →
34
MCQeasy

A developer wants to store an API key for their application in Vault using the key-value secrets engine. They need to be able to retrieve the key and also roll back to a previous version if needed. Which secrets engine configuration should they use?

A.Enable the Transit secrets engine at a custom path
B.Enable the KV v2 secrets engine at a custom path
C.Enable the KV v1 secrets engine at a custom path
D.Enable the Database secrets engine at a custom path
AnswerB

Enabling KV v2 at a custom path satisfies the versioning requirement: KV v2 stores every write as a numbered version, so the developer can retrieve the current API key and roll back to an earlier version via the metadata endpoint. KV v1 offers no version history, making rollback impossible.

Why this answer

The KV v2 secrets engine supports versioning, allowing retrieval of previous versions and rollback capabilities. This directly meets the requirement to store an API key and revert to an older version if needed. KV v1 does not support versioning, while Transit and Database engines serve different purposes (encryption and dynamic credentials, respectively).

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2, where candidates mistakenly assume all KV engines support versioning, or confuse the Transit engine's encryption capabilities with secret storage.

How to eliminate wrong answers

Option A is wrong because the Transit secrets engine is designed for encryption/decryption operations, not for storing secrets with versioning. Option C is wrong because KV v1 secrets engine does not support versioning or rollback; it only stores the latest value. Option D is wrong because the Database secrets engine generates dynamic database credentials, not for storing static API keys with version history.

Practice this question →
35
MCQmedium

A company wants to use Vault to generate IAM users dynamically for each application, following the principle of least privilege. Which secrets engine configuration should they use?

A.Enable AWS engine with a dedicated IAM user (limited permissions) and use 'iam_user' credential type
B.Enable AWS engine with a root IAM user and use 'federation_token' credential type
C.Enable AWS engine with a static access key and use 'iam_user' credential type
D.Enable AWS engine with an IAM role and use 'assumed_role' credential type
AnswerA

The AWS engine's iam_user credential type creates a distinct IAM user per request, with permissions bounded by the role's policy. Pairing it with a limited-permission IAM user for the engine enforces least privilege for each application.

Why this answer

The AWS secrets engine can be configured with a dedicated IAM user that has limited permissions, and by using the 'iam_user' credential type, Vault dynamically creates a new IAM user for each application. This approach adheres to the principle of least privilege by ensuring each application gets a unique set of credentials scoped to its specific needs, without sharing or reusing static keys.

Exam trap

HashiCorp often tests the distinction between dynamic user creation ('iam_user') and temporary credential generation ('federation_token' or 'assumed_role'), where candidates mistakenly choose 'assumed_role' because it is commonly used for temporary access, but it does not create per-application IAM users for granular isolation.

How to eliminate wrong answers

Option B is wrong because using a root IAM user violates security best practices and the principle of least privilege, as root users have unrestricted access; the 'federation_token' credential type generates temporary tokens but still relies on a highly privileged root user. Option C is wrong because using a static access key with the 'iam_user' credential type defeats the purpose of dynamic credential generation, as it reuses the same key across applications, increasing the risk of exposure and violating least privilege. Option D is wrong because the 'assumed_role' credential type generates temporary credentials for an IAM role, which is suitable for cross-account access or role-based scenarios, but it does not create individual IAM users per application, making it less granular for per-application isolation.

Practice this question →
36
MCQhard

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?

A.vault write -f transit/keys/payments/trim min_available_version=2
B.vault write -f transit/keys/payments/rotate
C.vault write transit/keys/payments/config rotation_period=24h
D.vault write transit/keys/payments/rewrap ciphertext=<ciphertext>
AnswerB

The rotate endpoint generates a new key version for the named key and sets it as the current version for future encrypt operations. Existing ciphertext remains decryptable because Vault retains previous key versions and embeds the version in the ciphertext. This command is the supported way to perform key rotation in the Transit secrets engine without re-encrypting all data.

Why this answer

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.

Exam trap

The trap here is confusing automatic rotation configuration with an immediate rotation, or mistaking rewrap for the operation that creates a new key version.

Practice this question →
37
MCQmedium

An application needs to obtain short-lived, time-limited credentials to access an external database using username/password authentication. Which secrets engine should be used?

A.KV v2 secrets engine
B.Database secrets engine
C.Consul secrets engine
D.Identity secrets engine
AnswerB

The database secrets engine dynamically generates unique, short-lived database credentials on demand, then automatically revokes them at lease expiry. This directly satisfies the stem's requirement for time-limited credentials using username/password authentication against an external database, rather than issuing static long-lived passwords that persist until manually rotated.

Why this answer

The Database secrets engine is designed specifically to generate short-lived, dynamic credentials for databases, including external databases accessed via username/password authentication. It creates unique, time-limited usernames and passwords on-the-fly, which are automatically revoked after a configurable TTL, meeting the requirement for temporary credentials.

Exam trap

HashiCorp often tests the distinction between static secret storage (KV) and dynamic secret generation (Database, AWS, etc.), so the trap here is assuming that any secrets engine can produce time-limited credentials, when only engines like Database, AWS, or PKI are designed for dynamic, lease-based credentials.

How to eliminate wrong answers

Option A is wrong because the KV v2 secrets engine stores static secrets (like fixed passwords or API keys) and does not generate dynamic, time-limited credentials; it simply retrieves stored values without any built-in expiration or rotation mechanism. Option C is wrong because the Consul secrets engine generates dynamic credentials for Consul services (e.g., ACL tokens) and is not designed for database username/password authentication. Option D is wrong because the Identity secrets engine manages entity and group identities within Vault, not external database credentials; it handles aliases and policies, not dynamic secret generation.

Practice this question →
38
MCQeasy

A platform team wants to provide applications with short-lived AWS credentials that are automatically revoked when their lease expires, without managing long-term IAM users. They also need to allow the applications to assume a role for cross-account access. Which secrets engine should the team enable and configure?

A.The AWS secrets engine with an IAM user type role
B.The AWS secrets engine with an access key type role
C.The AWS secrets engine with a federation token type role
D.The AWS secrets engine with an assumed role type role
AnswerD

The assumed role type uses STS AssumeRole to issue temporary credentials that automatically expire with the lease, and it supports cross-account access when the role's trust policy allows it. This matches both the short-lived requirement and the cross-account assumption need without creating persistent IAM users.

Why this answer

The AWS secrets engine's assumed_role credential type issues STS temporary credentials by assuming a role, so leases expire naturally and cross-account access works when the target role trusts the Vault-provided identity. This avoids the operational overhead of IAM user creation and deletion while supporting the cross-account pattern described.

Exam trap

The trap here is conflating IAM user creation with role assumption, when only the assumed_role credential type provides STS temporary credentials suitable for cross-account access.

Practice this question →
39
MCQmedium

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?

A.The read returns a 404 with 'no value found' because the latest version is soft-deleted and no data is returned by default.
B.The read returns the previous version of the secret because soft-delete only marks the latest version as deleted.
C.The read returns a permission denied error because the developer lacks the 'undelete' capability on the path.
D.The read returns the data normally because soft delete only takes effect after a subsequent write operation.
AnswerA

In KV v2, `vault kv delete` performs a soft delete that marks the latest version as deleted. Subsequent reads of the path return HTTP 404 with no data unless a specific non-deleted version is requested. The secret data remains recoverable, but the default read does not surface it, matching the observed 404 behavior.

Why this answer

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.

Exam trap

The trap here is assuming that a soft delete behaves like a hard destroy and permanently removes the data, or conversely that a normal read still returns the deleted value.

Practice this question →
40
Multi-Selecthard

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

Select 2 answers
A.vault secrets enable -custom-path=my-aws aws
B.vault write sys/mounts/my-aws type=aws
C.vault secrets enable -path=my-aws aws
D.vault secrets enable -mount-path=my-aws aws
E.vault secrets enable my-aws aws
AnswersB, C

Writing to `sys/mounts/my-aws` with `type=aws` enables the AWS secrets engine at the custom path `my-aws`, satisfying the non-default path constraint. The mount path is the final segment of the endpoint, so this registers the engine there rather than at the default `aws` location.

Why this answer

Option B is correct because writing directly to the sys/mounts/<path> endpoint with type=<engine> is the underlying API operation that enables a secrets engine at a custom path, so `vault write sys/mounts/my-aws type=aws` mounts the AWS engine at my-aws. Option C is correct because the CLI `vault secrets enable` command accepts the `-path` flag to specify a non-default mount path, so `vault secrets enable -path=my-aws aws` enables the AWS secrets engine at my-aws. Option A is incorrect because `-custom-path` is not a valid flag for `vault secrets enable`.

Option D is incorrect because `-mount-path` is not a recognized flag; the correct flag is `-path`. Option E is incorrect because `vault secrets enable my-aws aws` passes my-aws as the engine type rather than a path, and the CLI does not accept a positional path argument in that form.

Exam trap

Vault's CLI supports two distinct methods for enabling secrets engines: the higher-level 'vault secrets enable' command and the lower-level 'vault write' on the sys/mounts endpoint. The exam often tests whether candidates know both methods and the correct flag names.

Practice this question →
41
MCQmedium

A developer needs to generate a new certificate for an internal web service using the PKI secrets engine. A role named 'webserver' has been created. What is the correct command to issue the certificate?

A.vault write pki/webserver/issue
B.vault write pki/webserver/cert common_name=web.example.com
C.vault read pki/cert/webserver
D.vault write pki/issue/webserver common_name=web.example.com
AnswerD

Issuing through pki/issue/<role> uses the named role's parameters to generate a certificate and private key, returning them directly. This satisfies the scenario because the webserver role supplies the configuration and common_name sets the requested identity.

Why this answer

The PKI secrets engine uses the path `pki/issue/<role_name>` to issue certificates. The `vault write` command sends a POST request to this endpoint with the required `common_name` parameter, which generates a new certificate signed by the CA associated with the 'webserver' role.

Exam trap

HashiCorp often tests the exact API path structure, where candidates mistakenly assume the role name is part of the path before 'issue' (e.g., `pki/role/issue`) or confuse the issue endpoint with the read endpoint for existing certificates.

How to eliminate wrong answers

Option A is wrong because `pki/webserver/issue` is not a valid endpoint; the correct path is `pki/issue/webserver`. Option B is wrong because `pki/webserver/cert` is not a valid endpoint for issuing certificates; it incorrectly appends 'cert' to the role name. Option C is wrong because `vault read pki/cert/webserver` retrieves an existing certificate by serial number or ID, not issue a new one, and 'webserver' is a role name, not a certificate identifier.

Practice this question →
42
Drag & Dropmedium

Drag and drop the steps to configure Vault's database secrets engine with PostgreSQL into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence for configuring Vault's database secrets engine with PostgreSQL is: first enable the secrets engine, then configure the database connection, then create a role that defines the credential generation parameters, then generate credentials, and finally revoke the lease when done. This order ensures all prerequisites are met at each step.

Practice this question →
43
MCQmedium

A platform team stores application configuration and credentials in a KV v2 secrets engine mounted at 'kv/'. A developer deleted version 3 of the secret 'kv/app/db' by running 'vault kv delete kv/app/db'. Two days later, the security team asks the developer to recover that version because it contained a valid certificate. The developer runs 'vault kv get -version=3 kv/app/db' and receives an error that the version has been deleted. What must the developer do to recover version 3?

A.Run 'vault kv rollback -version=3 kv/app/db' to revert the secret to version 3.
B.Run 'vault kv metadata get kv/app/db' to retrieve the deleted version from metadata.
C.Run 'vault kv undelete -versions=3 kv/app/db' to restore the deleted version.
D.Run 'vault kv patch kv/app/db' to restore the missing version from the patch history.
AnswerC

The 'vault kv undelete' command restores soft-deleted versions of a KV v2 secret. Because a delete operation on KV v2 only marks the version as deleted rather than destroying it, running undelete with the specific version number makes version 3 readable again via 'vault kv get -version=3'. This is the designed recovery path for accidental deletes within the retention window.

Why this answer

In KV v2, a delete operation is a soft delete that marks a version as deleted but keeps the data until it is destroyed or removed by the 'delete_version_after' setting. The 'vault kv undelete' command reverses that soft delete for the specified versions, making the data readable again. Rollback and patch both create new versions instead of restoring the old one, and metadata get only returns metadata.

Exam trap

The trap here is confusing soft delete with permanent destruction, leading to the belief that a deleted KV v2 version can only be recovered by writing the data again or that undelete is unavailable.

Practice this question →
44
MCQeasy

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?

A.The PKI secrets engine
B.The Transit secrets engine
C.The KV v2 secrets engine
D.The database secrets engine
AnswerD

The database secrets engine generates dynamic database credentials by connecting to the database and creating users based on role configuration. It supports creation and revocation statements, lease management, and multiple database plugins including MySQL. This matches the requirement for short-lived, dynamically generated credentials for an external MySQL database.

Why this answer

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.

Exam trap

The trap here is assuming that storing a database password in KV v2 is equivalent to dynamic credential generation, when it only provides static secrets.

Practice this question →
45
MCQmedium

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?

A.vault write pki/root/generate/internal common_name="Internal Intermediate CA"
B.vault write pki/intermediate/set-signed certificate=@intermediate.crt
C.vault write pki/intermediate/generate/exported common_name="Internal Intermediate CA"
D.vault write pki/intermediate/generate/internal common_name="Internal Intermediate CA"
AnswerD

The generate/internal endpoint creates a new private key and CSR inside Vault, storing the private key securely and returning the CSR for the offline root to sign. This matches the requirement that the intermediate key never leaves Vault, enabling the root CA to remain air-gapped while still establishing a chain of trust.

Why this answer

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.

Exam trap

The trap here is assuming that any generate endpoint produces a CSR, when only the internal variant keeps the private key inside Vault while the exported variant deliberately returns it.

Practice this question →
46
MCQmedium

A team is adopting Vault and wants to organize secrets by application and environment (e.g., production, staging). What is the best practice for secrets engine path naming?

A.Use hierarchical paths like 'app/env/secret'
B.Use a single path like 'secrets/' for simplicity
C.Use the same path for all applications but separate with prefixes like 'app1-'
D.Use random UUIDs to avoid guessing
AnswerA

Hierarchical paths such as 'app/env/secret' map directly onto Vault's path-based policy model, letting each application-environment pair receive a distinct ACL boundary. This satisfies the stem's requirement to organise secrets by both application and environment, since policies and audit logs can then be scoped precisely to, say, 'payments/production/*' without overlapping other environments.

Why this answer

Hierarchical paths like 'app/env/secret' are the best practice because they allow Vault's ACL policies to apply fine-grained access control at each level of the path. This structure maps directly to the organization's application and environment boundaries, enabling least-privilege access without complex policy rules. It also simplifies secret rotation and auditing by keeping related secrets logically grouped.

Exam trap

HashiCorp often tests the misconception that flat or prefix-based naming is simpler and therefore better, but the trap is that Vault's ACL engine is path-based and hierarchical paths are required for proper policy isolation and least-privilege access control.

How to eliminate wrong answers

Option B is wrong because using a single flat path like 'secrets/' prevents any granular access control; all policies would apply to the entire path, violating the principle of least privilege. Option C is wrong because using prefixes like 'app1-' on a shared path still forces all secrets under one policy scope, making it impossible to restrict access to specific applications or environments without cumbersome regex-based policies. Option D is wrong because random UUIDs make secrets unmanageable and impossible to organize by application or environment; they also break the human-readable path structure that Vault policies rely on for clear, maintainable access rules.

Practice this question →
47
MCQmedium

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?

A.Enable the database secrets engine and configure role-based dynamic credential generation
B.Use the transit secrets engine to encrypt the static credentials and distribute them
C.Use the PKI secrets engine to issue certificates for database authentication
D.Store the credentials in KV v2 and have each instance read them
AnswerA

Configuring the database secrets engine with role-based dynamic credential generation lets Vault mint a unique username/password pair per instance on demand, each tied to a lease that expires automatically. This satisfies the frequent-instance, time-limited and minimal-overhead constraints, since no static credentials are stored or rotated manually.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (database secrets engine) versus those that manage static secrets (KV v2) or provide encryption (transit) or certificates (PKI), leading candidates to confuse the purpose of each engine.

How to eliminate wrong answers

Option B is wrong because the transit secrets engine is used for encryption/decryption of data in transit, not for generating dynamic credentials; encrypting static credentials still requires manual rotation and does not provide unique, time-limited pairs per instance. Option C is wrong because the PKI secrets engine issues X.509 certificates for TLS/mTLS authentication, not username/password pairs, and database authentication typically does not use certificates unless the database supports certificate-based auth (e.g., MySQL with SSL), which is not the stated requirement. Option D is wrong because storing credentials in KV v2 (Key-Value version 2) provides static secrets that must be manually rotated and shared across instances, failing to deliver unique, time-limited credentials and increasing operational overhead for credential management.

Practice this question →
48
MCQmedium

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?

A.Key versioning
B.Key derivation
C.Key ttl
D.Convergent encryption
AnswerA

Key versioning lets the Transit secrets engine retain prior key versions, so ciphertext keeps a reference to the version that encrypted it. New writes use the latest version, while existing files decrypt under their original version — satisfying rotation without re-encrypting stored data.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between key rotation (which preserves access to old ciphertext via versioning) and key expiration (which invalidates the key entirely), leading candidates to confuse 'key ttl' with a rotation mechanism.

How to eliminate wrong answers

Option B (Key derivation) is wrong because key derivation is a process that generates a unique encryption key per input plaintext using a key derivation function (KDF), but it does not provide a mechanism to rotate the master key without re-encrypting existing data. Option C (Key ttl) is wrong because key TTL (time-to-live) sets an expiration time for a key, but it does not enable rotation without re-encryption; once the TTL expires, the key becomes unusable, forcing re-encryption if the data must remain accessible. Option D (Convergent encryption) is wrong because convergent encryption derives the encryption key from the hash of the plaintext, making it deterministic and unsuitable for key rotation—changing the key would break the ability to decrypt existing ciphertext.

Practice this question →
49
MCQmedium

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?

A.24h
B.72h
C.48h
D.48h if allowed_domains matches, else error
AnswerC

The requested 48h falls below the role's max_ttl ceiling of 72h, so Vault issues the certificate with the shorter value. allow_any_name only governs name validation, not duration; it does not override the TTL constraint. The effective TTL is therefore the requested 48h, satisfying the max_ttl limit.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that `max_ttl` overrides a shorter requested TTL, leading candidates to pick the max_ttl value (72h) instead of understanding that the requested TTL is honored if it is within the limit.

How to eliminate wrong answers

Option A is wrong because 24h would only result if the requested TTL were subtracted from max_ttl or if a default TTL were applied, but no such subtraction or default is specified; the role's max_ttl is an upper limit, not a deduction. Option B is wrong because 72h is the max_ttl, but the user explicitly requested a shorter TTL (48h), and the PKI role honors the requested TTL as long as it does not exceed max_ttl. Option D is wrong because `allow_any_name=true` bypasses the `allowed_domains` check entirely, so no matching is required; the certificate is issued regardless of domain, and the TTL remains 48h.

Practice this question →
50
Multi-Selecthard

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

Select 3 answers
A.Create a role that maps to the database user and permissions
B.Configure a policy to allow users to read credentials from the role
C.Configure the database connection with connection details and credentials
D.Tune the engine's default TTL
E.Enable the database secrets engine
AnswersA, C, E

Creating a role maps Vault's dynamic credential generation to a specific database user template and permission set, satisfying the requirement to define what credentials are issued. Without a role, the database secrets engine has no blueprint for creating users, so this step is mandatory for generating dynamic credentials.

Why this answer

Option E is correct because the database secrets engine must first be enabled (e.g., `vault secrets enable database`) before any connections or roles can be created. Option C is correct because you must configure a database connection (`vault write database/config/<name>`) with the plugin, connection URL, and privileged credentials Vault uses to create dynamic users. Option A is correct because a role (`vault write database/roles/<name>`) defines the SQL statements and mappings that generate the dynamic credentials with the appropriate permissions.

Option B is not required for generating credentials, since it only governs authorization to read them, and Option D is optional tuning rather than a required configuration step.

Exam trap

HashiCorp often tests the distinction between required configuration steps and optional or subsequent steps, so the trap here is that candidates mistakenly include tuning TTL or writing policies as mandatory steps when they are not part of the core three-step configuration sequence (enable, configure connection, create role).

Practice this question →
51
MCQhard

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

A.KV v3
B.KV v1
C.KV v2
D.Transit secrets engine
AnswerC

KV v2 stores secret metadata alongside data, retaining a configurable number of prior versions per secret. This directly satisfies the rollback requirement: `vault kv rollback` or reading `secret/data/<path>?version=N` restores an earlier value. KV v1 overwrites in place with no version history, so it cannot meet the stem's constraint.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that KV v3 exists or that the Transit secrets engine can handle versioned secret storage, leading candidates to choose those incorrect options.

How to eliminate wrong answers

Option A is wrong because KV v3 does not exist in Vault; the KV secrets engine has only two versions (v1 and v2). Option B is wrong because KV v1 stores secrets without versioning, so it cannot support rollback to previous values. Option D is wrong because the Transit secrets engine is used for encryption as a service, not for storing secrets with versioning capabilities.

Practice this question →
52
MCQmedium

A cloud operations team needs to provide temporary, dynamically generated credentials for an AWS IAM user to a CI/CD pipeline. The credentials must be automatically revoked when the lease expires. They have configured the AWS secrets engine at 'aws/' with root credentials. Which configuration step is required to allow the pipeline to assume a specific IAM role and receive credentials?

A.Create a role with credential_type=federation_token and specify the role ARN in the policy document.
B.Create a role in the AWS secrets engine that specifies the credential type as 'assumed_role' and provides the ARN of the IAM role.
C.Create a role with credential_type=assumed_role and set the policy_arns parameter to the ARN of the IAM role.
D.Create a role with credential_type=iam_user and attach a policy that allows sts:AssumeRole.
AnswerB

For the AWS secrets engine to generate credentials that assume an IAM role, you must create a role with credential_type=assumed_role and provide the role_arns parameter. This allows Vault to call STS AssumeRole and return temporary credentials. The other options either use static credentials or incorrect parameters, and do not fulfill the dynamic credential requirement with automatic revocation.

Why this answer

To generate temporary credentials that assume a specific IAM role, the AWS secrets engine role must have credential_type set to 'assumed_role' and include the role_arns parameter with the ARN of the target role. This leverages AWS STS AssumeRole, producing credentials that automatically expire with the lease. Other credential types produce different kinds of credentials that do not meet the dynamic, role-assuming requirement.

Exam trap

The trap here is mixing up the parameters for specifying a role ARN versus attaching policies; the role_arns parameter is required to assume a role, while policy_arns is for attaching policies to generated users or sessions.

Practice this question →
53
MCQeasy

An organization wants to encrypt data in transit and at rest using a centralized key management system. Which secrets engine is designed for encryption/decryption operations without storing data?

A.KV secrets engine
B.PKI secrets engine
C.Database secrets engine
D.Transit secrets engine
AnswerD

The transit secrets engine performs cryptographic operations on data supplied by clients, returning ciphertext without persisting it, satisfying the requirement for encryption in transit and at rest via centralized key management. Keys remain inside Vault, so applications never handle raw key material directly.

Why this answer

The Transit secrets engine performs encryption/decryption operations on data in transit without storing the data itself. It is designed for centralized key management, allowing applications to send plaintext for encryption or ciphertext for decryption via API calls, while the keys remain securely managed within Vault. This makes it ideal for encrypting data in transit and at rest without persisting the data.

Exam trap

HashiCorp often tests the distinction between storing data (KV) and encrypting data (Transit), where candidates mistakenly choose KV because they associate 'encryption at rest' with storage, but Transit is the correct engine for performing encryption operations without storing the data.

How to eliminate wrong answers

Option A is wrong because the KV secrets engine stores secrets as key-value pairs and is not designed for encryption/decryption operations; it stores data at rest but does not provide cryptographic operations. Option B is wrong because the PKI secrets engine generates and manages X.509 certificates for TLS/SSL, not for generic encryption/decryption of data. Option C is wrong because the Database secrets engine generates dynamic database credentials (e.g., usernames/passwords) and does not perform encryption/decryption of arbitrary data.

Practice this question →
54
MCQeasy

An organization needs to automatically issue X.509 certificates for internal services. Which secrets engine should they use?

A.SSH secrets engine
B.Cert secrets engine
C.Transit secrets engine
D.PKI secrets engine
AnswerD

The PKI secrets engine generates X.509 certificates on demand, signing them against a configured CA or intermediate, so internal services receive short-lived certificates automatically rather than through manual issuance. This directly satisfies the requirement for automatic certificate issuance, unlike static key-value storage or transit encryption, which cannot produce certificates.

Why this answer

The PKI secrets engine is specifically designed to generate X.509 certificates for internal services. It acts as a certificate authority (CA), handling certificate signing requests (CSRs), issuing certificates with configurable lifetimes, and managing revocation via CRLs or OCSP. This directly meets the requirement for automated certificate issuance.

Exam trap

HashiCorp often tests the distinction between the Transit secrets engine (encryption operations) and the PKI secrets engine (certificate issuance), leading candidates to confuse 'encryption' with 'certificate generation'.

How to eliminate wrong answers

Option A is wrong because the SSH secrets engine is designed to manage SSH credentials (client and host keys) and automate SSH access, not to issue X.509 certificates. Option B is wrong because the Cert secrets engine is a deprecated alias for the PKI secrets engine in older Vault versions; the current and correct name is PKI, and using 'Cert' implies an incorrect or outdated reference. Option C is wrong because the Transit secrets engine performs encryption/decryption operations as a service (encryption as a service) and does not generate or manage X.509 certificates.

Practice this question →
55
MCQeasy

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

A.Store secrets encrypted by the Transit engine
B.Store secrets that are isolated per token
C.Store secrets that are replicated across clusters
D.Store secrets with high availability
AnswerB

The cubbyhole secrets engine stores data scoped strictly to the token that wrote it; no other token, even with identical policies, can read those secrets. This satisfies the scenario by providing per-token isolated storage that is destroyed when the token expires.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between cubbyhole and the KV (Key-Value) engine, where candidates mistakenly think cubbyhole provides replication or persistence, but the trap is that cubbyhole is purely token-scoped and ephemeral, not a general-purpose secrets store.

How to eliminate wrong answers

Option A is wrong because the Transit engine handles encryption as a service (encrypt/decrypt data without storing it), while cubbyhole stores raw secrets per token. Option C is wrong because cubbyhole is explicitly not replicated across clusters; it is local to the token and does not participate in Performance or DR replication. Option D is wrong because cubbyhole provides no high availability guarantees; it is a single-token, non-durable store that vanishes with the token.

Practice this question →
56
MCQeasy

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?

A.The database secrets engine is not enabled at the expected path; the role is pointing to a different engine.
B.The application is not using a valid token to authenticate to Vault, so the request is rejected.
C.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.
D.The TTL values are too short; applications are requesting new credentials too frequently and exhausting a hidden limit. Increase the TTL.
AnswerC

The role's `max_leases` parameter caps how many concurrent leases the database secrets engine will issue for that role. With a low value such as 5, each application's credential request consumes a lease until the cap is hit, producing "No more available leases on this role". Raising `max_leases` restores issuance; TTL settings are irrelevant here.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between TTL-based limits and lease-count limits; the trap here is that candidates confuse 'max_ttl' (maximum duration of a lease) with 'max_leases' (maximum number of concurrent leases), leading them to incorrectly adjust TTL values instead of the lease count parameter.

How to eliminate wrong answers

Option A is wrong because if the secrets engine were not enabled at the expected path, the error would be something like 'path not found' or 'no handler for route', not a lease exhaustion error. Option B is wrong because an invalid token would result in a 'permission denied' or 'token not found' error, not a lease-specific error. Option D is wrong because increasing TTL would actually reduce the frequency of lease creation, not solve the exhaustion of a fixed lease count; the error is about a limit on the number of concurrent leases, not their duration.

Practice this question →
57
MCQhard

Refer to the exhibit. An application uses this policy to access Vault. The application is able to read database credentials from `database/creds/my-role`. However, attempts to list all roles at `database/roles/` fail. What is the most likely cause?

A.The path `database/roles/` is not a valid path for listing roles
B.The database secrets engine is not enabled
C.The policy does not allow the 'list' capability on the path `database/roles/`
D.The application needs the 'sudo' capability to list roles
AnswerC

Reading credentials at `database/creds/my-role` requires only the `read` capability, which the policy grants. Listing `database/roles/` is a distinct operation requiring the `list` capability on that exact path; Vault denies it because no policy rule grants `list` there, regardless of `read` access elsewhere.

Why this answer

The policy grants 'read' capability on `database/creds/my-role` but does not include the 'list' capability on `database/roles/`. In Vault, listing requires an explicit 'list' capability in the policy, even if 'read' is allowed on sub-paths. Without 'list', the API call to `LIST database/roles/` returns a permission denied error.

Exam trap

HashiCorp often tests the distinction between 'read' and 'list' capabilities, trapping candidates who assume that read access on sub-paths implies the ability to list the parent path.

How to eliminate wrong answers

Option A is wrong because `database/roles/` is a valid path for listing roles when the database secrets engine is enabled; Vault uses a standard endpoint for listing. Option B is wrong because the application can read credentials from `database/creds/my-role`, which proves the database secrets engine is enabled and mounted. Option D is wrong because the 'sudo' capability is not required for listing roles; 'sudo' is used for privileged operations like modifying policies or enabling engines, not for standard listing.

Practice this question →
58
MCQhard

An organization uses the AWS secrets engine to generate IAM users for each application. They want to ensure that if a Vault server is compromised, the attacker cannot use the AWS secrets engine configuration to gain access to the AWS account. Which additional security measure should be implemented?

A.Enable Vault's seal wrapping to encrypt the engine configuration
B.Store the AWS access key used by the engine in a separate Vault instance
C.Use a dedicated Vault server for the AWS engine
D.Use a non-root IAM user with minimal privileges for the engine and restrict the engine's role policies to the minimum needed
AnswerD

The engine's own AWS credentials define the blast radius if Vault is compromised. Using a non-root IAM user with minimal privileges, plus tightly scoped role policies, limits what an attacker could do with the engine configuration.

Why this answer

The core principle of least privilege ensures that even if the Vault server is compromised, the attacker can only perform actions allowed by the minimal IAM policy attached to the non-root user. This limits the blast radius, preventing the attacker from gaining full administrative access to the AWS account. The AWS secrets engine uses the configured IAM credentials to create temporary IAM users, so restricting those credentials to only the necessary permissions is the most effective mitigation.

Exam trap

HashiCorp often tests the misconception that encryption or isolation (seal wrapping, separate instances) is sufficient to protect against credential abuse, when in reality the underlying IAM permissions are the critical control.

How to eliminate wrong answers

Option A is wrong because seal wrapping encrypts the engine configuration at rest and in transit, but it does not limit the permissions of the underlying AWS credentials; if the Vault server is compromised, the attacker can still use the decrypted credentials to perform any action allowed by the IAM policy. Option B is wrong because storing the AWS access key in a separate Vault instance does not prevent an attacker who compromises the primary Vault server from using the engine's configuration to call the AWS API; the attacker would still have access to the credentials via the engine's storage backend. Option C is wrong because using a dedicated Vault server for the AWS engine does not reduce the risk; if that dedicated server is compromised, the attacker still has full access to the AWS credentials configured in the engine.

Practice this question →
59
Multi-Selectmedium

Which TWO of the following are valid use cases for the Transit secrets engine? (Select exactly 2.)

Select 2 answers
A.Signing and verifying data
B.Encrypting data in transit without exposing the encryption key
C.Storing encryption keys
D.Storing encrypted data at rest
E.Managing X.509 certificates
AnswersA, B

The Transit secrets engine performs cryptographic operations on data in transit without storing it, so signing and verifying data is a core capability. It satisfies the stem's requirement for a valid use case by handling signing and verification through named encryption keys, keeping plaintext outside Vault entirely.

Why this answer

Option A is correct because the Transit secrets engine provides cryptographic operations as a service, including signing and verifying data via endpoints such as /transit/sign/:name and /transit/verify/:name, so applications can perform signature operations without handling raw signing keys. Option B is correct because Transit supports encryption and decryption through endpoints like /transit/encrypt/:name and /transit/decrypt/:name, allowing data to be encrypted in transit while the encryption key never leaves Vault. Option C is not the intended use case because Transit does not serve as a general-purpose key store; key storage is handled by other engines such as KV or by Vault's key management features, and Transit keys are used for cryptographic operations rather than being retrieved.

Option D is incorrect because Transit does not store encrypted data at rest; it only performs encryption/decryption operations, while data storage belongs to engines like KV. Option E is incorrect because X.509 certificate management is handled by the PKI secrets engine, not the Transit secrets engine.

Exam trap

HashiCorp often tests the distinction between 'performing cryptographic operations' (Transit) and 'storing secrets or keys' (KV), so the trap here is that candidates confuse the Transit engine's ability to store keys internally with the use case of storing keys for external retrieval.

Practice this question →
60
Multi-Selecteasy

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

Select 2 answers
A.Supports federation via SAML with Azure AD
B.Provides native integration with Azure Key Vault for key management
C.Allows connection to AWS via IAM instance profiles
D.Can generate IAM users with custom policies
E.Can generate STS temporary credentials for cross-account access
AnswersD, E

The AWS secrets engine can mint IAM users, attaching custom policies that scope permissions per credential. The Azure secrets engine issues service principals and role assignments instead, so per-request custom policy generation is unique to AWS.

Why this answer

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 Azure AD 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.

Exam trap

HashiCorp often tests the distinction between the AWS and Azure secrets engines, and the trap here is confusing the AWS engine's ability to generate IAM users and STS tokens with Azure-specific features like SAML federation or Key Vault integration.

Practice this question →
61
MCQmedium

A security engineer is enabling the Transit secrets engine at the path 'transit/'. They need to encrypt data without ever exposing the plaintext key material to the application, and they want the ciphertext to be safely stored in an external database. They also require the ability to rotate the encryption key periodically without re-encrypting existing data. Which command correctly configures a new encryption key named 'orders' for this purpose?

A.vault write -f transit/keys/orders
B.vault write transit/encrypt/orders plaintext=$(base64 <<< "my secret")
C.vault write transit/keys/orders type=rsa-2048
D.vault secrets enable -path=orders transit
AnswerA

This command creates a named encryption key in the Transit secrets engine at the path transit/keys/orders. The -f flag forces the write without requiring data, which is appropriate because the key is generated by Vault. The key can then be used for encrypt/decrypt operations, and Vault manages the key material internally, supporting rotation and versioning without exposing plaintext.

Why this answer

The Transit secrets engine centralizes encryption as a service, allowing applications to encrypt data without managing keys. To create a new named encryption key, the correct command is 'vault write -f transit/keys/orders', which generates a key of the default type (aes256-gcm96) and enables encryption, decryption, and rotation. This satisfies the requirement of not exposing key material and supporting future rotation.

Exam trap

The trap here is confusing the command to enable a secrets engine with the command to create a key within an already enabled engine.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Compare and configure secrets engines questions.

Start 20-question session