Troubleshooting practice questions

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

Trap 1: Run 'vault write' to test if the token can write to a path.

'vault write' mutates data, so using it as a diagnostic risks creating or overwriting secrets at the target path. It is tempting because a write does confirm token policy permissions, and it is the correct test when validating that a token can legitimately create a specific secret.

Trap 2: Run 'vault status' to check if the server is reachable.

'vault status' reports seal state and cluster health but returns successfully even when the caller's token is invalid or lacks policy permissions, so it cannot explain authorisation failures. It is the right first step when the server itself may be sealed, unreachable, or uninitialised.

Trap 3: Run 'vault read' to test if any secret is accessible.

A successful 'vault read' only proves that one specific path and token combination works; it does not verify server reachability or token validity generally, so it cannot isolate the failure. It is tempting because reading a known secret is a natural first sanity check when credentials look suspect.

A
Run 'vault token lookup' to verify the token is valid and has the expected policies.
Token lookup returns the token's policies, TTL and renewal status, so an authentication or permission failure can be traced to an expired token or missing policy. This directly satisfies the stem's need to verify token validity and expected policies before retrying the command.
B
Run 'vault write' to test if the token can write to a path.
Why it fails: 'vault write' mutates data, so using it as a diagnostic risks creating or overwriting secrets at the target path. It is tempting because a write does confirm token policy permissions, and it is the correct test when validating that a token can legitimately create a specific secret.
C
Run 'vault login' to re-authenticate and obtain a new token if needed.
Re-authenticating issues a fresh token with a new TTL, resolving failures caused by an expired or revoked token. This satisfies the stem's troubleshooting requirement by restoring valid credentials before the command is retried against Vault.
D
Run 'vault status' to check if the server is reachable.
Why it fails: 'vault status' reports seal state and cluster health but returns successfully even when the caller's token is invalid or lacks policy permissions, so it cannot explain authorisation failures. It is the right first step when the server itself may be sealed, unreachable, or uninitialised.
E
Run 'vault read' to test if any secret is accessible.
Why it fails: A successful 'vault read' only proves that one specific path and token combination works; it does not verify server reachability or token validity generally, so it cannot isolate the failure. It is tempting because reading a known secret is a natural first sanity check when credentials look suspect.

Question 2mediummultiple choice

A Vault operator is troubleshooting a newly deployed Vault server that is initialized but not yet unsealed. The operator needs to understand which component is responsible for holding the unseal keys and root token during the initialization process. Which statement accurately describes the role of the barrier in Vault's architecture?

Trap 1: The barrier is the network interface that Vault uses to communicate…

The barrier is not a network interface; it is a cryptographic barrier that encrypts data before it is written to storage. Network communication with storage is handled by the storage backend configuration, not the barrier. TLS certificates are used for securing client and cluster communication, not for the barrier's operation.

Trap 2: The barrier is the audit log that records all requests and…

Audit logs are separate devices that record requests and responses after Vault is unsealed and operational. They are not involved in the unseal process. The barrier is an encryption mechanism, not an auditing component. Enabling audit logs before unsealing is not possible because Vault is sealed and cannot process requests.

Trap 3: The barrier is the seal mechanism that automatically unseals Vault…

Auto-unseal uses a seal mechanism like AWS KMS or Azure Key Vault to decrypt the master key, but that is a separate feature. The barrier itself is the encryption layer that must be unsealed, whether manually or via auto-unseal. The barrier does not automatically unseal; it requires the correct unseal keys or auto-unseal configuration.

A
The barrier is the network interface that Vault uses to communicate with the storage backend, and it must be configured with TLS certificates.
Why it fails: The barrier is not a network interface; it is a cryptographic barrier that encrypts data before it is written to storage. Network communication with storage is handled by the storage backend configuration, not the barrier. TLS certificates are used for securing client and cluster communication, not for the barrier's operation.
B
The barrier is the encryption layer that protects data at rest and must be unsealed using unseal keys before Vault can access storage.
The barrier is Vault's encryption layer that secures all data written to the storage backend. It requires unseal keys to reconstruct the master key, which decrypts the barrier. Until unsealed, Vault cannot read or write secrets. This is why initialization produces unseal keys and a root token, and why unsealing is mandatory after every restart.
C
The barrier is the audit log that records all requests and responses, and it must be enabled before unsealing to capture initialization events.
Why it fails: Audit logs are separate devices that record requests and responses after Vault is unsealed and operational. They are not involved in the unseal process. The barrier is an encryption mechanism, not an auditing component. Enabling audit logs before unsealing is not possible because Vault is sealed and cannot process requests.
D
The barrier is the seal mechanism that automatically unseals Vault when it detects a trusted cloud provider's instance identity.
Why it fails: Auto-unseal uses a seal mechanism like AWS KMS or Azure Key Vault to decrypt the master key, but that is a separate feature. The barrier itself is the encryption layer that must be unsealed, whether manually or via auto-unseal. The barrier does not automatically unseal; it requires the correct unseal keys or auto-unseal configuration.

