003 practice questions and answers

Correct answer: A — Enable the OIDC auth method for the engineers and the AppRole auth method for the Jenkins pipeline, and do not use the GitHub personal access token.

Vault splits auth methods into human-oriented ones (OIDC, userpass, LDAP), where a person proves who they are, and system-oriented ones (AppRole, Kubernetes, AWS IAM, JWT), where a workload proves what it is. OIDC gives engineers single sign-on with the existing identity provider, and AppRole gives the pipeline a RoleID plus SecretID that belong to the machine, not to a person. Option B fails because a GitHub personal access token is tied to a human account: it carries that person's org and team membership, it is rarely rotated, and it keeps working after the person leaves. Option C shares one human credential between people and a robot, which destroys audit trails. Option D swaps the two families around, giving humans a machine credential and giving a build server a directory identity that a human can also log in with.

Correct answer: C — Integrated Storage (Raft) on five Vault nodes. The data is replicated by the Vault nodes themselves, quorum is three, and the cluster survives two failures.

Integrated Storage is the recommended backend today because the Vault nodes replicate the data themselves, so there is no second cluster to install, secure and upgrade. Raft needs a majority, so five nodes have a quorum of three and tolerate two failures, while three nodes have a quorum of two and tolerate only one, which makes option A's arithmetic wrong. Option B still works but adds a whole Consul cluster to operate, and its claim is false since Raft provides high availability on its own. Option D has no high availability at all, and snapshots only shorten an outage rather than prevent one.

Correct answer: D — A `VaultConnection` for the server address and CA, a `VaultAuth` for the auth mount and role, and a `VaultStaticSecret` whose `destination` creates the Kubernetes Secret.

The Vault Secrets Operator is driven entirely by custom resources: `VaultConnection` says how to reach the Vault server, `VaultAuth` says how to authenticate to it (for example the Kubernetes auth mount, the role and the service account), and `VaultStaticSecret` names the KV mount and path and writes the result into the Kubernetes Secret named under `destination`. `VaultDynamicSecret` is the resource for leased credentials such as database or AWS secrets, and it still needs a connection and an auth resource, so B is wrong on both points. A belongs to the Vault CSI provider and the Secrets Store CSI Driver, not to the operator. C is Vault Agent Injector annotation syntax, which renders files into a sidecar volume and never creates a Kubernetes Secret.

Correct answer: A, C — Call transit/datakey/plaintext/<key>, encrypt the file locally with the plaintext data key that comes back, then store the ciphertext copy of that key next to the file and clear the plaintext key from memory. · To read the file later, send the stored ciphertext data key to transit/decrypt/<key>, get the plaintext data key back, and decrypt the file locally.

Envelope encryption means Vault mints a one-time data key, the client does the bulk work locally, and only the small data key ever travels to Vault. transit/datakey/plaintext returns both the usable key and its encrypted form, so the client encrypts now and keeps the encrypted form for later. Option B is the trap: the wrapped endpoint returns only the ciphertext key, which is useful when you do not need to encrypt right away, but it gives the app nothing to encrypt with today. Option D sends gigabytes through the API, which the requirement rules out, and option E is wrong because Vault stores no data keys, only the master key that wraps them.

Correct answer: B, D — Deploy Vault Proxy for workload 1. It handles auto-auth, proxies the Vault API and caches tokens and leases, with no template rendering. · Deploy Vault Agent in process supervisor mode for workload 2. Agent starts the binary, passes the secrets in as environment variables, and restarts the process when they change.

Vault Proxy is the right fit when the only need is auto-auth, API proxying and caching for clients that already call the Vault API, so option A is wrong. Vault Agent adds templating and process supervisor mode: with an exec block and env templates it launches the child process, injects the secrets as environment variables, and restarts the process when the secrets change, which is exactly what a binary that reads its password once at start-up needs. Proxy has no templating and no process supervisor, so option C is wrong. Both tools support auto-auth, where they authenticate with an auth method and manage the token themselves, so option E is wrong.

Correct answer: C — Run vault token capabilities <token> secret/data/payments/config.

vault token capabilities returns the effective capability list for one token on one exact path after Vault has merged all of its policies, so it answers the question in a single command. vault token lookup only prints the names of the attached policies, not what they allow on that path. Reading each policy by hand is slow and easy to get wrong, because deny always wins and an exact path rule beats a glob. An audit device does record the request, but you must enable it and reproduce the failure first. Remember that the built-in default policy grants almost nothing on secret/: it covers token self-lookup, self-renew and self-revoke, the token's own cubbyhole, and lookup of wrapping tokens.

