Select Two (Multi-Select) Questions

Reducing the default lease TTL

Leases expire when their TTL elapses, so lowering the default lease TTL causes leases to be revoked sooner and reduces how many remain active at any moment. This directly decreases the count of outstanding leases Vault must track.

Revoking a lease

Revoking a lease immediately invalidates it and removes it from Vault's active lease set, rather than waiting for TTL expiry. This directly decreases the number of active leases, satisfying the stem's requirement to reduce them.

Barrier encryption key

The barrier key encrypts Vault's root key, which in turn protects every data encryption key, so no data at rest can be decrypted without it. This satisfies the stem's requirement for encryption at rest, since the barrier is the foundational cryptographic layer underpinning Vault's storage backend.

Storage backend

Vault's storage backend persists the encrypted data, so it is mandatory for encryption at rest. Without a configured backend such as Integrated Storage or Consul, Vault has nowhere to write ciphertext, meaning the barrier cannot protect anything. The backend satisfies the stem's requirement that encrypted data must actually be stored.

Seal mechanism

Vault's seal mechanism protects the root key, which encrypts the data encryption keys securing stored data. Without an unsealed barrier, the barrier key remains inaccessible and encryption at rest cannot function. This satisfies the stem's requirement by providing the cryptographic root of trust underpinning the entire storage encryption hierarchy.

Can generate IAM users with custom policies

The AWS secrets engine can mint IAM users, attaching custom policies that scope permissions per credential. The Azure secrets engine issues service principals and role assignments instead, so per-request custom policy generation is unique to AWS.

Can generate STS temporary credentials for cross-account access

AWS supports STS AssumeRole, issuing short-lived temporary credentials that can target a role in another account. The Azure secrets engine issues service principal credentials scoped to its own tenant, so cross-account federation via STS is AWS-specific.

Configure the 'ttl' parameter in the PKI role definition.

The PKI role's ttl parameter sets the default lease duration for certificates issued under that role, so adjusting it directly controls how long issued certificates remain valid. This is the supported mechanism for influencing lease duration at issuance time.

Set the 'default_lease_ttl' on the PKI secrets engine mount.

Setting default_lease_ttl on the PKI secrets engine mount caps certificate lifetimes, since Vault uses the mount's TTL as the baseline when the role does not override it. This directly satisfies the operator's need to manage lease durations for issued certificates.

vault read auth/token/lookup-self

The lookup-self endpoint returns metadata about the calling token itself, including its attached policies, TTL and renewal status. Reading auth/token/lookup-self therefore satisfies the requirement to inspect the current token without needing its accessor or a privileged token.

vault token lookup

`vault token lookup` queries the token's own accessor and returns its metadata, including TTL, issue time, renewal status and attached policies — exactly the token information the user needs. It satisfies the stem's requirement to view current token policies and TTL without requiring the root token or any privileged path.

Rewrap all existing ciphertext with the new key version.

Rewrapping re-encrypts existing ciphertext under the new key version without exposing plaintext, satisfying the compliance requirement that data previously encrypted with the retired version remains readable. Vault's `rewrap` endpoint decrypts with the old version and re-encrypts with the latest, so historical ciphertext stays accessible after rotation.

Rotate the key using Vault's key rotation endpoint.

Rotating via Vault's key rotation endpoint generates a new version of the encryption key while retaining old versions for decryption, satisfying the periodic rotation requirement. Vault's transit secrets engine supports this natively, so existing ciphertext remains decryptable and no re-encryption is forced immediately.

Allows applications to delegate encryption/decryption to Vault without handling keys

Vault's transit secrets engine performs cryptographic operations server-side, so applications send plaintext to Vault and receive ciphertext back without ever holding key material. This satisfies the stem's delegation benefit: encryption and decryption are offloaded, keys remain centrally managed, and no application-side key handling or storage is required.

Provides automatic key rotation and versioning

Vault's transit engine manages keys centrally, automatically rotating them on a defined schedule and retaining prior versions. This satisfies the benefit of removing manual key lifecycle work, so applications keep decrypting older ciphertext while new encryptions use the latest key version.

Signing and verifying data

