Vault Enterprise Vault Security Model Practice Test 3 — 15 Questions

Question 1

Which THREE actions are recommended to secure the Vault-Kubernetes integration against token theft?

Accepted Answer

Use the Vault Agent injector for automatic sidecar management.. Option A is correct because the Vault Agent injector automatically manages the lifecycle of Vault tokens for pods, rendering secrets into a shared volume and renewing or re-authenticating tokens without exposing long-lived credentials to application code, which reduces the attack surface for token theft. Option B is correct because applying 'token_bound_cidrs' to the Kubernetes auth role restricts the issued token so it can only be used from specified CIDR ranges, meaning a stolen token is useless if replayed from an unauthorized network location. Option C is correct because setting short TTLs on all issued tokens limits the window of opportunity for an attacker who obtains a token, forcing frequent re-authentication and reducing the blast radius of a compromise. Option D is not recommended because disabling audit logging removes the ability to detect and investigate token theft or misuse, and audit logging is a core security control rather than an optional performance trade-off. Option E is not recommended because using the 'root' token for an application grants unrestricted, long-lived privileges across Vault, so any theft of that token results in total compromise rather than scoped access.

Answer

Disable audit logging to increase performance.

Answer

Use the 'root' token for the application.

Question 2

Which TWO of the following are true regarding the Vault Kubernetes Auth Method 'bound_service_account_names' parameter?

Accepted Answer

It allows wildcards to match multiple service accounts.. Option B is correct because the Vault Kubernetes Auth Method's bound_service_account_names parameter accepts glob-style wildcards (for example, 'app-*') so a single role can match multiple service account names. Option D is correct because this parameter defines the allowlist of Kubernetes service account names permitted to authenticate against that Vault role, so any service account not listed is rejected. Option A is wrong because the parameter has nothing to do with cluster-admin privileges; it merely constrains service account identities and works with any service account. Option C is wrong because Vault policies are still required to define the actual permissions granted after authentication; bound_service_account_names only governs who may log in. Option E is wrong because bound_service_account_names is a required parameter for the Kubernetes auth role, not something that becomes optional when bound_namespaces is configured.

Answer

It can only be applied to cluster-admin accounts.

Answer

It replaces the need for Vault policies.

Answer

It is optional if 'bound_namespaces' is set.

Question 3

In the context of the Vault Kubernetes Auth Method, what is the role of the 'reviewer_service_account'?

Accepted Answer

It is the account Vault uses to verify client tokens.. The reviewer_service_account is a Kubernetes service account that Vault uses to call the TokenReview API to validate client tokens presented during login. Vault needs permissions to create TokenReview requests, which are granted to this service account.

Answer

It is the account that logs in to Vault.

Answer

It is the account that manages K8s secrets.

Answer

It is an administrative account used to manage Vault roles.

Question 4

Which TWO of the following are valid ways to improve the security of the AppRole authentication process?

Accepted Answer

Enable 'secret_id_bound_cidrs' on the role.. Option B is correct because 'secret_id_bound_cidrs' restricts the CIDR blocks from which a SecretID can be used, so even if a SecretID leaks, it cannot be redeemed from an unauthorized network location, adding a strong network-based constraint to the AppRole login. Option C is correct because Response Wrapping delivers the SecretID as a single-use wrapped token that the application unwraps exactly once, limiting exposure in logs, CI systems, or transit and reducing the window for theft or replay. Option A is wrong because disabling TLS on the Vault listener exposes all traffic, including AppRole credentials, to interception and is never a security improvement. Option D is wrong because an infinite SecretID TTL means a leaked SecretID remains valid forever, increasing rather than reducing risk. Option E is wrong because sharing one SecretID across replicas removes per-instance attribution and blast-radius control, so compromise of one replica compromises them all.

Answer

Disable TLS on the Vault listener.

Answer

Increase the SecretID TTL to infinity.

Answer

Share the same SecretID across all application replicas.

Question 5

Which TWO of the following are true about AppRole 'SecretID' management?

Accepted Answer

SecretIDs can be constrained by 'num_uses'.. Option B is correct because a SecretID can be created with a 'num_uses' constraint, meaning it is invalidated after a set number of authentication uses, which limits the blast radius if the SecretID leaks. Option D is correct because SecretIDs are issued with a TTL (via 'secret_id_ttl' on the role or an explicit TTL at generation), after which they expire and can no longer be used to authenticate. Option A is wrong because RoleID and SecretID are distinct AppRole credentials: the RoleID identifies the role and is not secret, while the SecretID is the sensitive half of the pair. Option C is wrong because SecretIDs are sensitive credentials and must never be committed in cleartext to version control. Option E is wrong because each SecretID is uniquely generated per application/instance, not shared across all applications in a namespace.

Answer

SecretIDs are synonymous with RoleIDs.

Answer

SecretIDs should be stored in cleartext in version control.

Answer

SecretIDs are the same for all applications in a namespace.

Question 6

