Courseiva

CCNA Vault Leases Questions

46 questions · Vault Leases topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
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

`vault list sys/leases/lookup/<mount_path>` lists all active lease IDs for a given secrets engine mount path by querying the lease lookup endpoint. Option C is correct because `vault list sys/leases/prefix/<mount_path>` lists leases that share a common prefix, which effectively returns all active leases under that mount path when the mount path is used as the prefix. Both commands use the `list` operation against the sys/leases API to retrieve active lease IDs.

Exam trap

Candidates often confuse the correct API endpoint paths for listing leases, such as `/lookup/` vs `/prefix/` vs `/list/`, and may incorrectly use `vault read` instead of `vault list`.

Practice this question →
2
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.

Practice this question →
3
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.
AnswerA

Correct. The token used to renew the lease has expired, causing the renewal to fail because authentication fails.

Why this answer

The error 'lease is not renewable or does not exist' typically occurs when the token used to authenticate the renewal request has expired. In Vault, KV v2 secrets engine reads do not produce renewable leases; the lease_id returned is actually from the token. If the application's token expires, it cannot renew any leases, even if the secret data is still accessible via a new read with a valid token.

Options B and C would cause the secret path itself to change, but the secret data is still present, so they are unlikely. Option D is incorrect because KV v2 leases are not renewable, so they cannot expire in the scenario described.

Exam trap

Candidates often mistake KV v2 secrets as having renewable leases similar to dynamic secrets, but KV v2 reads do not generate renewable leases. The lease_id in the response is actually the token lease, which can expire.

How to eliminate wrong answers

Option A is wrong because token expiration would cause all operations to fail, not just lease renewal; the application can still read the secret, proving the token is valid. Option B is wrong because deleting and recreating the secret under the same path would generate a new lease, but the original lease would still exist until its TTL expires; the error 'lease is not renewable or does not exist' is not caused by secret recreation. Option C is wrong because disabling and re-enabling the KV v2 engine would destroy all existing leases and secrets, making the secret data inaccessible; the application can still read the secret, so the engine was not disabled.

Practice this question →
4
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

The 'ttl' parameter in a PKI role definition directly controls the lease duration (time-to-live) for certificates issued by that role. This is the primary mechanism for setting how long a certificate is valid, overriding the mount-level default if specified.

Exam trap

The trap here is that candidates confuse the 'default_lease_ttl' on the mount (which is a fallback) with the role-level 'ttl' (which is the direct control), or mistakenly think auth method lease settings apply to secrets engine leases.

Practice this question →
5
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 actual TTL of a lease issued by a secrets engine is determined by the minimum of three values: the role's `default_ttl`, the role's `max_ttl`, and the system's `max_lease_ttl` configuration. The system's `max_lease_ttl` acts as a hard upper bound that cannot be exceeded by any lease, regardless of role settings. This ensures that even if a role has a longer `default_ttl`, the system-wide limit will cap the lease duration.

Exam trap

The trap here is that candidates often assume the requesting token's TTL directly controls the lease TTL, but Vault decouples token and lease lifetimes, using the role and system settings as the authoritative source.

Practice this question →
6
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

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.

Practice this question →
7
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.

Practice this question →
8
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

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.

Practice this question →
9
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

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.

Practice this question →
10
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

The `vault lease revoke <lease_id>` command is specifically designed to manually revoke a single lease by its unique identifier. This directly terminates the associated secret's validity and any derived tokens, aligning with the requirement to manually revoke leases in Vault.

Exam trap

In the HashiCorp Vault exam, candidates often confuse lease revocation with token revocation, leading them to mistakenly choose `vault token revoke` (option B) when the question specifically asks about leases, not tokens.

Practice this question →
11
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

The `vault lease revoke -prefix <mount>` command is specifically designed to revoke all leases associated with a given mount path without affecting other mounts. This command iterates through all leases under that prefix and forces their revocation, cleaning up invalid leases efficiently. It is the targeted, non-disruptive approach for lease cleanup in Vault.

Exam trap

Candidates often think that restarting Vault or disabling/re-enabling a mount is the simplest way to clear leases, but the trap here is that these actions are either ineffective or overly destructive, while the `revoke -prefix` command provides a precise, non-disruptive solution.

How to eliminate wrong answers

Option A is wrong because restarting Vault servers does not force cleanup of leases; leases persist in storage and will be re-evaluated on restart, not removed. Option B is wrong because disabling and re-enabling the secret engine is overly disruptive, as it removes all secrets and configuration for that mount, not just leases, and may cause data loss or service interruption. Option D is wrong because reducing the mount's `max_lease_ttl` to 0 only affects future lease creation and renewal, not existing leases; it does not force revocation of current invalid leases.

Practice this question →
12
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.
AnswerA

Correct. The lease is marked as expired and can no longer be renewed. This is the accurate description of what happens when a lease reaches its TTL.

Why this answer

When a lease reaches its Time-To-Live (TTL), it becomes expired and cannot be renewed. Vault does not automatically delete the lease from storage at the moment of TTL expiry; rather, the lease is marked as expired and is eventually garbage-collected. This cleanup is separate from revocation of the underlying secret, which must be performed explicitly or via a different mechanism.

Exam trap

Candidates often mistakenly think that a lease reaching its TTL triggers revocation of the underlying secret, when in fact Vault only marks the lease as expired and relies on separate revocation logic for the actual secret.

How to eliminate wrong answers

Option A is wrong because a lease that reaches its TTL is not marked as expired and left in storage; it is deleted entirely, and Vault does allow renewal before the TTL expires, not after. Option B is wrong because leases are not automatically renewed; renewal must be explicitly requested by the client before the TTL expires. Option C is wrong because the secret associated with the lease is not automatically revoked when the lease reaches its TTL; revocation is a separate action that can occur before or after TTL, but at TTL the lease is simply deleted, and the secret may still be valid if it has a longer lifetime.

Practice this question →
13
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.

Practice this question →
14
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

