Vault Security Model practice questions

Set the 'allowed_namespaces' policy on the service account.

Why it fails: Vault's Kubernetes auth role has no 'allowed_namespaces' parameter; namespace restriction is enforced through bound_service_account_namespaces on the role. It is tempting because scoping a service account sounds like the natural place for namespace limits, but policies attached to the account cannot constrain which namespace authenticates.

Apply a Vault namespace to the Kubernetes pod manifest.

Why it fails: Vault namespaces partition Vault's own API and storage, not Kubernetes pod metadata, so they cannot match pod namespace claims. The role's bound_service_account_namespaces parameter performs that restriction. Vault namespaces would be correct when isolating teams' secrets and policies within a single Vault cluster.

Use a regex in the 'token_policies' field to filter by namespace.

Why it fails: token_policies lists Vault policies to attach after login; it does not filter authentication by namespace, so any pod could still authenticate. It is tempting because regex matching appears elsewhere in Vault, but namespace binding belongs in bound_service_account_namespaces on the role.

vault.hashicorp.com/auto-renew: 'true'

Why it fails: This is not a valid annotation.

vault.hashicorp.com/token-renewal: 'enabled'

Why it fails: This is not the correct annotation syntax.

vault.hashicorp.com/k8s-auth: 'true'

Why it fails: This enables auth but doesn't specifically trigger the agent process.

The Kubernetes node's SSH private key.

Why it fails: Vault authenticates to the Kubernetes API using a service account token and CA certificate, never SSH keys; SSH access to nodes is unrelated. It is tempting because administrators already hold node SSH keys for maintenance, but the auth method communicates over HTTPS to the API server.

A list of all pod IP addresses.

Why it fails: Vault validates service account tokens against the Kubernetes TokenReview API; pod IPs are irrelevant because authentication is token-based, not network-based. It is tempting when teams assume IP allowlisting secures the integration, but pod addresses are ephemeral and never verified by the auth method.

A token created in a child namespace can be used to access secrets in the parent namespace if the parent namespace's policies allow it.

Why it fails: Tokens are downward-scoped: a token from a child namespace cannot be used to access the parent namespace. The parent namespace is outside the token's scope. Even if the parent namespace's policies would allow the action, the token itself is not valid in the parent namespace, so access is denied.

Namespace isolation can be bypassed by using a token with the 'sudo' capability on the 'sys/namespaces' path.

Why it fails: The 'sudo' capability allows privileged operations within a namespace, but it does not bypass namespace boundaries. Accessing another namespace requires authentication within that namespace or using a token that has been explicitly granted access via namespace paths. The 'sudo' capability does not override namespace isolation.

A root token in a parent namespace can access all child namespaces without additional policies.

Why it fails: Root tokens are powerful within their own namespace but do not automatically grant access to child namespaces. To access child namespaces, the root token must be used with the appropriate namespace path, and the child namespace may require its own authentication. Root tokens are not superuser across all namespaces by default.

The Vault node is not able to reach the KMS endpoint due to network restrictions.

Why it fails: If the KMS endpoint were unreachable, Vault would log connection errors rather than decryption failures. The error specifically mentions inability to decrypt the root key, which points to a key mismatch or permission issue on the KMS side, not network connectivity.

The KMS key used for auto-unseal was rotated without updating the seal stanza.

Why it fails: Rotating the KMS key does not necessarily prevent auto-unseal if the seal stanza references the key by alias or ID and the KMS maintains old key versions for decryption. However, if the key is deleted or the alias changed, auto-unseal could fail. But this is less likely than a mismatch in key configuration during initial setup.

The KMS key policy does not grant the Vault service account the 'encrypt' permission.

Why it fails: The 'encrypt' permission is not required for auto-unseal; Vault needs 'decrypt' permission to unwrap the root key. The 'encrypt' permission is used during initialization to wrap the root key. At startup, Vault only decrypts, so a missing 'encrypt' permission would not cause this failure.

explicit_max_ttl

Why it fails: explicit_max_ttl sets a hard maximum lifetime for the token, but it does not enforce expiration based on continuous use. It caps the total lifespan regardless of activity, which could expire the token prematurely if the job runs longer than 30 minutes without renewal. This does not meet the requirement of expiring after 30 minutes of continuous use.

period

Why it fails: period creates a periodic token that can be renewed indefinitely as long as it is renewed before its period expires. This would not cause the token to expire after 30 minutes of continuous use; instead, it would allow the token to persist as long as it is renewed. This contradicts the requirement for automatic expiration.

num_uses

Why it fails: num_uses limits the number of times a token can be used, not its duration. Setting num_uses would restrict the token based on usage count, not time. This does not enforce expiration after 30 minutes of continuous use, and the token could expire earlier or later depending on usage frequency.

