HashiCorp Certified: Vault Operations Professional (Vault Enterprise) (Vault Enterprise) (Vault Enterprise) — Questions 151–196

`vault status` queries the active node's seal configuration directly, reporting the seal type and whether auto-unseal is backed by an HSM (PKCS#11). This satisfies the stem's requirement to verify HSM usage, since the output exposes the seal stanza details without requiring unseal keys or privileged operator tokens.

Raft replication traffic between clusters flows over the cluster port 8201, while 8200 carries the API and request forwarding. Both must be open bidirectionally so the secondary can receive replication streams and serve client requests.

Token replication is a feature of Vault Enterprise that replicates tokens from the primary to DR replicas. After promotion, clients can continue using their existing tokens without re-authenticating, as the tokens are already present on the DR replica. This ensures minimal disruption during failover.

The reviewer_service_account is the Kubernetes service account whose token Vault uses to call the TokenReview API, validating client JWTs presented during login. It satisfies the constraint of authenticating clients without granting Vault broad cluster permissions.

The audience field validates the 'aud' claim inside the service account JWT presented by the pod, ensuring Vault only accepts tokens minted for its own configured audience rather than any cluster token. This binds authentication to the intended relying party, satisfying the requirement that tokens be scoped to Vault specifically.

Enabling an audit device ensures that all requests, including cryptographic operations on the Transit engine, are logged. This provides an audit trail for compliance and detection of unauthorized use. It satisfies the requirement that cryptographic operations are audited.

AWS KMS stores the key version used during encryption within the ciphertext metadata. When Vault calls KMS to decrypt the root key, KMS automatically selects the correct key version for decryption, even after rotation, as long as that version remains enabled. Thus, Vault unseals successfully without configuration changes. This is the expected behavior when key rotation occurs and old versions are retained.

A wrapped response delivers the SecretID as a single-use token; the application unwraps it once, so interception yields nothing reusable. The specific TTL bounds exposure, satisfying the requirement that secret delivery remains uncompromised for the periodically fetching legacy application.

The root policy is Vault's built-in, non-deletable policy granting full administrative access across all paths and operations, including managing policies, auth methods and mounts. It satisfies the stem by defining the highest privilege level, so it must be tightly restricted.

Setting ui = true activates Vault's built-in web-based graphical interface, allowing browser access to manage secrets, policies and authentication. Without it, the UI listener is not served, so operators must use the CLI or API instead.

The seal component interfaces directly with the HSM to perform cryptographic operations such as unsealing Vault's master key, satisfying the requirement that Vault communicate with the HSM. It handles auto-unseal and seal-wrap functionality, delegating root key protection to the hardware module rather than storing it in Vault's storage backend.

A separate HSM partition isolates development keys from production material, so test operations such as key generation, deletion or reset cannot overwrite or destroy live keys. This directly satisfies the stem's requirement to avoid accidental data loss or interference with production keys.

After a partition, nodes that were isolated may not automatically rejoin if they fell behind or lost their configuration. Running `vault operator raft join` on each isolated node with the leader's API address forces them to rejoin the cluster and catch up. This is the documented procedure for adding or re-adding nodes to a Raft cluster and minimizes downtime because the active cluster continues serving requests.

Performance Standby nodes serve read-only requests within one Vault cluster, offloading reads from the active node and thereby satisfying the stem's read-scaling requirement. This is distinct from Performance Replication, which spans multiple clusters across regions. The scaling here stays intra-cluster, so no cross-cluster replication topology is involved.

The tls_key_file parameter specifies the path to the private key corresponding to the server certificate. It is required for TLS to decrypt and sign handshake messages. Without it, Vault cannot complete the TLS handshake. It must be set in the listener stanza and kept secure with appropriate file permissions.

After promoting the DR secondary, the new primary can generate a new activation token for a new DR secondary. You then deploy a new Vault cluster in Region A, configure it with the same storage backend and seal, and use the token to enable DR replication. This establishes a new DR relationship and ensures data is replicated to the new secondary.

Version mismatches between the PKCS#11 library and HSM firmware break the C_GetFunctionList contract, so Vault's seal or auto-unseal calls fail with a PKCS#11 error. This satisfies the stem's requirement for a genuine cause: the vendor library must match the firmware's supported interface version.

The activation token is required to authenticate the secondary to the primary. It is generated on the primary cluster and then used on the secondary when enabling replication. This token contains the necessary details for the secondary to establish a connection and start receiving data. Without it, the secondary cannot be activated.

The PKCS#11 seal stanza uses the lib field to specify the absolute path to the vendor's PKCS#11 shared library, such as /usr/lib/libpkcs11.so. Vault loads this library at startup to communicate with the HSM. Without a correct lib path, Vault cannot initialize the seal and auto-unseal fails. This is the documented configuration field for library discovery, not an environment variable.

Tokens are namespace-scoped. A token created in team-a is not valid for API calls in team-b; it cannot be used to authenticate to team-b's secrets engine. Even if the policy path matched, the token's namespace context prevents access. Thus the read fails due to namespace isolation.

The AWS auth method's 'method' block requires 'role' to name the IAM role whose bound principal and policies Vault uses when authenticating. Without it, Vault cannot map the signed STS identity to a configured role, so login fails.

Vault stores only the KMS key identifier and relies on IAM permissions to call Decrypt; AWS KMS rotation creates new backing key material under the same key ID, so no Vault reconfiguration is needed provided permissions persist.

Auto-auth handles token login, renewal, and maintenance.