(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.

Practice this question →
15
Multi-Selectmedium

A Vault administrator needs to manage leases for dynamic secrets. Which TWO of the following are valid operations related to lease management?

Select 2 answers
A.Call the sys/leases/renew endpoint to renew a lease.
B.Call the sys/leases/list endpoint to disable a lease.
C.Call the sys/leases/revoke endpoint to revoke a lease.
D.Call the sys/leases/extend endpoint to increase the lease duration.
E.Call the sys/leases/rotate endpoint to rotate the secret associated with a lease.
AnswersA, C

Correct operation to renew a lease.

Why this answer

The `sys/leases/renew` endpoint is the standard Vault API endpoint used to renew the lease of a dynamic secret, extending its time-to-live (TTL) within the maximum allowed limit. Option C is correct because the `sys/leases/revoke` endpoint is the designated API endpoint to immediately invalidate a lease and its associated secret, preventing further use and cleaning up the secret engine's state.

Exam trap

HashiCorp often tests the misconception that lease management endpoints have intuitive names like 'extend' or 'rotate', when in fact Vault uses only three core lease operations: renew, revoke, and list (with no dedicated extend or rotate endpoints).

Practice this question →
16
MCQmedium

A security policy requires that all leases must be revoked within 1 hour of creation. Which setting should be configured on the secret engine mount?

A.default_lease_ttl = 1h
B.token_ttl = 1h
C.max_lease_ttl = 1h
D.default_lease_ttl = 1h and max_lease_ttl = 1h
AnswerD

This combination caps the lease at 1h and ensures initial TTL is 1h.

Why this answer

The security policy requires that all leases must be revoked within 1 hour of creation, meaning no lease can exceed 1 hour. The `default_lease_ttl` sets the initial TTL for leases when no specific TTL is provided, and the `max_lease_ttl` enforces an absolute upper limit that no lease can exceed. Configuring both to 1h ensures that every lease starts with a 1-hour TTL and cannot be renewed or extended beyond that hard cap, guaranteeing revocation within 1 hour.

Exam trap

A common trap is that candidates assume setting only `max_lease_ttl` is sufficient, overlooking that `default_lease_ttl` must also be set to ensure all leases start with the required TTL and cannot be extended beyond it.

How to eliminate wrong answers

Option A is wrong because setting only `default_lease_ttl = 1h` does not prevent a client from requesting a longer TTL or renewing the lease beyond 1 hour; the `max_lease_ttl` is needed to enforce the absolute cap. Option B is wrong because `token_ttl` controls the lifetime of the authentication token itself, not the TTL of leases issued by a secret engine mount; leases are governed by `default_lease_ttl` and `max_lease_ttl` on the mount. Option C is wrong because setting only `max_lease_ttl = 1h` without `default_lease_ttl` means leases could be created with a shorter TTL (e.g., 30 minutes) and then renewed up to the max, but the policy requires all leases to be revoked within 1 hour of creation—without a default, some leases might be issued with a very short TTL and still be renewed, but the policy's intent is that no lease lasts longer than 1 hour from creation, which both settings together guarantee.

Practice this question →
17
MCQeasy

A company runs a microservices architecture where each service authenticates to Vault using AppRole and is assigned a role with a periodic token. The operations team notices that some services experience authentication failures after exactly 24 hours of uptime, even though their tokens were initially issued with a TTL of 24 hours and 'renewable' set to true. The services are configured to renew their tokens automatically before expiry. Upon investigation, the Vault logs show the error: 'failed to renew token: token has exceeded its max TTL'. The Vault server is configured with a default 'max_lease_ttl' of 24 hours and a 'default_lease_ttl' of 1 hour at the system level. The AppRole role has no explicit TTL or max TTL set. What is the most likely cause of the failure?

A.The token's lease duration is actually 1 hour (the default) and the services fail to renew before expiry.
B.The AppRole role has an implicit max TTL of 0, which prevents any renewal after the initial TTL.
C.The services are not renewing their tokens because the 'renewable' flag is ignored by periodic tokens.
D.The periodic token's max TTL is set by the system's 'max_lease_ttl' of 24 hours, and once that time is reached, renewal is no longer allowed.
AnswerD

Periodic tokens have a max TTL equal to the system's 'max_lease_ttl' unless overridden on the role. Here, 24 hours elapsed, hitting the limit.

Why this answer

The periodic token's max TTL is derived from the system's 'max_lease_ttl' of 24 hours when no explicit max TTL is set on the AppRole role. Even though the token is renewable and the services attempt to renew before expiry, the token cannot be renewed once its cumulative lifetime reaches the max TTL of 24 hours, causing the 'token has exceeded its max TTL' error. The periodic token's TTL is reset on each renewal, but the max TTL is a hard limit on the total lifespan of the token.

Exam trap

A common pitfall when working with Vault periodic tokens is confusing the token TTL, which resets on each renewal, with the max TTL, which is a cumulative lifetime limit. Candidates may mistakenly think that automatic renewal prevents any expiry, but the max TTL is a hard limit that cannot be exceeded, even with renewal.

How to eliminate wrong answers

Option A is wrong because the token's lease duration is not 1 hour; the token was issued with a TTL of 24 hours (the default_lease_ttl of 1 hour applies to non-periodic leases, not to the token's TTL when renewable is true and no explicit TTL is set on the role). Option B is wrong because an AppRole role with no explicit max TTL does not have an implicit max TTL of 0; instead, it inherits the system's max_lease_ttl, and a max TTL of 0 would mean no renewal is allowed at all, which is not the case here. Option C is wrong because the 'renewable' flag is not ignored by periodic tokens; periodic tokens are explicitly designed to be renewable, and the failure is due to the max TTL limit, not the renewable flag being ignored.

Practice this question →
18
MCQeasy

A development team is using Vault to dynamically generate PostgreSQL credentials for their application. They configured a database role with a max_lease_ttl of 24 hours. However, credentials are becoming invalid after only 1 hour, causing application errors. The team has verified that the credentials are not being explicitly revoked. Which action should the Vault administrator take to resolve this issue?

A.Extend the TTL of the token used to generate credentials.
B.Update the database role's default_lease_ttl to 24 hours.
C.Increase the database engine's max_lease_ttl to 48 hours.
D.Instruct the team to renew the lease every 30 minutes.
AnswerB

The default_lease_ttl controls the initial lease duration; increasing it to match the max prevents early expiration.

Why this answer

The issue is that the credentials are expiring after 1 hour, which is the default value for `default_lease_ttl` in Vault database roles. Even though the `max_lease_ttl` is set to 24 hours, the actual lease duration for each credential is determined by the `default_lease_ttl` unless it is explicitly configured. By setting `default_lease_ttl` to 24 hours, the administrator ensures that each generated credential has a lease duration matching the maximum allowed, preventing premature expiration.

Exam trap

The trap here is that candidates assume setting `max_lease_ttl` alone controls the credential lifetime, but the actual lease duration is governed by `default_lease_ttl` unless explicitly configured.

How to eliminate wrong answers

