Vault Server Configuration practice questions

They provide a way to bypass authentication.

Why it fails: Recovery keys do not bypass authentication.

They increase the encryption strength of the data at rest.

Why it fails: Recovery keys do not change encryption algorithms.

They are required for every client login.

Why it fails: Recovery keys are for administrative disaster recovery only.

Using environment variables exclusively.

Why it fails: Environment variables are not for persistent auth configuration.

By editing the core binary settings.

Why it fails: You should never edit the binary.

In the HCL configuration file

Why it fails: Auth methods are configured via API, not the static HCL config.

path

Why it fails: path defines the storage location on disk, not the identity.

api_addr

Why it fails: api_addr is for client communication, not Raft node identification.

retry_join

Why it fails: retry_join is for joining existing clusters, but node_id is the primary identifier.

vault monitor

Why it fails: The monitor command streams a live log of a Vault server's audit and operational events, so it displays activity rather than reporting node health. It is tempting because it does surface server state, and it would be the right choice when actively tailing logs to debug a running node.

vault health

Why it fails: This command does not exist.

vault inspect

Why it fails: No vault inspect command exists; inspection of stored data is performed through read operations on specific paths. It is tempting because other HashiCorp tooling uses inspect-style subcommands, and it would be correct if Vault offered a dedicated command to examine a node's internal state.

ui

Why it fails: This enables or disables the web UI.

max_lease_ttl

Why it fails: This controls lease durations, not background tasks.

plugin_directory

Why it fails: This specifies where plugins are loaded.

file_path

Why it fails: This is for file-based audit, not specifically for HA.

audit_non_blocking

Why it fails: This is a feature, but not a config param for audit device.

tcp_addr

Why it fails: Used for remote syslog, not HA specifically.

Unseal the cluster.

Why it fails: Initialization happens before unsealing.

Enable secret engines.

Why it fails: This is a post-init step.

Configure the audit device.

Why it fails: This is a post-init step.

A backup of the previous storage.

Why it fails: Not required to join.

A list of all other cluster nodes.

Why it fails: The cluster leader propagates the peer list.

The root unseal key.

Why it fails: Not needed for joining.

An LDAP server.

Why it fails: Used for auth, not transport security.

An external load balancer.

Why it fails: Optional, not strictly necessary for security.

A `listener "tcp"` block containing `tls_disable_client_certs` and `tls_require_and_verify_client_cert` parameters.

Why it fails: These parameters control mutual TLS client certificate verification, not the serving of a custom CA certificate chain. `tls_disable_client_certs` disables client certificate requests, and `tls_require_and_verify_client_cert` enforces verification. Neither provides the server's CA chain to clients, so this block does not meet the stated TLS requirement.

A `listener "tcp"` block containing `tls_cert_file` and `tls_key_file` parameters.

Why it fails: The `listener "tcp"` block with `tls_cert_file` and `tls_key_file` enables TLS on the API listener, but it does not provide a custom CA certificate chain. To serve a custom CA chain, the listener must instead use `tls_client_ca_file` or the certificate file itself must include the full chain. This option alone does not satisfy the CA chain requirement.

A `storage "raft"` block containing `max_entry_size` and `path` parameters.

Why it fails: The `storage "raft"` block is correct for Integrated Storage, but `max_entry_size` controls the maximum size of a single Raft log entry, not the automatic snapshot threshold. Snapshot behavior is controlled by `snapshot_threshold` and `snapshot_interval`. Including only `max_entry_size` would not enable log-size-driven snapshots and would leave the requirement partially unmet.

`disable_clustering = true` in the `storage "raft"` block.

Why it fails: `disable_clustering` is not a valid parameter in the Raft storage stanza; clustering is controlled by the `cluster_addr` and retry_join settings. Setting this would not enable local read serving or Raft log maintenance on a performance standby. The parameter does not exist, so it cannot satisfy the requirement.

`ha_enabled = true` in the `listener "tcp"` block.

Why it fails: `ha_enabled` is not a valid listener parameter; HA and performance standby behavior are configured in the `server` block or via environment variables. The listener block handles network TLS settings, not cluster roles. Using this would not enable performance standby mode or local read serving, so it fails the requirement.

`performance_standby = true` in the `storage "raft"` block.

Why it fails: There is no `performance_standby` parameter inside the Raft storage block. Performance standby behavior is enabled by the Enterprise license and the `performance_standby` setting in the `server` block or via environment variable. Placing it in the storage block is invalid and would not enable the required behavior.