The Transit secrets engine performs cryptographic operations on data in transit without storing it, so signing and verifying data is a core capability. It satisfies the stem's requirement for a valid use case by handling signing and verification through named encryption keys, keeping plaintext outside Vault entirely.

Encrypting data in transit without exposing the encryption key

The Transit secrets engine performs cryptographic operations server-side, so applications submit plaintext to Vault and receive ciphertext back without ever handling the encryption key itself. This satisfies the stem's requirement for encryption without key exposure, enabling centralised key management, rotation and audit logging across distributed services.

It stores encrypted data

Data is encrypted by the barrier before storage.

It is abstracted and can be swapped

Vault supports multiple storage backends.

Barrier

The barrier is Vault's core security mechanism: data in the storage backend stays encrypted until unsealed with unseal keys, separating storage from trust. This satisfies the stem by naming a genuine architectural component, distinct from pluggable storage and audit devices.

Seal

The seal is a core architectural component: Vault starts sealed and must be unsealed with threshold key shares before any secret operation. It directly satisfies the question's requirement for a genuine architecture component, alongside the storage backend and barrier.

Renewing a lease increments the lease number.

Each renewal increases the lease number, visible in lease details.

A lease can be renewed up to the max_lease_ttl.

Max_lease_ttl sets the absolute maximum lifetime.

The renew operation can extend the lease TTL.

Renewal grants additional time up to the max.

Enable the database secrets engine

Enabling the database secrets engine at a path mounts it so Vault can generate dynamic database credentials. This is the mandatory first step before configuring a MySQL connection and a role, which the remaining required steps then build upon.

Create a role that specifies the SQL statements for credential creation

Creating a role defines the SQL statements Vault executes to generate database credentials, satisfying the requirement to map a role to credential-creation logic. Without it, the secrets engine cannot issue dynamic MySQL users, so this step is mandatory alongside configuring the connection and enabling the engine.

Configure a connection with the MySQL plugin and connection details

Configuring a connection with the MySQL plugin and connection details establishes the database secrets engine's link to the target instance, satisfying the stem's requirement for one of the three mandatory steps. Vault needs this connection URL, plugin name and credentials before it can generate dynamic MySQL credentials.

It supports check-and-set operations for concurrent updates.

KV v2 implements check-and-set semantics: writes supply a version number, and Vault rejects the write if the stored version differs, preventing lost updates. This satisfies the concurrency requirement by detecting conflicting concurrent modifications rather than silently overwriting them.

It supports metadata like created_time and deletion_time.

KV v2 stores per-version metadata including created_time and deletion_time, alongside custom metadata and version numbers. This satisfies the requirement by allowing administrators to audit when each secret version was written or soft-deleted without reading the secret data itself.

It supports versioning of secrets.

KV v2 retains multiple versions of each secret, allowing retrieval of previous values and rollback after accidental overwrites or deletions. This satisfies the versioning requirement, distinguishing it from KV v1, which stores only the latest value with no history.

The wrapping token can only be used once to unwrap the response

A wrapping token is single-use: unwrapping consumes it, returning the wrapped data and rendering the token invalid for further calls. This one-time property limits exposure if the token leaks, satisfying the security constraint behind response wrapping.

The client can request response wrapping by setting the X-Vault-Wrap-TTL header

Clients request wrapping by setting the X-Vault-Wrap-TTL header on the API call; Vault then returns a wrapping token instead of the secret. The TTL value determines how long the wrapping token remains valid before expiry.

The wrapped response is stored in a cubbyhole secret engine

Response wrapping stores the token in a cubbyhole, a per-token single-use secret engine that only the wrapping token can read. This satisfies the stem's requirement that wrapped responses remain isolated until unwrapped, since the cubbyhole is destroyed after the single read, preventing replay or interception.

Accessors should be used in audit logs instead of token values

Token accessors are one-way hashes derived from token values, so they uniquely identify a token without exposing its secret. Logging accessors satisfies the audit requirement to trace token issuance and use while preventing credential leakage, since the original token cannot be reconstructed from the hash.

Accessors are unique identifiers for tokens

Each token issued by Microsoft Entra ID carries a distinct accessor value, so an accessor functions as a unique identifier for that specific token rather than for the user or session. This satisfies the stem's requirement that accessors uniquely identify individual tokens, enabling per-token revocation and correlation during investigation.

