Knowledge + Practice

CCNA Compare and configure secrets engines Questions

75 of 78 questions · Page 1/2 · Compare and configure secrets engines · Answers revealed

Practice these questions Domain overview All questions

1

Multi-Selecteasy

Which TWO of the following are correct statements about Vault secrets engines?

Select 2 answers

A.Secrets engines are enabled at a path, and each engine can be mounted at multiple paths.

B.The Transit secrets engine performs encryption operations without storing the encrypted data.

C.Dynamic secrets engines generate credentials on demand and have a Time-to-Live (TTL).

D.The KV secrets engine can be configured to store both versioned and unversioned data simultaneously.

E.Static secrets engines do not support rotation.

AnswersB, C

Transit acts as an encryption service; it stores keys but not the data payloads.

Why this answer

The Transit secrets engine performs encryption operations such as encrypt, decrypt, sign, and verify without storing the encrypted data. Option C is correct: dynamic secrets engines (e.g., database, AWS) generate credentials on demand with a configurable Time-to-Live (TTL). Option A is incorrect because each secrets engine instance is mounted at a single path; however, the same engine type can be enabled at multiple paths.

Option D is incorrect because a KV engine is either version 1 (unversioned) or version 2 (versioned), not both simultaneously. Option E is incorrect because static secrets, such as database static roles, do support rotation to rotate passwords periodically.

Practice this question →

2

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

Transit encrypts/decrypts data without exposing keys.

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 →

3

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 the oldest version that needs to be decryptable resolves the issue.

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 →

4

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

The engine must be enabled at a path (e.g., database/) before use.

Why this answer

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

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 →

5

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 supports CAS using the cas parameter.

Why this answer

KV v2 supports check-and-set (CAS) operations via the `cas` parameter in the write path. CAS ensures that a write only succeeds if the current version matches the expected value, preventing concurrent overwrites and providing optimistic locking for secret updates.

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 →

6

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

An error in the revocation statement causes failure to revoke.

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 →

7

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 can automatically renew leases and manage secrets lifecycle.

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 →

8

Multi-Selectmedium

Which THREE operations does the transit secrets engine support?

Select 3 answers

A.Generate a new key in an external KMS

B.Generate a hash using SHA256

C.Encrypt data using a named key

D.Rewrap ciphertext to a new key version

E.Decrypt data using a named key

AnswersC, D, E

Transit provides encryption as a service.

Why this answer

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

Exam trap

HashiCorp often tests the exact set of supported hash algorithms in the transit engine, and candidates mistakenly assume SHA256 is included when it is not, leading them to select option B incorrectly.

Practice this question →

9

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

Generates dynamic credentials on the fly for databases like MySQL, PostgreSQL, etc.

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 →

10

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 supports versioning and rollback of secrets.

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 →

11

MCQmedium

A company is using the PKI secrets engine to issue certificates for internal services. They want to ensure that certificates are automatically revoked if a service is decommissioned. What should they implement?

A.Implement certificate pinning in all services.

B.Use Vault's built-in lifecycle management and revocation capabilities.

C.Set a very short TTL on certificates so they expire quickly.

D.Configure a Certificate Revocation List (CRL) that clients check.

AnswerB

Vault can revoke certificates via API or when lease expires.

Why this answer

Vault's PKI secrets engine includes built-in lifecycle management that can automatically revoke certificates when a lease expires or when a secret is deleted via the API. This allows you to tie certificate validity to the service's lifecycle in Vault, ensuring decommissioned services have their certificates revoked without manual intervention.

Exam trap

The trap here is that candidates confuse passive revocation mechanisms (like CRLs or short TTLs) with active, automated revocation, assuming that expiration or client-side checks are sufficient for decommissioning scenarios.

How to eliminate wrong answers

Option A is wrong because certificate pinning is a security mechanism to prevent man-in-the-middle attacks by hardcoding certificates, not a method for automatic revocation upon decommissioning. Option C is wrong because setting a very short TTL only forces certificates to expire quickly, but does not actively revoke them; expired certificates may still be accepted by clients that do not validate expiration, and this approach does not handle immediate revocation needs. Option D is wrong because a Certificate Revocation List (CRL) is a passive distribution mechanism that clients must fetch and check; it does not automate the revocation trigger when a service is decommissioned, and relies on clients to enforce revocation.

Practice this question →

12

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

This ensures even if a role requests a long TTL, it cannot exceed the mount limit.

Why this answer

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

Practice this question →

13

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

List operations in KV v2 are on the metadata path.

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 →

14

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

Correct syntax: enable kv-v2 at custom path.

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 →

15

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

Database secrets engine is specifically designed to generate dynamic credentials for databases like MySQL, PostgreSQL, etc.

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 →

16

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

This enforces least privilege for each service.

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 →

17

MCQhard

