Courseiva

HashiCorp Vault Associate VA-003 (VA-003) — Questions 1–75

514 questions total · 7pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 7

Page 2
1
MCQeasy

An application needs to read a secret using the Vault API after authenticating with an AppRole RoleID and SecretID. The application has already obtained a Vault token. Which API endpoint should be called to read a secret at 'secret/data/myapp' with the token?

A.GET /v1/secret/metadata/myapp
B.POST /v1/auth/approle/login
C.GET /v1/secret/myapp
D.GET /v1/secret/data/myapp
AnswerD

This is the standard API path to read a KV v2 secret.

Why this answer

Option D is correct because after authentication, the application already has a Vault token and needs to read a secret from the KV v2 secrets engine. The correct API endpoint for reading a secret from the KV v2 engine is GET /v1/secret/data/myapp, where 'secret' is the mount path and 'data' is the sub-path for KV v2 operations. The token is passed in the X-Vault-Token header, not in the URL.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 API paths, specifically that KV v2 requires '/data/' in the path to read secrets, while KV v1 uses a flat path without '/data/'.

How to eliminate wrong answers

Option A is wrong because GET /v1/secret/metadata/myapp is used to read metadata (like version info) of a KV v2 secret, not the secret data itself. Option B is wrong because POST /v1/auth/approle/login is the endpoint for authenticating with AppRole RoleID and SecretID to obtain a Vault token, but the question states the application has already obtained a token, so this step is unnecessary. Option C is wrong because GET /v1/secret/myapp is the endpoint for the KV v1 secrets engine, which does not support versioning and uses a different path structure; the question implies KV v2 (since the path includes 'data'), and using KV v1 endpoint would fail or return incorrect data.

Full explanation →
2
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

Option B is correct: dynamic secrets engines generate credentials on demand with a TTL. Option E is correct: the Transit secrets engine performs encryption operations without storing the data. Option A is incorrect because each engine instance is mounted at a single path, though the same engine type can be enabled at multiple paths.

Option C is incorrect because static secrets (e.g., database static roles) can have rotation. Option D is incorrect because each KV engine is either v1 (unversioned) or v2 (versioned), not both.

Full explanation →
3
MCQeasy

A developer creates a token using the 'token create' command with the 'period=24h' flag. What type of token is created?

A.Root token
B.Periodic token
C.Orphan token
D.Batch token
AnswerB

The period flag creates a periodic token.

Why this answer

Option B is correct. A token created with a 'period' becomes a periodic token, which is a subtype of service token that does not have a TTL but instead has a period. Option A is wrong because batch tokens are created with '-type=batch'.

Option C is wrong because orphan is a property, not a type. Option D is wrong because it is not a root token.

Full explanation →
4
Multi-Selectmedium

An admin wants to view all active leases for a specific secrets engine path. Which two approaches are valid? (Choose two.)

Select 2 answers
A.vault write sys/leases/list lease_id=<mount_path>
B.vault list sys/leases/lookup/<mount_path>
C.vault list sys/leases/prefix/<mount_path>
D.vault lease list -prefix <mount_path>
E.vault read sys/leases/list/<mount_path>
AnswersB, C

This path lists lease IDs for the given mount.

Why this answer

Both `vault list sys/leases/lookup/<mount_path>` and `vault list sys/leases/prefix/<mount_path>` are valid paths to list leases under a mount or prefix. Option C is not a real command. Option D uses an incorrect path.

Option E is incorrect because you cannot write to list.

Full explanation →
5
MCQhard

A large enterprise uses Azure Active Directory as its identity provider. They want to authenticate users to Vault using Azure AD tokens. However, they require that Vault validate the token's signature and claims without contacting Azure AD every time. Which authentication method should they use?

A.LDAP authentication
B.OIDC authentication
C.Token authentication
D.Azure authentication
AnswerB

OIDC can be configured to use cached JWKS keys, allowing offline validation.

Why this answer

Option B (OIDC authentication) is correct because OpenID Connect (OIDC) allows Vault to validate an Azure AD token's signature and claims locally using the provider's JWKS (JSON Web Key Set) endpoint, without requiring a round-trip to Azure AD for every authentication request. This satisfies the requirement for offline token validation while still leveraging Azure AD as the identity provider.

Exam trap

HashiCorp often tests the distinction between OIDC (which supports offline token validation via JWKS) and the Azure auth method (which relies on Azure-specific MSI tokens and requires online calls), leading candidates to mistakenly choose 'Azure authentication' when the question explicitly requires no contact with Azure AD.

How to eliminate wrong answers

Option A is wrong because LDAP authentication is designed for direct binding to an LDAP directory (like Active Directory on-premises) and cannot validate Azure AD tokens or perform OIDC-based token signature verification. Option C is wrong because token authentication in Vault uses Vault's own internal token system, not external Azure AD tokens, and requires Vault to manage the token lifecycle rather than validating third-party tokens. Option D is wrong because 'Azure authentication' is not a standard Vault auth method; Vault's Azure auth method uses Azure Managed Service Identity (MSI) tokens for VMs, not user Azure AD tokens, and it validates tokens by calling the Azure Instance Metadata Service (IMDS) or Azure Resource Manager, not by local signature verification.

Full explanation →
6
Multi-Selectmedium

A DevOps team is writing a Vault policy for a CI/CD pipeline that needs to authenticate using AppRole, read specific secrets, and write dynamic database credentials. Which THREE capabilities should be included in the policy to meet these requirements? (Choose three.)

Select 3 answers
A.write
B.create
C.read
D.sudo
E.update
AnswersB, C, E

'create' is needed to generate new database credentials.

Why this answer

Option B (create) is correct because the CI/CD pipeline needs to write dynamic database credentials, which requires the 'create' capability on the database secrets engine path (e.g., database/creds/my-role). The 'create' capability allows generating new credentials from a role, which is distinct from simply updating existing secrets. Without 'create', the pipeline cannot request fresh credentials from the database backend.

Exam trap

HashiCorp often tests the distinction between 'write' and 'create' capabilities, where candidates mistakenly choose 'write' for generating dynamic credentials, not realizing that 'create' is specifically required for role-based credential generation in the database secrets engine.

Full explanation →
7
MCQeasy

A small startup wants to run Vault in a development environment with minimal operational overhead. They need to store secrets in memory only, without any persistence. Which storage backend should they choose?

A.Integrated Storage (Raft) backend
B.In-memory storage backend
C.Consul storage backend
D.File storage backend
AnswerB

In-memory backend stores secrets only in RAM, with no persistence.

Why this answer

The in-memory storage backend stores all data in RAM with no persistence to disk, making it ideal for development environments where secrets must be lost on restart and operational overhead must be minimized. It requires no configuration, no external dependencies, and no data management, perfectly matching the requirement for minimal overhead and memory-only storage.

Exam trap

HashiCorp often tests the misconception that Integrated Storage (Raft) is the default or simplest backend, but candidates must recognize that Raft is persistent and requires cluster management, whereas the in-memory backend is the only option that guarantees zero persistence and minimal overhead.

How to eliminate wrong answers

Option A is wrong because Integrated Storage (Raft) is a persistent, highly available backend that writes data to disk and requires a cluster of nodes, adding operational overhead and violating the 'no persistence' requirement. Option C is wrong because the Consul storage backend relies on an external Consul cluster for persistence and high availability, introducing additional infrastructure and operational complexity. Option D is wrong because the File storage backend persists data to the filesystem on disk, which contradicts the requirement for memory-only storage with no persistence.

Full explanation →
8
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.

Full explanation →
9
MCQmedium

An application using a service token fails to renew it, receiving an error 'permission denied'. The token has policies that include 'path "auth/token/renew-self" { capabilities = ["update"] }'. The token is not expired and has remaining TTL. What is a likely cause?

A.The token's num_uses has reached zero
B.The token is a batch token
C.The token's parent was revoked
D.The token has reached its explicit max TTL
AnswerD

Renewal is denied if it would exceed max TTL.

Why this answer

Option C is correct because the token's max_ttl may have been reached, preventing further renewal even if TTL remains. Option A is wrong because if the token were batch, the error would be different. Option B is wrong because orphan tokens can still renew.

Option D is wrong because num_uses=0 gives unlimited uses.

Full explanation →
10
MCQmedium

A Vault operator accidentally revoked a token that was used to lease many database credentials. What happens to the leases associated with that token?

A.All leases are immediately revoked.
B.The leases become orphaned and will never be revoked.
C.Vault automatically renews the leases with a new token.
D.The leases continue until their natural expiration.
AnswerA

Token revocation revokes all associated leases.

Why this answer

In Vault, tokens are the root of identity and authorization for all associated leases. When a token is revoked, Vault immediately revokes all leases created using that token, including database credential leases, because the token's lifecycle governs the leases it has created. This ensures that no credentials remain valid after the token is revoked, maintaining security.

Exam trap

HashiCorp often tests the misconception that leases have independent lifetimes or that Vault might orphan or auto-renew leases, when in fact the token's revocation is the authoritative trigger for immediate lease cleanup.

How to eliminate wrong answers

Option B is wrong because Vault does not orphan leases; it actively tracks the parent token for each lease and revokes them when the token is revoked. Option C is wrong because Vault does not automatically renew leases with a new token; lease renewal requires the original token or a token with sufficient privileges, and revocation is a terminal action. Option D is wrong because leases are tied to the token's lifecycle, not independent; they do not continue to natural expiration once the token is revoked.

Full explanation →
11
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.

Full explanation →
12
MCQhard

A security auditor requires that all encryption keys used to protect customer data must be periodically rotated according to company policy. The company uses Vault's Transit secrets engine. What is the recommended approach to rotate the encryption key?

