Hard Difficulty Questions

The secondary cluster is forwarding token creation requests to the primary for signing, causing cross-region latency.

Why it fails: In Performance Replication, token creation can be handled locally on the secondary because the token signing keys are replicated. Forwarding to the primary would only occur for operations that require the primary, such as certain writes to replicated mounts. Token creation is a local operation, so this is not the cause of increased latency.

The secondary cluster is performing a local token creation but must wait for the primary to acknowledge the write to the token store before returning.

Why it fails: Performance Replication allows secondaries to handle token creation locally without waiting for primary acknowledgment. The token store is replicated, and secondaries can issue tokens independently. Waiting for primary acknowledgment would defeat the purpose of performance replication, which is to offload read and some write operations to secondaries.

The secondary cluster's integrated storage is experiencing high disk I/O due to replication of audit logs from the primary.

Why it fails: Audit logs are not replicated between primary and secondary clusters in Performance Replication. Audit logging is configured per cluster and writes to local storage. Therefore, replication of audit logs is not a factor, and disk I/O from audit logs would be local to each cluster's own audit configuration, not a result of replication.

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.

Create an identity entity for each pod and attach the policy directly to the entity.

Why it fails: Creating individual identity entities for each pod is not scalable and not required. The Kubernetes auth method automatically creates entities and aliases based on the service account and namespace. Policies are attached via the auth role, not directly to entities. This approach would be cumbersome and does not leverage the built-in identity mapping of the auth method.

Attach a Sentinel EGP to the Kubernetes auth method's login path to check the service account annotations.

Why it fails: While Sentinel EGPs can inspect request data, the Kubernetes auth method's login path receives the service account token, not the annotations directly. The annotations are part of the pod's metadata, which is not passed in the login request. Therefore, an EGP cannot enforce annotation-based restrictions at the login endpoint. This step is not required and would not achieve the goal.

Use a token role to limit the TTL of tokens issued to pods based on their service account annotations.

Why it fails: Token roles are used to define parameters for tokens created via the token auth method, not for tokens issued by other auth methods like Kubernetes. The Kubernetes auth method has its own role configuration that includes token TTL settings. Token roles cannot be used to enforce conditions based on service account annotations. This step is not applicable.

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.

Set the 'groupattr' parameter to 'memberOf' and configure the LDAP auth method with 'use_token_groups=true' and 'transitive_groups=true'.

Why it fails: Vault's LDAP auth method does not have a 'transitive_groups' parameter. While 'use_token_groups' can help with nested groups by using the tokenGroups attribute, there is no 'transitive_groups' option. This configuration would be invalid because the parameter does not exist, and the auth method would fail to configure or would ignore the unknown parameter, leaving nested group resolution unresolved.

Configure the LDAP auth method with 'discoverdn=true' and 'groupfilter' set to '(memberOf=cn=Engineering,ou=groups,dc=example,dc=com)'.

Why it fails: Setting 'discoverdn=true' allows Vault to discover the user's DN via anonymous bind, and a specific groupfilter for 'Engineering' would only match that group, not nested groups. This would not automatically include the 'AllEmployees' group policies. Moreover, a static groupfilter is not dynamic and would not resolve nested memberships; it would only find users directly matching the filter. This approach fails to address the nested group requirement.

Set the 'groupattr' parameter to 'memberOf' and enable 'use_token_groups' to true.

Why it fails: Setting 'groupattr' to 'memberOf' and enabling 'use_token_groups' allows Vault to use the tokenGroups attribute for group membership, which includes nested groups. However, 'use_token_groups' is a parameter that, when true, uses the 'tokenGroups' attribute on the user object to determine group membership. This can resolve nested groups, but it requires that the LDAP bind account has permissions to read the tokenGroups attribute, and it may not work in all directory configurations. It is not the most direct or supported method for nested group resolution in Vault's LDAP auth method.

Promote the performance secondary to a primary cluster using the `vault operator raft snapshot restore` command.

Why it fails: The `vault operator raft snapshot restore` command is used to restore a Raft snapshot, not to promote a secondary to primary. Promotion of a performance secondary to primary is done via the `vault operator promote` command (or through the UI/API). Using snapshot restore would overwrite the secondary's data and is not the correct procedure for promotion.

Enable `dr_replication` on the performance secondary to allow it to accept writes during a primary outage.