Which THREE of the following are potential security risks when using the AppRole method if not configured correctly?

Accepted Answer

Setting 'token_ttl' to 87600h.. Option A is correct because setting 'token_ttl' to 87600h (10 years) means tokens issued via AppRole effectively never expire, so a leaked token remains valid for an extremely long period and cannot be contained by short-lived credential rotation. Option B is correct because without CIDR binding on the SecretID, the SecretID can be used from any network address, so an attacker who obtains it can authenticate to Vault from anywhere instead of being restricted to trusted source IPs. Option E is correct because an unlimited SecretID usage count (e.g., 'secret_id_num_uses=0') lets a single SecretID be replayed indefinitely, so a stolen SecretID can be used repeatedly to obtain new tokens rather than being consumed after its intended uses. Option C is not a risk of AppRole misconfiguration; the Transit secrets engine is a separate feature for encryption-as-a-service and does not affect AppRole authentication security. Option D is also not an AppRole risk; Vault Namespaces are a multi-tenancy isolation feature and do not by themselves introduce an AppRole security weakness.

Answer

Enabling the Transit engine.

Answer

Using Vault Namespaces.

Question 7

Which TWO of the following statements about the 'vault-agent' injector in Kubernetes are correct?

Accepted Answer

It runs as a Kubernetes Mutating Admission Webhook.. Option B is correct because the Vault Agent Injector is implemented as a Kubernetes Mutating Admission Webhook that intercepts pod creation requests and mutates the pod spec to add the vault-agent and vault-agent-init containers along with the necessary annotations. Option C is correct because the injector configures Vault Agent to render secrets into files inside a shared in-memory volume (typically /vault/secrets) mounted into the application container, allowing secrets to be consumed directly as files. Option A is incorrect because the injector is available in both Vault Enterprise and Vault Community (non-Enterprise) editions. Option D is incorrect because injected secrets are still fetched using the pod's Kubernetes service account token via Vault's Kubernetes auth method, so all Vault policies and auth boundaries apply. Option E is incorrect because Vault Agent can run continuously and re-render secrets when they are renewed or rotated, so manual pod restarts are not required for updates.

Answer

It is only available for non-Enterprise versions.

Answer

It bypasses all Vault policies.

Answer

It requires manual pod restarts to update secrets.

Question 8

When designing a secure Vault-Kubernetes Auth integration, which THREE factors must be considered to prevent token compromise?

Accepted Answer

The scope of the service account token.. Option B is correct because the scope of the service account token determines what the Vault Kubernetes auth backend can validate and which namespaces, service accounts, and audiences are trusted; a broadly scoped or overly permissive token increases the blast radius if compromised. Option C is correct because Vault must validate the Kubernetes API server CA when calling the TokenReview API, ensuring it is communicating with the legitimate API server and preventing man-in-the-middle attacks that could forge token validation responses. Option E is correct because the TTL of the Vault token generated limits the window of exposure; shorter TTLs reduce the impact of a stolen Vault token and force periodic re-authentication. Option A is not relevant because the number of nodes in the cluster does not directly affect Vault-Kubernetes auth token compromise. Option D is not relevant because the Kubernetes binary version alone does not determine the security of the Vault auth integration, though supported versions matter for overall cluster security.

Answer

The number of nodes in the cluster.

Answer

The version of the Kubernetes binary.

Question 9

You are configuring a Vault Enterprise cluster to use a hardware security module (HSM) for seal wrapping and auto-unseal. During testing, you notice that after a node restarts, Vault still requires manual unseal despite the HSM being available. You have verified that the HSM is reachable and the seal stanza is correctly configured. Which of the following is the most likely cause?

Accepted Answer

The HSM slot or partition configured in the seal stanza does not contain the key that was used to initialize Vault.. Auto-unseal with an HSM depends on Vault being able to retrieve the correct encryption key from the HSM. If the slot or partition specified in the seal stanza does not contain that key, Vault cannot decrypt the root key, and manual unseal is required. Ensuring the correct slot and key are referenced is critical for successful auto-unseal.

Answer

The HSM key is not marked as exportable, preventing Vault from using it for auto-unseal.

Answer

The seal stanza is missing the 'disabled' parameter set to false.

Answer

The Vault node was started with the '-dev' flag, which disables auto-unseal.

Question 10

A Vault Enterprise administrator is configuring a new auth method to authenticate an on-premises application that cannot present a platform identity. The administrator wants to ensure that the initial authentication can only be performed once per login attempt and that the authentication material is bound to the application's network location. Which AppRole role configuration should the administrator apply to achieve these requirements?

Accepted Answer

Set `secret_id_num_uses=1` and `secret_id_bound_cidrs` to the application's subnet.. The requirement is to limit the SecretID to a single use and restrict it to the application's network. secret_id_num_uses=1 ensures one-time use, and secret_id_bound_cidrs binds the SecretID to specific CIDR blocks. Together they prevent replay and enforce network location. Other parameters like token_num_uses or TTLs do not address the SecretID's usage or binding.

