Vault Enterprise Hsm Integration Practice Test 3 — 15 Questions

Question 1

What permission level is required for the user account used to authenticate with the HSM?

Accepted Answer

The account must have Crypto User (CU) privileges.. The HSM user account used by Vault must have Crypto User (CU) privileges because Vault only needs to perform cryptographic operations (encrypt/decrypt/wrap/unwrap) against the HSM — it does not need to manage partitions, users, or policies. CU is the standard PKCS#11 role that grants access to cryptographic mechanisms and key objects without administrative control. This least-privilege model is what HashiCorp documents for Vault Enterprise HSM auto-unseal.

Answer

The account must be the partition owner.

Answer

The account must have anonymous access.

Answer

The account must have full Administrative (SO) privileges.

Question 2

Which Vault command is used to check the status of the seal configuration and verify if it is using an HSM?

Accepted Answer

vault status. The 'vault status' command reports the seal configuration and status of a Vault node, including whether auto-unseal is in use and, for HSM-backed seals, details about the seal type. It is the standard CLI command to check seal state and confirm HSM usage. Running it against a Vault server shows fields like 'Seal Type: hsm' when HSM auto-unseal is configured.

Answer

vault operator hsm-check

Answer

vault read sys/seal-config

Answer

vault seal-status

Question 3

Which TWO of the following are potential causes for a 'PKCS#11 error' during Vault operation?

Accepted Answer

Incompatibility between the library version and the HSM firmware.. Option A is correct because Vault's PKCS#11 auto-unseal and HSM integrations load a vendor PKCS#11 library (e.g., libCryptoki2.so) to talk to the HSM, and a mismatch between that library version and the HSM's firmware can cause the C_* calls to fail, surfacing as a 'PKCS#11 error'. Option B is correct because the PKCS#11 session login uses the HSM's user PIN (C_Login with CKU_USER); an incorrect or expired PIN makes authentication fail and Vault reports a PKCS#11 error. Option C is not a PKCS#11 cause: an expired Vault token produces a Vault API 'permission denied' or token-expired error, unrelated to the HSM's PKCS#11 interface. Option D is unrelated because a full storage backend causes write failures in Vault's storage layer, not a PKCS#11 cryptographic error. Option E is unrelated because a local firewall blocking network traffic would typically manifest as connection timeouts or refused connections, not a PKCS#11 library-level error.

Answer

The Vault token has expired.

Answer

The storage backend is full.

Answer

The network is blocked by a local firewall.

Question 4

Which component of Vault is responsible for communicating with the HSM?

Accepted Answer

The seal component.. The seal component is the Vault subsystem responsible for encrypting and decrypting the root key, and it is the layer that integrates with external key management, including HSMs via PKCS#11. When auto-unseal is configured, the seal stanza drives all communication with the HSM — loading the library, opening a session, and using the HSM key to wrap/unwrap Vault's master key. No other Vault component talks to the HSM directly.

Answer

The audit log manager.

Answer

The storage backend.

Answer

The transit engine.

Question 5

When testing a new HSM configuration in a development environment, why is it recommended to use a separate partition?

Accepted Answer

To avoid accidental data loss or interference with production keys.. Using a separate HSM partition for development isolates dev/test keys from production keys, preventing accidental overwrites, deletions, or cryptographic operations that could corrupt or expose production key material. Partitions in an HSM are logically isolated security domains, so operations in one partition cannot affect objects in another. This is a best practice for safe testing of new HSM configurations.

Answer

The PKCS#11 library requires a unique partition for every Vault instance.

Answer

It reduces the memory footprint of the Vault service.

Answer

To increase the speed of the cryptographic operations.

Question 6

Which THREE of the following are common troubleshooting steps when Vault fails to unseal via HSM?

Accepted Answer

Check Vault logs for specific PKCS#11 error codes.. Option B is correct because when Vault fails to unseal via HSM, the Vault server logs typically surface PKCS#11 error codes (e.g., CKR_SLOT_ID_INVALID, CKR_TOKEN_NOT_PRESENT) that pinpoint whether the failure is a slot, token, PIN, or session issue, making log inspection a standard first troubleshooting step. Option D is correct because Vault's seal stanza requires a valid path to the HSM vendor's PKCS#11 library (e.g., /usr/lib/libpkcs11.so or /opt/vendor/lib/libpkcs11.so); if that path is wrong, missing, or unreadable by the vault user, Vault cannot load the library and unsealing fails. Option E is correct because using the HSM vendor's own CLI tools (e.g., pkcs11-tool --list-slots or the vendor utility) confirms the slot/token is present, initialized, and accessible outside Vault, isolating whether the problem is in the HSM itself versus Vault's configuration. Option A is not a troubleshooting step for HSM unsealing failures because 'vault operator unseal' is the normal unseal operation itself, not a diagnostic action, and it will simply fail again if the underlying PKCS#11 issue is unresolved. Option C is incorrect because the storage backend driver is unrelated to HSM-based auto-unseal; upgrading it would not address PKCS#11 library, slot, or token problems.