Option A is wrong because extending the TTL of the token used to generate credentials does not affect the lease TTL of the dynamically generated database credentials; token TTL and credential lease TTL are independent. Option C is wrong because increasing the database engine's `max_lease_ttl` to 48 hours does not change the fact that the `default_lease_ttl` is still 1 hour; the credentials would still expire after 1 hour unless the role's `default_lease_ttl` is updated. Option D is wrong because instructing the team to renew the lease every 30 minutes is a workaround, not a resolution; the proper fix is to adjust the role's `default_lease_ttl` to match the desired lease duration.

Practice this question →
19
MCQeasy

Refer to the exhibit. What is the most likely cause of this error?

A.The token lacks permission.
B.The secret engine was disabled.
C.The lease ID is incorrect.
D.The lease has expired.
AnswerC

An incorrect lease ID will result in 'lease not found'.

Why this answer

The error message indicates that the lease ID provided for the renewal or revocation operation is invalid. In Vault, lease IDs are unique identifiers tied to a specific secret or token lease. If the lease ID is incorrect—due to a typo, truncation, or mismatch—Vault cannot locate the lease, resulting in this error.

Option C correctly identifies this as the most likely cause.

Exam trap

In the HashiCorp Vault exam, a common pitfall is confusing an invalid lease ID with an expired lease. The error message explicitly states the lease ID is incorrect, so candidates should avoid selecting 'lease has expired' when the lease ID itself is malformed or mistyped.

How to eliminate wrong answers

Option A is wrong because a token lacking permission would produce a 'permission denied' or '403 Forbidden' error, not an invalid lease ID error. Option B is wrong because if the secret engine were disabled, Vault would return an error indicating the mount path is not enabled or the engine is unavailable, not a lease ID issue. Option D is wrong because an expired lease would generate a 'lease not found or expired' error, but the error message specifically states the lease ID is invalid, not that it has expired.

Practice this question →
20
MCQmedium

A DevOps team is using Vault's database secrets engine to generate dynamic credentials for a PostgreSQL database. They notice that the lease duration is set to 24 hours, but security policy requires that credentials expire after 1 hour. What should the team do to enforce the 1-hour expiration without changing the default lease TTL for all secrets?

A.Set the mount's max_lease_ttl to 1h.
B.Ask each developer to set the TTL when requesting credentials.
C.Configure the role with a ttl of 1h.
D.Use a periodic token with a period of 1h.
AnswerC

The role-level ttl overrides the default lease TTL.

Why this answer

The database secrets engine allows role-level TTL configuration that overrides the default lease duration for credentials generated from that role. By setting the role's `ttl` to 1h, the team enforces a 1-hour expiration for credentials created under that specific role without affecting the default lease TTL for all secrets or other roles. This directly meets the security policy requirement while maintaining flexibility for other secrets.

Exam trap

The trap here is that candidates often confuse mount-level TTL settings with role-level TTL settings, assuming that changing the mount's `max_lease_ttl` is the only way to enforce expiration, when in fact role-level configuration provides granular control without affecting other secrets.

How to eliminate wrong answers

Option A is wrong because setting the mount's `max_lease_ttl` to 1h would enforce a hard upper limit on all secrets generated from that mount, including other roles or engines, which violates the requirement to not change the default lease TTL for all secrets. Option B is wrong because relying on each developer to set the TTL when requesting credentials is error-prone and does not enforce the policy centrally; developers might forget or intentionally set a longer TTL, leading to non-compliance. Option D is wrong because periodic tokens are used for long-lived tokens that automatically renew, not for database credentials; they do not control the TTL of dynamic credentials generated by the database secrets engine.

Practice this question →
21
MCQeasy

A developer requests a credential from this role. Which statement about the resulting lease is true?

A.The lease will have a TTL of 24 hours and can be renewed.
B.The lease will have a TTL of 1 hour and can be renewed.
C.The lease will have a TTL of 1 hour and cannot be renewed.
D.The lease will have a TTL of 24 hours and cannot be renewed.
AnswerC

The default_ttl sets the initial TTL, and renewable=false prevents renewal.

Why this answer

In Vault, when a developer requests a credential from a role that is configured with the default lease TTL of 1 hour and the role has `explicit_max_ttl` set to 0 (or not set), the resulting lease will have a TTL of 1 hour. Additionally, if the role is configured with `renewable=false`, the lease cannot be renewed. Option C correctly reflects both the 1-hour TTL and non-renewable behavior.

Exam trap

In the Vault exam, candidates often confuse the default lease TTL (1 hour) with the maximum TTL (24 hours or higher), and they may incorrectly assume all leases are renewable. The 'renewable' flag is a separate configuration that can be set to false, making the lease non-renewable regardless of TTL.

How to eliminate wrong answers

Option A is wrong because the lease TTL is 1 hour, not 24 hours, and the lease cannot be renewed when `renewable=false`. Option B is wrong because while the TTL is 1 hour, the lease cannot be renewed when the role has `renewable=false`. Option D is wrong because the lease TTL is 1 hour, not 24 hours, and although the non-renewable part is correct, the TTL value is incorrect.

Practice this question →
22
MCQeasy

Based on the exhibit, what is the maximum total lifespan of this lease?

A.2 hours
B.90 minutes
C.1 hour
D.30 minutes
AnswerC

The max_ttl indicates the maximum total lifespan.

Why this answer

The lease duration for a Vault lease is specified in seconds, and the exhibit shows a lease duration of 3600 seconds. Converting 3600 seconds to hours gives exactly 1 hour (3600 / 3600 = 1). This represents the maximum total lifespan of the lease before it expires or must be renewed.

Exam trap

A common trap is misreading the lease duration unit: Vault displays lease durations in seconds, but candidates may mistakenly interpret them as minutes. In this question, 3600 seconds equals 1 hour, not 90 minutes or 2 hours.

How to eliminate wrong answers

Option A is wrong because 2 hours would correspond to 7200 seconds, which is not the value shown in the exhibit. Option B is wrong because 90 minutes equals 5400 seconds, not the 3600 seconds displayed. Option D is wrong because 30 minutes equals 1800 seconds, which is half the actual lease duration of 3600 seconds.

Practice this question →
23
MCQhard

A large enterprise runs Vault in a production environment with multiple secrets engines, including databases, AWS, and PKI. Recently, the operations team noticed that the number of active leases has grown significantly, causing performance degradation in Vault. The team suspects that many leases are orphaned or expired but not cleaned up. They run the vault lease tidy command regularly, but the issue persists. The vault audit logs show no errors during revocation. However, the team observes that the database credentials are being revoked correctly, but the PKI certificates are not being revoked when their leases expire. Additionally, some AWS IAM user leases seem to persist beyond their max TTL. What is the most likely cause of this issue?

