Free Vault Operations Advanced practice test: 30 questions with answers

Dev mode is meant only for local experiments: it stores data in memory, runs without TLS, and starts unsealed with a printed root token, so its data cannot be carried into a production cluster. The other options describe licensing, auth handling, and sealing behaviour that dev mode does not have.

An AWS KMS seal stanza enables auto-unseal, so nodes unseal after a restart without key shares, and the wrapping key is a KMS key the company controls. The Shamir option needs people after each restart, dev mode is unsuitable for production, and plain text key files defeat the purpose of sealing.

vault operator rotate adds a new encryption key term that Vault uses for new data while older keys remain available to read existing data, and vault operator rekey replaces the unseal key shares. The first option swaps the two commands, and the last two options claim changes that neither command makes.

The database secrets engine must be mounted and given a connection, and a role defines how each dynamic user is created. Copying the administrator password into application files is a security risk, and disabling the KV engine is unrelated to dynamic database credentials.

Vault exposes runtime metrics through sys/metrics, and the format=prometheus parameter produces output Prometheus can scrape. Audit logs record requests rather than metrics, sys/health reports health status rather than latency, and parsing vault status output is not a supported metrics interface.

Vault fails closed on auditing: if no audit device can record a request, the request is refused, so audit coverage is never silently skipped. The other options assume buffering, a dev-mode fallback, or substitution of operational logs, none of which Vault does for the audit trail.

Operational logs describe the server's own behaviour, and their verbosity is set by the configured log level. Secret values are not written to operational logs in clear text, and the audit log, not the operational log, is the record that shows which client accessed a secret.

The socket audit device can send audit entries over TCP to a remote collector without writing a local file. The file device leaves files on the hosts, and the other two options name device types that do not exist for audit logging.

AppRole is designed for machines: the role_id identifies the role, and a secret_id can be issued and rotated separately without changing the policy. Userpass shares one login across runners, the root token gives unlimited access, and runners outside Kubernetes have no service account token to present.

Response wrapping returns the secret inside a single-use wrapping token with a short TTL, so the value can be unwrapped once before the token expires. Dev mode is not for production, root policy inheritance does not transport secrets, and HMAC only protects values inside audit entries.

Vault validates pod tokens by calling the Kubernetes TokenReview API, so its own service account needs permission to make that call, typically through a cluster role binding. Granting pods cluster-admin is excessive, and the other two options either weaken validation or abandon the Kubernetes method.

Root tokens do not expire, so the initial one should be revoked after setup and generated again only when genuinely needed. Scoped tokens limit what each person or workload can do. The other options keep or spread root-level access in ways that increase exposure.

Raft needs a majority of voting members, so three voters keep a quorum of two when one fails. Two voters cannot survive a failure, four voters tolerate one failure too but are not the smallest option, and a single voter offers no high availability.

DR replication maintains a full secondary that does not serve client traffic until an operator promotes it, which is the purpose of a disaster recovery site. Performance replication is designed to scale reads and still forwards writes upstream, snapshots are periodic backups rather than live failover, and dev-mode nodes are not for production.

Promotion of a DR secondary is authorized with a DR operation token, which is created using key material held by operators. Re-initializing does not promote a replica, and replication or audit replay does not make a secondary the active primary.

With five voters a majority is three, so the remaining three can elect a new active node and keep serving requests. Requiring all five voters is wrong for Raft, performance replication is not a failover mechanism for lost voters, and standby nodes can take over leadership.

The pkcs11 seal integrates Vault with a PKCS#11-capable HSM, which holds the wrapping key and unseals the cluster automatically. The awskms seal depends on a cloud provider, a Shamir seal still needs operators after each restart, and dev mode is not a production configuration.

Seal wrap uses the seal mechanism to protect critical security parameters that would otherwise rely only on Vault's own barrier encryption. The other options describe request routing, audit storage, and client-side encryption, none of which seal wrap provides.

Seal migration requires the current unseal keys, because Vault must decrypt its master key with the old seal before re-protecting it with the new one. Running init again does not migrate existing data, and deleting shares or exporting secrets does not perform a seal migration.

With auto-unseal, vault operator init returns recovery keys instead of unseal keys, and those keys authorize sensitive operations such as root token generation. They are not used for routine unsealing, which the seal handles, and they do not decrypt the audit log.

Batch tokens are lightweight, encrypted blobs that are not stored in Vault's storage, so they cannot be renewed, cannot have child tokens, and have no accessor. They do carry policies, can be issued by auth methods through token_type, and work on performance standby nodes.

Performance standby nodes handle most read requests locally and forward write requests to the active node, so read capacity grows without changing write handling. DR secondaries do not serve client traffic until promotion, dev-mode nodes are not production components, and audit devices record requests rather than handle them.

Performance replication lets a secondary cluster serve reads locally while forwarding writes to the primary, which keeps a single write path. DR replication is for failover and does not accept client writes, while manual exports and snapshot restores do not provide live replication.

A paths filter configured on the primary limits which mount paths are replicated to a particular secondary. Batch tokens and performance standbys do not decide which mounts a secondary receives, and DR replication copies everything rather than filtering.

In Vault ACL evaluation, deny takes precedence over every other capability from any attached policy, regardless of path specificity. The other options assume wildcard priority, alphabetical ordering, or group precedence, none of which override an explicit deny.

An external group in the identity system is mapped to the directory group through an alias, so each member's entity inherits the policies attached to the Vault group. Per-user tokens need manual management, batch tokens do not carry group policies, and audit filters do not grant permissions.

Sentinel is Vault Enterprise's policy-as-code framework: its rules run in addition to ACL policies, and each policy has an enforcement level such as advisory, soft-mandatory, or hard-mandatory. The other options misdescribe Sentinel as a replacement for ACLs, a dev-only feature, or an encryption mechanism.

Auto-auth lets Vault Agent authenticate and keep the token renewed, and a file sink writes that token to disk with file permissions the job's user can control. Writing the root token into an environment file is poor practice, an open HTTP listener exposes the token, and the audit log is not a cache.

Vault Agent templating reads the secret from Vault, writes it into a destination file, and re-renders the file when the underlying secret changes. The other options leave a stale value in place or require the application to call Vault itself.

Vault Agent templates use the consul-template language to render Vault secrets into files, and the agent re-renders them when the source secret changes. Templates are not limited to static text, and rendered output is written to a file rather than sent to the audit device.