A financial services company runs a mixed environment of on-premises and cloud workloads. They use Vault Enterprise with performance replication across two data centers: primary in us-east and secondary in eu-west. The secrets engine configuration includes KV v2 for static secrets, database engine for PostgreSQL credentials, and transit for encryption. Recently, the operations team noticed that after a network partition between the data centers, the secondary cluster stopped serving read requests for database credentials, although other secrets like KV v2 were still accessible. The team confirmed that the replication status shows 'secondary' and the cluster is healthy. The Vault configuration uses a single replication path filter that includes all mounts. What is the most likely reason for the database credentials not being available on the secondary?

A.The replication path filter excludes the database engine mount.

B.The secondary cluster has a network issue preventing it from connecting to the database.

C.The secondary cluster is configured to only serve static secrets.

D.Dynamic secrets are not replicated; the secondary cannot generate credentials if the primary is unreachable.

AnswerD

Performance replication replicates configuration, not leases or dynamic secrets.

Why this answer

In Vault Enterprise, performance replication replicates static data (like KV v2 secrets) but does not replicate dynamic secrets such as database credentials. Dynamic secrets are generated on-demand by the primary cluster; the secondary cluster cannot generate them if the primary is unreachable because it lacks the ability to create new leases or credentials. This is why database credentials were unavailable on the secondary after the network partition, while static KV v2 secrets remained accessible.

Exam trap

HashiCorp often tests the misconception that all secrets engines behave identically under replication, but the trap here is that dynamic secrets require primary availability for generation, unlike static secrets which are fully replicated and available on secondaries.

How to eliminate wrong answers

Option A is wrong because the replication path filter includes all mounts, so the database engine mount is not excluded. Option B is wrong because the secondary cluster is healthy and serving other secrets, indicating no network issue to the database itself; the problem is with credential generation, not connectivity. Option C is wrong because the secondary cluster is not configured to serve only static secrets; it can serve all replicated data, but dynamic secrets require primary reachability for generation.

Practice this question →

18

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 is the current standard for static secrets storage, with versioning and delete protection.

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 →

19

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 full Amazon Resource Name of the IAM role to assume.

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 →

20

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

Soft delete allows undelete unless destroyed.

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 →

21

Multi-Selectmedium

An administrator is configuring the Transit secrets engine for encryption as a service. Which TWO configuration options are valid?

Select 2 answers

A.Using the engine to generate one-time passwords

B.Configuring the engine to export the key in plaintext

C.Enabling automatic key derivation per context

D.Setting the encryption key rotation period

E.Setting a TTL on the key itself

AnswersC, D

You can enable derived keys so that each context gets a unique encryption key.

Why this answer

The Transit secrets engine supports key derivation, which allows a base key to be combined with a user-supplied context value to generate a unique encryption key per context. This enables multiple parties to use the same base key while deriving distinct keys for different data sets, enhancing security without managing separate keys. Option D is correct because the Transit engine allows administrators to set a rotation period for encryption keys, automatically rotating the key after a specified interval to comply with cryptographic best practices.

Exam trap

HashiCorp often tests the distinction between key rotation (which is supported) and key TTL (which is not), leading candidates to incorrectly assume that keys have an expiration time like tokens or leases.

Practice this question →

22

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 must trust the database server's certificate; otherwise x509 error occurs.

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 →

23

MCQeasy

A team wants to store configuration data such as feature flags in Vault. They need to be able to list all keys under a path. Which secrets engine supports listing?

A.Transit

B.KV v1

C.Cubbyhole

D.PKI

AnswerB

KV v1 supports LIST operation on paths.

Why this answer

The KV v1 secrets engine stores key-value pairs and supports listing all keys under a path via the LIST operation (e.g., `vault list secret/`). This is because KV v1 maintains a flat, non-versioned directory structure that allows enumeration of keys. The team's requirement to list all keys under a path is directly satisfied by KV v1's inherent listing capability.

Exam trap

HashiCorp often tests the misconception that Cubbyhole supports listing because it is a key-value store, but Cubbyhole is strictly per-token and does not expose a LIST endpoint, making it unsuitable for team-wide configuration enumeration.

How to eliminate wrong answers

Option A is wrong because Transit is an encryption-as-a-service engine that performs cryptographic operations on data in transit or at rest; it does not store or list configuration data or feature flags. Option C is wrong because Cubbyhole is a per-token private storage engine that only allows the owning token to read/write its own data and does not support listing keys under a path for other tokens or users. Option D is wrong because PKI is a secrets engine for generating and managing X.509 certificates and does not provide a key-value store for configuration data or support listing arbitrary keys.

Practice this question →

24

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

If min_decryption_version is higher than the ciphertext's key version, decryption is denied.

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 →

25

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 has eventual consistency, causing a short delay.

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 →

26

Matchingmedium

Match each Vault storage backend to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Highly available, key-value store

Integrated storage with consensus

Local filesystem storage

AWS object storage

AWS NoSQL database

Why these pairings

Vault supports multiple storage backends. Consul and Integrated Raft are both highly available, while File is for single-node setups. Common confusions include mixing Consul's distributed KV nature with file-based storage or incorrectly attributing external dependencies to Raft.

Practice this question →

27

MCQmedium