A.Use Vault's key rotation endpoint to rewrap the key
B.Use the `vault write -f transit/keys/my-key/rotate` command to rotate the key
C.Delete the existing key and create a new one with the same name
D.Generate a new key with a different name and update the application configuration
AnswerB

This creates a new key version; old ciphertexts remain decryptable with the previous version.

Why this answer

Option B is correct because the Vault Transit secrets engine provides a dedicated `rotate` endpoint that creates a new encryption key version while keeping the previous version available for decryption of existing ciphertext. This allows the key to be rotated without re-encrypting all data, and the new key version is automatically used for future encryption operations. The `-f` flag forces the rotation without requiring interactive confirmation.

Exam trap

HashiCorp often tests the misconception that 'rewrapping' is the same as 'rotating,' but rewrapping only re-encrypts data under a new key version without creating a new key version, whereas rotation creates a new key version and is the correct first step in a key lifecycle management process.

How to eliminate wrong answers

Option A is wrong because Vault's 'rewrap' endpoint re-encrypts ciphertext under a new key version but does not rotate the key itself; rotation is a separate operation that creates a new key version. Option C is wrong because deleting the existing key would render all previously encrypted data permanently undecryptable, violating data integrity and availability requirements. Option D is wrong because generating a new key with a different name and updating application configuration is an operational workaround that adds complexity and does not leverage Vault's built-in key versioning, which is the recommended approach for seamless rotation.

Full explanation →
13
MCQmedium

An application uses Vault's KV v2 secrets engine to read a static secret (e.g., API key) at path 'secret/data/myapp/config'. The application initially reads the secret and uses the returned lease_id to successfully renew the lease every hour. After a maintenance window, the application starts failing to renew the lease, receiving an error that the lease is not renewable or does not exist. The secret data is still present and accessible via a new read. What is the most likely cause of this failure?

A.The token used to renew the lease has expired.
B.The secret was deleted and recreated under the same path.
C.The KV v2 engine was disabled and re-enabled.
D.The lease expired during the maintenance window because the application did not renew it on time.
AnswerD

If the lease TTL passes without renewal, the lease is marked expired and can no longer be renewed; a fresh read is required.

Why this answer

KV v2 secrets engine supports lease renewal for static secrets, but if the lease expires (the renewal interval was missed), the lease becomes invalid and cannot be renewed. The application must perform a fresh read to obtain a new lease. Option C correctly identifies that the lease has already expired.

Option A is plausible but lease expiration is more common than token expiry in this context. Option B would cause read failures, not just renewal failures. Option D would affect reads altogether, which is not happening.

Full explanation →
14
Multi-Selectmedium

A Vault operator wants to manage lease durations for secrets issued by a PKI secrets engine. Which two actions can they take to affect the lease duration of certificates?

Select 2 answers
A.Set the 'default_lease_ttl' on the auth method used to log in.
B.Set the 'max_lease_ttl' on the auth method used to log in.
C.Configure the 'ttl' parameter in the PKI role definition.
D.Set the 'lease_duration' parameter in the PKI role definition.
E.Set the 'default_lease_ttl' on the PKI secrets engine mount.
AnswersC, E

The 'ttl' parameter in a PKI role overrides the mount's default lease TTL for certificates issued by that role.

Why this answer

Options B and D are correct. Setting the default lease TTL on the mount and configuring the 'ttl' parameter in the role both directly impact certificate lease durations. Option A is incorrect because the 'max_lease_ttl' on the auth method does not affect secrets engine leases.

Option C is incorrect because 'default_lease_ttl' on the auth method also does not affect secrets engine leases. Option E is incorrect because the 'lease_duration' parameter is not a valid parameter for PKI roles.

Full explanation →
15
MCQhard

A Vault operator runs 'vault token lookup s.abc123' and sees that the token type is 'service', renewable is true, but the ttl is 30m and creation_ttl is 1h. The token has num_uses set to 0. What is the most likely explanation for the discrepancy between ttl and creation_ttl?

A.The token has renewable set to false
B.The token type is service, so it cannot be renewed
C.30 minutes have elapsed since the token was created
D.The token has been used and num_uses decremented
AnswerC

TTL shows remaining time; creation_ttl was 1h, so 30m have passed.

Why this answer

Option A is correct because the token was created 30 minutes ago, so only 30 minutes of TTL remain. Option B is wrong because num_uses is 0, meaning unlimited uses, not reduced. Option C is wrong because token type service implies renewable.

Option D is wrong because renewable is true.

Full explanation →
16
MCQhard

A Vault administrator needs to create a policy that grants users read access only to the secrets that belong to their own team. The team membership is stored in an external identity provider and mapped to Vault entity aliases. The administrator wants to use a templated policy that references the entity's metadata. Which policy syntax accomplishes this goal?

A.path "secret/data/{{identity.entity.metadata.team}}/*" { capabilities = ["read", "list"] }
B.path "secret/data/{{entity.metadata.team}}/*" { capabilities = ["read", "list"] }
C.path "secret/data/{{.team}}/*" { capabilities = ["read", "list"] }
D.path "secret/data/{{identity.entity.aliases.team}}/*" { capabilities = ["read", "list"] }
AnswerA

Correctly references the entity metadata key 'team'.

Why this answer

Option C is correct because Vault's policy templating uses the format {{identity.entity.metadata.<key>}} to reference entity metadata. Option A misses the 'identity.' prefix. Option B uses 'entity' without 'identity'.

Option D uses an invalid template syntax.

Full explanation →
17
MCQhard

An administrator receives an access denied error when trying to use the token accessor to revoke a token. The administrator's token has the following policy capabilities: path "auth/token/revoke-accessor" { capabilities = ["create", "update"] }. What is the issue?

A.The administrator lacks the 'sudo' capability on that path
B.The administrator's token does not have any capabilities on the path
C.The path requires 'create' and 'update' but not 'sudo'
D.The accessor path is incorrect; it should be auth/token/accessors/revoke
AnswerA

Revoking by accessor requires sudo.

Why this answer

Revoking a token by accessor requires the 'sudo' capability on the path. Without sudo, the operation is denied. Option A is wrong because 'create' and 'update' are not sufficient.

Option B is wrong because the accessor path is correct. Option D is wrong because the token's policy does grant capabilities, but not the required one.

Full explanation →
18
MCQeasy

A security team wants to allow applications to authenticate to Vault without storing any secrets in configuration files. The applications run on AWS EC2 instances with an IAM role attached. Which Vault authentication method leverages the EC2 instance metadata to obtain credentials?

A.GCP IAM authentication
B.Userpass authentication
C.AppRole authentication
D.AWS IAM authentication
AnswerD

Uses EC2 instance metadata to sign a request, no secrets stored.

Why this answer

AWS IAM authentication (option D) is correct because it allows applications running on EC2 instances with an attached IAM role to authenticate to Vault without storing any secrets. The Vault client uses the EC2 instance metadata service (IMDS) to retrieve the instance identity document and its signature, which are then presented to Vault. Vault verifies these credentials against the AWS API, confirming the instance's identity and IAM role, thereby enabling secure, secretless authentication.

Exam trap

HashiCorp often tests the distinction between authentication methods that require pre-shared secrets (like AppRole) versus those that leverage cloud instance metadata (like AWS IAM), leading candidates to mistakenly choose AppRole because it is commonly associated with machine authentication.

How to eliminate wrong answers

Option A is wrong because GCP IAM authentication is designed for Google Cloud Platform instances, not AWS EC2, and relies on GCP instance metadata and service accounts. Option B is wrong because Userpass authentication requires a username and password to be provided at login, which would still need to be stored or transmitted as a secret, contradicting the requirement to avoid storing secrets. Option C is wrong because AppRole authentication requires a RoleID and a SecretID; while the RoleID can be supplied via configuration, the SecretID must be securely delivered (e.g., via a trusted orchestrator), and it does not leverage EC2 instance metadata for credential retrieval.

Full explanation →
19
MCQeasy

Which authentication method allows a user to authenticate using a one-time password (OTP) generated by an authenticator app?

A.Okta
B.Userpass
C.GitHub
D.LDAP
AnswerA

Okta supports TOTP via the Okta API.

Why this answer

Okta supports Time-based One-Time Password (TOTP) as an authentication factor, which is the standard method used by authenticator apps like Google Authenticator or Microsoft Authenticator. TOTP generates a temporary code based on a shared secret and the current time, as defined in RFC 6238, and Okta's multifactor authentication (MFA) policies can require this OTP for user login. This makes Okta the correct choice for authenticating with an OTP from an authenticator app.

Exam trap