Correct answer: A — Write one ACL policy whose path is `secret/data/user/{{identity.entity.id}}/*` and attach it to the identity group that holds all developers.

ACL policy paths support templating. Vault replaces `{{identity.entity.id}}` at request time with the ID of the entity making the call, so a single policy document gives every developer a path that only that developer can reach. B grants everyone access to everyone else's folder, which breaks the isolation requirement outright. C creates 500 mounts plus 500 policies and slows the cluster down at unseal time. D still produces 500 policies and adds a job that drifts out of date whenever someone joins or leaves.

Correct answer: A, C — Look up the token's policies, TTL and creation time with `vault token lookup -accessor <accessor>`. · Revoke the token with `vault token revoke -accessor <accessor>` when an employee leaves the company.

An accessor is a reference to a token that lets operators manage the token without ever seeing it: lookup, renew and revoke all accept -accessor. That is why B is wrong; the accessor is not a credential and cannot be used to authenticate or read a secret. D is wrong because the mapping is one way by design, which is exactly what makes accessors safe to keep in audit logs. E is wrong because unwrapping needs the wrapping token itself; the wrapping token's accessor only lets you look up wrap information or check whether it was already used.

Correct answer: B — Run Vault Agent on the virtual machine with an auto_auth block: a method stanza that logs in with AppRole and a file sink that writes the fresh token to the path the application already reads.

Vault Agent auto-auth handles login for the workload: the method stanza authenticates with a machine identity such as AppRole, and the sink writes the resulting token to a file, which the agent keeps renewed and rewrites when it changes. Because the application keeps reading the same file, no application code changes. Option A only moves a secret from a file to an environment variable, and makes it worse by using a root token. Option C is the long-lived static credential the team is trying to remove. Option D is not how Vault works, since policies attach to tokens and identities, and every request still needs a token.

Correct answer: A — Run Vault Agent on the host with an auto-auth method and a template stanza that renders /etc/app/config.ini from the KV secret, and set the command option in that template stanza to reload the application when the rendered file changes.

Vault Agent is built for exactly this case: auto-auth handles login and token renewal, the template stanza renders a file from a Vault secret using Consul Template syntax, and the command option runs a reload or restart only when the rendered content actually changes. Option B adds a polling script the team must maintain and restarts the app on a schedule even when nothing changed. Option C contradicts the constraint that the application cannot call Vault, and parks a long-lived token on disk. Option D moves a secret into a ConfigMap, which is neither encrypted nor rotated by Vault, and ties every rotation to a full redeploy.

Correct answer: B — Integrated Storage (Raft) on each of the three nodes.

Integrated Storage replicates the data over Raft between the Vault nodes themselves, elects an active node and promotes a standby when the active one fails, and needs nothing beyond the Vault binary. Consul also supports HA and is a supported backend, but it means running, upgrading and monitoring a second cluster, which is more operational overhead. The file backend keeps data on local disk, does not support HA, and putting it on a shared mount does not make it safe for more than one node. The inmem backend holds everything in memory and loses all data when the process stops, so it exists only for development and testing.

Correct answer: C — Create an external identity group with the `platform-admin` policy, then create a group alias whose name matches the value sent in the OIDC `groups` claim and whose mount accessor is the OIDC auth mount.

An external identity group has no members you manage by hand. Its membership comes from a group alias, which maps a group name returned by an auth method — here the value of the `groups` claim that the OIDC role reads through `groups_claim` — onto the Vault group and its policies. Vault recalculates that membership at every login, so removing the user in the provider removes the policy. A is an internal group, which someone must edit by hand every time a team changes. B fails because external groups reject member entities; only the alias decides who is in them. D hands the policy to every employee who uses that role, not just the admins.

Correct answer: C — Create a transit key of type ed25519 and call transit/sign and transit/verify.

Signing needs an asymmetric key. ed25519 supports the sign and verify endpoints, produces short signatures, and its public key can be read from transit/keys/<name> and handed to partners, while the private half stays inside Vault. aes256-gcm96 and chacha20-poly1305 are symmetric: aes256-gcm96 does support transit/hmac, but an HMAC can only be checked by someone who holds the same secret key, so partners would need Vault access or a copy of the key. Encrypting a hash is not a signature and gives the partner nothing to check. Sharing a symmetric key breaks the rule that the key never leaves Vault, and it lets the partner forge records.

Correct answer: B — KMS now holds the key that decrypts Vault's root key at start-up, `vault operator init` returns recovery keys instead of unseal keys, and a quorum of recovery keys is still required for operations such as generating a new root token.