A company is using Vault's PKI secrets engine to issue certificates for internal services. They have set up a root CA and an intermediate CA. The intermediate CA's certificate expires soon, and they need to renew it. They generate a new intermediate CSR and have it signed by the root CA. After importing the new intermediate certificate, the team notices that certificates issued by the old intermediate are still valid but new certificate requests fail with 'no valid intermediate CA found'. What step did the team likely miss?

A.They forgot to set the new intermediate certificate as the issuing CA by writing it to the correct path (e.g., pki/intermediate/set-signed).

B.They forgot to update the CRL distribution points on the new intermediate.

C.They changed the root CA's key algorithm, causing incompatibility.

D.They did not revoke the old intermediate CA before importing the new one.

AnswerA

After signing the CSR, the signed certificate must be written back to the intermediate mount via set-signed endpoint.

Why this answer

In Vault's PKI secrets engine, after the root CA signs a new intermediate certificate, the signed certificate must be explicitly set as the issuing CA by writing it to the `pki/intermediate/set-signed` endpoint. Without this step, Vault still references the old (expiring) intermediate certificate and cannot sign new ones, resulting in the 'no valid intermediate CA found' error. Simply importing the signed certificate is not sufficient; it must be configured as the active issuing CA.

Option B is incorrect because failing to update CRL distribution points would affect CRL distribution, not cause a 'no valid intermediate CA found' error during certificate issuance.

Exam trap

HashiCorp often tests the specific API workflow of Vault's PKI secrets engine, where candidates confuse the CSR generation and signing process with the final step of importing the signed certificate via `set-signed`, assuming that simply having the signed certificate in the mount path is sufficient.

How to eliminate wrong answers

Option B is wrong because updating CRL distribution points is a configuration detail for certificate revocation, not a prerequisite for the intermediate to be recognized as a valid issuing CA; the immediate failure is due to the missing set-signed step, not CRL endpoints. Option C is wrong because changing the root CA's key algorithm would require re-signing the entire chain and is unrelated to the described renewal process; the question states they generated a new CSR and had it signed by the root CA, implying no algorithm change. Option D is wrong because revoking the old intermediate CA is not required before importing the new one; Vault can have multiple intermediate certificates in the same mount, and the old one remains valid until its expiration — the issue is that the new certificate was not set as the active issuing CA.

Practice this question →

28

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

Database engine creates dynamic credentials.

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 →

29

MCQeasy

A team wants to store static secrets like database passwords and rotate them periodically. Which secrets engine should they enable?

A.AWS secrets engine

B.PKI secrets engine

C.Transit secrets engine

D.KV v2 secrets engine

AnswerD

KV v2 supports versioning and can store static secrets with rotation capabilities.

Why this answer

The KV v2 secrets engine is designed for static secrets like database passwords, offering versioning, configurable deletion, and periodic rotation via lease management or external automation. It stores secrets as key-value pairs with metadata, making it ideal for static credentials that need controlled lifecycle management.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic secrets (like AWS or PKI) versus those that store static secrets (like KV v2), leading candidates to confuse 'rotation' with 'dynamic generation' and pick a dynamic engine instead.

How to eliminate wrong answers

Option A is wrong because the AWS secrets engine is specifically for dynamically generating AWS IAM credentials or accessing AWS Secrets Manager, not for storing static secrets locally in Vault. Option B is wrong because the PKI secrets engine generates and manages X.509 certificates, not static passwords or secrets. Option C is wrong because the Transit secrets engine performs encryption/decryption operations on data in transit without storing secrets; it is a cryptographic function, not a storage backend.

Practice this question →

30

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

PKI dynamically issues X.509 certificates.

Why this answer

The PKI secrets engine is correct because it dynamically generates X.509 certificates for TLS/mTLS authentication, enabling short-lived credentials that reduce the risk of key compromise. This aligns with the requirement for dynamically generating credentials for external systems, as certificates can be issued on-demand with configurable TTLs and revocation support.

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 →

31

MCQhard

A multi-national company uses Vault's AWS secrets engine to manage access to multiple AWS accounts. They have a central Vault cluster and need to generate IAM users in account A that assume a role in account B for cross-account access. The team has configured the AWS secrets engine with the root credentials of account A. They created a role on the engine that should generate STS credentials for the cross-account role. However, when they try to generate credentials, Vault returns an error: 'AccessDenied: User: arn:aws:iam::<accountA>:user/vault-user is not authorized to perform: STS:AssumeRole on resource: arn:aws:iam::<accountB>:role/CrossAccountRole'. What additional configuration is required?

A.Create a new role in the AWS secrets engine that uses the cross-account role ARN directly.

B.Change the AWS secrets engine mount path to avoid conflicts.

C.Set up AWS federation with SAML to allow cross-account access.

D.Attach an IAM policy to the Vault user in account A that allows sts:AssumeRole on the cross-account role ARN.

AnswerD

The Vault user needs explicit permission to assume the target role.

Why this answer

The error indicates that the Vault user in account A lacks the IAM permission to call sts:AssumeRole on the cross-account role in account B. Even though the AWS secrets engine is configured with root credentials of account A, the engine uses those credentials to make API calls on behalf of the Vault user. Therefore, you must attach an IAM policy to the Vault user in account A that explicitly allows sts:AssumeRole on the target role ARN in account B.

