Select Two (Multi-Select) Questions

tls_client_ca_file

Why it fails: tls_client_ca_file is not a valid parameter in Vault's listener stanza. The correct parameter for client CA verification is tls_ca_file, used when tls_require_and_verify_client_cert is true. Since mutual TLS is not specified in the scenario, this parameter is unnecessary and its name is incorrect.

tls_min_version

Why it fails: tls_min_version is an optional parameter that sets the minimum TLS version accepted. It is not required to enable TLS; Vault will use a default (currently TLS 1.2) if not set. While it is good practice to specify it for security, it is not mandatory for the basic TLS configuration described.

tls_ca_file

Why it fails: The tls_ca_file parameter is used to specify a CA certificate for verifying client certificates when mutual TLS is enabled. It is not required for basic TLS where only the server presents a certificate. While it can be set, it is not mandatory for enabling TLS; the required parameters are the server certificate and key.

SecretIDs are synonymous with RoleIDs.

Why it fails: RoleID and SecretID are two distinct halves of AppRole authentication: the RoleID identifies the role, while the SecretID proves the client's authorisation to use it. They are separate values delivered through separate channels. Treating them as synonyms would collapse the two-factor design that lets SecretIDs be rotated and revoked independently.

SecretIDs should be stored in cleartext in version control.

Why it fails: SecretIDs are bearer credentials that authenticate an application to Vault; storing them in cleartext in version control exposes them to anyone with repository access, enabling unauthorised secret retrieval. They should be delivered via a secure channel such as response wrapping. Cleartext storage would only be acceptable for non-sensitive, throwaway test data.

SecretIDs are the same for all applications in a namespace.

Why it fails: Each SecretID is unique per AppRole and per issued credential; Vault generates distinct values so that individual clients can be revoked independently. Sharing one value across applications destroys that per-client audit and revocation granularity. Identical SecretIDs would only arise from manual, deliberately duplicated issuance, which defeats the security model.

The Vault token has expired.

Why it fails: An expired Vault token yields a permission denied or 403 error, not a PKCS#11 error, which originates from the HSM library or token. Token expiry would be the right diagnosis for authorisation failures on otherwise valid operations.

The storage backend is full.

Why it fails: A full storage backend produces write failures in Vault's storage layer, not PKCS#11 errors, which originate from the HSM's cryptographic token interface. Capacity exhaustion is remedied by expanding or pruning storage. The PKCS#11 provider communicates with the HSM independently of Vault's storage backend, so the two are unrelated.

The network is blocked by a local firewall.

Why it fails: PKCS#11 calls go to the HSM over its own session channel, so a local firewall blocking general network traffic does not generate PKCS#11 errors unless it specifically filters the HSM's port. Firewall troubleshooting suits connectivity failures to remote services, not token-level cryptographic faults.

Sentinel policies are written in HCL.

Why it fails: Sentinel policies are written in Sentinel, HashiCorp's own policy language, not HCL; HCL is used for Vault configuration and policy definitions. The temptation is that HCL appears throughout Vault, so it seems the natural policy syntax, yet Sentinel's constructs and imports require its dedicated language.

Sentinel policies replace ACLs.

Why it fails: Sentinel supplements ACLs rather than replacing them; ACLs still grant or deny path-level access, and Sentinel only evaluates requests that ACLs already permit. It is tempting because Sentinel enforces fine-grained, attribute-based rules, but removing ACLs leaves no underlying capability grant for Sentinel to constrain.

Sentinel policies are evaluated before ACLs.

Why it fails: Sentinel policies run after ACLs, not before; ACLs first filter the request, then Sentinel evaluates the permitted action. The temptation is that Sentinel adds a second authorisation layer, so it feels like a preceding gate, but its role is post-ACL fine-grained control over already-allowed operations.

delete

Why it fails: The change_mode parameter accepts noop, restart, and signal; delete is not a valid value, so it cannot be triggered. It is tempting because delete implies removing stale rendered files, but Vault Agent handles template output through restart or signal, with noop taking no action at all.

exec

Why it fails: The change_mode parameter accepts noop, restart, and signal; exec is not a valid value, so it cannot be triggered. It is tempting because exec suggests running a command on change, but Vault Agent instead uses signal to send a process signal and restart to stop and restart the service.

Audit logging.

Why it fails: Audit logging ships in Vault Community Edition, so it is not an Enterprise-only server configuration feature. It is tempting because auditing is configured on the server, but Enterprise server features include namespaces, replication and seal-wrap.

KV Secret Engine.

Why it fails: KV is a secrets engine available in Vault Community Edition, so it is not Enterprise-specific server configuration. It is tempting because KV is central to most deployments, but the question targets Enterprise server features such as performance replication or HSM support.

Token management.

Why it fails: Token management is a Vault Community feature, available in the open-source server, so it cannot be an Enterprise-only configuration capability. It tempts because tokens underpin every auth method and policy, yet the Enterprise question targets server configuration features such as replication, seal wrap, and HSM support.