Question 3mediummultiple choice

A Vault administrator is troubleshooting a Vault cluster using integrated storage (Raft). The cluster has three nodes: node1 (active), node2 (standby), and node3 (standby). The administrator runs `vault operator raft list-peers` and sees that node3 is listed as a non-voter. What is the most likely reason for node3 being a non-voter?

Trap 1: Node3 has a different Vault version than the other nodes, so it is…

Vault does not automatically demote a node to non-voter based on version differences. While it is recommended that all nodes run the same Vault version, a version mismatch does not directly change Raft voting status. Autopilot may consider version as part of health checks, but it does not demote a voter to non-voter solely due to version. Other factors like health and stability are more relevant.

Trap 2: Node3 is configured as a performance standby, which prevents it…

Performance standby is a feature of Vault Enterprise that allows a standby node to serve read requests. It does not affect Raft voting membership. A performance standby can still be a voter in the Raft configuration. The non-voter status is unrelated to performance standby; it is typically due to the node being newly added or unhealthy.

Trap 3: Node3 is a standby node and therefore cannot be a voter in the Raft…

Standby nodes can be voters in Vault's Raft configuration. In fact, all nodes in a Vault cluster using integrated storage are typically voters, regardless of whether they are active or standby. The active/standby status is related to the Vault cluster leadership, not Raft voting membership. A standby node can and usually does participate in Raft consensus as a voter.

A
Node3 has a different Vault version than the other nodes, so it is automatically demoted to a non-voter.
Why it fails: Vault does not automatically demote a node to non-voter based on version differences. While it is recommended that all nodes run the same Vault version, a version mismatch does not directly change Raft voting status. Autopilot may consider version as part of health checks, but it does not demote a voter to non-voter solely due to version. Other factors like health and stability are more relevant.
B
Node3 is configured as a performance standby, which prevents it from being a voter.
Why it fails: Performance standby is a feature of Vault Enterprise that allows a standby node to serve read requests. It does not affect Raft voting membership. A performance standby can still be a voter in the Raft configuration. The non-voter status is unrelated to performance standby; it is typically due to the node being newly added or unhealthy.
C
Node3 was recently added to the cluster and has not yet been promoted to a voter by autopilot.
When a new node is added to a Vault Raft cluster, it initially joins as a non-voter. Autopilot then monitors its health and, after a stabilization period, promotes it to a voter if the cluster needs more voters. This gradual promotion ensures that a new node does not disrupt the cluster's quorum if it is unhealthy or slow. The non-voter status is temporary until autopilot promotes it.
D
Node3 is a standby node and therefore cannot be a voter in the Raft configuration.
Why it fails: Standby nodes can be voters in Vault's Raft configuration. In fact, all nodes in a Vault cluster using integrated storage are typically voters, regardless of whether they are active or standby. The active/standby status is related to the Vault cluster leadership, not Raft voting membership. A standby node can and usually does participate in Raft consensus as a voter.

Question 4hardmultiple choice

A security engineer is troubleshooting why a Vault token cannot be renewed. The token was created with a TTL of 4 hours and is renewable. After 2 hours, the engineer attempts to renew it using `vault token renew <token>` but receives the error: "lease not found". The engineer confirms the token is still valid and not expired. Which of the following is the most likely cause?

Trap 1: The token's TTL has been exceeded, causing Vault to delete the…

If the token's TTL had been exceeded, the token itself would be expired and `vault token lookup` would fail or show it as invalid. The scenario states the token is still valid and not expired. The "lease not found" error specifically indicates the lease associated with the token is missing, not that the token's TTL was exceeded. Exceeding TTL would yield a different error such as "token expired" or the token would simply be gone.

Trap 2: The token was created with the -no-default-policy flag, which…

The -no-default-policy flag only prevents the default policy from being attached to the token; it has no effect on renewal. Tokens can be renewable regardless of whether they have the default policy. This flag does not cause a "lease not found" error. The error is related to lease management, not policy attachment. The engineer should look for lease revocation or expiration issues instead.

Trap 3: The token was created with a period but no explicit max TTL, and…

Periodic tokens are a special type where the TTL is reset to the period value upon renewal. They do not produce a "lease not found" error during renewal; in fact, they are designed to be renewed indefinitely as long as the period hasn't elapsed. The error here suggests a missing lease, not a periodic token behavior. Periodic tokens are typically used for long-lived services and do not cause this specific error when renewed within the period.