Auto-unseal moves only one job to the cloud KMS or HSM: unwrapping the root key when a node starts, which is what the Shamir unseal keys used to do. Because the unseal keys disappear, init hands out recovery keys instead, and they still form a quorum for privileged actions such as generate-root or rekey. Option A is the common trap: recovery keys cannot be passed to `vault operator unseal`, since unsealing is now the seal's job. Option C forgets the recovery key quorum, and option D is wrong because the barrier encryption key still lives inside Vault; KMS never sees individual secrets.

Correct answer: A — Use the SSH secrets engine in signed certificate (CA) mode, point sshd at the Vault CA public key with TrustedUserCAKeys, and have each engineer get their own public key signed with a short TTL.

In CA mode Vault signs the engineer's existing public key and returns a certificate with a TTL. The bastions trust the Vault CA once through TrustedUserCAKeys, so no per-user key ever lands in authorized_keys and nothing extra runs on the host. OTP mode does meet the no-shared-key goal, but it fails the requirement because vault-ssh-helper must be installed on each target host. A shared key in KV still means one key that everyone holds, and nightly rotation does not expire an active session. The dynamic key type is deprecated and works by writing keys into authorized_keys on the host, which the requirement forbids.

Correct answer: B — Vault revoked the token automatically as soon as `num_uses` reached zero, so the token no longer exists and cannot be looked up.

`-use-limit` sets `num_uses` on the token. Every request authenticated with that token decrements the counter — including `vault token lookup-self` — and Vault revokes the token the instant the counter reaches zero. That is why the later lookup reports an invalid token instead of showing `num_uses: 0`. A describes the user lockout feature, which counts failed logins on auth methods such as userpass, LDAP and AppRole and has nothing to do with use limits. C is not a real behaviour; policies are not consumed. D is wrong because any token with `update` on `auth/token/lookup` can look up another token, and the operator's admin token clearly reached the endpoint.

Correct answer: D — Update the key configuration to set exportable and allow_plaintext_backup to true, and accept that both are one-way changes that let the raw key material leave Vault.

By default a transit key can never leave Vault: you send plaintext in and get ciphertext back, and the key material stays inside. Backup and export are blocked until allow_plaintext_backup and exportable are turned on, and neither flag can be turned off again once set, so every key version becomes copyable from then on. Policy is not the blocker here, so extra sudo changes nothing. deletion_allowed only controls whether the key can be deleted at all. Rotation creates a new version but does not make any version exportable.

Correct answer: A — Two of the three required key shares have been entered. The node stays sealed and rejects requests until a third, different unseal key is entered against the same unseal nonce.

Sealed is true and Unseal Progress shows 2/3, so two valid shares out of the threshold of three have been supplied and the node is half unsealed. It answers status calls but refuses all other requests until a third, different share is entered, and every share in the same attempt must carry the matching unseal nonce. The node is not a standby: HA Mode only appears once a node is unsealed, and Total Shares 5 with Threshold 3 simply describes how the key was split at init time, not lost shares, so re-initialising would destroy the cluster. Progress is held in memory only, so a restart or a mismatched nonce resets it to 0/3 and the count starts over; nothing arrives from the other nodes on its own.

Correct answer: C — The max_lease_ttl configured on that secrets engine mount caps how long the lease may live, so Vault granted the largest allowed value instead of the requested 72h.

A renewal request is a suggestion. Vault honours it only up to the maximum TTL, which comes from the mount's max_lease_ttl (set with `vault secrets tune`), or from the system default if the mount does not set one, and it silently returns the capped value rather than failing. Option A is wrong because a lease TTL is not clamped to the creating token's TTL; revoking that token does revoke its leases, but renewal length is a different rule. Option B is wrong because -increment is always considered, not just when a role TTL is missing. Option D is wrong because Vault does not count renewals; it limits total lease lifetime by TTL.

Correct answer: C — Vault is deny by default and merges the attached policies. An explicit deny on a matching path beats any grant from another policy, even a more specific one.

Vault starts with no access and adds up the capabilities from every attached policy, but deny is absolute: if any attached policy denies a matching path, the request is refused. That is why option B's specificity argument fails here, and specificity only breaks ties between rules inside the same policy. Option A invents an ordering rule that does not exist, and option D is wrong because deny is a real capability and secret/data/... is the correct read path for KV v2.

Correct answer: D — Export `VAULT_ADDR=https://vault.example.com:8200` so the CLI stops using the default local address.