Answer

Run 'vault operator unseal' manually.

Answer

Upgrade the storage backend driver.

Question 7

An administrator has configured a Vault Enterprise server to use a PKCS#11 HSM for auto-unseal. After a reboot, Vault fails to start and logs show that the PKCS#11 library could not be loaded. Which action should the administrator take first to resolve the issue?

Accepted Answer

Verify that the `lib` path in the `seal` stanza points to a valid PKCS#11 shared library and that the file permissions allow the Vault process to read it.. A PKCS#11 library load failure typically stems from an incorrect `lib` path or missing file permissions. The Vault process must be able to read and load the vendor's shared library. Verifying the path and permissions is the correct first troubleshooting step, whereas reinitializing the token, changing the mechanism, or disabling Seal Wrap do not address the root cause.

Answer

Reinitialize the HSM token with a new PIN using the vendor's management utility.

Answer

Change the `mechanism` in the seal stanza to `CKM_RSA_PKCS_OAEP` and restart Vault.

Answer

Disable Seal Wrap temporarily by setting `seal_wrap = false` in the seal stanza and restart Vault.

Question 8

You are deploying Vault Enterprise 1.15 on three nodes and want auto-unseal backed by a PKCS#11 HSM. The HSM vendor provides a shared library at /usr/lib64/libpkcs11.so, and each node must authenticate using an HSM partition PIN. Which seal configuration key holds the PIN so Vault can open the HSM session?

Accepted Answer

pin. The PKCS#11 seal stanza requires both the token label and the user PIN to open a session against the HSM partition. The PIN is supplied through the pin field. Without the correct pin value, Vault cannot log in to the token and auto-unseal will fail, even if the library path and token label are correct.

Answer

password

Answer

key_label

Answer

token_label

Question 9

A Vault Enterprise cluster uses a PKCS#11 HSM for seal wrap and auto-unseal. The security team rotates the HSM partition PIN. Vault nodes are still running with the old PIN in their configuration files. What is the most likely operational impact?

Accepted Answer

Vault nodes will fail to unseal after a restart because they cannot authenticate to the HSM with the old PIN.. The PKCS#11 PIN is used to authenticate to the HSM partition whenever Vault needs to open a session, including during unseal. Rotating the PIN without updating Vault's seal configuration means the old PIN is rejected, so nodes cannot unseal after a restart. The correct remediation is to update the pin value in the seal stanza and restart Vault.

Answer

Vault will automatically fall back to Shamir unseal and prompt for unseal keys.

Answer

Vault continues to operate normally because the PIN is only used during initial unseal and is cached in memory.

Answer

Seal wrap operations will continue using the old PIN until the next key rotation, then fail.

Question 10

A Vault Enterprise operator enables Seal Wrap on a cluster backed by a PKCS#11 HSM. After enabling Seal Wrap, the operator notices that some existing secrets still appear in plaintext within the storage backend. Which statement explains this behavior?

Accepted Answer

Seal Wrap only applies to new writes; existing data must be re-written or migrated to be wrapped, so pre-existing plaintext entries remain until they are updated.. Seal Wrap protects data by wrapping values with the HSM at write time. It is not a retroactive process, so secrets written before Seal Wrap was enabled remain unwrapped in storage. Operators must re-write or migrate that data to bring it under HSM protection. This is why a mix of wrapped and unwrapped entries can appear after enabling the feature.

Answer

The HSM is not configured with a wrapping key, so Vault silently falls back to plaintext storage for all secrets until a wrapping key is generated.

Answer

Seal Wrap requires a cluster restart to take effect, so until all nodes are restarted the storage backend will continue to show plaintext for all entries.

Answer

Seal Wrap is only compatible with the transit secrets engine, so data from other engines such as KV will always remain unwrapped in storage.

Question 11

