Vault lets you fine-tune TTL and visibility per secrets engine and per auth method (i.e., per mount). When this is designed well, you can safely rotate short-lived dynamic secrets while avoiding unnecessary exposure.
Based on the stable behavior documented in the official docs, this article walks through the precedence between default_lease_ttl and max_lease_ttl, and the behavior of listing_visibility, with concrete examples. Items with minor version differences are flagged, and the key points commonly asked on the exam are summarized.
Vault enables secrets engines and auth methods as "mounts." Mount Tuning is the mechanism that overrides behavior such as TTL (default_lease_ttl, max_lease_ttl) and visibility (listing_visibility) on a per-mount basis.
The key idea is to start from the server-wide default and maximum TTLs and fine-tune for mount-specific requirements (e.g., short TTL for dynamic DB credentials, longer TTL for general-purpose KV). tune changes apply to newly issued leases and tokens; they do not apply retroactively to existing ones.
Conceptual view of per-mount TTL and visibility
default_lease_ttl is the standard lifetime for newly issued leases on that mount. max_lease_ttl is the cap; TTLs at issuance or renewal cannot exceed this value. The server-wide max_lease_ttl (set in the vault server config) also acts as the final cap, and a mount cannot specify a value beyond it.
Renewal behavior deserves special attention. Even if a client requests a longer TTL, any extension that exceeds the mount-level max_lease_ttl (and the server-wide cap) is either rejected or clamped to the cap. Depending on the engine or API, you may see either an error or silent clamping, so verify in advance that rounding behaves as you expect in production.
When a role-level or engine-specific TTL exists (e.g., a TTL set on a Database engine Role), it often takes precedence over default_lease_ttl, but all such values are still bound by max_lease_ttl and the server-wide cap.
In operations, you use vault secrets tune (for secrets engines) and vault auth tune (for auth methods). Units can be specified intuitively as 1h, 30m, or 3600s. After making a change, always confirm it took effect with the -detailed flag.
To automate via the API, use reads and writes against /sys/mounts/<path>/tune (secrets engines) or /sys/auth/<path>/tune (auth methods). For changes driven from CI/CD, capture the before and after values so you can detect drift.
Concrete CLI and API examples
# シークレットエンジン(database/)のTTLを調整
vault secrets tune -default-lease-ttl=1h -max-lease-ttl=24h database/
# 認証方式(kubernetes/)のTTLを調整
vault auth tune -default-lease-ttl=20m -max-lease-ttl=4h kubernetes/
# KVを一覧から隠す
vault secrets tune -listing-visibility=hidden kv/
# 反映確認（詳細表示）
vault secrets list -detailed
vault auth list -detailed
# APIでtune値を取得（例: database/）
# VAULT_ADDRとVAULT_TOKENを環境変数で指定している前提
curl -sH "X-Vault-Token: $VAULT_TOKEN" "$VAULT_ADDR/v1/sys/mounts/database/tune" | jq .listing_visibility controls how prominently a mount appears in listings. In operations, it is typical to use hidden for paths whose existence you want to hide (e.g., an administrative KV) while leaving general-purpose engines on default.
The available values and their fine-grained behavior depend on the Vault version, UI, and policy interactions. The unauth-related visibility in particular ties into enumeration behavior in an unauthenticated state, so confirm both the official docs and your own environment before relying on it.
| Value | Summary | Display in vault secrets list | Unauthenticated enumeration |
|---|---|---|---|
| default | Standard visibility. Recommended for general use. | Shown | Not shown (depends on environment, version, and policy) |
| hidden | Not shown in listings. Direct access by path is still possible. | Not shown | Not shown (direct URL access is a separate matter) |
| unauth (verify before use) | A setting that relates to enumeration in an unauthenticated state. Limited use cases. | Environment-dependent | Environment-dependent (verify against the official spec and your environment before production use) |
The principle for dynamic secrets is "short TTL with automatic renewal." For example, database/ credentials are typically 15-60 minutes, and cloud temporary credentials similar or slightly shorter, with the application designed to renew before expiry. Since the renewal cap is bounded by the mount-level max_lease_ttl and the server-wide cap, leave a sufficient buffer between your renewal interval and the cap.
TTL does not directly apply to static data such as KV, but tactics like setting the mount visibility to hidden to keep operational paths out of plain view are effective. The important thing is that, ultimately, access should be restricted by policy, not by visibility.
Common pitfalls: existing leases do not change TTL after tune; renewal requests come back shorter than expected (or are rejected) due to max_lease_ttl; and people misread hidden as "not in the listing means inaccessible." All of these are by design.
For exam prep, make sure you have the flow server cap → mount max → mount default / role-specific TTL down cold, along with when to use vault secrets tune vs. vault auth tune, and the meaning of listing_visibility=hidden (hidden but still present).
Ops
問題 1
An ops team configured the database/ mount with default_lease_ttl=30m and max_lease_ttl=2h. An app requests, immediately after issuance, that the lease be renewed to 90 minutes, and intends to renew periodically thereafter. Which statement is correct?
正解: C
max_lease_ttl=2h acts as the cap, and renewal requests cannot exceed it. 90 minutes is within the cap and is therefore allowed, but in real environments the way rounding and limits are applied varies by engine/API, so the resulting TTL may be clamped or otherwise limited by the cap. default_lease_ttl is just the initial value; it does not, by itself, prevent renewal.
I changed the TTL with tune, but the TTL on leases that were already issued did not change. Why?
tune changes apply only to leases issued after the change; they do not apply retroactively to existing leases. Existing leases are subject to the new constraints such as max_lease_ttl only when they are renewed.
Does setting listing_visibility=hidden make a mount completely inaccessible?
No. hidden only removes the mount from listings. A client that knows the path and has the right policy permissions can still access it. Control access with policies, not visibility.
Can I set a mount-level max_lease_ttl that is longer than the server-wide max_lease_ttl?
No. The server-wide max_lease_ttl is the final cap. The mount-level max_lease_ttl can only be set within that range. Values exceeding it are rejected or clamped to the cap.
Practice with certification-focused question sets
無料で問題を解いてみるNicheeLab Editorial Team
NicheeLab editorial team focused on data engineering and cloud certification learning. Content is structured around practical study needs and official exam domains.
Vault Core Concepts: Sealed/Unsealed, Auth, Secrets (2026)
Vault fundamentals — sealed/unsealed state, auth methods, se...
Vault Operations Professional (VOP-003): Complete Guide (2026)
Pass the Vault Operations Professional exam — enterprise pat...
Vault Path-Based Routing: API URL Structure (2026)
How Vault's path-based routing works — mount points, sub-pat...
Vault Tokens: Auth Token Mechanics (2026)
Token fundamentals — service vs. batch tokens, accessor, ren...
Vault Token Types: Service, Batch, Periodic (2026)
Service vs. batch tokens compared — performance, ACL behavio...