Sentinel in Vault Enterprise supports both endpoint governing policies, which evaluate requests to Vault endpoints, and role governing policies, which apply to tokens issued to specific roles. Naming both types correctly satisfies the stem's requirement for true statements about Sentinel usage.

Sends a signal to the process specified by the exec block's command, allowing graceful reload without terminating it. This satisfies the change_mode requirement for notifying a running application of updated secrets via a configurable signal.

The `request` parameter supplies Sentinel with the current request's metadata, including the path being accessed and the operation type, such as read or write. This satisfies the stem's requirement to restrict secret access based on request details, since policies evaluate `request.data` and `request.operation` directly.

The `read` capability grants retrieval of secrets at a specified path, satisfying the requirement for read access to the KV v2 path. It permits GET operations on that path without allowing writes, deletes or list operations, which matches the least-privilege constraint stated in the scenario.

The 'vault_raft_leader_lastContact' metric measures the time since the leader last contacted each follower. Spikes indicate delays in communication, often caused by network issues such as high latency, packet loss, or congestion. This directly affects Raft replication and can lead to performance degradation. The operator should investigate network connectivity between nodes to resolve the intermittent spikes.

This tracks the time spent during the seal/unseal phase.

The `vault operator raft join` command is used to join a node to an existing Raft cluster. You must specify the API address of a node that is already a member of the cluster, typically the leader. Running this on vault-2 and vault-3 will add them as followers. This is the standard procedure for adding nodes to a Vault Raft cluster after initialization.

Debug level emits the most granular diagnostics, including configuration parsing, plugin loading and seal/unseal steps, which is what startup troubleshooting needs. It satisfies the requirement for detailed debugging information beyond the coarser info and warn levels.

Auto-unseal requires the HSM to access the same key that was used during initialization to encrypt the root key. If the slot or partition is incorrect, Vault cannot decrypt the root key and falls back to manual unseal. Verifying the slot and key label is essential when troubleshooting HSM auto-unseal failures.

Raft requires a strict majority of voting nodes to commit entries and elect a leader. Losing more than half the voters halts writes and leader election, directly satisfying the stem's quorum-loss condition. Non-voting or standby nodes do not count towards this majority, so their survival cannot prevent quorum loss.

Performance Replication enables secondaries to serve read requests locally, satisfying the stem's demand for a benefit over DR Replication. DR Replication secondaries remain on standby and cannot handle reads, whereas Performance Replication secondaries actively serve reads, distributing load and reducing latency for geographically dispersed clients.

Control Groups only restrict access to the specific paths they protect. The token's other capabilities remain unaffected, so it can read secrets outside the Control Group's scope. This allows users to continue working with other secrets while awaiting approval for the protected path.

When Vault fails to start with an HSM seal, the first step is to examine the server logs, which will indicate if the PKCS#11 library cannot be loaded or if there is an authentication failure with the HSM. Verifying the library path and HSM credentials is essential to resolve connectivity issues.

Before promotion, the secondary must be unsealed and operational. A valid license with Performance Replication is required for the secondary to function as a replication target and to be promoted. Without these, the promotion will fail or the cluster may not operate correctly.

Grafana queries Vault's Prometheus-compatible /sys/metrics endpoint and renders the returned counters and gauges as dashboards, satisfying the requirement for graphical visualisation. Unlike CLI output or raw log files, it presents time-series data visually, letting operators spot trends and anomalies in seal status, request latency and token counts.

High availability of the HSM is essential for auto-unseal and Seal Wrap operations. Vault's PKCS#11 seal can be configured with multiple endpoints or a load-balanced address so that if one appliance fails, Vault can reach another. Without this, loss of the HSM prevents unsealing and cryptographic operations. This directly addresses survival of a single HSM appliance failure and is a critical design consideration.

Path filters let you exclude high-churn paths from replication, directly cutting the volume of write-ahead log entries shipped to secondaries. Less replicated data means the secondary applies the log faster, reducing measured replication lag at the primary.

The seal-status endpoint returns sealed, initialized, standby, and cluster identifiers without requiring authentication. It is designed for exactly this readiness check, so a load balancer or operator can poll each node and confirm it is unsealed and either active or standby before routing traffic. It reports the state the operator needs without exposing sensitive data.

Raft requires a quorum of (n/2)+1 nodes to elect a leader and commit writes. Three nodes tolerate one failure while retaining quorum, satisfying the stem's fault-tolerance constraint; two would lose quorum on any single failure.

Performance Secondary clusters maintain their own Integrated Storage and serve reads locally. If the underlying storage is undersized or has high latency, read operations will be slow even with low replication lag. This is a common oversight when scaling reads: the secondary's local storage performance directly affects read latency.

For auto-unseal, Vault must authenticate to the same HSM partition and use the same key. If the new cluster's seal configuration has a different token_label or pin, or if the HSM partition is not accessible, Vault cannot log in and will remain sealed with a PKCS#11 error. This is the most likely cause when restoring to a new cluster with HSM auto-unseal.

When the HSM partition PIN is rotated, the old PIN becomes invalid. Vault uses the configured PIN to log in to the PKCS#11 token during unseal. If the configuration still contains the old PIN, Vault cannot establish a session, so auto-unseal fails on restart. This is the expected impact of a PIN rotation without updating Vault's seal configuration.

Wildcards are supported in `bound_service_account_names`, letting one role match many service accounts without listing each individually. This satisfies the stem's requirement that the parameter can target multiple accounts, since patterns such as `web-*` match every service account sharing that prefix, reducing role sprawl across namespaces.