Your Vault Enterprise cluster is configured with a PKCS#11 HSM for auto-unseal. During a disaster recovery test, you restore a snapshot to a new cluster that also has the same HSM seal configuration. After starting the new cluster, Vault remains sealed and logs indicate a PKCS#11 error. What is the most likely cause?

Accepted Answer

The new cluster cannot authenticate to the HSM because the token label or PIN in its seal configuration does not match the HSM partition.. Auto-unseal with PKCS#11 requires Vault to authenticate to the same HSM partition and use the same key. When restoring to a new cluster, the seal configuration must reference the correct token_label and pin. If these do not match, Vault cannot log in to the HSM and remains sealed. The most likely cause is a mismatch in token label or PIN.

Answer

The snapshot must be decrypted with the old cluster's unseal keys before the HSM can be used.

Answer

The HSM key used for seal wrap was not included in the snapshot and must be recreated on the HSM.

Answer

The new cluster requires a different PKCS#11 library version that matches the HSM firmware.

Question 12

You are deploying a new Vault Enterprise cluster that will use a PKCS#11 HSM for auto-unseal. The HSM is a network-attached appliance reachable over TCP. Which TWO configuration elements must be present in the seal stanza to allow Vault to communicate with this HSM? (Choose two.)

Accepted Answer

The slot number or slot label that identifies the HSM partition.. To use a PKCS#11 HSM for auto-unseal, Vault needs the vendor's PKCS#11 library path and a way to select the correct slot or partition. These two elements allow Vault to load the library, initialize a session, and log in to the HSM. Other details such as management IP, serial number, or firmware version are not part of the seal stanza configuration.

Answer

The HSM's firmware version to ensure compatibility with Vault's PKCS#11 calls.

Answer

The HSM's serial number to bind the seal to a specific hardware unit.

Answer

The IP address and port of the HSM's management web interface.

Question 13

An operator needs to verify that a Vault Enterprise cluster is currently using a PKCS#11 HSM for its seal and that the seal is healthy. Which command provides the seal type and status without requiring unseal keys?

Accepted Answer

vault status. The vault status command reports the seal type and whether Vault is sealed. When an HSM is configured, the output includes a seal type such as pkcs11 or hsm, confirming that auto-unseal is active. This command is safe to run without unseal keys and is the quickest way to verify seal health.

Answer

vault operator unseal -status

Answer

vault debug -seal

Answer

vault read sys/seal

Question 14

A Vault Enterprise cluster is configured with PKCS#11 auto-unseal. After a scheduled HSM firmware upgrade, Vault nodes fail to unseal and log 'PKCS#11 error: CKR_SLOT_ID_INVALID'. The HSM administrator confirms the partition is online and the PIN is unchanged. Which action should you take first to restore auto-unseal?

Accepted Answer

Verify the current slot ID with pkcs11-tool --list-slots and update the slot parameter in the seal stanza to match the new slot numbering.. After HSM firmware updates, slot numbering can change, causing CKR_SLOT_ID_INVALID because the seal stanza references an old slot index. Enumerating slots with pkcs11-tool --list-slots and updating the slot value restores auto-unseal. Reinitializing or restarting without fixing the slot does not resolve the mapping, and timeout tuning is irrelevant to slot validation.

Answer

Restart the Vault service on each node to force a re-read of the seal configuration.

Answer

Regenerate the Vault seal key and reinitialize the cluster with vault operator init.

Answer

Increase the hsm timeout parameter in the seal stanza to allow Vault more time to connect to the HSM.

Question 15

A Vault Enterprise operator enables Seal Wrap on a cluster backed by a PKCS#11 HSM. After enabling, they notice that the storage backend contains wrapped values for the barrier key and some data encryption keys, but not for all keys. Which statement explains why only some keys are wrapped?

Accepted Answer

Seal Wrap wraps keys only when the mount or key is explicitly configured to use it, so keys created before enabling or without the setting remain unwrapped.. Seal Wrap is not global by default; it applies to the barrier key and to key material for mounts or keys explicitly configured to use it. Keys created before enabling Seal Wrap, or on mounts where it is not enabled, remain unwrapped. This explains the partial wrapping seen in storage without implying any HSM fault or mechanism limitation.

Answer

The HSM is returning CKR_USER_NOT_LOGGED_IN for some operations, causing Vault to skip wrapping those keys.

Answer

Seal Wrap requires the HSM to support CKM_AES_KEY_WRAP; if unsupported, Vault wraps only the barrier key.

Answer

Seal Wrap only wraps the root key and recovery keys, not any data encryption keys.