`plugin_directory = "/opt/vault/plugins"` in the `storage` block.

Why it fails: While `plugin_directory` is the correct parameter name, it belongs in the `server` block, not the `storage` block. The storage block defines the persistence backend (e.g., Raft, Consul). Placing `plugin_directory` under `storage` would cause a configuration error or be ignored, so this option does not achieve the desired result.

`plugin_path = "/opt/vault/plugins"` in the `storage` block.

Why it fails: `plugin_path` is not a valid Vault configuration parameter, and the `storage` block is used for backend configuration such as Raft or Consul. Placing a plugin directory setting there would be ignored by Vault. This option does not enable plugin loading and is therefore incorrect for the scenario.

`external_plugins = true` in the `listener` block.

Why it fails: `external_plugins` is not a recognized listener parameter; the listener block configures network and TLS settings. Enabling external plugins requires specifying a plugin directory in the `server` block, not a boolean in the listener. This option would not allow Vault to find or load the plugin binaries from the specified path.

raft_snapshot_threshold

Why it fails: raft_snapshot_threshold controls when Vault takes a snapshot of the Raft log, not the number of copies stored. It affects snapshot frequency and disk usage but has no impact on write acknowledgement or fault tolerance. Configuring this would not ensure that writes are replicated across multiple zones before being acknowledged.

raft_performance_multiplier

Why it fails: The raft_performance_multiplier parameter is used to adjust the number of parallel Raft operations, not the replication factor for log entries. It does not control how many copies of a log entry are stored before acknowledging a write. Setting this parameter would not provide the desired fault tolerance across availability zones.

replication_factor

Why it fails: replication_factor is not a valid Vault configuration parameter. While it may sound plausible, Vault does not expose a setting by that name. The replication factor in Integrated Storage is determined by the number of voters in the Raft cluster, not by a configurable parameter. Using this would result in a configuration error.

seal "pkcs11" { lib = "/usr/lib/libpkcs11.so" slot = "1" pin = "1234" key_label = "vault-key" }

Why it fails: While a seal block with type pkcs11 is required, the parameter names and structure are incorrect. Vault expects specific fields such as lib, slot, pin, and key_label, but these must be nested under a mechanism block and the seal stanza must include the correct type. This configuration would fail to load because Vault does not recognize the provided fields at the top level of the seal stanza.

seal "hsm" { library = "/usr/lib/libpkcs11.so" slot = "1" pin = "1234" key_label = "vault-key" }

Why it fails: The seal type hsm is not valid in Vault. Vault uses specific seal types such as pkcs11 for PKCS#11-compatible HSMs. Additionally, the parameter library is incorrect; it should be lib. This configuration would be rejected by Vault during startup because the seal type is unrecognized and the required parameters are missing or misnamed.

seal "pkcs11" { mechanism = "0x1082" library = "/usr/lib/libpkcs11.so" slot = "1" pin = "1234" key_label = "vault-key" }

Why it fails: This option uses library instead of lib, which is not a valid parameter. Vault's PKCS#11 seal configuration requires the lib parameter to specify the path to the PKCS#11 library. Additionally, the mechanism should be specified as a string or number, but the parameter name is mechanism and it must be inside the seal stanza. Using library would cause Vault to ignore the setting and fail to initialize the seal.

`performance_multiplier` in the storage stanza

Why it fails: `performance_multiplier` is used to adjust the number of applied log entries before a snapshot is triggered. While it can indirectly affect snapshot frequency, it is not the primary parameter for controlling database size, and its use is generally discouraged unless specific performance tuning is required. It does not directly set the threshold for snapshotting.

`max_request_duration` in the storage stanza

Why it fails: `max_request_duration` specifies the maximum time a request can take before being canceled. It is unrelated to raft log size or database growth. It governs request timeouts and does not influence snapshotting or log truncation, so it would not mitigate the disk usage issue described.

`max_entry_size` in the storage stanza

Why it fails: `max_entry_size` sets the maximum size of a single raft log entry, not the overall database size. It helps prevent overly large entries but does not directly control the total disk consumption or trigger snapshotting. Adjusting this would not address the rapid growth of the raft database file in this scenario.

Configure a `tls_cluster` stanza with the cluster certificate and key.