Why it fails: Performance replication secondaries are read-only; they cannot accept writes unless promoted to primary. DR replication is a separate feature that provides a standby cluster for disaster recovery, but it does not allow a performance secondary to accept writes. Enabling DR replication on a performance secondary is not a supported configuration for write availability.

Set the `replication_primary` flag on the secondary to force it to accept writes immediately.

Why it fails: There is no `replication_primary` flag that forces a performance secondary to accept writes. Promotion to primary is a deliberate operation using the `vault operator promote` command. Setting arbitrary flags is not a valid method and could lead to data corruption or split-brain scenarios if attempted.

Disable replication for the entire secondary cluster and use a separate backup mechanism for other data.

Why it fails: Disabling replication for the secondary cluster would stop all data replication, not just the sensitive secrets. This defeats the purpose of performance replication and would require an alternative method to replicate non-sensitive data, which is inefficient and not the intended solution for filtering specific secrets.

Set the 'replication_deny' parameter on the secondary cluster for the mount paths of the sensitive secrets.

Why it fails: The 'replication_deny' parameter does not exist in Vault Enterprise. Replication filtering is configured on the primary cluster, not on the secondary. Setting a non-existent parameter on the secondary will not prevent replication of data and is not a valid method to exclude secrets.

Manually delete the sensitive secrets from the secondary cluster after replication occurs.

Why it fails: Manually deleting secrets on the secondary does not prevent replication; the primary will re-replicate the secrets in subsequent operations, and deletions may be overwritten. This approach is not reliable, does not enforce a policy, and could lead to data inconsistencies or accidental exposure if replication is not filtered.

The Performance Standby nodes are forwarding all read requests to the active node due to a misconfiguration.

Why it fails: Performance Standby nodes are designed to serve reads locally. If they were forwarding all reads, the active node's CPU would be high, but this would not cause 500 errors unless the active node is overwhelmed. However, the scenario suggests the active node is already using significant CPU, which could be due to other factors. Misconfiguration of read forwarding is not a standard behavior.

The secondary cluster's license is invalid, causing it to throttle performance.

Why it fails: An invalid license would typically cause Vault to enter a restricted mode or stop serving requests entirely, not just intermittent 500 errors under load. Licensing issues are usually logged clearly and do not manifest as CPU-related performance problems. This is not a likely cause.

The Performance Standby nodes are not properly joined to the Raft cluster, causing the active node to handle all reads.

Why it fails: If Performance Standby nodes were not joined, they would not be able to serve reads, and all reads would go to the active node, increasing its CPU. However, the scenario states there are three Performance Standby nodes, implying they are configured. Even if they were not joined, the issue would be a lack of read offloading, but the active node's CPU being high due to replication is more directly related to the described symptoms.

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.

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.

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.

Create a Sentinel EGP policy that denies access unless two approvals are present.

Why it fails: While Sentinel EGP policies can enforce custom logic, control groups are a native Vault feature and do not require Sentinel. Using Sentinel would be an alternative approach, but it is not a necessary step for configuring a control group. The question specifically asks for control group configuration, not Sentinel policies.

Enable the control group feature in the Vault Enterprise license.

Why it fails: Control groups are a built-in feature of Vault Enterprise and do not require a separate license enablement step. The feature is available once Vault Enterprise is installed and licensed. No additional activation is needed beyond configuration.

Configure an identity alias for each member of the security team to map to the 'security-team' group.

Why it fails: Identity aliases are used to map external identities to Vault entities, but the requirement is to reference an existing identity group. The group 'security-team' must already exist and contain the appropriate members. Creating aliases is not a step specific to control group configuration; it is part of identity management that would be done beforehand.

The policy is not effective because the secret engine at 'secret/data/finance' is not replicated to the secondary.

Why it fails: Secret engines and their data are replicated in Performance Replication if they are mounted in the primary and replication is enabled. The question states the user is trying to read a secret; if the secret engine were not replicated, the path would not exist, but the error is permission denied, not path not found. So this is not the cause.

The auth method role in the secondary is not associated with the correct policy because role configurations are not replicated.

Why it fails: Auth method roles are replicated from primary to secondary. The administrator confirmed that the role is replicated. Therefore, the role should have the policy attached. The failure is not due to role replication but possibly due to how the token's policies are evaluated in the secondary, such as missing entity aliases or namespace differences.

The policy was created in the primary but not replicated to the secondary because policies are not replicated in Performance Replication.