Tokens are global and can access any namespace if the policy allows.

Why it fails: Tokens in Vault Enterprise are not global; they are scoped to the namespace in which they are created. A token from the 'engineering' namespace cannot access resources in the 'finance' namespace, regardless of policy, because namespace boundaries are enforced at the token level. This statement is incorrect.

Tokens can access child namespaces but not sibling or parent namespaces.

Why it fails: Tokens are not automatically granted access to child namespaces. While administrative tokens in a parent namespace can manage child namespaces, a regular token created in a namespace does not have implicit access to child namespaces. Access to child namespaces requires specific policies and is not inherent to the token's scope.

Tokens can be used across namespaces only if they have a policy with a wildcard path.

Why it fails: Policies do not override namespace isolation. Even with a wildcard path, a token from one namespace cannot access another namespace's secrets. The namespace boundary is enforced independently of policies. This statement misrepresents how Vault Enterprise isolates namespaces.

Response wrapping requires the client to have a policy that allows unwrapping.

Why it fails: Unwrapping a token does not require any special policy; the wrapped token itself is the authorization to unwrap. The client simply uses the wrapped token to call the unwrap endpoint. No additional policy is needed because the token is self-contained and its only capability is to unwrap the response.

The wrapped token can be unwrapped multiple times if the wrapping TTL is long enough.

Why it fails: Response wrapping is designed for single-use by default; the token is revoked after the first unwrap. While there is a feature to allow multiple unwraps by setting a higher num_uses during wrapping, it is not the default behavior and is not recommended for secure secret distribution. The statement incorrectly implies that multiple unwraps are standard.

The wrapped token can be used to access any secrets that the original token could access.

Why it fails: A wrapped token does not grant access to secrets directly; it is only used to unwrap the response. It does not carry the policies of the original token. Attempting to use the wrapped token for other operations will fail. Its sole purpose is to retrieve the wrapped data, which typically contains a secret or a new token with specific policies.

The HSM's key label does not match the 'key_label' specified in the seal stanza.

Why it fails: A mismatched key label would likely cause errors during seal wrapping or unseal operations, not just prevent auto-unseal. If the key label is incorrect, Vault may fail to initialize or unseal at all. This is not the specific cause of seal wrapping working but auto-unseal not working.

The HSM's seal wrapping key is not marked as exportable.

Why it fails: Exportability of the seal wrapping key is not required for auto-unseal. Seal wrapping keys are typically non-exportable for security, and Vault uses the HSM to perform wrap/unwrap operations without exporting the key. This setting does not affect whether auto-unseal functions.

The 'disable_mlock' option is set to true in the Vault configuration.

Why it fails: The 'disable_mlock' option controls whether Vault locks memory to prevent swapping. It has no effect on auto-unseal behavior. Setting it to true may be required in some environments but does not cause manual unseal to be necessary when HSM auto-unseal is configured.

Child tokens are not automatically revoked when the parent token is revoked.

Why it fails: Revoking a parent token does revoke all child tokens by default. Vault maintains a token hierarchy, and when a parent is revoked, its children are revoked as well. This is a core security feature to prevent orphaned tokens from retaining access.

The child token was created with a longer TTL than the root token, so it outlives the parent.

Why it fails: Token TTL does not affect revocation propagation. Even if a child token has a longer TTL, revoking the parent token immediately revokes all child tokens regardless of their TTL. TTL only determines when a token expires on its own, not whether it survives parent revocation.

The secrets engine was mounted with the 'delegated' option, granting persistent access.

Why it fails: The 'delegated' option is not a standard Vault feature for secrets engines. Mounts do not grant persistent access independent of token revocation. Access is controlled by policies attached to tokens, and revoking the parent token would revoke child tokens unless they are orphaned.

token_num_uses=10 and token_max_ttl=24h

Why it fails: token_num_uses=10 correctly limits the token to 10 uses. However, token_max_ttl sets the maximum TTL for the token, but it does not make the token renewable. To allow renewal up to 24 hours, you need token_ttl and token_max_ttl together. Setting only token_max_ttl without token_ttl may result in a token that cannot be renewed, or renewal behavior depends on other settings. Thus, this combination does not fully enforce the requirement of renewable up to 24 hours.

token_num_uses=10 and token_ttl=24h

Why it fails: token_num_uses=10 limits uses correctly. token_ttl=24h sets the initial TTL to 24 hours, but without a token_max_ttl, the token could potentially be renewed indefinitely, exceeding the 24-hour maximum. The requirement is a maximum TTL of 24 hours, meaning the token should not be renewable beyond that. Therefore, this combination fails to enforce the maximum TTL constraint.