This is a prerequisite for cross-account access via STS.

Exam trap

HashiCorp often tests the misconception that configuring the AWS secrets engine role with the cross-account role ARN is sufficient, when in fact the underlying IAM permissions for the Vault user must also be explicitly granted.

How to eliminate wrong answers

Option A is wrong because creating a new role in the AWS secrets engine that uses the cross-account role ARN directly does not grant the Vault user the required sts:AssumeRole permission; the engine role definition alone cannot bypass IAM authorization. Option B is wrong because changing the mount path only affects the API endpoint path in Vault and has no impact on AWS IAM permissions or cross-account trust. Option C is wrong because SAML federation is an alternative identity federation method, but it is not required here; the existing AWS secrets engine with root credentials can perform cross-account access once the proper IAM policy is attached to the Vault user.

Practice this question →

32

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 role defines the policies to attach to generated IAM users.

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 →

33

MCQhard

An administrator runs the commands shown in the exhibit. Later, they run 'vault kv delete kv-v2/secret' and then 'vault kv undelete -versions=1 kv-v2/secret' to recover the secret. Which command must the administrator run to verify that the secret is now readable?

A.vault kv list kv-v2/secret

B.vault read kv-v2/data/secret

C.vault kv get kv-v2/secret

D.vault kv metadata get kv-v2/secret

AnswerC

After undelete, the secret is readable; this command retrieves the data.

Why this answer

'vault kv get' is the standard command to read and display the latest version of a secret from a KV v2 secrets engine. After running 'vault kv undelete -versions=1', version 1 is restored from a deleted state, and 'vault kv get kv-v2/secret' will retrieve and show that version's data, confirming it is readable.

Exam trap

HashiCorp often tests the distinction between 'vault kv get' (reads secret data) and 'vault kv metadata get' (reads metadata only), leading candidates to choose the metadata command when they need to verify data readability.

How to eliminate wrong answers

Option A is wrong because 'vault kv list' lists the secret paths under a given path, not the data of a specific secret; it would show 'secret' as a key but not its values. Option B is wrong because 'vault read kv-v2/data/secret' is the correct raw API path for reading a KV v2 secret, but the question asks for the command to verify readability, and the standard CLI command is 'vault kv get', not 'vault read' (though 'vault read' would also work technically, it is not the intended answer in the context of the 'kv' subcommand). Option D is wrong because 'vault kv metadata get' retrieves metadata (like version info, deletion time, created time) but does not return the secret's actual data, so it cannot verify that the secret is readable.

Practice this question →

34

MCQhard

A company has multiple Vault clusters in different regions. They want to use the replication feature to synchronise secrets across clusters. However, they want to exclude a specific secrets engine from replication for compliance reasons. What should they do?

A.Create a separate Vault cluster for that secrets engine.

B.Disable replication on that specific mount.

C.Use disaster recovery (DR) replication and exclude the mount.

D.Use performance replication and configure a mount filter.

AnswerD

Performance replication supports mount filtering with path_filter.

Why this answer

Performance replication in Vault allows you to replicate secret data across clusters while using mount filters to include or exclude specific secrets engines. This is the correct approach because mount filters are designed precisely for this use case, enabling selective replication to meet compliance requirements without creating separate infrastructure.

Exam trap

HashiCorp often tests the distinction between performance replication (which supports mount filters) and DR replication (which does not), leading candidates to incorrectly choose DR replication when the requirement is selective exclusion.

How to eliminate wrong answers

Option A is wrong because creating a separate Vault cluster for a single secrets engine adds unnecessary operational complexity and cost, and does not leverage the built-in replication filtering capabilities. Option B is wrong because disabling replication on a mount is not a supported operation; replication operates at the cluster level, not per mount, and you cannot disable it for individual mounts without using mount filters. Option C is wrong because disaster recovery (DR) replication is designed for failover and does not support mount filters; it replicates all data and cannot exclude specific mounts.

Practice this question →

35

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

This correctly enables the database secrets engine at the 'db-creds' 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 →

36

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 v1 secrets are accessed without '/data/'; KV v2 uses '/data/'. The exhibit confirms v1.

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 →

37

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 are automatically revoked or rotated when leases expire.

Why this answer

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

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 →

38

MCQmedium

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

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

B.Set the 'delete_version_after' parameter to 30 days on the KV v2 mount

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

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

AnswerB

This ensures that after soft-deletion, versions are kept for 30 days before permanent removal.

Why this answer

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

Exam trap

HashiCorp often tests the distinction between parameters that control version retention ('max_versions' and 'delete_version_after') versus those that control write safety ('check-and-set'), and the trap here is that candidates confuse 'max_versions' (which limits total versions) with the soft-delete retention period, leading them to pick option D instead of B.

How to eliminate wrong answers

