Vault Secrets Engines Overview: Static, Dynamic, and Cryptographic Categories

Secrets Engines are the heart of Vault. Each engine is mounted at a path, and the path determines what happens there (store, issue, or encrypt). This article walks through the categories you see most often on the exam — static, dynamic, and encryption/signing — covering behavior, use cases, and exam-relevant points.

At the Associate level, what matters is being able to tell apart static management with KV, dynamic credential issuance with engines like Database and AWS, and encryption/signing with Transit using concrete examples. We focus on the stable fundamentals: TTL/Lease, Revoke/Renew, policy application, and path design.

The Big Picture and Categories of Secrets Engines

A Secrets Engine is a plugin mounted into Vault, with paths separated by purpose. For example, kv/ stores key-value pairs, database/ issues dynamic DB credentials, and transit/ provides data encryption/signing. Clients access paths with a token plus policy, and the engine performs the corresponding action.

The classification axes are: do you store the value (static), issue it on demand (dynamic), or hold no data and only perform operations on it (encryption/signing)? This split is the first decision point both in design and on the exam.

• Static: store and retrieve existing values (e.g., kv)
• Dynamic: issue temporary credentials on demand with a Lease/TTL (e.g., database, aws)
• Encryption/signing: hold no data; provide key-based operations (e.g., transit)
• Policies grant capabilities (read, create, update, delete, list, sudo) against paths
• A Lease is the lifetime attached to an issued artifact. Manage it alongside token TTL/Renew.

Authorization and engine dispatch flow in Vault

Enabling representative engines (example)

# Administrator enables engines at the required paths
vault secrets enable -path=kv kv-v2
vault secrets enable -path=database database
vault secrets enable -path=transit transit

# Check current mounts
vault secrets list -detailed

Static Secrets: Key Points of the KV Engine

Static secrets follow a simple model: retrieve a value that was previously stored. The most common engine is kv, which holds app config, API keys, webhook tokens, and so on. At the Associate level, the key points are path design, granting least-privilege policies, and operations (update, delete, audit).

The versioned implementation of kv is widely used. With versioning, you get operations like retrieving the latest or a specific version, soft delete, and hard delete — all useful for audit and rollback. When the exam asks about versioning, the keywords to remember are metadata and history management.

• Use case: centralized management of config values and long-lived tokens
• Policy: grant only read per path; restrict create/update
• Lifecycle: rotation (periodic updates), labeling/folder partitioning, audit logs
• Security: allow apps only the minimum required paths and separate them per environment (dev/stg/prd)

KV fundamentals (store / retrieve / version management examples)

# Enable the engine first if it is not already enabled
vault secrets enable -path=kv kv-v2

# Store (create/update)
vault kv put kv/app/config api_key=xxx timeout=30

# Retrieve (latest)
vault kv get kv/app/config

# Overwrite (creates a new version)
vault kv put kv/app/config api_key=yyy timeout=30

# Retrieve a specific version (e.g., version 1)
vault kv get -version=1 kv/app/config

# Soft delete (deletes the latest)
vault kv delete kv/app/config

# Hard delete (erases the history itself)
vault kv destroy -versions=1 kv/app/config

Dynamic Secrets: Issuance Engines like Database and AWS

Dynamic secrets issue short-lived credentials on every request, with Lease/TTL governing their lifetime. Because expiry or Revoke disables the credentials, they reduce leak risk and make least-privilege easy to implement. Canonical examples are database (issuing user/password for RDBMSs) and aws (issuing IAM credentials).

Issuance is role-based. A role defines the connection target, the permissions (e.g., DB GRANTs), the maximum TTL, and whether Renew is allowed. Clients just call read to get a fresh credential; the response carries metadata such as lease_id, lease_duration, and renewable.

• Lease/TTL: lifetime is explicit and the credential is invalidated after expiry
• Renew: extend as needed (watch the maximum TTL)
• Revoke: instant invalidation (use on leak or decommission)
• Role design: least-privilege principle, max TTL, and rotation policy
• Audit: who issued, from which role, and when

From minimum Database engine setup through issuance and revocation

# Enable the engine
vault secrets enable -path=database database

# Connection (e.g., PostgreSQL). Register connection info with an admin user
vault write database/config/appdb \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=disable" \
  username="vault_admin" \
  password="s3cr3t"

# Define a role (least privilege, TTL settings)
vault write database/roles/app \
  db_name=appdb \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl=1h \
  max_ttl=24h