Why it fails: There is no `tls_cluster` stanza in Vault configuration. TLS for cluster communication is not configured via a separate stanza. Instead, it uses the same TLS settings as the listener, or you can specify a separate TLS certificate for cluster traffic using the `cluster_addr` with HTTPS and the listener's TLS configuration. This option is invalid.

Enable `seal` stanza with `tls_skip_verify = false` to enforce TLS on cluster ports.

Why it fails: The `seal` stanza configures auto-unseal, not cluster TLS. `tls_skip_verify` is a parameter used in some seal configurations but does not enforce TLS on cluster communication. Cluster TLS is handled by the listener's TLS settings and the `cluster_addr` scheme. This option misinterprets the purpose of the seal stanza.

Set `disable_clustering = false` in the listener stanza.

Why it fails: The `disable_clustering` parameter is used to disable clustering on a listener, but setting it to false (the default) does not enforce TLS on cluster traffic. It merely allows clustering. TLS for cluster communication is controlled by the `cluster_addr` scheme and the presence of a TLS-enabled listener. This option does not provide the necessary certificate configuration.

`max_entry_size`

Why it fails: `max_entry_size` is an optional parameter that limits the size of a single raft log entry. It is not required for joining a cluster and is used for tuning. It does not affect the node's ability to join; it only controls entry size. Therefore, it is not a must-set parameter for cluster joining.

`cluster_addr`

Why it fails: `cluster_addr` is set in the top-level configuration, not in the `storage` stanza. It specifies the address for cluster communication. It is required for the node to participate in the cluster, but it is not part of the storage stanza. The question specifically asks for parameters in the `storage` stanza, so this is incorrect.

`retry_join`

Why it fails: `retry_join` is used to specify one or more existing cluster members to join. While it is commonly used for automatic joining, it is not strictly required if you manually join the node using the `vault operator raft join` command. The question asks for parameters that must be set in the storage stanza to enable joining; `retry_join` is optional because you can join manually. However, for automated joining, it is necessary. But the scenario does not specify automation, so it is not a must.

To mount storage backends.

Why it fails: Storage backends are configured via the storage stanza, not cluster_addr, which handles server-to-server cluster traffic. It is tempting because storage configuration is central to Vault setup; that stanza would be the correct answer if the question asked which block defines the persistence layer rather than the cluster communication address.

To handle client API requests.

Why it fails: Client API requests are served on the api_addr listener, not cluster_addr, so this fails the scenario. It is tempting because api_addr does handle client traffic; that address would be the correct answer if the question asked which parameter defines the client-facing API endpoint rather than the cluster listener.

To communicate with external secret engines.

Why it fails: External secret engines are reached through normal API requests, not cluster_addr, which carries server-to-server cluster traffic. It is tempting because Vault does communicate with external systems; that would be correct if the question asked how plugins or secrets engines are contacted, rather than which address handles internal cluster replication and request forwarding.

The request is rejected with a 403 error.

Why it fails: Performance standbys forward write requests to the active node rather than rejecting them, so no 403 is returned. A 403 arises from permission or token issues, not node role. Tempting because standbys cannot persist writes locally, but the correct behaviour is forwarding, not denial.

The node processes it locally.

Why it fails: Performance standbys serve reads locally but cannot write to storage, so they forward write requests to the active node. Processing locally would break consistency. Tempting because standbys do handle read traffic locally, but writes require the active node to commit to the storage backend.

The node triggers an election.

Why it fails: Only the active node participates in leader election; a performance standby never triggers one on receiving a write. It forwards the request to the active node instead. Tempting because standbys do become active after failover, but that requires the active to fail, not an incoming write.

tls_disable = true

Why it fails: Setting tls_disable = true removes TLS from the listener entirely, so Vault serves cleartext HTTP — the exact opposite of the hardening goal. It is tempting because it simplifies initial testing or lab setups where certificates are absent, and it would be the correct choice only for a non-production, isolated environment.

proxy_protocol = true

Why it fails: Proxy protocol preserves the client's original address when Vault sits behind a load balancer; it neither enables nor disables TLS. It is tempting because it appears in hardened listener configurations, but cleartext prevention requires TLS configuration, not address forwarding.

tls_prefer_server_cipher_suites = false

Why it fails: This setting governs cipher-suite preference order during TLS negotiation; setting it false does not disable TLS, so cleartext remains possible if TLS is not enforced. It is tempting because it appears security-related, but the correct control is disabling the plaintext listener or requiring TLS.