Run 'vault operator unseal' manually.

Why it fails: Manual unseal still requires the HSM to decrypt the root key, so it fails identically when the PKCS#11 configuration or key handle is wrong. It is the correct step for Shamir-sealed clusters where operators supply unseal keys by hand.

Upgrade the storage backend driver.

Why it fails: The storage backend driver is unrelated to HSM unsealing, which depends on the PKCS#11 library, key material, and HSM connectivity. Upgrading the driver is correct when storage errors or compatibility issues affect Vault's data persistence, not seal operations.

Telemetry endpoint is down.

Why it fails: Telemetry endpoint availability is not part of Vault's health assessment; the health endpoint reports on seal, standby and HA raft states, not metrics export. It tempts because telemetry monitoring matters operationally, and a down endpoint would be the right concern when diagnosing observability gaps rather than node health.

Audit logs are full.

Why it fails: Audit logs filling does not make a Vault node unhealthy; the audit device blocks requests and Vault seals itself only when it cannot write audit entries, which is a write failure rather than a full disk. It is tempting because audit devices are commonly configured with file backends, where capacity planning genuinely matters.

It can only be applied to cluster-admin accounts.

Why it fails: The parameter accepts any service account name in the namespace, not only cluster-admin ones; it defines which Kubernetes service accounts may authenticate to this role. It is tempting because cluster-admin accounts are highly privileged and often the focus of access reviews, but binding is scoped by name list, not privilege level.

It replaces the need for Vault policies.

Why it fails: The parameter restricts which Kubernetes service accounts may authenticate; Vault policies are still attached separately to the resulting token and govern authorisation. It is tempting because binding identities feels like access control, but that is authentication only, and policy mapping remains mandatory regardless of how tightly the service account names are bound.

It is optional if 'bound_namespaces' is set.

Why it fails: 'bound_service_account_names' is required whenever the Kubernetes auth method is configured; 'bound_namespaces' is an additional constraint, not a substitute. It is tempting because namespace binding also narrows which pods may authenticate, but the parameter must still be supplied, and omitting it causes configuration or login failure.

Create a user login.

Why it fails: User logins are created through 'vault auth enable' plus userpass or LDAP configuration, not 'vault operator', which governs seal, unseal, rekey, and cluster membership. The name 'operator' suggests broad administrative control, but authentication methods fall under the auth command group instead.

Create a new secret engine.

Why it fails: Secret engines are mounted through 'vault secrets enable', not the operator group, which handles cluster-level tasks such as seal, unseal, rekey, and storage migration. Operators might assume 'operator' covers all administrative actions, yet enabling a secrets engine is a secrets-management operation, not a cluster operation.

Performance Replication is a type of Performance Standby.

Why it fails: Performance Replication and Performance Standby are distinct Vault Enterprise features addressing different concerns: cross-cluster data replication versus read-only request handling. The shared 'Performance' prefix tempts candidates into treating one as a subtype of the other, which the architecture does not support.

Performance Standby nodes are required for Performance Replication.

Why it fails: Performance Replication replicates data across clusters independently of standby node roles; standby nodes serve read-only requests, not replication. It tempts because both features appear together in Vault Enterprise clustering, so candidates assume a dependency where none exists.

Replication requires performance standby for all nodes.

Why it fails: Performance standby nodes serve read-only requests locally; they are not a prerequisite for Performance Replication, which works across clusters regardless of standby configuration. The claim inverts the dependency. It tempts because performance standbys do complement replication by scaling read throughput, so pairing them is a valid design choice, but replication itself never mandates them.

A cluster of at least 5 nodes.

Why it fails: Auto-unseal needs only KMS credentials, key ID and region, plus seal stanza configuration; cluster size is irrelevant to unsealing. Five nodes is tempting because it is the recommended quorum for integrated storage in production, but that is a high-availability sizing decision, not an auto-unseal prerequisite.

A local unseal key file.

Why it fails: Auto-unseal removes the need for a local unseal key file, since the KMS holds the root key material and unseals Vault on start. The file is tempting because Shamir seal requires threshold key shares, but supplying one alongside KMS auto-unseal contradicts the purpose and is not configured.

A secondary Vault cluster.

Why it fails: A secondary Vault cluster serves disaster recovery or performance replication, not the standard HA quorum that elects an active node within one cluster. It is tempting because replication is real Vault Enterprise functionality, and it would be correct when the requirement is cross-region failover rather than local node redundancy.

An external monitoring tool.

Why it fails: External monitoring observes health and alerts but holds no Vault state, forwards no client requests, and cannot acquire the active node lock. It is tempting because monitoring is genuinely part of production operations, and it would be correct when the requirement is alerting on cluster health rather than serving sealed or active Vault traffic.

The number of Performance Standby nodes on the Primary cluster.

Why it fails: Performance Standby nodes serve read requests on the Primary cluster; they do not process or replicate data to a Performance Secondary, so their count does not affect Secondary throughput. It is tempting because standbys do scale read performance, but that applies only to the cluster they reside in.