A.The max_ttl setting for the PKI and AWS roles is set incorrectly.
B.The vault lease tidy command is not effective for PKI and AWS secrets engines.
C.The PKI and AWS secrets engines require explicit revocation of the underlying secret, which is not triggered by lease expiration alone.
D.The Vault server's clock is out of sync, causing lease expiration calculations to be inaccurate.
AnswerC

Lease expiration does not automatically revoke certificates or IAM users; explicit revocation is needed.

Why this answer

In Vault, lease expiration triggers revocation only for secrets engines that support automatic revocation at the Vault level. The PKI secrets engine does not automatically revoke issued certificates when a lease expires; it only removes the lease metadata. Similarly, AWS IAM user credentials are not automatically revoked upon lease expiration because the underlying secret (the IAM user or access key) must be explicitly revoked via the AWS API.

The `vault lease tidy` command cleans up stale lease entries in Vault's storage but does not trigger revocation of the underlying secrets for these engines.

Exam trap

HashiCorp Vault often tests the misconception that lease expiration always triggers revocation of the underlying secret, but in reality, some secrets engines (like PKI and AWS) require explicit revocation actions separate from lease lifecycle management.

How to eliminate wrong answers

Option A is wrong because the max_ttl setting controls the maximum lifetime of a lease, but the issue is not about the lease duration; it is about the failure to revoke the underlying secret when the lease expires. Option B is wrong because the `vault lease tidy` command is effective for cleaning up orphaned lease entries in Vault's storage, but it does not perform revocation of secrets for engines like PKI and AWS that require explicit revocation. Option D is wrong because clock skew would affect lease expiration calculations globally, but the audit logs show no errors during revocation, and the database credentials are being revoked correctly, indicating that clock sync is not the issue.

Practice this question →
24
MCQmedium

A company uses Vault to manage database credentials for its applications. The applications request a one-hour TTL for database secrets, but the database engine's default lease TTL is set to 24 hours. The Vault administrator wants to ensure that leases are revoked promptly after the applications finish using them, to minimize the window of exposure. Which approach best achieves this goal?

A.Set the default lease TTL on the database mount to 1 hour.
B.Configure the database role with a TTL of 1 hour and an explicit max TTL of 2 hours.
C.Increase the system's default lease TTL to 48 hours to give applications more flexibility.
D.Manually revoke leases after each application finishes using them.
AnswerB

This ensures each lease expires after 1 hour, and the explicit max TTL prevents any renewal beyond 2 hours, minimizing exposure.

Why this answer

Configuring the database role with a TTL of 1 hour and an explicit max TTL of 2 hours allows the application to request a 1-hour lease while ensuring that the lease cannot exceed 2 hours, even if the application fails to renew or release it. This minimizes the exposure window by capping the lease duration, and the Vault administrator can rely on automatic lease revocation at TTL expiry rather than manual intervention. The database engine's default lease TTL of 24 hours is overridden by the role-level TTL, which is the proper way to enforce shorter-lived credentials for specific applications.

Exam trap

The trap here is that candidates often confuse the mount-level default lease TTL with the role-level TTL, assuming that changing the mount default is sufficient, when in fact the role-level TTL and explicit max TTL are required to enforce a strict upper bound on credential lifetime.

How to eliminate wrong answers

Option A is wrong because setting the default lease TTL on the database mount to 1 hour would affect all roles and secrets under that mount, potentially breaking applications that need longer leases, and it does not provide a separate max TTL to cap the absolute lifetime. Option C is wrong because increasing the system's default lease TTL to 48 hours would make the exposure window even larger, directly contradicting the goal of minimizing it. Option D is wrong because manually revoking leases is impractical, error-prone, and does not scale; Vault is designed to automate lease lifecycle management via TTLs and revocation on expiry.

Practice this question →
25
MCQmedium

A company runs a microservices application on Kubernetes. Each service authenticates to Vault using the Kubernetes auth method and obtains a short-lived token with a TTL of 15 minutes. The services use these tokens to read secrets from the KV v2 secrets engine. Recently, the operations team noticed that Vault's lease count has been steadily increasing, and some services are experiencing 'lease not found' errors when trying to renew their tokens. Investigation reveals that the services are not renewing tokens before they expire because the token TTL is too short to complete some long-running tasks. The team wants to fix the issue without compromising security. They are considering the following actions: A. Increase the default lease TTL for the KV v2 mount to 1 hour. B. Increase the token TTL for the Kubernetes auth role to 1 hour. C. Implement a renewal loop in each service to renew tokens every 10 minutes. D. Use periodic tokens with a period of 1 hour for all services.

A.Increase the default lease TTL for the KV v2 mount to 1 hour.
B.Increase the token TTL for the Kubernetes auth role to 1 hour.
C.Implement a renewal loop in each service to renew tokens every 10 minutes.
D.Use periodic tokens with a period of 1 hour for all services.
AnswerB

Token TTL directly addresses the token expiration issue.

Why this answer

Increasing the token TTL for the Kubernetes auth role to 1 hour directly addresses the root cause: the current 15-minute TTL is too short for long-running tasks, causing tokens to expire before services can complete their work. By raising the TTL to 1 hour, services have sufficient time to complete tasks and renew tokens, while still maintaining security through short-lived credentials. This approach does not require code changes and leverages Vault's built-in token lifecycle management.

Exam trap

HashiCorp often tests the distinction between token TTL and secret lease TTL, and the trap here is that candidates confuse increasing the KV v2 mount's default lease TTL (Option A) with increasing the token TTL, when only the latter resolves token expiration issues for long-running tasks.

How to eliminate wrong answers

Option A is wrong because increasing the default lease TTL for the KV v2 mount affects the lease duration of secrets read from the mount, not the token TTL itself; the 'lease not found' errors are due to token expiration, not secret lease expiration. Option C is wrong because implementing a renewal loop in each service does not fix the underlying issue that the token TTL is too short for long-running tasks; even with renewal, if a task exceeds the TTL without renewal, the token will expire, and adding renewal logic increases complexity without addressing the root cause. Option D is wrong because periodic tokens are designed for long-lived daemons or services that need indefinite token lifetimes, which would compromise security by removing the short-lived nature of tokens, contrary to the requirement to fix the issue without compromising security.

Practice this question →
26
MCQeasy

An admin needs to check the remaining lifespan of a lease. Which command should they use?

A.vault read sys/leases/lookup/<lease_id>
B.vault lease list <lease_id>
C.vault lease lookup <lease_id>
D.vault lease renew -increment=0 <lease_id>
AnswerC