`VAULT_ADDR` defaults to `https://127.0.0.1:8200`, so leaving it unset makes every command talk to the laptop itself — which is why the message is a refused TCP connection rather than an authentication or TLS error. A is wrong because a missing token produces a permission error from a server that answered, and `vault status` does not need a token at all. B is an Enterprise namespace setting and would return an HTTP error, not a dial failure. C only turns off certificate verification and should be avoided in production; the correct way to trust a private CA is `VAULT_CACERT` pointing at the CA bundle.

Correct answer: B — A static role that points at the existing report_user with rotation_period set to 24h; the app reads the current password from database/static-creds/<role>.

Static roles are built for exactly this case: Vault takes over an account that already exists, keeps the username fixed, and rotates only the password on the schedule in rotation_period. Option A is the trap, because a dynamic role creates a brand new username on every read, which the tool cannot use. Option C rebuilds rotation by hand and leaves you owning the script and its failures. Option D rotates the credential Vault itself uses to manage the database, not the reporting account, and running it daily would not help the tool at all.

Correct answer: B — Unsealing reconstructs the root key, which decrypts the keyring. The keyring holds the encryption key Vault uses with AES-256-GCM, so everything written to storage is already ciphertext.

The barrier is the layer every read and write must pass through: unseal keys rebuild the root key, the root key decrypts the keyring, and the keyring's encryption key protects data with AES-256-GCM before it reaches storage. Option A gets it backwards, since Vault never trusts the storage backend and hands it ciphertext only. Option C confuses authentication with encryption, because a root token grants API access but decrypts nothing on disk. Option D is wrong because policies, mount tables and audit configuration all live behind the barrier, which is exactly why a sealed Vault cannot serve any of them.

Correct answer: A, C — A performance replication secondary serves read requests locally and forwards write requests to the primary cluster. · A disaster recovery secondary accepts no client requests at all until an operator promotes it.

Performance replication exists for scale: the secondary holds a copy of the data, answers reads locally, and forwards writes to the primary. Disaster recovery replication exists for failover only, so its secondary is a warm standby that refuses all client traffic until it is promoted. B is the classic mix-up between the two modes. D is wrong because a performance secondary keeps its own token store and its own leases, so clients authenticate again against that cluster; it is the DR secondary that carries tokens and leases across. E is wrong because replication streams changes continuously from a write-ahead log rather than shipping scheduled snapshots.

Correct answer: C — New encrypt calls use key version 2 and return vault:v2: ciphertext, while existing vault:v1: ciphertext still decrypts; the transit/rewrap endpoint can move old ciphertext to the new version without exposing plaintext.

Rotating a transit key adds a new key version and makes it the latest one. From then on encrypt operations use that version and tag the output vault:v2:, while older versions stay available for decryption, so nothing breaks for data already written. Vault never walks your database for you, which rules out A; to update old ciphertext you send it to transit/rewrap, where Vault decrypts and re-encrypts inside the barrier and the plaintext never leaves. B describes what happens only if you raise min_decryption_version, which rotation does not do. D is wrong because transit keys are non-exportable unless the key was created with exportable enabled, and exporting defeats the purpose of encryption as a service.

Correct answer: D — Clients log in at `auth/ci-cd/login`; the operator policy grants `auth/ci-cd/role/*`.

`-path` sets the mount path, and every endpoint of that mount lives under it. The login endpoint becomes `auth/ci-cd/login`, roles live at `auth/ci-cd/role/<name>`, so the operator policy must be written against `auth/ci-cd/role/*`. A and B invent paths that mix the method type into the URL; the type never appears there, only the mount path. C is wrong twice: auth endpoints are always prefixed with `auth/`, and `sys/auth/ci-cd` only controls enabling, tuning and disabling the mount itself, not the roles stored inside it.

Correct answer: C — Enable the Kubernetes auth method and let the pod log in with the projected service account token it already has.

The Kubernetes auth method makes Vault verify the pod's service account token with the cluster's TokenReview API, so the credential is already on disk and nothing has to be created, shipped or rotated by the team. AppRole (option A) works, but the SecretID is a real secret that someone must generate, wrap and deliver on every deploy, which is exactly the extra work the question asks you to avoid. Option B stores a long-lived token in a Kubernetes Secret, so it never expires cleanly and must be rotated by hand. Option D reinvents the same trust chain the cluster already provides and adds a signing key and a distribution step to maintain.

Correct answer: C — vault operator init -key-shares=5 -key-threshold=3 -pgp-keys="op1.asc,op2.asc,op3.asc,op4.asc,op5.asc"

With Shamir's secret sharing, -key-shares is how many pieces the key is split into and -key-threshold is how many pieces must be combined to rebuild it, so five holders with any three able to unseal means shares=5 and threshold=3. Supplying -pgp-keys with one public key per share makes Vault encrypt each share to its own owner, so the person running init sees only ciphertext. Option A is rejected outright because the threshold can never be larger than the number of shares. Option B works but forces all five operators to be available for every unseal, which is stricter than the requirement. Option D prints all five shares in clear text first and then locks them behind a single key, which breaks the split entirely.