The number of root tokens in the system.

Why it fails: Root tokens are authentication credentials for privileged operations; their quantity has no bearing on replication throughput, storage, or request handling on a Performance Secondary. It is tempting because root tokens relate to cluster administration, but token count is not a performance dimension in Vault Enterprise.

storage_type

Why it fails: storage_type selects the local backend (for example integrated storage or Consul) and does not govern inter-cluster replication transport. Tempting because storage is central to Vault, but cross-cluster communication requires correct api_addr, cluster_addr and replication configuration rather than the backend type.

ui

Why it fails: The ui stanza only configures the web interface listener and has no bearing on cluster-to-cluster replication traffic. It is tempting because it appears in the config file, yet cross-cluster communication depends on api_addr, cluster_addr and replication settings, not the UI block.

Disable audit logging to increase performance.

Why it fails: Disabling audit logging removes the record of token issuance and usage, so theft cannot be detected or investigated, directly undermining the hardening goal. It is tempting because audit logging carries storage and performance overhead, and disabling it would be the choice when maximising raw throughput matters more than forensic traceability.

Use the 'root' token for the application.

Why it fails: The root token has unrestricted policy bypass, so theft grants full Vault compromise; applications should authenticate with scoped tokens or Kubernetes service accounts. It is tempting because root tokens work immediately without policy configuration, but they are intended only for initial setup and emergency recovery.

The number of nodes in the cluster.

Why it fails: Node count does not affect token compromise; the critical factors are token reviewer binding, audience restriction and short TTLs. Cluster sizing is tempting because it influences availability and performance planning, which is where this consideration would legitimately apply, not authentication security.

The version of the Kubernetes binary.

Why it fails: The Kubernetes binary version is irrelevant to Vault token compromise; what matters is service account token validation, bound service account names and namespaces. Version tracking is tempting for compatibility and upgrade planning, which is where this factor would correctly feature, not auth hardening.

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

Why it fails: Firmware version is not a seal stanza parameter. Vault relies on the PKCS#11 library to abstract firmware differences. Compatibility is handled by the vendor's library and Vault's supported PKCS#11 mechanisms. Specifying a firmware version in the seal stanza would have no effect on Vault's ability to communicate with the HSM.

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

Why it fails: PKCS#11 does not require Vault to specify a serial number in the seal stanza. Vault identifies the HSM through the library and slot. While a serial number may be used for inventory, it is not a configuration parameter Vault needs to establish a session or perform wrapping operations.

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

Why it fails: Vault does not use the HSM's management web interface to perform cryptographic operations. Communication happens through the PKCS#11 library, which handles the network transport to the HSM. The management interface is for administrators, not for Vault's seal mechanism, so including it in the seal stanza is unnecessary.

Enable the token to be renewed indefinitely so that partners do not need to re-authenticate frequently, reducing the chance of credential exposure during login.

Why it fails: Indefinite renewal increases the blast radius because a stolen token can be kept alive forever. The goal is to minimize the impact of theft, which means limiting token lifetime, not extending it. This option contradicts the requirement and would make the situation worse by allowing persistent unauthorized access.

Assign the root policy to the token so that administrators can quickly investigate and remediate any suspicious activity.

Why it fails: Granting the root policy to external partners is a severe violation of least privilege. Root tokens can perform any operation, so a stolen token would give an attacker complete control over Vault. Investigation should be done by administrators using their own privileged access, not by giving partners root-level tokens.

Disable audit logging for the auth method to prevent attackers from learning which policies are assigned to the token.

Why it fails: Disabling audit logging removes the ability to detect and investigate token misuse. Audit logs do not expose policies to attackers; they record requests for security monitoring. Turning them off would hide malicious activity and hinder incident response, which is the opposite of reducing risk from a stolen token.

Performance standbys participate in the Raft quorum and can become the active node if the current active fails.

Why it fails: Performance standbys are not voting members of the Raft quorum and cannot become active. Only the active node and non-performance standby nodes participate in Raft elections. Performance standbys are designed for read scaling, not for failover. This statement confuses the role of performance standbys with that of standard standbys that can be promoted.

Performance standbys can accept write requests and commit them directly to the integrated storage backend.

Why it fails: Write requests must be forwarded to the active node, which is the only node that can commit to the Raft log. Performance standbys cannot commit writes locally because they do not participate in the Raft quorum for writes. Accepting and committing a write directly would break consistency. This statement misrepresents the write path in a Vault cluster with performance standbys.

Performance standbys require a separate integrated storage backend that is synchronized via performance replication.

Why it fails: Performance standbys within the same cluster share the same integrated storage backend as the active node; they do not have a separate backend. Performance replication is a cross-cluster feature that synchronizes data between a primary and secondary cluster, not between nodes in the same cluster. This statement conflates intra-cluster standby behavior with inter-cluster replication.