Refer to the Exhibit Practice Questions

The token is a service token and has expired

Why it fails: Service tokens are a distinct token type; the stem specifies batch, so expiry of a service token is not the mechanism. It is tempting because expired tokens commonly produce renewal errors, but service tokens are the correct choice when a long-lived token tied to an entity's lifecycle is required.

The token is a periodic token and its period has expired

Why it fails: Periodic tokens are renewable by design, so an expired period is not the cause here; batch tokens cannot be renewed at all. It is tempting because periodic tokens also involve renewal timing, but periodic tokens are the correct choice when a token must be renewed indefinitely without re-authentication.

The token is an orphan token

Why it fails: Orphan status concerns parent token revocation, not renewal; batch tokens are non-renewable regardless of parentage. It is tempting because orphan tokens behave unusually in some lease operations, but orphan tokens are the correct choice when a token must survive revocation of its parent.

HSM seal via PKCS#11

Why it fails: PKCS#11 requires a physical HSM or network-attached appliance, and the exhibit shows no such seal stanza or library path. It is tempting because PKCS#11 is a genuine Vault seal type, and would be correct if the configuration named a PKCS#11 module and slot for hardware-backed key storage.

Shamir seal with default shares

Why it fails: Shamir seal requires operators to supply unseal key shares, and the exhibit shows an automatic cloud KMS seal instead. It is tempting because Shamir is Vault's default seal type, and would be correct if the configuration contained no auto-unseal stanza and the instance prompted for key shares at startup.

No seal; Vault is in insecure mode

Why it fails: Vault always requires a seal mechanism; insecure mode does not exist as a supported configuration, so the exhibit cannot show this. It is tempting because Shamir seals can be disabled in dev mode, but production Vault instances still seal on startup and unseal with keys or auto-unseal.

The user's policy does not cover the sub-path 'secret/data/app'.