token_num_uses=10 and token_period=24h

Why it fails: token_period=24h creates a periodic token that can be renewed indefinitely as long as it is renewed before each period ends. This does not enforce a maximum TTL of 24 hours; the token could live forever if renewed. The requirement is a maximum TTL, not a periodic token. Therefore, this combination is incorrect because it does not cap the total lifetime at 24 hours.

Enable the Transit secrets engine's 'convergent encryption' mode to ensure that identical plaintexts produce the same ciphertext.

Why it fails: Convergent encryption is a feature that allows identical plaintexts to produce the same ciphertext, which can be useful for searching encrypted data. However, it can weaken security because it reveals when two plaintexts are identical. The requirement is to protect against unauthorized access and audit operations, not to enable a feature that may reduce security. Therefore, enabling convergent encryption does not enhance security in this context and may be counterproductive.

Configure the Transit secrets engine to use a customer-supplied encryption key (BYOK) stored in an HSM.

Why it fails: While using an HSM for key storage can enhance security, Vault's Transit secrets engine does not support customer-supplied encryption keys (BYOK) in the sense of providing your own key material for encryption. Vault manages the keys internally, and they are protected by Vault's seal mechanism. The Transit engine does support key import in some cases, but that is not the same as BYOK for encryption. Therefore, this action is not applicable or supported as described.

Set the Transit secrets engine to use a longer key length, such as 4096-bit RSA keys, for all encryption operations.

Why it fails: The Transit secrets engine supports symmetric keys like AES-256-GCM and asymmetric keys like RSA and ECDSA. However, the scenario does not specify the type of data or the need for asymmetric encryption. Simply using a longer key length does not inherently enhance security if the algorithm is not appropriate or if key management is poor. Moreover, Transit's default symmetric keys are already strong. The key requirement is access control and auditing, not key length. Therefore, this action is not the best choice.

token_explicit_max_ttl

Why it fails: token_explicit_max_ttl sets an explicit maximum TTL that cannot be overridden by the client, but it is used when you want a hard limit that even the token's own max_ttl cannot exceed. However, in the context of an auth method role, token_max_ttl is the standard parameter to set the maximum TTL. token_explicit_max_ttl is more common for token creation directly, not for auth method roles.

token_period

Why it fails: token_period is used for periodic tokens, which can be renewed indefinitely as long as the period is valid. Setting a period would actually allow tokens to live longer than 24 hours if renewed, which is the opposite of the requirement. It does not enforce a maximum lifetime.

token_ttl

Why it fails: token_ttl sets the initial TTL for tokens issued by the role, but it does not enforce a maximum lifetime. Tokens can be renewed up to token_max_ttl. Setting only token_ttl would not prevent tokens from being renewed beyond 24 hours if token_max_ttl is higher.

path "secret/data/dev/*" { capabilities = ["read", "list"] }

Why it fails: This statement adds the 'list' capability, which allows listing keys under the path. While listing does not allow modification or deletion, it is not strictly necessary for the requirement. The requirement is to allow reading secrets and prevent deletion or modification. Adding 'list' does not violate the requirement, but it is not the most precise answer because it grants an additional permission that was not requested. However, the key issue is that it still does not allow deletion or modification, so it is not wrong per se, but the question asks for the statement that correctly achieves the requirement, and this one includes an extra capability that is not needed.

path "secret/data/dev/*" { capabilities = ["read", "delete"] }

Why it fails: This statement includes the 'delete' capability, which allows deleting secrets at the specified path. This directly violates the requirement to prevent deletion. Even though it also allows read, the inclusion of delete makes it incorrect. The policy would permit developers to remove secrets, which is not allowed.

path "secret/data/dev/*" { capabilities = ["read", "update"] }

Why it fails: This statement includes the 'update' capability, which allows modifying existing secrets. This violates the requirement to prevent modification. The 'update' capability also typically allows creation of new secrets. Therefore, this policy would allow developers to change secrets, which is explicitly forbidden. Thus, it does not meet the requirement.

Set the 'namespace' parameter on the token role to restrict token creation to the namespace.

Why it fails: There is no 'namespace' parameter on token roles. Namespaces are separate logical environments, and token creation is inherently scoped to the namespace in which it occurs. You cannot set a namespace parameter on a token role to restrict creation; it is not a valid configuration option.

Ensure that the team's tokens are created with the 'no_parent' option to prevent cross-namespace access.

Why it fails: The 'no_parent' option creates orphan tokens but does not affect cross-namespace access. Orphan tokens still reside within the namespace and are subject to namespace boundaries. This option is unrelated to namespace isolation and does not prevent access to other namespaces.

Enable the 'isolated' flag on the namespace to block all cross-namespace communication.