Answer

Set `token_num_uses=1` and `token_bound_cidrs` to the application's subnet.

Answer

Set `secret_id_ttl=1m` and `token_ttl=1m` to force rapid expiration.

Answer

Set `bind_secret_id=false` and rely on `secret_id_bound_cidrs` alone.

Question 11

A Vault Enterprise cluster uses namespaces to isolate teams. An administrator creates a token in the `team-a` namespace with a policy that grants read access to `secret/data/team-a/*`. The administrator then uses this token to read a secret at `secret/data/team-b/config` in the `team-b` namespace. What is the outcome?

Accepted Answer

The read fails because the token is not valid in the `team-b` namespace.. Vault Enterprise namespaces provide strict isolation. A token is bound to the namespace in which it was created and cannot be used to authenticate to another namespace. Therefore, a token from team-a cannot read secrets in team-b, regardless of its policies. The correct outcome is that the read fails because the token is not valid in team-b.

Answer

The read fails because the token's TTL expires when crossing namespace boundaries.

Answer

The read succeeds if the token has a policy that allows `secret/data/*` in the root namespace.

Answer

The read succeeds because the token's policy path is relative to the root namespace.

Question 12

A security team is reviewing the configuration of a Vault Enterprise cluster that uses the Transit secrets engine for encryption as a service. They want to ensure that the encryption keys are protected against unauthorized export and that cryptographic operations are audited. Which two configurations should they implement? (Choose two.)

Accepted Answer

Enable the audit device and configure it to log all requests to the Transit engine.. To protect Transit keys from unauthorized export, the key must be created with exportable=false, which prevents extraction of key material. To audit cryptographic operations, an audit device must be enabled and capturing requests to the Transit engine. These two configurations together ensure key protection and auditability.

Answer

Set `allow_plaintext_backup=true` to enable secure backups of the key.

Answer

Configure the key with `derived=true` to ensure keys are unique per context.

Answer

Use `type=rsa-4096` to ensure strong encryption and prevent export.

Question 13

An administrator is configuring Vault Enterprise to use a hardware security module (HSM) for seal wrapping and auto-unseal. After enabling the HSM, the administrator notices that the Vault cluster fails to start, reporting that the seal wrap key cannot be retrieved. Which configuration step is most likely missing?

Accepted Answer

The `seal` stanza in the Vault configuration file does not include the correct `key_label` for the seal wrap key.. When using an HSM for seal wrapping, Vault must be configured with the correct key_label in the seal stanza to locate the seal wrap key. If the key_label is missing or incorrect, Vault cannot retrieve the key and fails to start. Other HSM-related issues like PIN or firmware would produce different errors.

Answer

The HSM slot PIN was not provided to Vault via the `VAULT_HSM_PIN` environment variable.

Answer

The HSM firmware version is incompatible with Vault's PKCS#11 library.

Answer

The `disable_mlock` option is set to true, preventing Vault from accessing the HSM.

Question 14

An administrator is configuring Vault Enterprise to use a hardware security module (HSM) for auto-unseal. The HSM supports PKCS#11. After configuring the seal stanza, Vault fails to start. Which action should the administrator take to troubleshoot the issue?

Accepted Answer

Check the Vault server logs for errors related to the HSM connection and verify the PKCS#11 library path.. The most effective troubleshooting step is to review Vault's server logs, which will contain specific error messages about the HSM connection, such as a missing PKCS#11 library or authentication failure. Verifying the library path and credentials directly addresses common misconfigurations. The other options are either too broad or do not target the root cause.

Answer

Reinstall the HSM firmware to ensure compatibility with Vault.

Answer

Increase the Vault server's memory allocation to accommodate the HSM library.

Answer

Disable the HSM seal and use Shamir seals instead to verify Vault can start.

Question 15

A Vault Enterprise operator has just enabled the Transit secrets engine in a namespace dedicated to a payment processing team. The team stores encryption keys in Transit and uses them to encrypt customer credit card data before writing it to an external database. An auditor asks the operator to prove that the plaintext of those credit card numbers never leaves the Vault server. Which property of the Transit secrets engine supports this claim?

Accepted Answer

Transit performs cryptographic operations inside Vault's barrier and returns only ciphertext, so plaintext submitted for encryption is never persisted or returned to callers.. Transit is a cryptographic service: callers send plaintext, Vault returns ciphertext, and no plaintext is persisted. This directly satisfies the auditor's requirement that credit card plaintext never leaves the Vault server. Options that describe storing plaintext on disk or in the barrier describe architectures that do not exist and would undermine the compliance guarantee the team needs.

Answer

Transit stores each plaintext alongside its ciphertext in the barrier so that decryption can be audited against the original input.

Answer

Transit encrypts plaintext only after it has been written to a write-ahead log, ensuring recoverability but leaving a transient plaintext copy on disk.

Answer

Transit uses the storage backend's encryption-at-rest to protect plaintext, so plaintext is stored but remains unreadable without the unseal keys.