Why it fails: ACL policies are replicated from primary to secondary in Performance Replication. The administrator verified that the policy exists in the secondary, so replication is not the issue. The problem lies elsewhere, likely in token association or entity mapping. This option contradicts the given verification.

Generate a new seal wrap key on the new HSM and update the seal stanza to reference it.

Why it fails: Generating a new key would not decrypt data encrypted with the original key. Seal Wrap uses the HSM key to protect the Vault master key and other sensitive material; a new key cannot unwrap data wrapped with a different key. The original key must be preserved or migrated.

Disable Seal Wrap on the new cluster before restoring the snapshot.

Why it fails: Disabling Seal Wrap does not decrypt existing wrapped data. The snapshot contains data encrypted with the original HSM key; without that key, the data cannot be read. Disabling Seal Wrap only affects future operations and does not provide the necessary decryption key.

Restore the snapshot and then rekey Vault using the new HSM's key.

Why it fails: Rekeying Vault changes the master key but does not address the seal wrap encryption applied to stored data. The wrapped data still requires the original HSM key to be unwrapped. Rekeying after restore would not make the data accessible without the original key.

`pin` — the user PIN to authenticate to the HSM token.

Why it fails: The `pin` parameter is used to authenticate to the HSM token, but it is not strictly required in the seal stanza if the HSM is configured for passwordless or externally authenticated access. In many deployments the PIN is supplied via an environment variable or a separate file. Therefore, while often used, it is not a mandatory configuration element for PKCS#11 auto-unseal.

`slot` — the numeric slot ID where the HSM token is inserted.

Why it fails: The `slot` parameter is optional in the PKCS#11 seal stanza. Vault can discover the correct slot by using the token label or by scanning available slots. While specifying a slot can be useful in multi-slot HSM configurations, it is not a required parameter. The mandatory elements are the library path and the key identifier.

`mechanism` — the cryptographic mechanism Vault should use for wrapping.

Why it fails: The `mechanism` parameter is optional. Vault defaults to a suitable mechanism such as `CKM_AES_GCM` or `CKM_RSA_PKCS_OAEP` depending on the key type. Administrators can override it, but it is not required for basic PKCS#11 auto-unseal configuration. The essential parameters are the library path and the key label.

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

Why it fails: Vault does not automatically fall back to Shamir unseal when the HSM is unavailable or authentication fails. The seal type is fixed in the configuration. If the PKCS#11 seal cannot authenticate, Vault remains sealed and reports an error; it does not switch to a different unseal mechanism without reconfiguration and reinitialization.

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

Why it fails: Vault does not cache the PIN in memory for later use; it authenticates to the HSM at startup and during unseal operations. After a PIN rotation, the old PIN will no longer be accepted by the HSM partition, so subsequent unseal attempts will fail. This option incorrectly assumes the PIN is only needed once.

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

Why it fails: Seal wrap operations also require an authenticated HSM session. Once the PIN is rotated, any operation that needs the HSM, including seal wrap, will fail because Vault cannot log in to the token. There is no grace period tied to key rotation; the old PIN is invalid immediately after the change.

Sentinel RGP (Role Governing Policy) attached to the auth method's role in the child namespace.

Why it fails: Role Governing Policies (RGPs) are attached to tokens via roles, such as in the token auth method or other auth methods, and they apply globally to the token's requests. They cannot be scoped to a specific secrets engine path in a child namespace. While an RGP could enforce conditions based on entity alias, it would affect all requests made with that token, not just those to the specific secrets engine path.

A policy in the root namespace that uses the 'path' parameter with a wildcard to match the child namespace's secrets engine, combined with a condition on the entity alias.

Why it fails: Vault ACL policies do not support conditional logic based on entity aliases. The 'path' parameter in policies does not allow filtering by entity alias or other token metadata. While you can write a policy that grants access to a path in a child namespace, you cannot enforce the condition that the token must have a specific entity alias using standard ACL policies.

Identity groups in the root namespace that include entities from the child namespace's auth method, with a policy attached that grants access to the child namespace's secrets engine.

Why it fails: Identity groups can be used to grant policies based on group membership, but they do not provide path-specific conditional access. Once a token is a member of a group, the group's policies apply to all requests that the token makes, not just to a specific secrets engine path. There is no mechanism in identity groups to restrict access to a particular path based on the token's entity alias.

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.

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.