Correct answer: B — Set `min_decryption_version` back to 1, call `transit/rewrap/<key>` for each stored ciphertext so it is re-encrypted under key version 2, then raise `min_decryption_version` to 2 again.

`min_decryption_version` stops Vault from using older key versions, so `vault:v1:` ciphertext becomes unreadable until that setting is lowered again. The `transit/rewrap` endpoint decrypts and re-encrypts entirely inside Vault and returns only the new ciphertext, so the caller never sees plaintext — which is exactly why rewrapping should happen before `min_decryption_version` is raised. A throws away the only key that can read the existing records. C is wrong because rotation only adds a version for new encryptions; it does not unblock a version that policy has disabled. D leaks plaintext to the application and still fails, since the decrypt call is blocked by the same setting.

Correct answer: A — 8 hours

The most specific setting wins, and it can never raise the limit above a broader one. The role's token_max_ttl of 8h is the most specific value and is also the smallest, so Vault caps the token there. The 72h mount tune and the 768h system value are only outer limits for anything that does not set its own max. 1h is the starting TTL that each renewal resets, not a cap. Near the end Vault still accepts the renew call but returns a shorter and shorter TTL, and once 8h from creation is reached the token expires and renewal is refused.

Correct answer: B — vault list sys/leases/lookup/database/creds/readonly

Vault's expiration manager tracks every lease and calls the secrets engine to revoke it when the TTL ends. If revocation fails, for example because the database is down, Vault retries with backoff and keeps the lease, so the credential stays outstanding. Listing sys/leases/lookup under the role path shows those lease IDs, and vault lease lookup on one ID shows its state. Revoking with -prefix is the fix you apply after you know what is there, not the way to find it, and it can silently fail again while the database is unreachable. sys/mounts/database returns mount configuration, not leases. A restart does not clear leases: they live in storage and the expiration manager reloads and retries them.

Correct answer: C — Writing policies and configuring the auth methods and secrets engines the applications need.

HCP Vault Dedicated is a managed service, so HashiCorp runs the infrastructure: it performs version upgrades, takes automatic snapshots, configures auto-unseal, and runs the cluster across availability zones for production tiers. What it does not do is decide how you use Vault. Policies, auth method configuration, secrets engines, roles and TTLs are still the customer's work, exactly as on a self-managed cluster. Options A, B and D all describe platform tasks that the service already handles for you.

Correct answer: D — Configure the auth role to issue batch tokens. They are not written to storage, but they cannot be renewed, cannot create child tokens, and have no accessor.

Batch tokens are encrypted blobs handed to the client instead of records in storage, so creating them costs no storage write, which is exactly the problem here. The trade-off is real: no renewal, no child tokens, no cubbyhole and no accessor, so you cannot look one up or revoke it by accessor. Option A still writes every token to storage, only for less time. Option B removes all isolation and auditability. Option C keeps service tokens, so the storage writes stay, and a short-lived function has nothing to renew.

Correct answer: B — By default the standby node forwards the request to the active node over the cluster port using the `cluster_addr` each node advertises for node-to-node traffic, while `api_addr` is the address advertised to clients.

Vault is active/standby. By default a standby node forwards client requests to the active node over the cluster port, 8201 by default, using the `cluster_addr` each node advertises, and the client sees a normal response. `api_addr` is the address a node advertises for regular API traffic and is what a client gets redirected to when request forwarding is turned off with `disable_clustering`. A is wrong because standby nodes do handle requests, by forwarding or redirecting them. C is wrong because Community Edition never serves reads from a standby; performance standbys are a Vault Enterprise feature. D swaps the two settings — a redirect uses `api_addr`, and `cluster_addr` must point at the node itself, never at the load balancer.

Correct answer: A — The app sends base64-encoded plaintext, Vault returns ciphertext beginning with vault:v1:, and Vault stores neither the plaintext nor the ciphertext, so the app must keep the ciphertext itself.

Transit is encryption as a service: the key never leaves Vault, and Vault never keeps your data. The app base64-encodes the plaintext, receives ciphertext whose vault:v1: prefix names the key version used, and stores that ciphertext in its own database. Option B is the common misunderstanding that transit is storage, which it is not. Option C would defeat the whole point by handing the key to the app. Option D reverses the rule, since base64 is required so binary data survives the JSON API.