A
The token's TTL has been exceeded, causing Vault to delete the lease record.
Why it fails: If the token's TTL had been exceeded, the token itself would be expired and `vault token lookup` would fail or show it as invalid. The scenario states the token is still valid and not expired. The "lease not found" error specifically indicates the lease associated with the token is missing, not that the token's TTL was exceeded. Exceeding TTL would yield a different error such as "token expired" or the token would simply be gone.
B
The token's lease was revoked or expired, possibly due to a parent token revocation or lease cleanup, even though the token itself remains valid.
In Vault, tokens and their leases are related but distinct. A token can remain valid while its lease record is removed due to parent revocation, manual lease revocation, or a bug in lease management. The "lease not found" error indicates that Vault cannot find the lease to renew. This can happen if the token's parent was revoked, causing the child token's lease to be cleaned up, but the token itself might still be usable until its TTL expires. The engineer should check for revoked parent tokens or lease revocation events.
C
The token was created with the -no-default-policy flag, which disables renewal.
Why it fails: The -no-default-policy flag only prevents the default policy from being attached to the token; it has no effect on renewal. Tokens can be renewable regardless of whether they have the default policy. This flag does not cause a "lease not found" error. The error is related to lease management, not policy attachment. The engineer should look for lease revocation or expiration issues instead.
D
The token was created with a period but no explicit max TTL, and the period has not yet elapsed.
Why it fails: Periodic tokens are a special type where the TTL is reset to the period value upon renewal. They do not produce a "lease not found" error during renewal; in fact, they are designed to be renewed indefinitely as long as the period hasn't elapsed. The error here suggests a missing lease, not a periodic token behavior. Periodic tokens are typically used for long-lived services and do not cause this specific error when renewed within the period.

Question 5mediummultiple choice

An admin is troubleshooting a Vault cluster where some dynamic secrets leases are not being revoked after their TTL expires. The admin confirms that the TTLs are set correctly. Which Vault component is responsible for revoking expired leases?

Trap 1: The audit device

Audit devices log requests and responses but do not perform revocation. They are passive observers. While audit logs can help diagnose why revocation failed, they are not the mechanism that revokes leases. Looking at audit devices for revocation issues would be a misunderstanding of their role.

Trap 2: The Vault storage backend

The storage backend persists data but does not actively revoke leases. Revocation is a function of Vault's core and its expiration manager. The storage backend simply stores lease metadata; it does not initiate revocation actions. Misattributing lease revocation to storage can lead to troubleshooting the wrong component.

Trap 3: The secrets engine plugin

Secrets engines create and revoke credentials when instructed, but they do not schedule or trigger revocation based on TTLs. The expiration manager calls the secrets engine's revocation endpoint when a lease expires. The secrets engine itself does not monitor lease TTLs; it responds to revocation requests from the core.

A
The audit device
Why it fails: Audit devices log requests and responses but do not perform revocation. They are passive observers. While audit logs can help diagnose why revocation failed, they are not the mechanism that revokes leases. Looking at audit devices for revocation issues would be a misunderstanding of their role.
B
The expiration manager
Vault's expiration manager is responsible for tracking lease TTLs and revoking leases when they expire. It runs as part of the Vault core and periodically checks for expired leases. If leases are not being revoked, the expiration manager may be disabled or malfunctioning, making it the correct component to investigate.
C
The Vault storage backend
Why it fails: The storage backend persists data but does not actively revoke leases. Revocation is a function of Vault's core and its expiration manager. The storage backend simply stores lease metadata; it does not initiate revocation actions. Misattributing lease revocation to storage can lead to troubleshooting the wrong component.
D
The secrets engine plugin
Why it fails: Secrets engines create and revoke credentials when instructed, but they do not schedule or trigger revocation based on TTLs. The expiration manager calls the secrets engine's revocation endpoint when a lease expires. The secrets engine itself does not monitor lease TTLs; it responds to revocation requests from the core.

Question 6hardmultiple choice

A Vault administrator is troubleshooting a batch of revoked database credentials. An application reported that its lease stopped working even though the application had been renewing it every few minutes. Reviewing the mount configuration, the administrator sees default_lease_ttl set to 15m and max_lease_ttl set to 2h. The application log shows successful renewals until roughly the two-hour mark, after which the renew call returned an error and the credential failed. What is the most likely explanation?

Trap 1: The database engine rotated its root credentials, which invalidated…

Root credential rotation affects Vault's ability to create new users but does not instantly revoke all existing dynamic credentials at a synchronized two-hour mark. The failure timing aligns precisely with the configured maximum lease TTL, which is a deterministic per-lease boundary. Root rotation would not produce a clean cutoff exactly at the lease ceiling.

Trap 2: The application's token expired, causing all leases it created to…

Token expiry revokes leases created by that token, but the symptom here is a renew failure at a time matching the mount's max_lease_ttl, not the token's own TTL. A token-expiry explanation would require the token TTL to coincidentally equal two hours and would also invalidate the app's ability to authenticate. The timing strongly implicates the lease ceiling instead.