Option A is wrong because 'check-and-set' (CAS) prevents overwrites of a secret when the provided version number does not match the current version; it does not affect deletion behavior or the soft-delete/undelete lifecycle. Option C is wrong because writing a custom script to call the 'undelete' endpoint immediately after deletion would undo the deletion, not enforce a 30-day recovery window; it also adds unnecessary complexity and does not address the root cause of permanent removal. Option D is wrong because setting 'max_versions' to 1 limits the total number of retained versions (older versions are automatically deleted when a new version is written), but it does not control the soft-delete retention period; it would actually reduce the history available for compliance.

Practice this question →

39

Multi-Selecteasy

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

Select 2 answers

A.Active Directory

B.AWS

C.SSH

D.LDAP

E.Transit

AnswersA, C

Correct. Active Directory is a valid secrets engine that rotates and manages AD service account passwords.

Why this answer

Options A (Active Directory) and C (SSH) are both valid secrets engines in Vault. Option B (AWS) is also a secrets engine but not one of the two required answers. Option D (LDAP) is an auth method, not a secrets engine.

Option E (Transit) is also a valid secrets engine, but the question expects the two that are most directly related to credential management, hence A and C are correct.

Exam trap

HashiCorp often tests the distinction between 'auth methods' and 'secrets engines' — candidates confuse LDAP (an auth method) with a secrets engine, or assume SSH is not a secrets engine because it is commonly used for authentication, but SSH is indeed a valid secrets engine for credential management.

Practice this question →

40

MCQmedium

An administrator configured the database secrets engine with PostgreSQL. When an application requests credentials, Vault returns a username and password. However, the application reports that the credentials are not working. What is the most likely cause?

A.The TTL on the role is set too low.

B.The database user used by Vault does not have sufficient privileges to create users.

C.The connection string provided to Vault is incorrect.

D.The generated credentials were revoked by Vault before the application used them.

AnswerB

Vault needs CREATE USER privilege; if missing, credentials won't work.

Why this answer

The most likely cause is that the database user configured in Vault lacks the necessary privileges to create new database users. When Vault generates dynamic credentials, it uses its own database connection (the root or management user) to execute `CREATE USER` and `GRANT` statements. If that user does not have the `CREATEROLE` or `SUPERUSER` attribute (or equivalent `CREATE USER` privilege in PostgreSQL), the credential creation fails silently or produces unusable credentials, even though Vault returns a username and password.

Exam trap

HashiCorp often tests the misconception that credential generation failures are always due to network or connectivity issues (like an incorrect connection string), when in reality the root cause is often a privilege misconfiguration on the database side that Vault does not surface as an obvious error.

How to eliminate wrong answers

Option A is wrong because a low TTL would cause credentials to expire quickly, but the application would still be able to use them initially; the reported issue is that credentials are not working at all, not that they stop working after a short time. Option C is wrong because if the connection string were incorrect, Vault would fail to configure the database secrets engine entirely or would return an error when testing the connection, not silently generate non-functional credentials. Option D is wrong because Vault does not automatically revoke credentials before the application uses them; revocation occurs only when the lease expires or is explicitly revoked, and the application reports the credentials are not working immediately, not after a delay.

Practice this question →

41

MCQhard

A Vault instance was upgraded from version 1.9 to 1.13. After the upgrade, a secrets engine mounted at 'transit/' is unresponsive and returns an error. The engine type is transit. What is the most likely cause?

A.The engine was accidentally disabled during the upgrade

B.The namespace was changed during the upgrade

C.The transit engine can only be mounted at the default path 'transit/'

D.The plugin version is incompatible with the new Vault version

AnswerA

This is correct because the upgrade process may have accidentally disabled the engine due to configuration conflicts or changes in engine management code.

Why this answer

During a Vault upgrade, there is a possibility that the upgrade process inadvertently disables certain secrets engines if there are configuration conflicts or if the engine was enabled using deprecated methods. This is especially likely in major version jumps like from 1.9 to 1.13, where significant changes in the engine management code could lead to such issues. Options B, C, and D are incorrect: namespaces are not altered during upgrades, the transit engine can be mounted at any path, and since transit is built-in, plugin incompatibility does not apply.

Exam trap

Candidates often mistakenly think that secrets engines are tied to specific mount paths or that upgrades cause plugin incompatibilities, but the real issue after a major version jump is that built-in engines may be inadvertently disabled if the upgrade process modifies default configurations.

How to eliminate wrong answers

Option A is wrong because Vault upgrades do not automatically disable mounted secrets engines; the engine remains mounted unless explicitly removed. Option B is wrong because namespaces are not altered during a Vault upgrade; they are a configuration element that persists across versions. Option C is wrong because the transit engine can be mounted at any valid path, not only 'transit/'; the default path is 'transit/' but it is not a requirement.

Practice this question →

42

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

This directly restricts each service to its allowed paths using Vault's policy language.

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 →

43

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

Transit provides encryption as a service without exposing keys.

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 →

44

MCQmedium

A company uses Vault to manage database credentials for a production PostgreSQL cluster. The application team reports that dynamic credentials generated from the database secrets engine are being revoked before the application has finished using them. The Vault lease TTL is set to 1 hour, but the application workload sometimes runs for up to 2 hours. What is the MOST efficient way to ensure credentials remain valid for the full workload duration?