Correct answer: A — KV v2 holds static secrets, so the read creates no tracked lease. Only dynamic secrets, such as those from the database, AWS or PKI engines, come with a renewable lease_id.

Vault tracks a lease only when it generated the credential and can revoke it later. KV v1 and KV v2 store values you gave Vault, so nothing is generated and nothing is leased; the value stays until you change it. Option B describes a different error message, since a permission problem returns 403 and not a missing lease. Option C is wrong because vault kv rollback moves a secret back to an earlier version and has nothing to do with leases. Option D invents behaviour that a missing mount tuning value does not cause.

Correct answer: C — Set a period on the auth role so it issues a periodic token, which can be renewed forever as long as each renewal happens inside the period.

A periodic service token is not capped by a max TTL; it only has to be renewed within its period, which makes it the standard answer for a long-running daemon. Option A only pushes the wall further away, still ends in expiry, and loosens limits for every other workload in the cluster. Option B is wrong because a batch token has a fixed TTL and cannot be renewed at all. Option D fails because child tokens are revoked when the parent is revoked, so the whole chain dies when the original token hits max_ttl.

Correct answer: D — Add a second rule granting the list capability on secret/metadata/apps/billing/*.

KV version 2 rewrites paths: secret values live under secret/data/<path>, but key names are served from secret/metadata/<path>, so listing and UI browsing need the list capability on the metadata path. Option A is the classic trap; a LIST request is never sent to secret/data, so adding list there changes nothing. Option B does work but hands the developer every secret in the mount plus sudo, which is far more privilege than the task needs. Option C only affects whether the mount itself shows up, not whether the keys inside the billing folder can be listed.

Correct answer: A, D — vault operator seal needs a valid Vault token, and that token's policy must grant the sudo capability on the sys/seal path. · vault operator unseal needs no token at all, because Vault cannot authenticate anyone while it is sealed.

Sealing is a privileged API call on sys/seal, so it needs an authenticated token whose policy grants sudo on that path, which is why holding an unseal share alone is not enough and option E is wrong. Unsealing is the opposite case: while Vault is sealed it cannot read its own storage, so no auth method and no policy engine exist yet, and unseal is served unauthenticated to whoever supplies enough valid key shares, which also rules out option B. Sealing only drops the in-memory encryption key and refuses requests until enough shares are entered again; it does not touch the key shares or the data, so re-initialising as in option C would in fact destroy the cluster.

Correct answer: B — path "secret/data/teams/+/config"

The + wildcard matches exactly one path segment and can sit anywhere in the path, so secret/data/teams/+/config matches every team's config key and nothing else. The * glob is only a wildcard when it is the LAST character of the path, so option A does not behave as a wildcard at all. Option C matches everything under teams, which is far more than the requirement. Option D has the segments in the wrong order and would match paths under a team named config.

Correct answer: B, D — vault lease revoke -force -prefix database/creds/reporting removes the lease records from Vault without waiting for the database to confirm, so it succeeds while the server is offline. · After a forced revoke the database accounts still exist, so an operator has to delete them by hand once the server is reachable.

A normal prefix revoke asks the database secrets engine to drop each user, so with the server down it fails and Vault keeps retrying, which is why option A is wrong. Adding -force tells Vault to delete its own lease records and ignore errors from the backend, which is the only way to clear them while the database is unreachable. The cost is stated in option D: Vault forgets the credentials but the accounts remain in the database, so cleanup becomes a manual job. Option C is wrong because -force must be used together with -prefix, and option E is wrong because revoking leases does not revoke the tokens that requested them.

Correct answer: B, D — Create a single identity entity for the engineer and add two aliases to it: one using the LDAP mount accessor and one using the OIDC mount accessor. · Attach the shared policies to the entity, or to an identity group that contains the entity, so both logins inherit them.

An entity is the person; an alias is that person as seen by one auth mount, so two logins need two aliases on one entity, each tied to its own mount accessor. Policies placed on the entity or on an identity group are added to any token created through those aliases and appear as identity_policies. Option A is wrong because Vault does not merge entities on its own, and option C is wrong because an alias maps to exactly one entity for a given mount accessor. Option E removes a working login instead of fixing the identity model.

Correct answer: C — KV version 2, which keeps versions, supports check-and-set writes, and treats vault kv delete as a soft delete that vault kv undelete can reverse.

Only KV v2 offers all three behaviours: version history, check-and-set so a write fails unless it names the version it expects, and a soft delete that undelete can bring back. vault kv destroy is the permanent one, which is why option B is wrong about delete. Options A and D both credit KV v1 with features it does not have; KV v1 stores a single value per key, with no version history and no rollback.

Correct answer: B — Revoke the initial root token now. If a root token is needed later, run `vault operator generate-root`, which issues a one-time password, requires a threshold of unseal key holders to each supply a share, and returns an encoded token that is decoded with the OTP.

HashiCorp's guidance is to use the initial root token only for setup and then revoke it, because the generate-root workflow can always produce a new one. That workflow deliberately needs a quorum: the unseal (or recovery) key holders each enter their share, and only the person holding the OTP or PGP key can decode the resulting token. Option A is wrong because generate-root is designed for a running, unsealed cluster. Option C keeps a root token alive forever and just moves it, which is what the policy forbids. Option D fails because a root token cannot be minted by an ordinary token; creating a token with the root policy itself requires root or sudo rights.

Correct answer: C — Add spec.rolloutRestartTargets with kind: Deployment and name: orders-api, so the operator restarts the Deployment whenever the Secret changes.

Kubernetes injects environment variables only when a container starts, so updating the Secret can never change what a running pod already has. rolloutRestartTargets tells Vault Secrets Operator to trigger a rolling restart of the named Deployment, StatefulSet or DaemonSet after it writes new data into the Secret, and the fresh pods read the new password. Changing renewalPercent only changes when the operator refreshes the credential; the Secret was already correct, so this fixes nothing. A VaultStaticSecret has the same restart problem and would also lose the per-workload dynamic credentials. Mounting the Secret as a volume does let the kubelet refresh the file, but the process already read its configuration at start-up and still has to be restarted.

Correct answer: D — Run vault secrets tune -default-lease-ttl=1h -max-lease-ttl=24h database/.

vault secrets tune changes the lease settings of one mount, takes effect at once, and needs no restart. Every role on that mount, now and in the future, inherits the tuned values. Editing default_lease_ttl and max_lease_ttl in the config stanza sets them for the whole server, hits all other mounts, and needs a restart of each node. Setting the TTLs role by role works but is manual work that must be repeated for every new role. Disabling and re-enabling the engine does accept the flags, but it revokes existing leases and throws away the connection and role configuration.

Correct answer: A — Vault always starts sealed. A threshold number of unseal key holders must each run `vault operator unseal` with their own share until the threshold is reached; the shares are not tokens and cannot be used to authenticate or read secrets.

On start-up Vault has the encrypted data but not the key to decrypt it, so it comes up sealed. Each key holder submits their own share separately, and only when the configured threshold is met can Vault reconstruct the key that decrypts its root key and start serving requests. Option B is wrong and dangerous: init on an initialized cluster fails, and treating it as a fresh install would suggest destroying data. Option C ignores the whole point of Shamir, which is that no single share unseals anything. Option D confuses two different things: unseal keys unlock the storage, while a token authenticates a client, and one can never be used as the other.

Correct answer: D — Run `vault token revoke` against the leaked token.

Revoking a token revokes its entire tree: the token itself, every child token below it, and every lease that any of those tokens created. Vault therefore drops the dynamic PostgreSQL users as part of the same call. A revokes the leases but leaves the leaked token and its children alive, and it also destroys credentials belonging to every other application on that mount. B stops all work for everyone and revokes nothing; after unsealing, the leaked token still works. C only blocks future logins, while the token already issued keeps working until its TTL runs out. Use `vault token revoke -mode=orphan` only when you deliberately want the child tokens to survive.

Correct answer: B — Set secret_id_num_uses to 1 on the role.

secret_id_num_uses is the only setting that caps how many times a single SecretID can be exchanged for a token. With a value of 1 the pipeline consumes the SecretID on its own login, and the copy in the log is already dead when the attacker tries it. secret_id_ttl only shortens the window: inside that window the same SecretID still works, and it can be replayed many times. secret_id_bound_cidrs is good defence in depth, but it limits where the SecretID can be used, not how often, and a shared CI runner range is exactly where the attacker is likely to be. token_num_uses limits the token that login returns, not the SecretID, so a fresh login still succeeds.

Correct answer: C — Use the Vault Secrets Operator with a `VaultStaticSecret` that writes to a Kubernetes Secret, then reference that Secret from the Deployment with `envFrom.secretRef`.

The Vault Secrets Operator syncs Vault data into a native Kubernetes Secret and keeps it current as the values rotate, so the Deployment can load them as environment variables with `envFrom.secretRef` and the image is never touched. A and B both deliver the secret as a file, which this application cannot read, and A also needs the entrypoint change that the question rules out. D stores credentials in a ConfigMap, which is not meant for sensitive data, and adds a custom job that has to run again after every rotation.

Correct answer: C — The batch token was a child of the operator's token, and revoking a parent revokes every child. Let the job log in to an AppRole mount itself, because tokens returned by an auth method login are orphan tokens with no parent.

A token created with `vault token create` becomes a child of the token that called the endpoint, and revoking a parent revokes the whole subtree beneath it. Tokens issued by an auth method login, such as AppRole or Kubernetes, are orphan tokens, so no other token can take them away; the same effect is available from `vault token create -orphan`, which needs `sudo` on `auth/token/create-orphan`. A and D both describe TTL limits, which would have failed the job at a predictable clock time rather than at the exact moment the operator's token was revoked. B is wrong because a token carries its own list of policies; deleting an entity does not strip them.

Correct answer: A — The value is stored in the cubbyhole of a single-use wrapping token, and only the holder of that token can unwrap it. No other token can read that cubbyhole, not even a root token.

Response wrapping puts the payload in the cubbyhole of a brand new wrapping token with a short TTL. Cubbyhole storage is scoped to one token: no other token can reach it, root included, and the contents are destroyed when the token is used or expires. That is what makes the pattern useful, since an unwrap by anyone but the intended app is detected immediately because the token is single use. B is wrong because wrapped data never lands in the KV engine, C is wrong because root has no special path into another token's cubbyhole, and D is wrong because the cubbyhole is written to the storage backend like any other data.

Correct answer: B, E — The response is stored in the cubbyhole of a newly created single-use token, so the value can only be retrieved by presenting that wrapping token. · A wrapping token can be unwrapped only once, so an unwrap that fails for the intended consumer is a strong signal that someone else already read the response.

Response wrapping stores the response in the cubbyhole of a brand new single-use token and hands the caller only that token, so whoever holds the token is the only party who can retrieve the value. Because the token is single use, an unwrap that fails tells the consumer the payload was already taken and the secret must be treated as compromised. A is wrong: wrapping does not involve the transit engine, and the value stays inside Vault. C is wrong because a wrapping token has no policies beyond unwrapping its own payload. D describes the wrong endpoint — `sys/wrapping/lookup` reports creation time and TTL without consuming the token, while `vault unwrap` always consumes it.

Correct answer: B, D — The list capability maps to LIST requests and does not by itself allow a client to read the value of a secret. · The patch capability maps to HTTP PATCH requests and allows a partial update of a KV v2 secret; a policy that grants only update cannot make a PATCH request.

Capabilities map to HTTP verbs: create and update to POST/PUT, read to GET, delete to DELETE, list to LIST, and patch to PATCH. So B and D are correct: list only returns key names, and a partial update needs the patch capability because update does not cover the PATCH verb. A is wrong because create maps to a write, not a GET. C is wrong because only root-protected sys/ endpoints such as sys/seal, sys/rotate and sys/raw need sudo, not the whole sys/ tree. E is wrong because sudo is never granted alone; it is added next to read or update to reach a root-protected path and grants nothing by itself.

Correct answer: B — Enable the PKI secrets engine, create a role with a short max_ttl, and have each service request its own certificate at start-up.

The PKI engine issues a unique, short-lived certificate and private key to each service on demand, so a leaked key is useful only until it expires, it can be traced to one workload, and Vault can revoke it. Option A does nothing about exposure; versioning helps you roll back, not contain a leak. Option C still ends with the same long-lived key sitting in the memory of forty services, and it adds a decrypt call for no real gain. Option D breaks the use case, because a cubbyhole belongs to a single token and cannot be shared by many services.

Correct answer: C — The auth method only verifies the login and hands back a Vault token. That token carries the policies and the TTL, and Vault checks the token on every later call.

An auth method has one job: turn an external identity (LDAP, OIDC, AppRole, Kubernetes) into a Vault token. Everything after login is authorized from the token, which holds the policy list and the TTL. Option B and option D both put the enforcement back on the auth method or the mount; the mount configuration only decides which policies go on to the new token, it is not consulted per request. Option A is wrong because Vault never keeps the user's password for replay.

Correct answer: C — Enable the KV version 2 engine twice, once with `-path=payments` and once with `-path=analytics`, and write one policy per team scoped to that mount.

A secrets engine is mounted at a path, and a path can only be used once, which is why a second `vault secrets enable` fails with "path is already in use" unless you pass `-path`. Mounting KV v2 twice gives each team its own mount, its own data and a short policy on `payments/*` or `analytics/*`, all on one cluster. A depends on good behaviour instead of policy, so either team can read the other's secrets. B doubles the work of running, unsealing, upgrading and backing up Vault. D is wrong because access is decided by the policies on the token, not by which role issued it — both roles would still reach the same paths.