Why it fails: Vault Enterprise does not have an 'isolated' flag for namespaces. Namespace isolation is achieved through policy design and token scoping, not a simple flag. While namespaces provide logical separation, they do not automatically block all cross-namespace communication unless policies are configured correctly.

The performance replication secondary is in a failed state and is not receiving updates from the primary.

Why it fails: While a failed replication state could cause data not to sync, it is not the most likely reason in a typical scenario. If the secondary were failed, other data would also be missing, and the administrator would likely see replication status errors. The question does not indicate a failure, so this is less likely than a configuration issue.

Namespaces and policies are not replicated to performance secondary clusters; they must be created manually on each secondary.

Why it fails: This is incorrect because Vault Enterprise performance replication does replicate namespaces and policies from the primary to secondary clusters. The replication is designed to keep configuration and data in sync. Manual creation is not required. The absence of the namespace and policy suggests another issue, such as replication lag or a filtering rule.

The secondary cluster has a different license that does not support namespaces, so it cannot replicate them.

Why it fails: Vault Enterprise requires a license that supports namespaces for both primary and secondary clusters. If the secondary did not support namespaces, it would not be able to function as a performance secondary for a cluster using namespaces. The license would typically be the same across the replication set. Therefore, this is not a likely reason.

Restricts the Kubernetes API server access.

Why it fails: The parameter constrains the client IP addresses permitted to authenticate and use the token, not the Kubernetes API server's own access controls. It tempts because the auth method integrates with Kubernetes, yet it would be correct only if the goal were restricting API server traffic rather than Vault token usage.

Binds the login process to a specific pod IP.

Why it fails: token_bound_cidrs binds the token to source CIDR ranges, not to a pod's individual IP address. It tempts because Kubernetes auth validates service account tokens from pods, but it would be the right control only if you needed to pin a token to one specific pod's address.

Limits the number of simultaneous logins from an IP.

Why it fails: token_bound_cidrs restricts which source CIDR blocks may use a token issued by that role, an authorisation constraint on token use. It does not throttle concurrent logins; rate limiting is handled by Vault's request limiter or external controls.

Use a global static token for all AppRole authentications.

Why it fails: A global static token is shared across all AppRole authentications, so its compromise grants access to every role and cannot be bound to a single client. Static tokens suit short-lived bootstrap or break-glass tasks, not per-client secret introduction.

Hardcode the SecretID into the application's configuration file.

Why it fails: Hardcoding the SecretID into the configuration file exposes a long-lived credential to anyone reading the file or its backups, defeating the periodic-fetch design. Hardcoding suits throwaway lab testing, whereas production requires a short-lived, response-wrapped SecretID delivered out of band.

Disable the SecretID requirement and use only the RoleID.

Why it fails: Disabling the SecretID requirement reduces AppRole to RoleID-only authentication, so possession of the RoleID alone authenticates the client and the second secret factor is lost. SecretID-less mode suits trusted, isolated environments, not secure client introduction.

The pod's hostname.

Why it fails: The hostname is not a signed token and carries no claims, so Vault's Kubernetes auth method cannot validate it. The CLI reads the pod's projected service account JWT from its mounted path and sends that. Hostname would be relevant for identifying a node, not for authenticating a pod.

The Vault server's Root CA certificate.

Why it fails: A Root CA certificate is a trust anchor for verifying TLS, not a bearer credential, so Vault cannot authenticate with it. The Kubernetes auth method requires the pod's projected service account JWT. The CA certificate would be the right input when configuring a client to trust Vault's listener.

The Kubernetes API server public key.

Why it fails: The Kubernetes auth method expects a signed service account JWT; a public key cannot serve as that token and is instead used by Vault to verify signatures. The pod's projected service account token is what the CLI reads and submits. The API server key would matter when configuring Vault's token reviewer validation.

LDAP bind credentials.

Why it fails: LDAP bind credentials are a secrets engine that generates short-lived directory passwords; they do not introduce a Vault token to a new VM. It is tempting because it is an auth-adjacent secrets engine, but the secure introduction feature is response wrapping, which delivers a wrapped token the VM unwraps via the cubbyhole.

Cubbyhole storage.

Why it fails: Cubbyhole storage is a per-token private secret store that dies with its token, so it cannot deliver a token to a machine that does not yet hold one. It is tempting because it is used for wrapping, but the feature designed for secure introduction is response wrapping, which delivers a single-use wrapped token.

Transit Secret Engine.

Why it fails: The transit secrets engine provides encryption-as-a-service, encrypting and decrypting data without storing it; it does not issue or deliver Vault tokens. It is tempting because it secures data in dynamic infrastructure, but secure introduction requires response wrapping, which hands the new VM a single-use wrapped token.