CCNA Manage Vault leases Questions

Vault issues dynamic secrets together with a lease that records the secret's time-to-live, whether it can be renewed, and how it should be revoked. This server-side metadata is what allows Vault to automatically revoke credentials when they are no longer valid, which is a core security benefit of using dynamic secrets over static credentials.

The max_ttl on the role is the hard ceiling on a lease's total lifetime from issuance. Renewals can extend expiration in increments up to the default TTL, but the expiration manager refuses to push past max_ttl, after which the application must obtain brand-new credentials through the creds endpoint.

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.

Token revocation cascades to the leases that token created, and revoking a dynamic secret's lease instructs the secrets engine to delete the external credential. Revocation is scoped rather than mount-wide, revoked leases cannot be revived, and normal revocation cleans up the external system instead of merely dropping Vault's record.

The vault lease revoke command with the -prefix flag revokes all leases whose IDs share a given path prefix. Because AWS dynamic credentials are issued under aws/creds/<role-name>, using that prefix scopes the revocation to the compromised role only, achieving rapid containment without tearing down the secrets engine or affecting other roles.

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.

Revoking by prefix targets all leases under the role's creds path in one operation and triggers the secrets engine to remove the corresponding database accounts. Forcing deletion skips backend cleanup, token revocation is scoped to tokens rather than roles, and disabling the mount destroys configuration the team still needs.

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.

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.

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.

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

Renewing a lease is an update to the sys/leases/renew endpoint, so the policy must grant update there. Reading lease metadata, using sudo on the generation path, or granting create instead of update all leave the renewal call unauthorized, which is exactly the failure the applications are hitting.

Leases on dynamic secrets can be extended with vault lease renew, which asks the secrets engine to grant more time within the role's max_ttl boundary. Revoking destroys the credential, renewing a token affects authentication rather than the secret, and re-writing the creds path issues a separate credential instead of extending the current one.

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.

To revoke all leases under a specific secrets engine path, the admin must use `vault lease revoke -prefix <path>`. The `-prefix` flag tells Vault to revoke every lease whose ID begins with the given string, which effectively targets all leases generated by that path. Other flags either expect a full lease ID or revoke everything cluster-wide.

Vault leases govern Vault-side lifecycle, but the credential's validity in the target system is separate. If a database administrator rotates the password or removes the user outside Vault, the credential stops working even though the Vault lease is still active and renewable. This mismatch between Vault lease state and external system state is a common cause of premature credential failure.

The mount's max_lease_ttl defines the absolute cumulative lifetime of a lease, and renewal cannot push a lease past that boundary. The application's renewals succeeded until the lease reached two hours, at which point renewal failed and the credential expired. The correct remediation is for the application to request a new credential when renewal is no longer granted.

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

Revoking a token causes Vault to revoke the leases created by that token, providing precise containment for a compromised identity. This targets only the credentials spawned by the leaked token while leaving unrelated leases intact. More disruptive actions such as revoking the mount or sealing the cluster are unnecessary and cause collateral impact.

To revoke a single lease, the admin should run `vault lease revoke <lease_id>` without any additional flags. This command targets exactly that lease and triggers the appropriate secrets engine to revoke the underlying credential. Using `-prefix` would revoke multiple leases, while `-all` and `-force` are either invalid or overly broad.

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.

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

A renewable lease is bounded by the mount's max_lease_ttl, which acts as a cumulative ceiling measured from lease creation. Renewal can extend the lease's expiration toward that ceiling but never beyond it. With a 1-hour max and 20 minutes already elapsed, the lease can be renewed only to the 1-hour mark, after which it must be reissued.

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.

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.

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.

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.

To extend an active lease without issuing new credentials, use vault lease renew with the lease ID. To check how much time remains before renewal, use vault lease lookup, which reports the lease's expiration and TTL. Together these operations let the team confirm the remaining lifespan and then extend the existing lease in place.

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

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.

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

The max_ttl on a PKI role establishes the absolute maximum lifetime for any certificate issued by that role. When a client requests a TTL beyond that value, Vault clamps the issued lease to max_ttl, so the certificate is valid for 72 hours. The default_ttl only applies when no TTL is specified.

Service tokens are bounded by both a renewable TTL and an absolute max_ttl. Each renewal extends the token's lifetime only until the max_ttl ceiling is reached; beyond that point Vault refuses to extend it, and the token expires. Expiration invalidates the token immediately, so subsequent API calls authenticated with it fail with permission denied, exactly as the application observes after about four hours.