# Issue dynamic credentials (read produces a fresh credential)
vault read database/creds/app
# -> receive username/password and lease_id/lease_duration

# Revoke (instant invalidation on leak, etc.)
vault lease revoke <lease_id>

Encryption/Signing: Design Points for the Transit Engine

Transit does not store data. It is an "encryption service" that protects and operates on keys inside Vault, encrypting/decrypting plaintext sent by the client and signing/verifying data. The storage destination (DB, S3, etc.) is the application's responsibility.

The benefits are that applications never touch raw key material and that audit, rotation, and access control are centralized in Vault. Use cases include column-level encryption of sensitive data, transparent token signing, and message authentication between services.

• Data is not stored (the ciphertext/signature is returned)
• Centralized key management (creation, rotation, disabling)
• Operations: encrypt/decrypt, sign/verify, rewrap (re-encrypt ciphertext when keys rotate)
• Permissions are granted per path such as transit/keys/<name> or encrypt/decrypt

Creating a Transit key and performing encrypt/decrypt and sign/verify

# Enable the engine
vault secrets enable -path=transit transit

# Create a key (symmetric key example)
vault write -f transit/keys/payroll

# Encrypt (Base64 in and out is the default)
PLAINTEXT=$(echo -n "card=4111111111111111" | base64)
vault write transit/encrypt/payroll plaintext="$PLAINTEXT"
# -> ciphertext: vault:v1:...

# Decrypt
CIPHERTEXT="vault:v1:..."
vault write transit/decrypt/payroll ciphertext="$CIPHERTEXT"
# -> plaintext: Base64 (client decodes to plaintext)

# Sign / verify (for asymmetric keys or HMAC use)
vault write transit/sign/payroll input="$PLAINTEXT"
# -> signature: vault:sha2-256:...
vault write transit/verify/payroll input="$PLAINTEXT" signature="vault:sha2-256:..."

Access Control and Lifecycle: Policy, TTL, and Audit

Vault controls per-path capabilities with policies and manages lifecycle by attaching TTLs to tokens and Leases. A token's expiry and a dynamic secret's Lease expiry are independent — when either expires, effective access is lost.

In operations, choose deliberately between Renew (extend) and Revoke (invalidate), enforce max TTLs, and periodically review roles and policies. Drive everything from audit logs (who read or issued what) and during incidents execute lease revoke and token revocation immediately.

• Policies follow least privilege (only the required capabilities on required paths)
• Do not confuse token TTL with Lease TTL
• Renew works within the max TTL; Revoke invalidates immediately
• Audit-driven periodic cleanup (remove unused roles and paths)

A read-only policy plus token TTL/renewal

# Policy definition (read-only on kv/app/config)
cat > ro-app.hcl <<'POLICY'
path "kv/data/app/config" {
  capabilities = ["read"]
}
POLICY
vault policy write ro-app ro-app.hcl

# Create a token with the policy (1-hour TTL, renewable)
vault token create -policy=ro-app -ttl=1h -renewable=true

# Renew the token (add 1 hour)
vault token renew <token>

# Revoke the token
vault token revoke <token>

Exam Strategy and Pitfalls (Associate)

Practice deciding the category from a scenario on the fly. If storage is required, use kv. If short-lived credentials are required, use database/aws. If data is not stored and you only need encryption operations, use transit. Being able to articulate the relationships among Lease/TTL, Renew/Revoke, and roles/policies translates directly into points.

Versioning (kv) and Lease (dynamic) are easy to confuse. The essence of Transit is that it does not store data — never forget that storing ciphertext is the application's job.

• Questions often boil down to a three-way choice: store vs issue vs encrypt
• Spot dynamic engines by Lease metadata (lease_id, lease_duration, renewable)
• Revoke invalidates immediately; Renew extends within the max TTL
• Transit manages keys but does not retain data
• kv is easy to lock down to read-only via policy; per-environment path separation is the standard approach

Practice mapping categories (points you can confirm via commands)

# Which engines are enabled (the basis for classification)
vault secrets list -detailed

# Dynamic engines return Lease info on the read path (e.g., database/creds/...)
vault read -format=json database/creds/app | jq '.lease_id, .lease_duration, .renewable'

# Transit centers on encrypt/decrypt paths; unlike kv, it does not hold data
vault list transit/keys

Check Your Understanding

Frequently Asked Questions