This command shows the lease details including remaining TTL.

Why this answer

The `vault lease lookup` command is the correct way to inspect the remaining lifespan and metadata of a specific lease in Vault. It returns details such as the lease ID, issue time, expiration time, and TTL, allowing the admin to determine how much time remains before the lease expires.

Exam trap

The HashiCorp Vault exam often tests the distinction between `vault lease lookup` and `vault read sys/leases/lookup`, where candidates mistakenly think `vault read` can directly access the lease lookup endpoint without the proper command syntax.

How to eliminate wrong answers

Option A is wrong because `vault read sys/leases/lookup/<lease_id>` is not a valid Vault command; the correct API endpoint is `/sys/leases/lookup` but it is accessed via `vault lease lookup`, not `vault read`. Option B is wrong because `vault lease list` lists all lease IDs under a given prefix or mount, but does not show the remaining lifespan of a single lease. Option D is wrong because `vault lease renew -increment=0` attempts to renew the lease with zero increment, which is not a lookup operation and may actually revoke the lease or cause an error depending on the lease type, rather than simply checking its remaining lifespan.

Practice this question →
27
MCQhard

A developer runs the commands shown in the exhibit. After renewing the lease, the lease_duration remains 1 hour. What is the most likely reason?

A.The lease is not renewable.
B.The mount's max_lease_ttl is set to 1h.
C.The developer does not have permission to renew the lease.
D.The role's max_ttl is set to 1h.
AnswerD

The role max_ttl caps the lease duration.

Why this answer

The role's max_ttl overrides the lease duration when it is shorter than the requested TTL. Even if the lease is renewed, the effective TTL cannot exceed the role's max_ttl, which is set to 1 hour. This is a common Vault behavior where the role's maximum TTL acts as a hard cap on lease lifetimes.

Exam trap

HashiCorp often tests the distinction between role-level and mount-level TTL limits, trapping candidates who assume the mount's max_lease_ttl is the sole constraint when a lower role max_ttl is configured.

How to eliminate wrong answers

Option A is wrong because Vault leases are inherently renewable unless explicitly configured otherwise; the question states the lease was renewed, so it is renewable. Option B is wrong because the mount's max_lease_ttl is a system-wide limit, but the role's max_ttl is a more specific constraint that takes precedence when it is lower. Option C is wrong because the developer successfully renewed the lease, which requires permission to renew; if permission were lacking, the renewal would fail entirely.

Practice this question →
28
Matchingmedium

Match each Vault term to its definition.

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

Concepts
Matches

Encrypted state requiring unseal

Decrypt master key to access data

Encryption layer protecting storage

Key splitting for unseal

Superuser token with full access

Why these pairings

Correct matches: Secret is sensitive data; Token is an authentication credential. Common confusions: Policy vs. Auth Method — policies control access, auth methods authenticate users.

Practice this question →
29
Multi-Selectmedium

An admin needs to revoke all leases associated with a particular policy violation. Which two methods can be used? (Choose two.)

Select 2 answers
A.vault sys/leases/revoke-force <prefix>
B.vault token revoke -mode=orphan <token>
C.vault lease revoke <lease_id>
D.vault write sys/leases/revoke-prefix <prefix>
E.vault lease revoke -prefix <mount_path>
AnswersD, E

API equivalent to revoke by prefix.

Why this answer

`vault write sys/leases/revoke-prefix <prefix>` revokes all leases sharing a given prefix, which is the standard method for bulk revocation based on a policy violation path. Option E is correct because `vault lease revoke -prefix <mount_path>` achieves the same result by revoking all leases under a specified mount path, effectively targeting the same scope. Both commands allow an admin to revoke multiple leases associated with a particular policy violation without needing individual lease IDs.

Exam trap

This question tests your ability to distinguish between the `revoke-prefix` and `revoke-force` commands, as well as understanding that individual lease revocation or token revocation commands are not suited for bulk lease revocation by policy violation. Candidates often confuse the CLI syntax or mistakenly think `vault lease revoke` with a single lease ID can revoke all leases, or that `vault token revoke -mode=orphan` affects leases.

Practice this question →
30
MCQeasy

A developer is troubleshooting an application that uses Vault's PostgreSQL secrets engine. The application successfully obtains a database credential from Vault, but after 30 minutes, the application starts receiving authentication errors from the database. The developer checks the Vault audit logs and sees that the lease for the credential was revoked. The lease was originally created with a TTL of 1 hour. The application is not renewing the lease. The developer wants to fix the issue so that the credential works for the full 1 hour. What should the developer do?

A.Revoke the lease and request a new credential with a longer TTL.
B.Modify the application to renew the lease before it expires using the lease ID.
C.Use the lease ID from the response to call sys/leases/renew periodically.
D.Increase the TTL of the database role to 2 hours.
AnswerB, C

Correct. The application must actively renew the lease using its lease ID before the lease expires to avoid authentication errors.

Why this answer

Both options B and C describe valid approaches to renewing the Vault lease. Option B correctly states that the application must modify its code to renew the lease before it expires using the lease ID. Option C is also correct because calling `sys/leases/renew` periodically with the lease ID achieves the same goal; the phrase 'periodically' is acceptable as long as the renewal happens before the lease expires.

Options A and D are incorrect because increasing the TTL does not address the application's failure to renew the lease, and simply revoking and requesting a new credential without renewal will lead to the same issue.

Exam trap

The trap is that candidates might think only one explicit renewal method is correct, but both modifying the application to use the lease ID and calling sys/leases/renew periodically are valid, as long as the renewal happens before the lease expires.

How to eliminate wrong answers

Option A is wrong because revoking the lease and requesting a new credential with a longer TTL does not address the root cause—the application's failure to renew the lease; the credential will still expire if not renewed. Option C is wrong because calling sys/leases/renew is the correct API endpoint for renewal, but the developer needs to modify the application to call it periodically, not just use the lease ID from the response; the option implies a manual or one-time action, not a programmatic renewal loop. Option D is wrong because increasing the TTL of the database role to 2 hours only extends the maximum lease duration, but the application still does not renew the lease, so the credential will still be revoked after the TTL (now 2 hours) unless renewed; the issue is the lack of renewal, not the TTL length.

Practice this question →
31
MCQhard

A security team wants to ensure that database credentials generated by Vault are never renewed and have a fixed lifespan of 30 minutes. They configure the role with default_ttl=30m and max_ttl=30m, and set renewable=false. However, they find that some users are able to renew the leases anyway. What could be the reason?