The initial lease duration will be 30 minutes (the role TTL).

The role TTL overrides the mount's default lease TTL, so credentials issued under this role receive an initial lease of 30 minutes rather than the mount's 15-minute default. The explicit max TTL of 1 hour caps renewal, not the initial issuance, satisfying the stem's role-level TTL constraint.

The lease can be renewed up to a total lifetime of 1 hour (explicit max TTL).

Renewal is capped by the role's explicit max TTL, so credentials can be renewed repeatedly until total lifetime reaches 1 hour, then Vault revokes them. The 30-minute role TTL governs each individual lease, while the 15-minute mount default is overridden.

Create a role that maps to the database user and permissions

Creating a role maps Vault's dynamic credential generation to a specific database user template and permission set, satisfying the requirement to define what credentials are issued. Without a role, the database secrets engine has no blueprint for creating users, so this step is mandatory for generating dynamic credentials.

Configure the database connection with connection details and credentials

Configuring the database connection supplies the root credentials and endpoint that the secrets engine uses to reach the database. Without this stored configuration, Vault cannot authenticate to the target or create roles, so dynamic credential generation is impossible. This step satisfies the stem's requirement to establish the connection before defining roles.

Enable the database secrets engine

Enabling the database secrets engine mounts it at a path, which is the prerequisite for all subsequent configuration. Without this mount, you cannot write connection details, configure roles, or generate dynamic credentials. It satisfies the stem's requirement as the first mandatory step before database-specific settings can be applied.

Reduces the risk of secret exposure in transit

Response wrapping returns a single-use wrapping token instead of the secret itself, so interception during transit yields nothing usable. This satisfies the stem's benefit of reducing exposure of the actual secret while it travels between parties.

Ensures the secret is used only once

A wrapping token is single-use: unwrapping consumes it, and any second attempt fails. This satisfies the stem's benefit by guaranteeing the wrapped secret can be retrieved only once, limiting replay or reuse by an intercepting party.

Enables delegation of access without sharing the actual token

Response wrapping issues a single-use wrapping token that delivers the secret without exposing the underlying token, so a client can hand it to another party safely. This satisfies the delegation constraint: the recipient unwraps once, and the original token is never shared or revealed.

Vault can generate a wrapped Secret ID for secure delivery

Response wrapping lets Vault issue a single-use token carrying the Secret ID, so the credential is never exposed in transit or logs. This satisfies the stem's secure-delivery requirement: the wrapping token can be unwrapped only once, by the intended role, before the Secret ID is revealed.

CIDR bindings can restrict which IP addresses can use the Secret ID

CIDR bindings on the Secret ID restrict which source IP addresses may redeem it, satisfying the stem's requirement for a true AppRole statement. This is a genuine AppRole capability: the secret_id_bound_cidrs parameter limits use to specified network ranges, adding a network-layer constraint independent of the Role ID.

The Role ID is analogous to a username

The Role ID functions as the public identifier a client presents during AppRole login, much like a username in credential pairs. It satisfies the stem's requirement for a true statement by naming the correct axis: Role ID is the non-secret identifier, paired with the Secret ID, which acts as the password equivalent.

Providing cryptographic offloading for applications running in untrusted environments

Vault's Transit secrets engine performs encryption and decryption operations centrally, so plaintext keys never leave Vault. Applications in untrusted environments send data to Vault for cryptographic processing, satisfying the offloading requirement without exposing key material locally. This directly addresses the constraint of operating where local key storage cannot be trusted.

Performing signing and verification operations (e.g., for digital signatures)

Vault's Transit secrets engine handles cryptographic operations without exposing keys, and its signing and verification endpoints support digital signatures directly. This satisfies the scenario's requirement for cryptographic signing use cases, since Transit performs asymmetric sign/verify operations on data while keys remain securely within Vault's boundary.

Encrypting sensitive fields in a database without exposing encryption keys to the application

Vault's Transit secrets engine performs cryptographic operations as a service, so applications send plaintext to Vault and receive ciphertext back, never handling key material themselves. This directly satisfies the stem's requirement of encrypting database fields while keeping encryption keys entirely outside the application's trust boundary.