Trap 3: The application exceeded its allowed renewal count, and Vault…

Vault does not impose a fixed renewal-count limit on leases. Renewal eligibility is governed by time-based ceilings such as max_lease_ttl, not by how many times a client has renewed. A renewal-count explanation would not explain why the cutoff occurred at the two-hour mark matching the mount configuration.

A
The database engine rotated its root credentials, which invalidated every outstanding dynamic credential at once.
Why it fails: Root credential rotation affects Vault's ability to create new users but does not instantly revoke all existing dynamic credentials at a synchronized two-hour mark. The failure timing aligns precisely with the configured maximum lease TTL, which is a deterministic per-lease boundary. Root rotation would not produce a clean cutoff exactly at the lease ceiling.
B
The application's token expired, causing all leases it created to be revoked automatically at the same time.
Why it fails: Token expiry revokes leases created by that token, but the symptom here is a renew failure at a time matching the mount's max_lease_ttl, not the token's own TTL. A token-expiry explanation would require the token TTL to coincidentally equal two hours and would also invalidate the app's ability to authenticate. The timing strongly implicates the lease ceiling instead.
C
The lease reached the mount's max_lease_ttl, so renewal could no longer extend it and the credential had to be reissued.
Renewal extends a lease only up to the cumulative maximum defined by the mount's max_lease_ttl. Once a lease has lived for two hours, further renewal attempts fail and the credential expires, regardless of how frequently the client renewed. The application must request a new credential rather than continuing to renew the exhausted lease.
D
The application exceeded its allowed renewal count, and Vault rejected the renewal after a fixed number of attempts.
Why it fails: Vault does not impose a fixed renewal-count limit on leases. Renewal eligibility is governed by time-based ceilings such as max_lease_ttl, not by how many times a client has renewed. A renewal-count explanation would not explain why the cutoff occurred at the two-hour mark matching the mount configuration.

Question 7mediummultiple choice

An administrator is troubleshooting a policy where a token unexpectedly has permission to read 'secret/data/finance/payroll' even though the attached policy only contains a statement for 'secret/data/hr/*'. The administrator confirms the policy is attached correctly and the path is not covered by any wildcard in it. What is the most likely explanation?

Trap 1: Wildcard matching in Vault is greedy, so the hr wildcard also…

Vault wildcards match path segments at or below the specified prefix, not arbitrary sibling directories. A statement for secret/data/hr/* does not extend to secret/data/finance/payroll because the literal segment hr must appear in the request path. This misconception about greedy matching leads administrators away from the real cause, which is additional attached policies.

Trap 2: Reading a KV v2 secret requires only the metadata path, so the…

Reading secret values requires the read capability on the data path; metadata access alone returns version and deletion information rather than content. Even if a metadata grant existed, it would not explain a successful read of the payroll secret's value. This option misstates how KV v2 authorization works and does not fit the reported symptom.

Trap 3: The policy was written with a trailing wildcard that Vault silently…

Vault does not strip trailing wildcards or reinterpret them into broader grants. A trailing wildcard remains a prefix match scoped to the path where it appears. If the statement truly names the hr prefix, it cannot silently expand to the finance path, so this explanation does not account for the observed access and would send troubleshooting in the wrong direction.

A
Wildcard matching in Vault is greedy, so the hr wildcard also matches sibling prefixes like finance.
Why it fails: Vault wildcards match path segments at or below the specified prefix, not arbitrary sibling directories. A statement for secret/data/hr/* does not extend to secret/data/finance/payroll because the literal segment hr must appear in the request path. This misconception about greedy matching leads administrators away from the real cause, which is additional attached policies.
B
Reading a KV v2 secret requires only the metadata path, so the finance secret is exposed through an unrelated metadata grant.
Why it fails: Reading secret values requires the read capability on the data path; metadata access alone returns version and deletion information rather than content. Even if a metadata grant existed, it would not explain a successful read of the payroll secret's value. This option misstates how KV v2 authorization works and does not fit the reported symptom.
C
The policy was written with a trailing wildcard that Vault silently strips, leaving a root-level grant.
Why it fails: Vault does not strip trailing wildcards or reinterpret them into broader grants. A trailing wildcard remains a prefix match scoped to the path where it appears. If the statement truly names the hr prefix, it cannot silently expand to the finance path, so this explanation does not account for the observed access and would send troubleshooting in the wrong direction.
D
The token also has the default policy or another policy attached that contains a matching statement for the finance path.
Vault merges all policies attached to a token, and permissions are additive, so any additional policy with a statement covering the finance path grants the access regardless of what the hr policy says. The default policy is commonly attached automatically and may include broad read paths in some configurations, and operators often overlook extra policies during troubleshooting. Inspecting the token's full policy list resolves the discrepancy.