A.Set max_ttl to 2 hours on the database role.

B.Set the Vault server's default_lease_ttl to 2 hours in the server configuration.

C.Increase the default_lease_ttl on the database secrets engine mount to 2 hours.

D.Have the application manually renew the lease every 30 minutes.

AnswerC

This raises the default TTL for all credentials created by this engine, matching the workload's maximum duration without code changes.

Why this answer

Increasing the default_lease_ttl on the database secrets engine mount ensures that all credentials generated by that engine have a TTL of 2 hours, matching the maximum workload duration without requiring application changes. Option A is wrong because setting max_ttl on the role alone does not change the default TTL; the application would still need to request a longer TTL when generating credentials. Option B is wrong because changing the server's default_lease_ttl affects all secrets in Vault, not just database credentials, which could reduce security unnecessarily.

Option D is wrong because manually renewing leases adds complexity and overhead; it's more efficient to adjust the lease TTL at the engine level.

Practice this question →

45

Multi-Selecthard

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

Select 2 answers

A.It can generate AWS session tokens

B.It can generate dynamic IAM users

C.It can manage EC2 key pairs

D.It supports STS federation

E.It only supports static IAM users

AnswersA, B

The engine can generate temporary STS credentials.

Why this answer

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

Exam trap

HashiCorp often tests the misconception that the AWS secrets engine supports STS federation or EC2 key pair management, when in fact it only handles IAM user credentials and STS session tokens, not broader AWS federation or compute resource management.

Practice this question →

46

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 requires '/data/' in the path; the pipeline uses 'v1/secret/team-a/app-config' instead of 'v1/secret/data/team-a/app-config'.

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 →

47

Multi-Selecteasy

A team is evaluating which secrets engines to use for different use cases. Which TWO statements about secrets engines are true?

Select 2 answers

A.The AWS secrets engine can only generate static access keys

B.The Database secrets engine requires a root database user for all configurations

C.The KV v2 secrets engine supports versioning and can store metadata like TTL

D.The Transit secrets engine can generate dynamic database credentials

E.The PKI secrets engine can issue certificates that are automatically renewed by Vault

AnswersC, E

KV v2 stores versions and metadata such as TTL.

Why this answer

The KV v2 secrets engine stores multiple versions of a secret, supports metadata such as TTL and deletion time, and allows check-and-set operations for conflict detection. This makes it suitable for use cases requiring secret rotation and audit trails.

Exam trap

HashiCorp often tests the misconception that 'Transit' implies dynamic credential generation, when in fact Transit is strictly for cryptographic operations on data, not for database credential rotation.

Practice this question →

48

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

KV v2 supports versioning and rollback to previous versions.

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 →

49

MCQmedium

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

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

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

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

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

AnswerD

This is the correct order: enable, generate root, create role, issue.

Why this answer

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

Exam trap

HashiCorp often tests the correct sequence of operations in Vault PKI setup, and the trap here is that candidates confuse the order of enabling the engine versus generating the CA, or they incorrectly assume an intermediate CA is always required for a private CA setup.

How to eliminate wrong answers