A.The renewable flag requires the role to be updated after existing leases are issued.
B.The renewable flag is not respected when max_ttl equals default_ttl.
C.The renewable flag is only applicable to token auth methods, not secrets engines.
D.The lease's renewable property is controlled by the client token's renewable status.
AnswerA

Existing leases retain their original renewable setting; only new leases reflect the updated role.

Why this answer

The `renewable=false` setting on a Vault role only affects newly issued leases; it does not retroactively apply to leases that were already issued before the role was updated. Since the security team configured the role after some users had already obtained credentials, those existing leases retain their original `renewable=true` property, allowing users to renew them despite the new role setting. Vault enforces the `renewable` flag at lease creation time, not dynamically during renewal requests.

Exam trap

The trap in Vault is that the `renewable` flag on a role only affects new leases issued after the role update, not existing leases. Candidates often incorrectly assume that changing the role setting immediately prevents renewals, but Vault applies the flag at lease creation time.

How to eliminate wrong answers

Option B is wrong because the `renewable` flag is fully independent of TTL values; setting `max_ttl` equal to `default_ttl` does not override or disable the `renewable` flag. Option C is wrong because the `renewable` flag is applicable to both token auth methods and secrets engines (e.g., database, AWS, PKI) when generating dynamic credentials; it is not limited to token auth methods. Option D is wrong because the lease's `renewable` property is controlled by the role configuration of the secrets engine that issued the lease, not by the client token's `renewable` status; the client token's renewability is a separate concern.

Practice this question →
32
MCQmedium

An operator runs vault lease list and sees many expired leases. Why are expired leases still listed?

A.The leases are not actually expired.
B.The operator has a permission to see expired leases.
C.Vault keeps expired leases for auditing until cleaned up by garbage collection.
D.Expired leases are never removed.
AnswerC

Expired leases remain in storage until garbage collection runs.

Why this answer

Vault does not immediately remove expired leases; they are cleaned up by a periodic garbage collection process. Until then, they may appear in listing.

Practice this question →
33
MCQeasy

An admin wants to revoke all leases associated with a specific AWS IAM user created by Vault. Which command should they use?

A.vault lease revoke aws/creds/myrole/ -prefix
B.vault lease revoke aws/creds/myrole
C.vault lease revoke -prefix aws/creds/myrole
D.vault lease revoke -path aws/creds/myrole
AnswerC

This revokes all leases starting with 'aws/creds/myrole', which covers all IAM users from that role.

Why this answer

The `vault lease revoke -prefix` command revokes all leases that share a given prefix. Since AWS IAM user credentials generated by Vault under `aws/creds/myrole` have lease IDs that begin with that path, using the `-prefix` flag ensures all associated leases are revoked, regardless of their full lease ID.

Exam trap

A common trap in Vault exams is confusing the `-prefix` flag with the `-path` flag. The `-prefix` flag revokes all leases under a path, while `-path` is not a valid flag for lease revocation. Candidates may incorrectly think that just specifying the path without `-prefix` will revoke all leases, but that would only work if the exact lease ID is provided.

How to eliminate wrong answers

Option A is wrong because `-prefix` is a flag, not a positional argument; placing it after the path is syntactically incorrect. Option B is wrong because `vault lease revoke aws/creds/myrole` without the `-prefix` flag attempts to revoke a single lease with that exact ID, which does not exist (lease IDs are full UUIDs), so it will fail. Option D is wrong because `-path` is not a valid flag for `vault lease revoke`; the correct flag to revoke by prefix is `-prefix`.

Practice this question →
34
Multi-Selecthard

An organization uses Vault's AWS secrets engine to generate temporary IAM credentials. The Vault administrator has set the default lease TTL on the AWS mount to 15 minutes. A developer creates a role with role TTL of 30 minutes and explicit max TTL of 1 hour. Which TWO statements are true regarding the lease behavior for credentials generated under this role?

Select 2 answers
A.The initial lease duration will be 30 minutes (the role TTL).
B.The lease can be renewed up to a total lifetime of 1 hour (explicit max TTL).
C.The lease can be renewed indefinitely up to the system max TTL.
D.The initial lease duration will be 15 minutes (the default lease TTL).
E.The lease duration is the minimum of default lease and role TTL.
AnswersA, B

The role TTL is used as the lease duration at creation time.

Why this answer

When a role has an explicit role TTL (30 minutes), Vault uses that value as the initial lease duration for credentials generated under that role, overriding the default mount TTL. The default lease TTL of 15 minutes on the AWS mount only applies when no role TTL is specified.

Exam trap

HashiCorp often tests the distinction between initial lease duration (role TTL) and total allowable lifetime (explicit max TTL), and the trap here is assuming the default mount TTL or a minimum calculation governs the initial lease when a role TTL is explicitly configured.

Practice this question →
35
MCQeasy

Which of the following best describes a Vault lease?

A.A permission to access a path.
B.A time-limited agreement that governs the lifecycle of a secret.
C.A contract to use a secret for a certain duration.
D.The actual secret value.
AnswerB

This accurately describes a lease as a time-bound contract for secret usage.

Why this answer

A Vault lease is a time-bound agreement that governs the lifecycle of a secret, including its validity period, renewal, and revocation. When a secret is read from Vault, it is returned with a lease ID and a lease duration (TTL), after which the secret is automatically revoked unless renewed. This ensures that secrets are not valid indefinitely, reducing the risk of exposure.

Exam trap

HashiCorp often tests the distinction between the lease itself (the lifecycle management agreement) and the secret value, leading candidates to mistakenly choose Option D because they think the lease is the actual secret.

How to eliminate wrong answers

Option A is wrong because a Vault lease is not merely a permission to access a path; permissions are defined by policies attached to tokens or auth methods, not by leases. Option C is wrong because a lease is not a contract to use a secret for a certain duration; it is a technical mechanism that automatically manages the secret's lifecycle, including renewal and revocation, not a contractual agreement. Option D is wrong because the actual secret value is the data returned by Vault (e.g., a password or API key), while the lease is the metadata (lease ID, TTL, renewable flag) that controls that secret's lifecycle.

Practice this question →
36
MCQmedium

A developer wants to ensure that their application automatically renews its secret leases before expiration. Which approach is recommended?

A.Set the lease TTL to infinite.
B.Use a cron job to call vault lease renew periodically.
C.Use Vault agent with a template and renew capability.
D.Use periodic tokens with auto-renewal.
AnswerC

Vault Agent is designed for automatic lifecycle management of leases.

Why this answer