Why it fails: The policy grants 'read' on 'secret/*', and Vault's glob wildcard matches across path separators, so 'secret/data/app' is already covered. The 404 arises because the KV v2 API path is 'secret/data/app' while the CLI command maps to it; the policy must instead target 'secret/data/*'. This option would fit KV v1, where paths lack the 'data/' segment.

The secret path is mistyped; it should be 'secret/application'.

Why it fails: Vault's KV v2 API inserts 'data/' between the mount and the secret path, so 'secret/data/app' is the correct read path; a mistyped path would return 404 only if that exact key were absent, yet the policy already grants 'secret/*'. The error stems from the token lacking a policy on the 'data' path segment.

The secret engine at 'secret/' is not enabled.

Why it fails: Listing the engine at `secret/` succeeded, which proves the KV mount is enabled and reachable; a disabled engine returns a mount-not-found error instead. The 404 arises from the missing path beneath the mount, not the mount itself. Enabling an engine is the right step when `vault secrets list` shows no such mount.

Write

Why it fails: The exhibit shows a read or list operation on the secret, not a write, since no new version was created or value modified. Write is tempting because it is the operation most commonly audited in Vault, and would be correct had the log shown a secret creation or update.

Delete

Why it fails: The exhibit records a read or list of the secret rather than its removal, as the secret still exists with its metadata intact. Delete is tempting because Vault logs deletion events with similar paths, and would be correct had the entry shown a destroy or delete-version operation.

List

Why it fails: The exhibit shows a read of the secret's value, not an enumeration of keys, which would return a key list without values. List is tempting because it targets the same path prefix in Vault, and would be correct had the log shown a LIST request rather than a GET.

Read succeeds because the first path allows read.

Why it fails: Vault policies are deny-by-default and the most specific matching path wins, so a broader grant cannot override a narrower deny on secret/data/team/admin. It is tempting because path ordering in the policy document looks significant, but precedence is determined by path specificity, not by which stanza appears first.

Read fails because the path does not exist.

Why it fails: The 400-class failure here stems from policy evaluation, not from the secret being absent; a missing path returns 404 at read time, after authorisation passes. It is tempting because a nonexistent secret does produce an error, but the question asks what the policy itself causes.

Read succeeds if the user also has sudo capability.

Why it fails: Sudo grants access to privileged system paths such as sys/, not to arbitrary secret/ paths, and it cannot override a deny capability. It is tempting because sudo sounds like a universal privilege escalator, but in Vault it is a narrowly scoped capability for administrative endpoints.

Yes, because min_decryption_version does not affect decryption.

Why it fails: min_decryption_version sets the lowest key version Vault will accept for decryption, so it directly governs whether version 1 ciphertext can be decrypted. It is tempting because min_encryption_version only affects new encryptions, and confusing the two settings would be the correct reasoning when only encryption version is configured.

No, because min_decryption_version is 1, so only version 2 and higher can decrypt.

Why it fails: min_decryption_version of 1 permits decryption with version 1; the threshold blocks versions strictly below it, so only version 2 and higher is a misreading. It is tempting because a minimum of 1 appears restrictive, and setting min_decryption_version to 2 would be the correct configuration to block version 1 ciphertext.

No, because the data was encrypted with version 1 and min_decryption_version is 1, so decryption is blocked.

Why it fails: Decryption succeeds because min_decryption_version is 1, which permits version 1 ciphertext; the setting blocks versions below the minimum, not those equal to it. It is tempting because min_decryption_version does restrict older key versions, and raising it above 1 would be the correct action to retire version 1 decryption.

vault write shared/db_password value=s3cret

Why it fails: This is incorrect because writing directly to 'shared/db_password' without the '/data/' prefix is the syntax for KV v1. Since the exhibit likely shows a KV v2 engine, this path does not exist for writing secrets; it would be the metadata path for v2.

vault write shared/metadata/db_password value=s3cret

Why it fails: The metadata/ path stores version metadata for a KV v2 secret, not the secret data itself; writing there corrupts version tracking. It is tempting because metadata endpoints exist and accept writes, but they are used for operations like deleting versions or custom metadata, not for storing the password value.

vault write shared/config/db_password value=s3cret

Why it fails: config/ is a reserved KV v2 path for engine configuration such as max_versions and cas_required, not secret storage. It is tempting because config endpoints accept writes and appear alongside data/, but storing db_password there leaves the actual secret unset; the data/ path is required.

The renewal will fail because the token has exceeded its explicit max TTL.

Why it fails: Renewal succeeds while the token remains within its explicit max TTL; exceeding the period alone does not invalidate it. It is tempting because tokens do expire at max TTL, and would be correct if the renewal attempt occurred after that absolute lifetime had elapsed.

The token will be renewed for another 12h and can be renewed indefinitely.

Why it fails: Renewal cannot extend indefinitely; the token's explicit max TTL caps total lifetime regardless of how many renewals occur. It is tempting because Vault tokens do renew repeatedly within their period, and would be correct if no explicit max_ttl were set on the token role.

The token will be renewed for 12h, but the total lifetime cannot exceed 24h.

Why it fails: The renewal extends the token by its period, not by a fixed 12h, and the cap is the explicit max TTL rather than a 24h total. It is tempting because period and max TTL both bound token life, and would be correct if the exhibit showed those exact values.

The storage backend is a file backend.

Why it fails: The status output lists the seal type and HA mode, not the storage backend, so it cannot confirm a file backend. File storage is configured in the listener/storage stanza of the Vault configuration file, and would be the answer only if the exhibit showed that stanza.

Auto-unseal is enabled using Consul as the seal provider.

Why it fails: Auto-unseal requires a seal stanza naming a KMS provider such as AWS KMS, Azure Key Vault or Transit; Consul is a storage and HA backend, not a seal provider. Consul would be the answer only if the exhibit showed it configured under storage or ha_storage.

Vault is not configured for high availability.

Why it fails: The status output reports HA enabled with a cluster name and leader address, contradicting this statement. Claiming Vault is not HA would only hold if the exhibit showed HA disabled with no cluster information, which it does not.

The write succeeds if the secret already exists.

Why it fails: Vault writes create or update secrets regardless of prior existence, so this condition is irrelevant. It is tempting because update semantics suggest an existing secret is required, but the create capability in the policy already permits writing a new secret.

The write succeeds because the path matches.

Why it fails: The policy grants read on secret/data/production/*, not create or update, so the write is denied despite the path matching. Path matching alone does not authorise an operation; the capability list must include create or update on that path. A policy with those capabilities would permit the write.

The write fails because the user does not have list capability.

Why it fails: List capability governs reading keys at a path, not writing a secret, so its absence does not block the write. It is tempting because missing capabilities often cause denials, but create and update are the capabilities that authorise this operation.

The read fails because the path does not exist.

Why it fails: The path exists in Vault's KV v2 mount; the request fails because a matching deny policy overrides the grant, not because the secret is absent. Path-existence errors return different responses, and this policy explicitly names the admin path.

The read succeeds because the first path grants read.

Why it fails: Vault evaluates all matching policies and any matching deny capability takes precedence, so a broader grant cannot override a more specific deny on the same path. The first path grants read only where no deny matches; here the deny rule wins, so the read is refused.

The read succeeds because deny only applies to write operations.

Why it fails: A deny capability in Vault blocks every listed capability on the matching path, including read, not just write. Deny is an explicit precedence rule evaluated after all grants, so any read request matching that path is rejected regardless of other policies.

It is destroyed because cas_required is true

Why it fails: cas_required enforces check-and-set on writes, not deletion semantics; it has no bearing on what a delete does to a version. The tempting link is that both concern versioning, but cas_required governs write conflicts, whereas soft-delete behaviour is set by the KV v2 engine itself.

It is permanently deleted immediately

Why it fails: KV v2 delete marks the version as deleted rather than removing its data; the version remains recoverable via undelete. Permanent removal requires destroy or metadata deletion. It tempts because delete sounds final, but the v2 engine's soft-delete design deliberately separates deletion from destruction.

It is marked as deleted but can be undeleted because cas_required is true

Why it fails: The version is indeed soft-deleted and undeletable, but cas_required is not the reason; that setting only enforces check-and-set on writes. Undelete works because KV v2 retains version data. It tempts by pairing a true outcome with an unrelated configuration flag.

The Vault binary is corrupt.

Why it fails: A corrupt binary typically yields exec format or segmentation faults, not the listener bind error shown. It is tempting because reinstalling is a common first fix, and would be correct if Vault failed immediately with checksum or library-loading errors before reading any configuration.

The listener address is incorrect.

Why it fails: An incorrect listener address causes a bind failure such as 'address already in use' or 'cannot assign requested address', which is not the exhibited error. It would be the cause if the log showed the TCP listener failing to bind on its configured host and port.

The seal stanza is misconfigured.

Why it fails: A misconfigured seal stanza produces errors about auto-unseal keys or KMS access during initialisation, not the startup failure shown. It would be correct if the log referenced an unseal configuration block, such as an invalid transit token or unreachable key management service.

It sets the ciphertext field for encryption.

Why it fails: The flag controls display or extraction of an existing field rather than setting or assigning a value during encryption. Setting a ciphertext field would be an input or configuration operation, not a field-selection flag. It is tempting because the word "field" appears in the flag, suggesting assignment rather than selection.

It enables field-level encryption.

Why it fails: Field-level encryption is a data-protection capability configured elsewhere; this flag merely chooses which field the command reads or prints. It does not enable any cryptographic processing. It is tempting because the term "field" combined with "ciphertext" implies per-field encryption, which is a genuine feature in some database and vault products.

It specifies the encryption key name.

Why it fails: The flag names a field to display, not a cryptographic key. Key selection is handled by separate key parameters or configuration, not by a field selector. It is tempting because "ciphertext" relates to encryption, so the flag appears to reference key material, and key-name arguments are common in encryption tooling.

It outputs the command result to a file named ciphertext.

Why it fails: The flag selects which field of each record the command prints; it does not redirect output to a file. Redirection is performed by shell operators such as > or tee. It is tempting because "ciphertext" sounds like a filename, and output-to-file behaviour is a real function of other command-line tools.

The path `database/roles/` is not a valid path for listing roles

Why it fails: 'database/roles/' is the standard list path for database roles; a GET on it returns the role names. The failure stems from the policy lacking 'list' capability there. This path is valid whenever the database secrets engine is mounted at 'database/'.

The database secrets engine is not enabled

Why it fails: Reading credentials from 'database/creds/my-role' proves the database secrets engine is mounted and enabled; otherwise that path would return no handler. Enabling the engine is the fix when no database mount exists, not when credential generation already succeeds but listing fails.

The application needs the 'sudo' capability to list roles

Why it fails: The 'sudo' capability grants access to root-protected paths, not list permission on ordinary paths. Listing requires the 'list' capability on 'database/roles/'. Sudo would be relevant for privileged operations such as managing root credentials or seal status, not enumerating roles.