Option A is wrong because it places 'create a role' before 'generate root CA', but a role cannot be created without an existing CA (the role references the CA's key and certificate). Option B is wrong because it starts with 'generate root CA' before 'enable PKI', but the PKI secrets engine must be enabled first to have a mount point where the CA can be generated. Option C is wrong because it introduces an unnecessary 'generate intermediate CA' step; while intermediate CAs are used in multi-tier PKI, the question asks for a private CA setup, and generating an intermediate CA without first generating a root CA is invalid, and the question does not require an intermediate CA.

Practice this question →

50

MCQeasy

An administrator wants to view all currently enabled secrets engines and their mount paths. Which command provides this information?

A.vault list sys/mounts

B.vault secrets list

C.vault secrets show

D.vault read sys/mounts

AnswerB

`vault secrets list` is the standard CLI command that displays all enabled secrets engines and their mount paths.

Why this answer

The correct command to list all enabled secrets engines and their mount paths is `vault secrets list` (option B). Option D, `vault read sys/mounts`, is not a valid command in the Vault CLI; the endpoint `sys/mounts` is accessed via `vault secrets list` or by directly reading the path with `vault read sys/mounts` in some contexts, but the CLI command `vault read sys/mounts` does not exist. Options A and C are incorrect: `vault list sys/mounts` is not valid, and `vault secrets show` is not a real command.

Exam trap

Candidates often confuse `vault read sys/mounts` as a valid command, but the Vault CLI uses `vault secrets list` for this purpose. Option D is a trap that appears plausible but is not a supported command.

How to eliminate wrong answers

Option A is wrong because `vault list sys/mounts` is not a valid command; Vault's CLI uses `vault read sys/mounts` or `vault secrets list` to retrieve mount information, and `list` is not supported on that path. Option C is wrong because `vault secrets show` is not a valid Vault CLI command; the correct subcommand is `list`, not `show`.

Practice this question →

51

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

This follows least privilege and generates IAM users dynamically.

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 →

52

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

Database engine generates dynamic database credentials with lease duration.

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 →

53

Multi-Selecteasy

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

Select 1 answer

A.secret/delete/myapp

B.secret/data/myapp

C.secret/destroy/myapp

D.secret/myapp

E.secret/metadata/myapp

AnswersB

Correct. The `/data/` path is the standard endpoint for reading and writing secret values in KV v2.

Why this answer

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

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 paths, trapping candidates who assume both `/data/` and `/metadata/` paths can be used for data operations, when in fact only `/data/` handles reading and writing secret data.

Practice this question →

54

MCQhard

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

A.Generate a new intermediate with signature_bits=256

B.Set the issuer's signature_bits to 256 using vault write

C.Use a different issuer_name that already has SHA256

D.Change the role's signature_bits to 256

AnswerA

The intermediate must be recreated with the desired signature bits.

Why this answer

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

Exam trap

HashiCorp often tests the distinction between the CA's own signing algorithm (set at CA creation) and the role's signing algorithm (set per issuance), leading candidates to mistakenly think a role change can fix the CA's algorithm.

How to eliminate wrong answers

Option B is wrong because `vault write` on an existing intermediate CA cannot change its `signature_bits`; this parameter is immutable after issuance and only applies at generation time. Option C is wrong because using a different issuer_name that already has SHA256 would require a pre-existing intermediate CA configured with SHA256, which is not a direct action to fix the current intermediate — it avoids the root cause. Option D is wrong because a role's `signature_bits` only affects the signing algorithm for certificates issued by that role, but the intermediate CA's own certificate algorithm is fixed at creation; the role cannot override the CA's signing key algorithm.

Practice this question →

55

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

Correct: writing to 'sys/mounts/<path>' with 'type' parameter is a valid low-level method.

Why this answer

Options B and C are both valid methods to enable a secrets engine at a non-default path in Vault. Option B uses the raw API endpoint via 'vault write sys/mounts/my-aws type=aws', which is a valid low-level approach. Option C uses the higher-level 'vault secrets enable -path=my-aws aws' command, which is the standard CLI method.

Option E ('vault secrets enable my-aws aws') is invalid because it incorrectly places the path before the engine type; the correct syntax for a default path is 'vault secrets enable aws', but for a non-default path the '-path' flag is required.

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 →

56

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

This writes to the issue endpoint for the role 'webserver' with required parameters.

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 →

57

Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

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 →

58

MCQhard

A security team wants to ensure that secrets stored in Vault are encrypted in transit and at rest, and that even Vault administrators cannot read the plaintext secret values. Which configuration is required?

A.Set a strong master key for the Vault cluster

B.Configure storage backend encryption using a KMS

C.Enable the Transit secrets engine and encrypt secrets before writing them to KV

D.Both A and B

AnswerC

Transit encrypts secrets at the application level, so admins cannot see plaintext without the encryption key.

Why this answer

The Transit secrets engine allows clients to encrypt data (including secrets) using Vault-managed encryption keys before writing the ciphertext to a storage backend like KV. This ensures that even Vault administrators with access to the raw storage backend cannot read plaintext secret values, as the encryption key is never exposed to them. The Transit engine also supports encryption in transit via TLS and at rest via the encrypted ciphertext stored in the KV engine, meeting the full requirement.

Exam trap

HashiCorp often tests the misconception that storage backend encryption or a strong master key alone can protect secrets from administrators, but the correct approach is client-side encryption via the Transit secrets engine, which ensures that plaintext secrets are never visible to Vault operators.

How to eliminate wrong answers

Option A is wrong because a strong master key protects the Vault cluster's root key and seals/unseals the Vault, but it does not prevent Vault administrators from reading plaintext secrets once Vault is unsealed; administrators with appropriate policies can still access secret values. Option B is wrong because configuring storage backend encryption using a KMS encrypts the data at rest in the storage backend, but Vault administrators with access to the unsealed Vault can still read plaintext secrets; KMS encryption protects against physical theft of storage, not against administrative access. Option D is wrong because combining A and B still does not prevent Vault administrators from reading plaintext secrets; neither the master key nor storage backend encryption provides client-side encryption that keeps secrets opaque to Vault operators.

Practice this question →

59

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 enable fine-grained ACLs and easy organization by app and environment.

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 →

60

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

The database secrets engine creates unique, time-limited credentials on the fly, matching the requirement.

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 →

61

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

Versioning allows new data encrypted with new key, old data decryptable with old key.

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 →

62

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

User's request is within max_ttl and allowed.

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 →

63

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

A role defines the generated credential attributes (e.g., username template, default TTL).

Why this answer

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

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 →

64

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 metadata and multiple versions, allowing rollback and undelete.

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 →

65

Multi-Selectmedium

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

Select 3 answers

A.Automatically rotate certificates

B.Generate one-time pads

C.Revoke certificates

D.Generate self-signed root certificates

E.Create intermediate CA certificates

AnswersC, D, E

Revocation is a standard PKI operation.

Why this answer

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

Exam trap

HashiCorp often tests the distinction between 'automatic rotation' and 'manual revocation' in PKI secrets engines, leading candidates to incorrectly assume that rotation is a built-in capability when it actually requires external orchestration.

Practice this question →

66

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

Transit provides encryption as a service and handles key management without storing data.

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 →

67

MCQhard

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

A.The database secrets engine does not support revocation

B.The role's default_ttl is set too high

C.The lease duration is too long

D.The revocation statement is not configured in the database connection

AnswerD

If no revocation statement is set, Vault cannot delete the user on lease revocation.

Why this answer

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

Exam trap

The trap here is that candidates often assume Vault automatically removes database users on lease revocation, but in reality, the revocation behavior must be explicitly defined in the connection configuration; otherwise, no cleanup occurs.

How to eliminate wrong answers

Option A is wrong because the database secrets engine does support revocation; it can execute custom SQL statements to disable or drop users when leases expire or are revoked. Option B is wrong because the `default_ttl` controls how long a lease is valid before it must be renewed, not whether the user is removed after revocation; a high TTL would delay expiration but not prevent revocation. Option C is wrong because the lease duration (TTL) determines the lifetime of the credential, not the revocation behavior; a long lease would simply keep the user active longer, but revocation would still occur if properly configured.

Practice this question →

68

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

PKI engine issues and manages X.509 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 →

69

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

Correct; each token has its own cubbyhole.

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 →

70

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

If the role limits concurrent leases, once exceeded, new requests are denied until some leases are revoked.

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 →

71

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

The glob `database/roles/*` does not cover the exact path; need explicit `database/roles/` with list.

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 →

72

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

This limits what the attacker can do with the engine's credentials.

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 →

73

MCQeasy

A DevOps engineer creates the configuration above. After testing, they notice that the generated database credentials are not being revoked after the TTL expires. What is the most likely cause?

A.The creation_statements do not include the REVOKE command

B.The role definition has a syntax error in the creation_statements

C.The database configuration uses a connection_url with template variables but provides static admin credentials, not root rotation

D.The secrets engine is enabled at a path other than 'database/'

AnswerC

Without root credentials rotation, Vault cannot revoke dynamically created users because it uses the same admin credentials to manage them. The root credentials should be rotated first.

Why this answer

The database secrets engine requires root credential rotation to enable automatic revocation of generated credentials. When the `connection_url` uses template variables like `{{username}}` and `{{password}}` but the admin credentials are static (not rotated via `rotate_root`), Vault cannot track the actual root password. Without root rotation, Vault lacks the ability to execute `REVOKE` commands after TTL expiry because it cannot authenticate to the database with the current root credentials to perform cleanup.

Exam trap

HashiCorp often tests the misconception that `creation_statements` control both creation and revocation, or that the secrets engine path affects functionality, when the real issue is the missing root rotation step that enables Vault to maintain a valid admin session for cleanup operations.

How to eliminate wrong answers

Option A is wrong because the `creation_statements` are used to create the database user, not to revoke it; revocation is handled by the `revocation_statements` field in the role definition, and the absence of `REVOKE` in `creation_statements` is irrelevant. Option B is wrong because a syntax error in `creation_statements` would cause the role to fail at user creation, not silently fail to revoke credentials after TTL expiry. Option D is wrong because the secrets engine path does not affect credential revocation behavior; Vault can manage revocation regardless of the mount path as long as the engine is properly configured.

Practice this question →

74

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

Transit supports signing and verification operations.

Why this answer

The Transit secrets engine is designed to perform cryptographic operations on data without exposing the encryption keys to the client. Option A is correct because the engine supports signing and verifying data using HMAC or asymmetric keys, allowing clients to verify integrity and authenticity without handling the private key. Option B is correct because the engine can encrypt data in transit (e.g., via API calls) while the encryption key remains securely stored within Vault, never leaving the server.

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 →

75

MCQeasy

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

A.Cubbyhole

B.AWS

C.KV v2 at a client-specific path

D.Transit

AnswerA

Cubbyhole provides per-token isolated storage.

Why this answer

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

Exam trap

HashiCorp often tests the misconception that KV v2 with strict ACLs provides the same isolation as Cubbyhole, but the trap is that KV v2 is path-based and policy-dependent, whereas Cubbyhole is inherently token-scoped and cannot be accessed by any other token, even with root privileges.

How to eliminate wrong answers

Option B is wrong because the AWS secrets engine is designed to generate dynamic AWS IAM credentials or manage static AWS secrets, and it has no concept of per-client isolation — any client with the correct policy can access the same path. Option C is wrong because KV v2 at a client-specific path relies on ACL policies to restrict access, but it does not enforce token-scoped isolation; a misconfigured policy or a token with broader permissions could read another client's path, and the data persists even after the token expires. Option D is wrong because the Transit engine handles encryption and decryption operations (e.g., encrypting data in transit or at rest) and does not store configuration values at all; it is a cryptographic operations engine, not a storage engine.

Practice this question →

Page 1 of 2 · 78 questions totalNext →

Ready to test yourself?

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

Start 20-question session