Vault Agent's template and renew capability is the recommended approach because it automatically manages the lifecycle of dynamic secrets, including renewing leases before they expire. Vault Agent runs as a sidecar or daemon and uses its built-in renewer to periodically extend the lease TTL, ensuring the application always has a valid secret without manual intervention or external scheduling.

Exam trap

HashiCorp often tests the distinction between renewing a token (which can use periodic tokens) versus renewing a secret lease (which requires Vault Agent or explicit lease renewal), causing candidates to mistakenly choose periodic tokens for secret lease renewal.

How to eliminate wrong answers

Option A is wrong because setting the lease TTL to infinite is not supported by Vault; leases always have a finite TTL defined by the secret engine's default or maximum, and infinite TTL would violate security best practices by never forcing rotation. Option B is wrong because using a cron job to call vault lease renew is brittle and not recommended; it introduces a single point of failure, lacks awareness of lease expiration timing, and does not handle Vault Agent's automatic renewal or template rendering. Option D is wrong because periodic tokens with auto-renewal are used for long-lived tokens, not for renewing secret leases; secret leases (e.g., database credentials, AWS IAM keys) require explicit lease renewal via the /sys/leases/renew endpoint, and periodic tokens do not automatically renew those leases.

Practice this question →
37
MCQhard

An organization uses Vault with a database secrets engine. They have a role that issues credentials with a lease TTL of 30 minutes. After some time, they notice that the database is full of stale users. What is the most likely cause?

A.The lease revocation process is failing due to network issues.
B.The database rotation statement is incorrect, causing Vault to not properly revoke credentials.
C.The role's max_ttl is set too high, allowing leases to live longer.
D.Vault's tidy operation is not configured to clean up stale leases.
AnswerD

Without tidy, expired leases may not have their underlying secrets revoked.

Why this answer

Vault's database secrets engine does not automatically clean up stale user accounts in the target database. The `tidy` operation must be explicitly configured and run to remove users whose leases have expired or been revoked. Without it, even if Vault correctly revokes the lease, the database user may remain, leading to an accumulation of stale accounts.

Exam trap

The trap here is that candidates confuse Vault's lease revocation with database user cleanup, assuming that revoking a lease automatically deletes the corresponding database user, when in fact Vault requires an explicit tidy operation to remove stale accounts.

How to eliminate wrong answers

Option A is wrong because network issues would cause lease revocation failures, but the question states the database is full of stale users, not that revocation is failing—Vault's lease revocation is a separate process from database user cleanup. Option B is wrong because the rotation statement controls how credentials are rotated, not how they are revoked; an incorrect rotation statement would affect credential renewal, not the presence of stale users. Option C is wrong because the `max_ttl` setting limits the maximum lifetime of a lease, but even if set high, Vault would still revoke the lease when it expires; the issue is that revocation does not delete the database user.

Practice this question →
38
MCQmedium

A Vault administrator wants to configure a role for dynamic secrets with a default TTL of 1 hour and a max TTL of 4 hours. They also want to allow renewal but only up to the max TTL. Which configuration achieves this?

A.default_ttl=1h, max_ttl=4h, renewable=false
B.default_ttl=4h, max_ttl=1h, renewable=true
C.default_ttl=1h, max_ttl=4h, renewable=true
D.default_ttl=1h, max_ttl=4h, renewable=true, ttl=1h
AnswerC

This allows renewal up to the max_ttl of 4 hours.

Why this answer

It sets the default TTL to 1 hour, the maximum TTL to 4 hours, and enables renewal (renewable=true). In Vault, dynamic secret leases can be renewed up to the max_ttl, so with this configuration the initial lease is 1 hour, and each renewal extends the lease until the total lifetime reaches 4 hours, after which no further renewals are allowed.

Exam trap

A common trap is confusing the order of default_ttl and max_ttl. Remember that default_ttl sets the initial lease duration, while max_ttl limits the total lifetime including renewals. Also, renewable=true must be set to allow renewal up to the max_ttl.

How to eliminate wrong answers

Option A is wrong because renewable=false prevents any renewal, so the lease would expire after 1 hour and cannot be extended to the max TTL of 4 hours. Option B is wrong because it sets default_ttl=4h and max_ttl=1h, which is invalid—the default TTL cannot exceed the max TTL; Vault would reject this configuration or cap the default to the max. Option D is wrong because it includes an extra ttl=1h parameter, which is not a valid role parameter for dynamic secrets (the correct parameters are default_ttl and max_ttl); adding an undefined parameter may cause an error or be ignored, but the core issue is that it introduces confusion without adding value.

Practice this question →
39
MCQeasy

What command is used to view the remaining time on a lease?

A.vault lease lookup <lease_id>
B.vault lease info <lease_id>
C.vault status <lease_id>
D.vault read <lease_id>
AnswerA

This command shows lease information including TTL.

Why this answer

The correct command to view the remaining time on a lease is `vault lease lookup <lease_id>`. This command retrieves the lease metadata, including the issue time, duration (TTL), and remaining time, directly from the Vault server. It is the standard method for inspecting lease details without extending or modifying the lease.

Exam trap

HashiCorp often tests the distinction between `vault lease lookup` and `vault read`, where candidates mistakenly think `vault read` can inspect lease details because it is used to read secrets, but lease metadata requires a dedicated lease API command.

How to eliminate wrong answers

Option B is wrong because `vault lease info` is not a valid Vault CLI command; the correct subcommand is `lookup`. Option C is wrong because `vault status` displays the seal status and HA state of the Vault server, not lease information. Option D is wrong because `vault read` is used to read secrets or data from a path, not to inspect lease metadata; it would attempt to read the path as a secret, which would fail or return unrelated data.

Practice this question →
40
Multi-Selecteasy

Which two of the following are valid lease operations? (Choose two.)

Select 2 answers
A.vault lease renew
B.vault lease create
C.vault lease delete
D.vault lease generate
E.vault lease revoke
AnswersA, E

This is a valid command to renew leases.

Why this answer

`vault lease renew` is a valid Vault CLI command used to extend the lifetime of a lease before it expires. In HashiCorp Vault, leases are associated with dynamic secrets (e.g., database credentials, AWS IAM keys) and must be periodically renewed to maintain access. The `renew` operation is a core lease lifecycle operation supported by the Vault API and CLI.

Exam trap

HashiCorp often tests the distinction between lifecycle operations that are explicitly supported (renew, revoke) versus operations that are not part of the Vault CLI (create, delete, generate), leading candidates to assume all CRUD-like verbs are valid.

Practice this question →
41
MCQmedium

A DevOps team uses Vault to generate temporary database credentials. They notice that some applications are failing because their database credentials expire unexpectedly before the expected TTL. The Vault admin configured the database role with a default TTL of 1h and max TTL of 24h. What is the most likely cause?