HashiCorp often tests the distinction between an authentication method (like Okta's TOTP) and a protocol or service that can be used as an identity provider but does not natively generate OTPs, leading candidates to confuse GitHub's OAuth or LDAP's directory lookups with actual OTP generation.

How to eliminate wrong answers

Option B (Userpass) is wrong because it refers to a simple username/password authentication method in HashiCorp Vault, which does not generate or use one-time passwords from an authenticator app. Option C (GitHub) is wrong because GitHub authentication typically uses OAuth tokens or SSH keys, not OTPs from an authenticator app, though it can support TOTP as a second factor, the question asks for the authentication method itself, not a service that can be configured with MFA. Option D (LDAP) is wrong because LDAP is a directory protocol for verifying static credentials (username and password) against a directory server, and it has no built-in mechanism for generating or validating time-based one-time passwords.

Full explanation →
20
Multi-Selectmedium

Which of the following factors determine the actual TTL of a lease issued by a secrets engine? (Choose three.)

Select 3 answers
A.The system's max_lease_ttl configuration
B.The requesting token's TTL
C.The role's default_ttl
D.The backend's rotation period
E.The role's max_ttl
AnswersA, C, E

Global maximum TTL for all leases.

Why this answer

The lease's actual TTL is influenced by the role's default_ttl (initial TTL), the role's max_ttl (maximum allowed total TTL), and the system's max_lease_ttl configuration (global cap). The requesting token's TTL does not directly impact lease TTL. The rotation period is for password rotation, not lease duration.

Full explanation →
21
Multi-Selecteasy

Which TWO authentication methods are designed for human users? (Choose two.)

Select 2 answers
A.AWS
B.Kubernetes
C.AppRole
D.OIDC
E.Userpass
AnswersD, E

Designed for humans using SSO.

Why this answer

OIDC (OpenID Connect) is an identity layer built on top of OAuth 2.0 that allows human users to authenticate via an external identity provider (IdP) using tokens (ID tokens in JWT format). It is specifically designed for human user authentication, enabling single sign-on (SSO) across applications.

Exam trap

HashiCorp often tests the distinction between authentication methods designed for human users versus machine/application identities, and the trap here is that candidates may confuse 'AppRole' (a machine auth method) with a human-oriented method due to its name suggesting a role for a person.

Full explanation →
22
MCQmedium

A team is migrating from a monolithic application to microservices. Each microservice needs to authenticate to Vault using its own AppRole. The security team wants to enforce that each AppRole can only read secrets from its own dedicated path (e.g., service-a can only read from 'services/service-a/*', service-b from 'services/service-b/*'). They have created the AppRoles and policies. However, during testing, they notice that service-a can read secrets from service-b's path. The administrator checks the policy for service-a and sees it has a 'capabilities' list on 'services/service-a/*' and also 'services/service-b/*' by mistake. They correct the policy, but the issue persists. What is the most likely reason that service-a still has access?

A.The policy still contains an error that grants access to the wrong path
B.The policy update has not been applied to the Vault cluster yet
C.The service-a token has a second policy attached that grants access to service-b
D.The token was issued before the policy was corrected and still carries the old policy version; it must be replaced or renewed to get the updated permissions
AnswerD

Tokens inherit policies at creation time; updates to policies require new tokens or renewal depending on the auth method.

Why this answer

Vault tokens are immutable once issued; they carry a snapshot of the policies at the time of creation. Correcting the policy on the Vault server does not retroactively update existing tokens. Service-a's token was issued before the policy fix and still contains the old policy that granted access to 'services/service-b/*'.

The token must be replaced (revoked and re-issued) or renewed to pick up the updated policy permissions.

Exam trap

HashiCorp often tests the misconception that policy updates are immediately enforced on all existing tokens, when in fact tokens carry a snapshot of policies at issuance and require re-issuance to reflect changes.

How to eliminate wrong answers

Option A is wrong because the administrator already corrected the policy, so the policy itself no longer contains the error; the issue is with the token's cached policies, not the current policy definition. Option B is wrong because policy updates in Vault are applied immediately to the server; there is no 'apply' step or propagation delay for policy changes. Option C is wrong because while a second policy could grant access, the question states the administrator checked the policy for service-a and corrected it, implying no other policy was mentioned; the most likely cause is the token's cached policies, not an additional attached policy.

Full explanation →
23
MCQeasy

A DevOps team wants to automate authentication to Vault for Jenkins jobs running on AWS EC2 instances. Which authentication method is most appropriate and secure for this use case without storing long-lived credentials?

A.GitHub personal access token
B.AWS IAM auth
C.AppRole
D.Username & password (userpass)
AnswerB

AWS IAM auth allows instances to authenticate using IAM roles without storing static credentials.

Why this answer

AWS IAM auth is the most appropriate and secure method because it allows Jenkins jobs running on EC2 instances to authenticate to Vault using the instance's AWS IAM role without storing any long-lived credentials. The EC2 instance obtains temporary AWS credentials via the instance metadata service (IMDS), and Vault validates these against AWS STS to issue a short-lived Vault token. This eliminates the need to manage static secrets or tokens in Jenkins job configurations.

Exam trap

HashiCorp often tests the misconception that AppRole is the best choice for automated workloads, but the trap here is that AppRole still requires storing a secret ID, whereas AWS IAM auth eliminates all long-lived credentials by leveraging the EC2 instance's IAM role and temporary AWS credentials.

How to eliminate wrong answers

Option A is wrong because a GitHub personal access token is a long-lived static credential that must be stored securely, violates the requirement of not storing long-lived credentials, and is not designed for AWS EC2 instance authentication to Vault. Option C is wrong because AppRole requires a secret ID and role ID to be provisioned and stored, which are long-lived credentials that must be managed securely, and does not leverage the EC2 instance's IAM role for automatic credential rotation. Option D is wrong because username & password (userpass) authentication requires storing static credentials in Jenkins, which are long-lived and pose a security risk, and does not integrate with AWS IAM roles or instance metadata.

Full explanation →
24
MCQmedium

A healthcare application needs to encrypt sensitive patient data before storing it in a legacy database that does not support encryption. The team wants to use Vault's encryption as a service. However, the application is running on a restricted network that cannot make outbound HTTP requests to Vault. Which solution should the team implement?

A.Set up Vault replication from a central Vault to a local Vault instance.
B.Deploy Vault Agent in sidecar mode with a configured encrypt stanza to handle encryption locally.
C.Use Vault's HTTP API from the application to encrypt data directly.
D.Enable the transit secrets engine and call Vault's encrypt endpoint.
AnswerB

Vault Agent can process encryption locally via a Unix socket.

Why this answer

Option B is correct because Vault Agent in sidecar mode runs alongside the application on the same host, handling encryption locally without requiring outbound HTTP requests. The encrypt stanza in the agent configuration allows it to proxy encryption operations to Vault's transit secrets engine, while the application communicates with the agent over a local loopback interface, bypassing network restrictions.

Exam trap

HashiCorp often tests the misconception that enabling the transit secrets engine alone solves the network restriction, but the key point is that the application still needs a way to call Vault's API—Vault Agent sidecar provides that local proxy without requiring outbound HTTP.

How to eliminate wrong answers

Option A is wrong because Vault replication replicates data between Vault clusters (e.g., for disaster recovery or performance), but it does not enable local encryption operations without outbound HTTP calls; the application would still need to make requests to the local Vault instance, which may still require network connectivity. Option C is wrong because using Vault's HTTP API directly from the application requires outbound HTTP requests to Vault, which is explicitly prohibited by the restricted network. Option D is wrong because enabling the transit secrets engine and calling Vault's encrypt endpoint also requires the application to make outbound HTTP requests to Vault, violating the network restriction.

Full explanation →
25
Multi-Selecteasy

Which TWO of the following storage backends are capable of high availability without external dependencies? (Choose two.)

Select 2 answers
A.File storage backend
B.Integrated Storage (Raft)
C.In-memory storage backend with replication
D.Consul storage backend
E.MySQL storage backend
AnswersB, C

Raft provides HA natively within Vault.

Why this answer

Integrated Storage (Raft) is correct because it provides a fully internal consensus-based storage backend that does not rely on any external system. Raft manages Vault's data directly across a cluster of nodes, ensuring high availability through leader election and log replication without needing Consul, etcd, or any other external dependency.

Exam trap

HashiCorp often tests the distinction between 'high availability' and 'external dependency' — candidates mistakenly think that any backend supporting HA qualifies, but the trap is that Consul and MySQL require separate, external infrastructure to achieve that HA, whereas Integrated Storage and in-memory with replication are self-contained within Vault.

Full explanation →
26
Multi-Selectmedium

Which THREE authentication methods support generating tokens with TTL and renewable options?

Select 3 answers
A.Kubernetes authentication
B.Userpass authentication
C.AppRole authentication
D.Token authentication
E.LDAP authentication
AnswersB, D, E

Userpass creates tokens with configurable TTL and renew.

Why this answer

Userpass authentication (B) is correct because Vault's userpass auth method supports token generation with configurable TTL (time-to-live) and renewable options via the `token_ttl` and `token_renewable` parameters in the auth method configuration or role settings. This allows administrators to enforce session lifetimes and permit token renewal for user accounts authenticated via username/password.

Exam trap

HashiCorp often tests the misconception that all auth methods inherently support TTL and renewable options, but in Vault, only methods that generate a token (like userpass, LDAP, and token auth) directly support these parameters, whereas methods like Kubernetes rely on role-level configuration and do not expose TTL/renewable as native auth method settings.

Full explanation →
27
MCQmedium

A company is using Vault's Integrated Storage (Raft) for high availability. During a network partition, two Vault nodes become isolated from the third. What happens to the isolated nodes?

A.The two isolated nodes continue to serve requests, the third stops
B.All three nodes automatically rejoin after partition
C.All three nodes continue to serve requests
D.The two isolated nodes stop serving requests
AnswerA

The two nodes have quorum; the isolated third does not.

Why this answer

In Vault Integrated Storage (Raft), a quorum of nodes (majority) is required to maintain cluster leadership and serve requests. During a network partition where two nodes are isolated from the third, the two nodes form a majority (2 out of 3) and can continue to serve requests, while the isolated third node loses quorum and stops serving requests to prevent split-brain. This behavior is enforced by the Raft consensus algorithm, which requires a majority for any write or read operations to ensure consistency.

Exam trap

HashiCorp often tests the misconception that all nodes in a partitioned cluster stop serving requests, but the correct understanding is that only the minority side (nodes that lose quorum) stop, while the majority side continues to operate normally.

How to eliminate wrong answers

Option B is wrong because Raft does not automatically rejoin nodes after a partition; manual intervention or network restoration is required, and the isolated node will remain in a non-voting state until it can re-establish connectivity and catch up with the leader's log. Option C is wrong because if all three nodes continued to serve requests during a partition, it would lead to split-brain scenarios with inconsistent data, which Raft explicitly prevents by requiring a quorum. Option D is wrong because the two isolated nodes form a majority (2 out of 3) and therefore continue to serve requests; only the minority node (the single isolated node) stops serving requests.

Full explanation →
28
MCQhard

An application encrypts data using the transit engine and stores the ciphertext in a database. After a key rotation, the application can no longer decrypt the data. What is the most likely cause?

A.The ciphertext was generated with a different key
B.The token used for decryption has been revoked
C.The key was rotated and the old version was automatically deleted
D.The `min_decryption_version` was set to a value higher than the old key version
E.The transit engine was disabled
AnswerD

This prevents decryption with older versions, a common misconfiguration.

Why this answer

Option D is correct because the `min_decryption_version` parameter in Vault's transit engine specifies the minimum key version that can be used for decryption. After a key rotation, if this value is set higher than the old key version, the engine will refuse to decrypt data encrypted with that older version, even if the old key data is still present in the key ring. This is a common misconfiguration that leads to decryption failures post-rotation.

Exam trap

HashiCorp often tests the misconception that key rotation automatically deletes old keys, leading candidates to choose Option C, but the real issue is the `min_decryption_version` parameter that explicitly blocks decryption with older key versions.

How to eliminate wrong answers

Option A is wrong because the ciphertext is always generated with the current key version at the time of encryption; after rotation, the key used for encryption is still valid for decryption unless explicitly restricted. Option B is wrong because the transit engine does not use tokens for decryption; tokens are used for authentication and authorization, not for the cryptographic operation itself. Option C is wrong because Vault's transit engine does not automatically delete old key versions upon rotation; they are retained by default to allow decryption of existing ciphertexts.

Option E is wrong because disabling the transit engine would prevent all cryptographic operations, not just decryption of old data, and the question states the application can no longer decrypt, not that the engine is unavailable.

Full explanation →
29
MCQhard

A DevOps team uses Vault dynamic secrets for database credentials with a lease of 1 hour. They notice that applications are making excessive calls to renew leases, causing performance issues. The team wants to reduce the renewal frequency while maintaining security. What is the best approach?

A.Increase the default lease TTL to 8 hours and configure periodic tokens with a short TTL.
B.Remove the TTL entirely so that credentials never expire.
C.Decrease the default lease TTL from 1 hour to 30 minutes.
D.Increase the maximum TTL for the role to 24 hours.
AnswerA

A longer lease reduces renewal frequency, and periodic tokens ensure the overall lifetime is bounded.

Why this answer

Option A is correct because increasing the default lease TTL to 8 hours reduces the frequency of lease renewals, directly addressing the performance issue. Configuring periodic tokens with a short TTL ensures that the token itself still rotates frequently, maintaining security by limiting the window of exposure if a token is compromised. This balances reduced renewal overhead with strong security posture.

Exam trap

HashiCorp often tests the distinction between lease TTL and token TTL, and the trap here is that candidates mistakenly think increasing the maximum TTL (option D) will reduce renewal frequency, when in fact it only sets a ceiling and does not change the actual lease duration.

How to eliminate wrong answers

Option B is wrong because removing the TTL entirely (setting credentials to never expire) violates the principle of dynamic secrets and creates a permanent security risk, as compromised credentials would remain valid indefinitely. Option C is wrong because decreasing the default lease TTL to 30 minutes would increase the renewal frequency, worsening the performance issue rather than solving it. Option D is wrong because increasing the maximum TTL for the role to 24 hours only sets an upper bound; it does not change the actual lease duration (which remains at 1 hour) and thus does not reduce renewal calls.

Full explanation →
30
Multi-Selectmedium

A DevOps team needs to implement encryption as a service for application data stored in a PostgreSQL database. They want to use Vault's transit secrets engine to encrypt sensitive fields before storage. Which TWO actions should the team take to ensure the encryption keys are rotated automatically and securely?

Select 2 answers
A.Set 'min_decryption_version' to the latest key version to force re-encryption of old data.
B.Use a key derivation function with a unique context per application context to ensure each encryption produces distinct ciphertext.
C.Disable key rotation and rely on manual key updates using the transit key/rotate endpoint.
D.Restrict access to the decryption capability to prevent adversaries from learning the key material.
E.Configure a key rotation period using the 'auto_rotate_period' parameter when creating or tuning the encryption key.
AnswersB, E

Key derivation per context ensures that even if a ciphertext is exposed, it cannot be used across different contexts.

Why this answer

Option B is correct because using a key derivation function (KDF) with a unique context per application ensures that each encryption operation produces distinct ciphertext even if the same plaintext and key are used. This prevents ciphertext correlation attacks and is a recommended practice when encrypting many records with the same key. Option E is correct because Vault's transit secrets engine supports the 'auto_rotate_period' parameter, which allows you to set a time-based automatic rotation schedule for the encryption key, ensuring keys are rotated without manual intervention.

Exam trap

HashiCorp often tests the distinction between key rotation (creating new key versions) and re-encryption of data (rewrapping ciphertext), and the trap here is that candidates confuse setting 'min_decryption_version' with automatically re-encrypting old data, when in fact it only controls which key versions are allowed for decryption.

Full explanation →
31
MCQhard

A token with a policy that explicitly denies 'read' on 'secret/engineering/private' is issued. The same token also has another policy that grants 'read' on 'secret/engineering/*'. What is the result when the token tries to read 'secret/engineering/private'?

A.The read succeeds because the grant from the wildcard policy is more permissive
B.The read fails because the policies conflict and Vault defaults to deny
C.The read succeeds because the token has a separate policy that grants read
D.The read fails because the explicit deny on the specific path takes precedence
AnswerD

Vault's ACL model gives deny precedence over allow.

Why this answer

Option B is correct because Vault's ACL system uses a deny-first approach: if any policy explicitly denies a capability, it takes precedence over grants. Option A is wrong because the grant is overridden by the explicit deny. Option C is wrong because the token has both policies; one does not override the other unless there is an explicit deny.

Option D is wrong because the deny is explicit, not a lack of permission.

Full explanation →
32
MCQhard

A large enterprise uses Vault with multiple namespaces for different business units. The security team has implemented a policy that requires all tokens to be created with a bounded set of allowed policies defined in a token role. The token role allows policies 'app-dev', 'app-staging', and 'app-prod' for the development namespace. The token role has token_type set to 'service'. A developer attempts to create a token using this role but specifies an additional policy 'admin' in the creation request. The Vault administrator expects this request to fail because 'admin' is not in the allowed policies list. However, the token is created successfully with only the allowed policies applied. Why did the request succeed?

A.The token role's 'token_type' was set to 'batch', which ignores policy restrictions.
B.The token role had 'allowed_policies_glob' set to 'app-*', which matched 'admin' as well.
C.Vault ignores the 'allowed_policies' list when the token creation request includes policies, as long as one of the requested policies is in the allowed list.
D.The developer added the 'admin' policy directly to the token role before creating the token.
AnswerB

Correct: 'allowed_policies_glob' uses glob patterns and can override 'allowed_policies'; 'app-*' matches 'admin'? Actually 'admin' does not start with 'app-', but a pattern like '*' or 'a*' could match; this is a plausible reason if the glob is too permissive.

Why this answer

In Vault, token roles define constraints on token creation. If a token creation request includes policies not in the allowed list, Vault will typically reject the request. However, if the token role has 'allowed_policies_glob' set to a pattern that inadvertently allows all policies, or if the role has 'allowed_policies' set to include wildcards, the request may succeed.

Option C is correct because the 'allowed_policies_glob' field can override 'allowed_policies' and allow policies that match a pattern. Option A is incorrect because the token type is 'service', which is the default. Option B is incorrect because adding a policy to a token role does not affect role constraints.

Option D is incorrect because ignoring the request is not default behavior; usually Vault enforces the allowed list strictly.

Full explanation →
33
MCQeasy

Refer to the exhibit. What operation was performed on the secret "mysecret"?

A.Write
B.Read
C.Delete
D.List
AnswerB

The operation field is 'read'.

Why this answer

The exhibit shows a Vault CLI command that retrieves the value of a secret at the path 'secret/mysecret'. The 'vault read' command is used to read data from Vault's key-value store, returning the stored value. Since the command 'vault read secret/mysecret' is executed, the operation performed is a Read, making option B correct.

Exam trap

HashiCorp often tests the distinction between 'vault read' and 'vault list', where candidates confuse listing keys under a path with reading the actual secret value, leading them to incorrectly select 'List' instead of 'Read'.

How to eliminate wrong answers

Option A is wrong because 'Write' would correspond to a 'vault write' command, which stores or updates a secret, not retrieves it. Option C is wrong because 'Delete' would require a 'vault delete' command, which removes the secret from the path. Option D is wrong because 'List' would use a 'vault list' command, which enumerates keys under a path, not retrieve a specific secret's value.

Full explanation →
34
MCQhard

A company uses Vault to manage SSH OTP credentials. They set the role with default_ttl=5m and max_ttl=30m. Users report that they receive an error when trying to renew the OTP after 10 minutes. What is the most likely reason?

A.The OTP key is only valid for one-time use and cannot be renewed.
B.The renewable flag is set to false on the role.
C.The user's token does not have permission to renew leases.
D.The max_ttl of 30m is reached, but the OTP has already been used.
AnswerA

SSH OTPs are consumed on use and cannot be renewed.

Why this answer

Vault SSH OTP credentials are designed for one-time use: the OTP is generated, used to authenticate an SSH session, and then immediately invalidated. Once the OTP has been used, it cannot be renewed because the lease is tied to a credential that has already been consumed. The error after 10 minutes occurs because the OTP was used within that window, making renewal impossible regardless of TTL settings.

Exam trap

HashiCorp often tests the misconception that lease renewal is always possible as long as the TTL has not expired, but for one-time credentials like SSH OTP, the lease becomes non-renewable immediately after the credential is used.

How to eliminate wrong answers

Option B is wrong because the `renewable` flag on a Vault role controls whether the lease can be renewed before the credential is used, but SSH OTP credentials are inherently non-renewable after use due to their one-time nature; even if the flag were true, renewal would fail after the OTP is consumed. Option C is wrong because the error is not about token permissions—the user's token may have full renewal permissions, but the lease itself becomes invalid once the OTP is used. Option D is wrong because the max_ttl of 30m is not reached at 10 minutes; the issue is that the OTP has already been used, not that the TTL limit has been exceeded.

Full explanation →
35
MCQeasy

A user receives this error when trying to read a secret. What is the most likely cause?

A.The secret engine is not enabled
B.The token is a root token
C.The token has expired
D.The token's policy does not grant read on that path
AnswerD

Permission denied indicates the token lacks the necessary capability.

Why this answer

Option B is correct because the 403 error with 'permission denied' typically indicates the token lacks the required capability. Option A is wrong because token expiration also returns a 403, but the error message would usually include 'token expired' or similar, not just 'permission denied'. Option C is wrong because a missing secret engine would return a 404.

Option D is wrong because root tokens have full access and would not get permission denied.

Full explanation →
36
Multi-Selectmedium

A user wants to view information about their current token, including its policies and TTL. Which TWO CLI commands can be used?

Select 2 answers
A.vault read auth/token/lookup-self
B.vault token list
C.vault write auth/token/lookup
D.vault token info
E.vault token lookup
AnswersA, E

C is correct: reads the self-lookup API endpoint.

Why this answer

Option A is correct because `vault read auth/token/lookup-self` is a standard Vault CLI command that retrieves information about the current token, including its policies, Time-To-Live (TTL), and other metadata. This command uses the token lookup-self API endpoint, which is specifically designed for the calling token to inspect itself without needing explicit read permissions on its own token ID.

Exam trap

HashiCorp often tests the distinction between `vault token lookup` (which works for self-lookup without arguments) and `vault token info` (which does not exist), trapping candidates who assume a generic 'info' subcommand exists across all CLI tools.

Full explanation →
37
MCQeasy

A user has the above policy attached. What operation can the user perform on 'secret/data/production/db_password'?

A.Update the metadata of the secret
B.Read the secret
C.Delete the secret
D.Write a new version of the secret
AnswerB

Read capability is explicitly granted.

Why this answer

The policy grants 'read' capability on 'secret/data/production/db_password'. In Vault's KV Secrets Engine v2, the 'read' capability allows retrieving the secret data and its metadata. Therefore, the user can read the secret, which includes both the data and metadata.

Option B is correct because the policy explicitly allows the read operation on that path.

Exam trap

HashiCorp often tests the distinction between capabilities on the data path versus the metadata path, tricking candidates into thinking 'read' on the data path allows modifying metadata when it only allows reading it.

How to eliminate wrong answers

Option A is wrong because 'update metadata' requires the 'update' capability on the metadata path, not just 'read'. Option C is wrong because 'delete' requires the 'delete' capability, which is not granted by the policy. Option D is wrong because writing a new version requires the 'create' or 'update' capability, neither of which is present in the policy.

Full explanation →
38
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.

Full explanation →
39
Matchingmedium

Match each Vault secret engine to its primary purpose.

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

Concepts
Matches

Key-value storage with versioning

Dynamic AWS IAM credentials

X.509 certificate generation

Encryption as a service

Dynamic database credentials

Why these pairings

These are common Vault secret engines and their core functions.

Full explanation →
40
MCQmedium

A CI/CD pipeline needs to generate thousands of short-lived tokens each day for jobs that run for at most 5 minutes. The tokens should not be renewable or revocable individually. Which token type should be used?

A.Orphan tokens
B.Service tokens
C.Batch tokens
D.Periodic tokens
AnswerC

Batch tokens are non-renewable, non-revocable, and ideal for high-volume short-lived tokens.

Why this answer

Option D is correct because batch tokens are non-renewable, non-revocable, and suitable for high-volume, short-lived scenarios. Option A is wrong because service tokens are renewable and revocable, adding overhead. Option B is wrong because periodic tokens never expire unless explicitly revoked, which is not desired.

Option C is wrong because orphan tokens are a property, not a type.

Full explanation →
41
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

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

Full explanation →
42
MCQhard

A large enterprise runs Vault in a high-availability cluster with integrated storage (Raft). They notice that read requests are not being evenly distributed across nodes, causing some nodes to have high load. They want to offload read operations to standby nodes. What feature should they enable to achieve this?

A.Enable performance standby nodes
B.Configure a load balancer with a round-robin algorithm
C.Enable read replicas on standby nodes
D.Increase the number of Raft nodes to distribute reads
AnswerA

Performance standby nodes can serve read requests and handle authentication, distributing the load.

Why this answer

Performance standby nodes are a Vault Enterprise feature designed to handle read requests without participating in the Raft consensus write quorum. By enabling this, read operations are offloaded to standby nodes, distributing the load evenly and reducing the burden on the active cluster nodes. This directly addresses the uneven read distribution and high load on specific nodes.

Exam trap

HashiCorp often tests the misconception that a standard load balancer or adding more Raft nodes can solve read distribution issues, but the correct solution is the Vault Enterprise-specific performance standby nodes feature, which is designed exactly for this purpose.

How to eliminate wrong answers

Option B is wrong because configuring a load balancer with round-robin does not change Vault's internal read distribution; all nodes still handle reads equally, and without performance standby nodes, standby nodes do not serve read requests in a Raft cluster. Option C is wrong because Vault does not support read replicas; this is a database concept, not applicable to Vault's integrated storage architecture. Option D is wrong because increasing the number of Raft nodes only adds more nodes to the write quorum, which can actually increase write latency and does not offload reads to standby nodes—all Raft nodes still participate in read handling equally.

Full explanation →
43
MCQhard

An administrator notices that after revoking a specific lease, the underlying database credential is still accessible. What is the most likely cause?

A.The revocation script failed to delete the database user.
B.The secret engine caches credentials.
C.The lease ID was incorrect.
D.The lease was renewed after revocation.
AnswerA

If the revocation script fails, the credential remains despite lease revocation.

Why this answer

Option A is correct because when a lease is revoked in Vault, the revocation script associated with the database secret engine is responsible for deleting or disabling the corresponding database user. If that script fails (e.g., due to insufficient permissions, network issues, or a bug in the script), the underlying credential remains active in the database, even though the lease is no longer valid in Vault. This is a common operational issue where the lease lifecycle and the actual credential lifecycle become out of sync.

Exam trap

HashiCorp often tests the misconception that lease revocation automatically guarantees the underlying resource is destroyed, but the trap is that revocation only manages the Vault-side lease metadata, not the external resource, which depends on the success of the configured revocation script.

How to eliminate wrong answers

Option B is wrong because Vault's database secret engine does not cache credentials; each lease corresponds to a unique database user created dynamically, and revocation directly invokes the script to remove that user. Option C is wrong because if the lease ID were incorrect, Vault would return an error or not find the lease, but the question states the lease was successfully revoked, meaning the lease ID was valid. Option D is wrong because once a lease is revoked, it cannot be renewed; renewal is only possible before revocation, and attempting to renew after revocation would fail.

Full explanation →
44
MCQmedium

A team wants to use Vault's AWS auth method to authenticate EC2 instances. Which architectural requirement must be met?

A.Each EC2 instance must have an IAM role attached
B.Vault must have AWS API credentials configured
C.Vault must be deployed on an EC2 instance in the same region
D.Vault must be able to reach the AWS metadata endpoint
AnswerD

Vault verifies instance identity via metadata.

Why this answer

The AWS auth method in Vault authenticates EC2 instances by verifying the instance's identity via the AWS metadata endpoint (http://169.254.169.254/latest/meta-data/). Vault must be able to reach this endpoint to retrieve the instance's PKCS7 signature, instance ID, and account ID, which are used to validate the instance's IAM role and ensure it matches the configured auth role. Without network access to the metadata endpoint, Vault cannot perform the cryptographic verification required for authentication.

Exam trap

HashiCorp often tests the misconception that Vault requires AWS API credentials or an IAM role for the AWS auth method, when in fact it only needs network access to the EC2 metadata endpoint to perform identity verification.

How to eliminate wrong answers

Option A is wrong because while an IAM role is typically used to bind the instance to a Vault role, it is not a strict architectural requirement; the AWS auth method can also use the instance's AMI ID or account ID for binding, and the instance does not need an IAM role attached if other identity parameters are used. Option B is wrong because Vault does not need AWS API credentials for the AWS auth method; it relies on the EC2 instance's metadata endpoint to verify the instance's identity, and AWS credentials are only required for the AWS secrets engine, not the auth method. Option C is wrong because Vault does not need to be deployed on an EC2 instance in the same region; it only needs network connectivity to the EC2 instance's metadata endpoint, which is accessible from any network path that can reach the instance's link-local address.

Full explanation →
45
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.

Full explanation →
46
Multi-Selectmedium

Which TWO of the following are true about token accessors?

Select 2 answers
A.Accessors are the token value
B.Accessors should be used in audit logs instead of token values
C.Accessors are unique identifiers for tokens
D.Accessors can be used to renew the token
AnswersB, C

This is a security best practice to avoid exposing tokens.

Why this answer

Token accessors are non-sensitive references that can be used for token lifecycle operations. They are unique and can be used to revoke tokens without knowing the token value. Option A is incorrect because accessors cannot be used to renew tokens.

Option C is incorrect because accessors are not the token value. Option D is incorrect because accessors can be used in audit logs, but that's a recommendation, not a limitation.

Full explanation →
47
Multi-Selectmedium

Which TWO authentication methods allow a machine to authenticate without storing a static secret? (Choose two.)

Select 2 answers
A.LDAP
B.AppRole
C.Kubernetes
D.Userpass
E.AWS
AnswersC, E

Kubernetes auth uses the pod's service account token, no static secret.

Why this answer

Kubernetes authentication in Vault uses the Kubernetes service account token (a JWT) to authenticate. The JWT is dynamically generated by the Kubernetes API server and is not a static secret stored by the machine; Vault verifies it against the Kubernetes API server's token review endpoint. This allows the machine to authenticate without storing a long-lived static credential.

Exam trap

HashiCorp often tests the misconception that AppRole is a 'secretless' method, but in reality, the RoleID is a static secret that must be stored, and the SecretID, while dynamic, still requires secure distribution, making it not truly stateless.

Full explanation →
48
Multi-Selecthard

Which three statements about lease renewal are correct? (Choose three.)

Select 3 answers
A.A lease can be renewed indefinitely.
B.Renewing a lease increments the lease number.
C.A lease can be renewed up to the max_lease_ttl.
D.Lease renewal requires 'sudo' capability.
E.The renew operation can extend the lease TTL.
AnswersB, C, E

Each renewal increases the lease number, visible in lease details.

Why this answer

Option B is correct because in Vault, each lease renewal increments the lease number (a monotonically increasing counter) to track the renewal history. This allows clients and Vault to detect replay attacks or stale renewals, as the lease ID remains the same but the lease number changes with each successful renew operation.

Exam trap

HashiCorp often tests the misconception that lease renewal is unlimited or requires elevated privileges, when in fact it is bounded by max_lease_ttl and only needs the lease ID and appropriate token capabilities.

Full explanation →
49
MCQeasy

An application needs to encrypt sensitive data before storing it in a database. The security team wants to use Vault's encryption as a service to avoid managing encryption keys. Which Vault secrets engine should they enable?

A.AWS
B.KV v2
C.Consul
D.Transit
E.PKI
AnswerD

The Transit engine is designed for encryption/decryption, signing, and HMAC operations without exposing keys.

Why this answer

The Transit secrets engine is designed specifically for encryption as a service, allowing applications to encrypt and decrypt data without ever having direct access to the encryption keys. The keys are stored and managed entirely within Vault, which meets the security team's requirement to avoid managing encryption keys themselves.

Exam trap

HashiCorp often tests the distinction between a secrets engine that stores secrets (KV v2) and one that processes cryptographic operations (Transit), leading candidates to mistakenly choose KV v2 because they think 'storing encrypted data' is the same as 'encrypting data'.

How to eliminate wrong answers

Option A is wrong because the AWS secrets engine is used to generate dynamic AWS credentials (access keys), not to perform encryption operations. Option B is wrong because KV v2 is a key-value store for static secrets, not an encryption engine; it stores data as-is without providing encrypt/decrypt API endpoints. Option C is wrong because the Consul secrets engine generates Consul API tokens for service mesh access, not encryption services.

Option E is wrong because the PKI secrets engine generates X.509 certificates for TLS/SSL, not for encrypting arbitrary data.

Full explanation →
50
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

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

Full explanation →
51
MCQmedium

Refer to the exhibit. A user with this policy attempts to read 'secret/data/team/admin'. What will happen?

A.Read succeeds because the first path allows read.
B.Read fails because the path does not exist.
C.Read fails because deny overrides the broader path.
D.Read succeeds if the user also has sudo capability.
AnswerC

B is correct: deny overrides any allow.

Why this answer

Option C is correct because Vault's policy evaluation uses a deny-by-default model where explicit deny rules override any allow rules. The policy first allows read on 'secret/data/team/*' but then explicitly denies read on 'secret/data/team/admin'. Since the deny rule is more specific and matches the exact path, it takes precedence, causing the read operation to fail.

Exam trap

HashiCorp often tests the misconception that broader allow rules automatically grant access to all sub-paths, but the trap here is that an explicit deny on a more specific path always overrides the broader allow, and candidates mistakenly think sudo can bypass deny rules.

How to eliminate wrong answers

Option A is wrong because it ignores the explicit deny rule; in Vault, a deny on a more specific path overrides a broader allow. Option B is wrong because the path 'secret/data/team/admin' does exist in the policy context; the failure is due to the deny rule, not a missing path. Option D is wrong because sudo capability in Vault allows bypassing ACL path restrictions but does not override explicit deny rules; sudo only applies to path capabilities, not to deny enforcement.

Full explanation →
52
MCQmedium

A security audit reveals that many Vault tokens in an organization are orphan tokens (tokens with no parent). The tokens were created using a batch token creation script that did not set an explicit parent. The security team is concerned about these orphan tokens because they cannot be managed through the usual parent-child hierarchy. They want to revoke all orphan tokens created more than 30 days ago. However, the team does not have a list of token IDs for these tokens. Which approach should the team take to revoke the orphan tokens?

A.Reinitialize Vault and restore from a snapshot taken before the orphan tokens were created.
B.If the team stored token accessors at creation time, use the accessors to revoke the tokens via the /auth/token/revoke-accessor endpoint.
C.Use the token's parent token (the batch token creation script's token) to recursively revoke all children, which includes orphan tokens.
D.Revoke the batch token creation script's token and all its children, which will indirectly revoke orphan tokens associated with that script.
AnswerB

Correct: Accessors allow revocation without the token ID, making them ideal for orphan tokens if accessors were captured.

Why this answer

To revoke orphan tokens without token IDs, the team can leverage token accessors. If accessors were stored at creation time, they can be used to revoke tokens. However, if not stored, the team can list tokens using sys/internal/ui/mounts or auth/token/roles, but that may not directly provide accessors.

The most direct method is to use the token accessor lookup endpoint if accessors were logged. Option B is correct because revoking via accessors does not require token IDs. Option A is not directly possible without knowing the parent.

Option C would only affect the creating auth method but not orphan tokens. Option D is an extreme measure and not recommended without exploring alternatives.

Full explanation →
53
MCQhard

Refer to the exhibit. A user authenticates via the userpass method. The token helper stores the token. The user's default policy grants read access to secret/data/engineering. The user attempts to read secret/data/engineering using `vault kv get secret/engineering`. The command fails with "permission denied". What is the most likely reason?

A.The token helper is interfering by providing an expired token.
B.The default policy does not include the path "secret/data/engineering".
C.The CLI command should use `vault read secret/data/engineering` instead.
D.The userpass authentication method requires a one-time password for each operation.
AnswerB

The default policy only grants capabilities for token management, not secret reading.

Why this answer

Option D is correct because the default policy typically does not include read access to secrets; it only allows token management. The command syntax is correct for KV v2, and the token is valid. Option A is wrong because the token is newly created and stored correctly.

Option B is wrong because the command `vault kv get` is the appropriate CLI command for KV v2. Option C is wrong because userpass does not require OTP.

Full explanation →
54
Multi-Selecteasy

Which TWO statements are true when troubleshooting a failed Vault CLI command?

Select 2 answers
A.Run 'vault token lookup' to verify the token is valid and has the expected policies.
B.Run 'vault write' to test if the token can write to a path.
C.Run 'vault login' to re-authenticate and obtain a new token if needed.
D.Run 'vault status' to check if the server is reachable.
E.Run 'vault read' to test if any secret is accessible.
AnswersA, C

This helps diagnose token-related issues.

Why this answer

Option A is correct because `vault token lookup` is the standard diagnostic command to inspect the current token's metadata, including its validity, creation time, TTL, and associated policies. If the token is expired, revoked, or lacks the necessary policies for the failed command, this command will reveal the issue directly without side effects.

Exam trap

HashiCorp often tests the misconception that `vault status` is the first troubleshooting step for any CLI failure, but it only verifies server reachability and seal state, not token or permission issues.

Full explanation →
55
Multi-Selecthard

A Vault policy must allow a service to read secrets from "secret/data/app" and also be able to renew its own token. Which two policy statements are necessary and sufficient for this requirement? (Select two.)

Select 2 answers
A.path "secret/data/app" { capabilities = ["read"] }
B.path "auth/token/renew-self" { capabilities = ["update"] }
C.path "auth/token/renew" { capabilities = ["update"] }
D.path "secret/data/app/*" { capabilities = ["read"] }
E.path "sys/auth" { capabilities = ["read"] }
AnswersA, B

This provides read access to the specific secret path.

Why this answer

The necessary statements are path "secret/data/app" with read capability and path "auth/token/renew-self" with update capability. The other options either provide too much or are not relevant.

Full explanation →
56
MCQhard

A large enterprise runs a microservices architecture on Kubernetes. Each microservice authenticates to Vault using the Kubernetes auth method with a service account token. The Vault administrator configured a role 'microservice-role' with a TTL of 24h and a max TTL of 48h. The microservices renew their tokens every 12 hours via a sidecar. Recently, the security team noticed that some tokens are still valid after 72 hours, causing a security concern. The audit logs show that the tokens were renewed successfully multiple times. The administrator reviews the role configuration and sees that 'token_renewable' is set to true. What is the most likely reason the tokens are exceeding the intended 48h max TTL?

A.The sidecar renewal interval is too short, causing the token to be renewed before the max TTL is checked
B.The Kubernetes auth method's default TTL overrides the role's max TTL
C.The Vault role's max TTL is not propagated to the token because the token was created with a different policy
D.The Kubernetes service account token used for authentication is long-lived, allowing the Vault token to be renewed indefinitely
AnswerD

If the underlying auth token never expires, Vault tokens can be renewed up to their max TTL, but if the max TTL is not set correctly or the role allows renewal beyond max TTL due to a bug, it could exceed. However, the most common cause is that the Kubernetes API token used by the auth method is long-lived, and the Vault role's max TTL is not enforced because the auth method does not track the external identity's expiry.

Why this answer

The Kubernetes auth method uses the service account token to authenticate and derive a Vault token. If the Kubernetes service account token is long-lived (non-bound), the Vault token can be renewed indefinitely as long as the Kubernetes token remains valid, because the renewal process re-authenticates against the Kubernetes API and obtains a fresh lease. The role's max TTL of 48h is enforced only if the underlying Kubernetes token expires or is revoked; otherwise, Vault's renewal mechanism can extend the token beyond the configured max TTL.

Exam trap

HashiCorp often tests the misconception that the role's max TTL is an absolute hard limit, but in reality, the Kubernetes auth method's token lifetime is also dependent on the underlying service account token's validity, allowing indefinite renewal if that token is long-lived.

How to eliminate wrong answers

Option A is wrong because the sidecar renewal interval (12h) is shorter than the token TTL (24h) and does not affect max TTL enforcement; max TTL is a hard limit that Vault checks during renewal, not a function of renewal frequency. Option B is wrong because the Kubernetes auth method does not have a separate default TTL that overrides the role's max TTL; the role's max TTL is the authoritative upper bound unless explicitly overridden by a mount-level configuration, which is not mentioned. Option C is wrong because the token's policy does not influence TTL or max TTL propagation; max TTL is set at the role level and is applied to all tokens created by that role regardless of attached policies.

Full explanation →
57
MCQhard

A Vault cluster uses Integrated Storage. During a planned upgrade, the administrator wants to minimize downtime. Which upgrade strategy should be used?

A.Upgrade all nodes at once
B.Perform a rolling upgrade one node at a time
C.Stop all nodes, upgrade, then start
D.Add new upgraded nodes then remove old ones
AnswerB

Maintains quorum and availability.

Why this answer

Integrated Storage (Raft-based) requires a quorum of nodes to maintain cluster availability. A rolling upgrade, where each node is upgraded one at a time, ensures that the cluster never loses quorum (more than half of the nodes remain online and functional), minimizing downtime while the upgrade proceeds.

Exam trap

HashiCorp often tests the misconception that stopping all nodes or upgrading all at once is acceptable for a clustered system, but the trap is that candidates overlook the critical requirement of maintaining Raft quorum to avoid cluster unavailability and potential data loss.

How to eliminate wrong answers

Option A is wrong because upgrading all nodes at once would temporarily remove all nodes from the cluster, causing a complete loss of quorum and total downtime until the upgrade finishes. Option C is wrong because stopping all nodes before upgrading eliminates the cluster entirely, resulting in maximum downtime and no high availability during the process. Option D is wrong because adding new upgraded nodes then removing old ones is a blue/green deployment strategy that is not natively supported by Integrated Storage without manual reconfiguration and data rebalancing, and it introduces unnecessary complexity and risk of data inconsistency.

Full explanation →
58
Multi-Selectmedium

Which two commands can be used to manually revoke leases? (Choose two.)

Select 2 answers
A.vault secrets disable <path>
B.vault token revoke <token>
C.vault lease revoke <lease_id>
D.vault lease renew <lease_id>
E.vault lease revoke -prefix <prefix>
AnswersC, E

This revokes a specific lease.

Why this answer

Both 'vault lease revoke <lease_id>' and 'vault lease revoke -prefix <prefix>' are valid commands for manually revoking leases. Other options either renew, disable the entire mount, or revoke tokens.

Full explanation →
59
Multi-Selecthard

Which THREE factors influence the maximum TTL of a token?

Select 3 answers
A.The TTL set on the token role.
B.The max TTL of the auth method or mount.
C.The token's current TTL.
D.The max TTL set on the token role.
E.The system's default max TTL (usually 32 days).
AnswersB, D, E

The auth method's max TTL imposes a limit.

Why this answer

The maximum TTL is determined by the minimum of: the token role's max TTL, the auth method's max TTL, and the system's default max TTL. The role's default TTL and current TTL do not affect max TTL.

Full explanation →
60
MCQeasy

What is the purpose of the Seal/Unseal process in Vault architecture?

A.To delete old secrets
B.To rotate the encryption key
C.To back up the storage backend
D.To enable Vault to process requests
AnswerD

Unsealing allows Vault to decrypt the master key and serve requests.

Why this answer

The Seal/Unseal process in Vault is a security mechanism that protects the encryption key used to encrypt data at rest. When Vault starts, it is in a sealed state and cannot process any requests until it is unsealed by providing a threshold number of unseal keys (shards). Unsealing decrypts the master key in memory, allowing Vault to access the storage backend and serve API requests.

Option D is correct because the primary purpose is to enable Vault to process requests after a secure startup.

Exam trap

HashiCorp often tests the misconception that Seal/Unseal is about key rotation or backup, when in reality it is a startup security gate that prevents Vault from processing requests until the master key is decrypted in memory.

How to eliminate wrong answers

Option A is wrong because deleting old secrets is handled by secret lifecycle policies, TTLs, or manual revocation, not by the Seal/Unseal process. Option B is wrong because encryption key rotation is a separate operation (e.g., using `vault rotate` or automatic key rotation policies) and does not involve the unsealing workflow. Option C is wrong because backing up the storage backend is an operational task (e.g., snapshotting the file system or database) and is unrelated to the cryptographic unsealing mechanism.

Full explanation →
61
MCQhard

After a Vault migration, some leases are no longer valid and cause errors. What is the best way to force a cleanup of all leases under a specific mount without affecting other mounts?

A.Restart Vault servers
B.Disable and re-enable the secret engine
C.Use vault lease revoke -prefix <mount>
D.Reduce the mount's max_lease_ttl to 0
AnswerC

This revokes all leases under the given mount prefix.

Why this answer

Using 'vault lease revoke -prefix <mount>' revokes all leases under that prefix, effectively cleaning them up without disabling the engine.

Full explanation →
62
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

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

Full explanation →
63
MCQeasy

An organization has two Vault clusters in different geographic regions and wants to replicate secrets from the primary cluster to the secondary cluster for disaster recovery. Which Vault replication feature should they use?

A.Cluster replication
B.Active Directory replication
C.Disaster Recovery (DR) replication
D.Performance replication
AnswerC

DR replication replicates all data including secrets, policies, and configuration for failover.

Why this answer

Disaster Recovery (DR) replication is the correct Vault feature for replicating secrets from a primary cluster to a secondary cluster in a different geographic region for disaster recovery. DR replication copies all data, including secrets, policies, and tokens, in a one-way direction from primary to secondary, ensuring the secondary cluster can be promoted if the primary fails. This is distinct from performance replication, which is designed for load distribution and allows writes on both sides.

Exam trap

HashiCorp often tests the distinction between DR replication and Performance replication, trapping candidates who confuse the two by assuming Performance replication can also serve as a disaster recovery solution, when in fact it allows writes on both sides and is not designed for failover scenarios.

How to eliminate wrong answers

Option A is wrong because 'Cluster replication' is not a Vault feature; Vault uses 'Replication' as a core feature with specific modes (DR and Performance), and there is no standalone 'Cluster replication' mode. Option B is wrong because Active Directory replication is a Microsoft technology for synchronizing directory data across domain controllers, not a Vault feature. Option D is wrong because Performance replication is intended for scaling read operations across clusters in different datacenters, allowing writes on both sides, which is not suitable for a strict disaster recovery scenario where a single authoritative primary is required.

Full explanation →
64
MCQhard

Refer to the exhibit. Based on this policy, which actions can the associated token perform? (Assume all paths exist.)

A.Only encrypt and decrypt data.
B.Create and read keys, encrypt and decrypt data.
C.Only manage keys, not encrypt/decrypt.
D.Create keys only.
E.Create, read, update, delete keys; encrypt and decrypt data.
AnswerE

All listed capabilities are granted.

Why this answer

The exhibit shows a policy that grants the 'manage' capability on a key, which in Vault (the implied technology) includes create, read, update, and delete operations. Additionally, the policy includes 'encrypt' and 'decrypt' capabilities, allowing the token to perform both key management and cryptographic operations. Therefore, the token can create, read, update, delete keys, and encrypt/decrypt data.

Exam trap

HashiCorp often tests the distinction between 'manage' (which implies full CRUD on keys) and individual capabilities like 'create' or 'read', leading candidates to underestimate the scope of the 'manage' capability.

How to eliminate wrong answers

Option A is wrong because it only mentions encrypt and decrypt, ignoring the key management capabilities explicitly granted by the policy. Option B is wrong because it includes 'create and read keys' but omits 'update' and 'delete', which are part of the 'manage' capability. Option C is wrong because it states 'only manage keys, not encrypt/decrypt', but the policy also grants encrypt and decrypt capabilities.

Option D is wrong because it limits the token to 'create keys only', while the policy grants a broader set of key management actions and cryptographic operations.

Full explanation →
65
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.

Full explanation →
66
Multi-Selecthard

An application uses transit encryption with convergent encryption enabled. Which THREE statements are true about convergent encryption? (Choose three.)

Select 3 answers
A.It requires a separate key for each context.
B.It produces the same ciphertext for the same plaintext and context.
C.It is typically slower than non-convergent encryption.
D.It can be used for deduplication of encrypted data.
E.It uses a nonce that is derived from the plaintext.
AnswersB, D, E

Deterministic output is a key feature of convergent encryption.

Why this answer

Convergent encryption derives the encryption key from the plaintext content itself, typically by hashing the plaintext. Because the same plaintext always produces the same key, and the encryption algorithm is deterministic (no random nonce), the resulting ciphertext is identical for identical plaintexts. This property directly enables deduplication of encrypted data, as identical ciphertexts can be identified and stored only once.

Exam trap

HashiCorp often tests the misconception that convergent encryption requires a separate key for each context (Option A), when in fact the key is derived from the plaintext and is the same for identical data regardless of context.

Full explanation →
67
Multi-Selectmedium

Which TWO of the following are valid methods to revoke a Vault token?

Select 2 answers
A.vault token revoke <token>
B.vault secrets disable <path>
C.vault auth disable <path>
D.vault token revoke -accessor <accessor>
E.vault policy delete <name>
AnswersA, D

This revokes the specified token.

Why this answer

Option A is correct because `vault token revoke <token>` is the direct command to revoke a specific Vault token by its token value. This invalidates the token immediately, preventing any further use. Option D is correct because `vault token revoke -accessor <accessor>` revokes a token using its accessor, which is a non-sensitive identifier that can be used to manage tokens without exposing the token itself.

Exam trap

The trap here is that candidates confuse disabling an auth method or secrets engine with token revocation, not realizing that disabling only prevents new operations but does not invalidate existing tokens.

Full explanation →
68
MCQeasy

What happens when a lease reaches its TTL?

A.The lease is marked as expired and can no longer be renewed.
B.The lease is automatically renewed.
C.The secret is automatically revoked.
D.The lease is deleted from storage.
AnswerD

Upon expiration, the lease is eventually garbage-collected, but immediate effect is expiration.

Why this answer

When a lease reaches its TTL, it expires and cannot be renewed. The secret may still exist but Vault will not extend the lease.

Full explanation →
69
MCQmedium

Based on the exhibit, what is the maximum lifetime of this token?

A.720 hours
B.The max TTL is shown as 'ttl' and cannot exceed that
C.The token is valid indefinitely because it is renewable
D.The token will expire at expire_time unless renewed
AnswerD

The max TTL is not shown; the token behaves with current TTL and can be renewed.

Why this answer

The token has a TTL of 720h (30 days) and is renewable, but the max TTL is not shown in this output. The max TTL is determined by the token role or system default. However, the question asks for 'maximum lifetime' based on the output.

The output shows ttl: 720h, which is the current remaining TTL. But the max TTL is not displayed. Typically, the 'expire_time' indicates when it will expire if not renewed.

But since it's renewable, the max lifetime could be longer. The safest answer is that the max TTL cannot be determined from this output. Option A is wrong because 720h is the current TTL, not necessarily the max.

Option B is wrong because expire_time is for current TTL. Option D is wrong because indefinite is not indicated.

Full explanation →
70
Matchingmedium

Match each Vault audit device to its output destination.

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

Concepts
Matches

Writes to a local file

Sends to system syslog

Sends to a TCP or UDP endpoint

Publishes to Kafka topic

Why these pairings

These are audit devices for logging Vault requests.

Full explanation →
71
MCQeasy

A security engineer needs to choose an authentication method for a set of microservices running in a Kubernetes cluster that require short-lived secrets. The method should leverage the pod's identity. Which method is best?

A.AppRole auth
B.Token auth
C.LDAP auth
D.Kubernetes auth
AnswerD

Kubernetes auth is purpose-built for pods to authenticate using service account tokens.

Why this answer

Kubernetes auth is the best choice because it allows a pod to authenticate to Vault using its own service account token, which is automatically mounted and short-lived. This method directly leverages the pod's identity without requiring manual secret distribution, making it ideal for microservices in a Kubernetes cluster that need ephemeral credentials.

Exam trap

HashiCorp often tests the misconception that AppRole is suitable for Kubernetes workloads because it is 'machine-oriented,' but they ignore that AppRole does not leverage the pod's native identity and requires out-of-band secret distribution.

How to eliminate wrong answers

Option A is wrong because AppRole auth requires a pre-shared RoleID and a generated SecretID, which are not inherently short-lived or tied to a pod's identity, and managing these for many microservices adds operational overhead. Option B is wrong because Token auth relies on static, long-lived tokens that must be manually distributed and rotated, contradicting the requirement for short-lived secrets and pod identity. Option C is wrong because LDAP auth is designed for user or machine authentication against an LDAP directory, not for Kubernetes pod identities, and it does not integrate with the pod's service account token.

Full explanation →
72
MCQhard

Refer to the exhibit. An operator wants the credential to be valid for exactly 2 hours. What should they do?

A.Increase the mount's max_lease_ttl to 2h.
B.Renew the lease with a TTL of 2h.
C.Increase the role's max_ttl to 2h.
D.Request a new credential with a TTL of 2h.
AnswerC

This allows renewals up to 2h, enabling the desired lifetime.

Why this answer

To allow a 2-hour total lifetime, the role's max_ttl must be at least 2h. The current lease TTL is 30m but can be renewed up to the role's max_ttl. Simply renewing with 2h TTL will fail if max_ttl is lower.

Increasing mount's max_lease_ttl does not change the role's maximum. Requesting a new credential does not have a direct TTL parameter.

Full explanation →
73
MCQeasy

Refer to the exhibit. Which authentication method is currently enabled for production applications?

A.Token
B.LDAP
C.AppRole
D.Userpass
AnswerC

AppRole is mounted at prod/.

Why this answer

The exhibit shows that the production applications are configured with the 'AppRole' authentication method, which is indicated by the presence of a RoleID and SecretID in the application configuration. AppRole is a machine-oriented authentication method in HashiCorp Vault that allows applications to authenticate using a pair of credentials (RoleID and SecretID), making it suitable for automated, non-human workflows. The other methods listed (Token, LDAP, Userpass) are either human-centric or not configured for these applications.

Exam trap

HashiCorp often tests the distinction between human-centric authentication methods (LDAP, Userpass) and machine-centric methods (AppRole, Token), and the trap here is that candidates mistakenly choose Token because it is simpler, overlooking that AppRole is specifically designed for production applications requiring dynamic, role-based credentials.

How to eliminate wrong answers

Option A is wrong because Token authentication uses a single static token, which is less secure and not designed for dynamic application workloads where credentials should be rotated or have limited lifetimes. Option B is wrong because LDAP authentication is used for human users authenticating against an external directory service (e.g., Active Directory), not for machine-to-machine authentication in production applications. Option D is wrong because Userpass authentication requires a username and password, which is intended for interactive human logins and not suitable for automated application authentication without additional secret management.

Full explanation →
74
MCQhard

An organization uses Vault to issue certificates via the PKI secrets engine. They have set the default lease TTL on the PKI mount to 72h, and the role's ttl to 24h. A user requests a certificate with a requested TTL of 48h. What will be the actual TTL of the issued certificate?

A.The request will be rejected because the requested TTL exceeds the role's ttl.
B.48h
C.24h
D.72h
AnswerC

The role's ttl is the effective TTL when it is lower than the mount default.

Why this answer

The correct answer is C (24h) because when a certificate request is made, Vault applies the most restrictive TTL among the role's configured `ttl`, the mount's default lease TTL, and the requested TTL. Here, the role's `ttl` of 24h is the shortest, so it overrides both the requested 48h and the mount default of 72h, resulting in a certificate with a 24-hour validity.

Exam trap

The trap here is that candidates often assume the requested TTL is honored as long as it is within the mount's default lease TTL, overlooking that the role's ttl is the authoritative cap and that Vault silently truncates rather than rejects the request.

How to eliminate wrong answers

Option A is wrong because the requested TTL of 48h does not exceed the role's ttl of 24h; it exceeds it, but Vault does not reject the request—it silently caps the TTL to the role's maximum. Option B is wrong because Vault does not honor a requested TTL that is longer than the role's configured ttl; the role's ttl acts as a hard upper limit. Option D is wrong because the mount's default lease TTL of 72h is a system-wide fallback, not a per-role cap; the role's ttl takes precedence over the mount default when it is shorter.

Full explanation →
75
MCQmedium

A token has the properties shown in the exhibit. A user attempts to use this token to write a secret to 'secret/data/myapp'. The token fails with a permission denied error. What is the most likely cause?

A.The token has an explicit max TTL of 0s, which prevents write operations.
B.The token's policies do not grant write capability on the target path.
C.The token is a service token but the write operation requires a batch token.
D.The token is orphaned, so it cannot be used for write operations.
AnswerB

The token only has 'default' and 'my-policy' policies. Without a policy granting write on 'secret/data/myapp', the operation is denied.

Why this answer

The token's policies define the access control rules for paths in Vault. Since the user received a permission denied error when attempting to write to 'secret/data/myapp', the most likely cause is that the token's attached policies do not include a 'write' or 'create' capability on that specific path. Policies are evaluated based on the path and the requested operation, and without the appropriate capability, the request is denied regardless of other token properties.

Exam trap

HashiCorp often tests the misconception that token properties like TTL, type, or parentage affect permissions, when in reality only the attached policies determine what operations a token can perform on a given path.

How to eliminate wrong answers

Option A is wrong because a max TTL of 0s does not prevent write operations; it means the token has no explicit maximum lifetime, or it may be set to use the system default, but TTL does not affect permission to write. Option C is wrong because both service tokens and batch tokens can perform write operations if their policies allow it; the token type does not inherently restrict write capability. Option D is wrong because an orphaned token (one with no parent) can still be used for write operations as long as its policies grant the required capabilities; being orphaned does not revoke permissions.

Full explanation →

Page 1 of 7

Page 2

All pages

1234567

Practice VA-003 by domain

Target a specific domain to shore up weak areas.

Compare authentication methodsAssess Vault tokensCreate Vault policiesManage Vault leasesCompare and configure secrets enginesUtilize Vault CLI and APIExplain Vault architectureExplain encryption as a service
See all domains with question counts →