Compare authentication methods →hardMultiple Choice

VA-003 Compare authentication methods Practice Question

A consulting firm deploys Vault to multiple tenants. Each tenant uses the OIDC auth method with its own identity provider, but the security team observes that users from one tenant occasionally receive policies intended for another tenant. The OIDC mounts were configured separately, and each uses a distinct default_role. Which configuration issue most likely explains the cross-tenant policy assignment?

⚠ Common exam trap

The trap here is assuming that separate OIDC mounts provide complete tenant isolation, when identity group aliases derived from claims are actually shared across mounts within the same namespace.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The user_claim and groups_claim settings on each role resolve to values that collide across tenants, and Vault maps them to the same external group aliases.

Identity group aliases created from OIDC group claims are stored on the identity backend and are not isolated per auth mount. When claim values coincide across tenants, Vault treats them as the same external group and attaches that group's policies to all matching users. Auditing the user_claim and groups_claim values, and namespacing alias names, resolves the collision.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The user_claim and groups_claim settings on each role resolve to values that collide across tenants, and Vault maps them to the same external group aliases.
Why this is correct
When OIDC roles map group claims to external groups, Vault creates group aliases on the identity backend. If two tenants produce the same claim value, the alias collides and the group's policies are applied to users from both tenants. Distinct mounts and default roles do not prevent this, because the identity group alias is global to the namespace rather than scoped to the auth mount.
✗
Each OIDC mount uses the same bound_issuer value, so tokens from either provider are treated as originating from a single issuer.
Why it's wrong here
bound_issuer pins the expected iss claim for tokens validated by a given role. If both mounts used the same bound_issuer, tokens from the mismatched provider would fail validation entirely, producing login errors rather than successful logins with incorrect policies. The observed behavior shows logins succeeding, so issuer confusion is not the cause.
✗
The OIDC discovery URL for one tenant was entered with a trailing slash, causing claim parsing to fall back to defaults.
Why it's wrong here
A malformed discovery URL typically causes the OIDC configuration or role creation to fail with a validation error rather than silently misassign policies. Vault fetches the provider metadata at configuration time and rejects unreachable or invalid endpoints. Claim parsing does not fall back to defaults based on URL formatting, so this cannot explain cross-tenant policy leakage.
✗
The OIDC role's bound_audiences value includes an audience shared by both identity providers.
Why it's wrong here
bound_audiences restricts which aud claims are acceptable during token validation. A shared audience would allow a token from one provider to be accepted by the other mount, but it would not by itself cause the wrong policies to be attached, because policies come from the role definition and group mappings. The symptom described is policy assignment, not token rejection or acceptance.

Visual reference

Go deeper

VA-003 Compare authentication methods Practice Question

Why each option matters

Option-by-option breakdown

Related to this question