A.The database role's max TTL is being enforced, but the default TTL is shorter.
B.The Vault server's clock is skewed, causing early expiry.
C.The application is renewing the lease too frequently, causing Vault to reset the TTL.
D.The application is not renewing the lease, and the lease TTL is counted from the issue time.
AnswerD

Leases expire based on their original TTL if not renewed before expiry.

Why this answer

Vault database credentials are issued as leases with a TTL that starts counting from the moment they are issued. If the application does not renew the lease, the credentials expire exactly after the default TTL (1 hour) has elapsed, regardless of the max TTL setting. The failure occurs because the application expects the credentials to last longer, but the lease TTL is not extended without renewal.

Exam trap

A common trap in the HashiCorp Vault exam is confusing default TTL with max TTL. Candidates may think max TTL is the credential lifetime, but the default TTL is the initial lease duration, and renewal is required to extend it up to the max TTL.

How to eliminate wrong answers

Option A is wrong because the max TTL of 24h is not being enforced prematurely; the default TTL of 1h is the actual lease duration, and the max TTL only caps the total possible renewal period. Option B is wrong because Vault uses its own internal clock for lease expiry, and while clock skew can cause issues, it is not the most likely cause given the scenario describes credentials expiring at the expected TTL boundary. Option C is wrong because renewing a lease resets the TTL from the renewal time, extending the lease; frequent renewal would actually prevent early expiry, not cause it.

Practice this question →
42
Drag & Dropmedium

Drag and drop the steps to configure Vault's audit logging to a file into the correct order.

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

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

Why this order

The correct sequence for configuring Vault's audit logging to a file is: first enable the audit device (e.g., 'vault audit enable file file_path=...'), then perform operations (e.g., read/write secrets) to generate audit log entries, and finally verify the log file to confirm entries are being recorded. Common mistakes include enabling after generating logs, verifying too early, or skipping the generation step.

Practice this question →
43
Multi-Selecteasy

Which TWO of the following actions can reduce the number of active leases in Vault? (Select two.)

Select 2 answers
A.Reducing the default lease TTL
B.Revoking a lease
C.Creating a new lease
D.Increasing the max lease TTL
E.Renewing a lease
AnswersA, B

Shorter TTLs cause leases to expire faster, reducing count.

Why this answer

Reducing the default lease TTL (time-to-live) shortens the maximum duration for which a lease can be issued without renewal. When existing leases expire sooner, the system automatically removes them from the active lease count, thereby reducing the number of active leases. This directly affects the lease lifecycle by forcing earlier expiration.

Exam trap

HashiCorp often tests the misconception that increasing TTL values or renewing leases reduces active leases, but both actions actually prolong lease lifetimes and can increase the active count if new leases are created concurrently.

Practice this question →
44
MCQhard

A Vault cluster is sealed. An operator attempts to renew a lease but gets an error. What is the most likely error?

A.Vault is sealed
B.Upstream error
C.Permission denied
D.Lease not found
AnswerA

Vault returns an error indicating it is sealed when trying to perform operations.

Why this answer

When Vault is sealed, it cannot process any operations, including lease renewal. The error would indicate the sealed state.

Practice this question →
45
MCQhard

A Vault operator runs the command shown in the exhibit and wants to renew the lease before it expires. The operator has a valid token. What must be true for the renewal to succeed?

A.The operator must first revoke the lease and re-issue it to obtain a longer TTL.
B.The token's 'explicit_max_ttl' must be at least as long as the lease's remaining TTL.
C.The 'max_ttl' parameter in the database role must be increased to allow renewal.
D.The operator can renew the lease by running 'vault lease renew database/creds/my-role/abc123'.
AnswerD

Since the lease is renewable and the token is valid, a simple renew command will succeed and extend the lease.

Why this answer

The `vault lease renew` command with the specific lease ID (`database/creds/my-role/abc123`) is the standard way to extend a lease's TTL, provided the token has sufficient privileges and the lease is renewable. The operator has a valid token, so no prior revocation or role modification is required; the renewal will succeed as long as the token's policies allow it and the lease's remaining TTL is within the token's `explicit_max_ttl`.

Exam trap

A common trap is thinking that modifying the role's `max_ttl` or the token's `explicit_max_ttl` is necessary to renew a lease. In reality, renewal simply fails if those limits are exceeded; the correct action is to use the `vault lease renew` command with the lease ID.

How to eliminate wrong answers

Option A is wrong because revoking and re-issuing the lease is unnecessary and would break the existing credential; renewal extends the current lease without recreating it. Option B is wrong because the token's `explicit_max_ttl` limits the total lifetime of the token, not the lease; the lease's renewal is constrained by its own `max_ttl` and the role's settings, not the token's explicit max TTL. Option C is wrong because the `max_ttl` in the database role sets an upper bound on the lease duration, but it does not need to be increased for a single renewal to succeed unless the current lease has already reached that maximum; the renewal will simply fail if the lease's TTL would exceed the role's `max_ttl`.

Practice this question →
46
MCQmedium

Refer to the exhibit. A user with this policy can successfully read credentials but cannot renew the lease. What is the missing capability?

A.'list' on sys/leases/.
B.'renew' on the secret path.
C.'sudo' on sys/leases/.
D.'update' on sys/leases/renew.
AnswerD

This capability is required to perform lease renewal.

Why this answer

The user can read credentials but cannot renew the lease because the policy grants 'read' and 'list' capabilities on the secret path, but renewing a lease requires the 'update' capability on the 'sys/leases/renew' endpoint. This endpoint is used to extend the lifetime of a lease, and without 'update' access, the renewal request is denied.

Exam trap

HashiCorp often tests the distinction between capabilities on the secret path versus the system lease path, leading candidates to mistakenly think 'read' or 'list' on the secret path is sufficient for renewal.

How to eliminate wrong answers

Option A is wrong because 'list' on 'sys/leases/' allows listing active leases but does not grant the ability to renew a specific lease; renewal requires a different endpoint and capability. Option B is wrong because 'renew' is not a valid capability in Vault's policy language; capabilities are 'create', 'read', 'update', 'delete', 'list', and 'sudo', and the renewal action is mapped to 'update' on the 'sys/leases/renew' path. Option C is wrong because 'sudo' on 'sys/leases/' provides elevated privileges for certain operations but does not specifically grant the 'update' capability needed for lease renewal; 'sudo' is a modifier that bypasses ACL checks but still requires the appropriate capability on the endpoint.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Vault Leases questions.

Start 20-question session