Compare authentication methods →hardMultiple Select

VA-003 Compare authentication methods Practice Question

Which THREE of the following are true statements about the AppRole authentication method? (Choose three.)

⚠ Common exam trap

HashiCorp often tests the misconception that the Secret ID is inherently single-use, when in fact its usage count is configurable via the `secret_id_num_uses` parameter, and by default it has unlimited uses.

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

✓

Vault can generate a wrapped Secret ID for secure delivery

Option B is correct because Vault's AppRole auth method supports response wrapping: the Secret ID can be returned as a wrapped response, and the single-use wrapping token is delivered to the target application so the Secret ID is never exposed in plaintext in transit. Option C is correct because a Secret ID can have CIDR bindings (secret_id_bound_cidrs) that restrict the source IP addresses allowed to use that Secret ID during login, adding a network-layer constraint. Option D is correct because the Role ID is a non-secret, stable identifier that the application presents at login, functioning much like a username, while the Secret ID acts as the corresponding secret credential. Option A is not correct because token policies are attached to the AppRole role/token, not embedded in the Secret ID itself; the Secret ID is just a credential value. Option E is not correct because a Secret ID is not inherently single-use — it can be used multiple times unless it is created with the single-use property (e.g., via secret_id_num_uses) or is a wrapped response token, which is single-use.

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 Secret ID contains the token policies
Why it's wrong here
Policies attach to the token issued after login, not to the Secret ID, which is merely a credential half of the RoleID/SecretID pair. It is tempting because AppRole does bind policies, but that binding occurs on the role and token, not the Secret ID itself.
✓
Vault can generate a wrapped Secret ID for secure delivery
Why this is correct
Response wrapping lets Vault issue a single-use token carrying the Secret ID, so the credential is never exposed in transit or logs. This satisfies the stem's secure-delivery requirement: the wrapping token can be unwrapped only once, by the intended role, before the Secret ID is revealed.
✓
CIDR bindings can restrict which IP addresses can use the Secret ID
Why this is correct
CIDR bindings on the Secret ID restrict which source IP addresses may redeem it, satisfying the stem's requirement for a true AppRole statement. This is a genuine AppRole capability: the secret_id_bound_cidrs parameter limits use to specified network ranges, adding a network-layer constraint independent of the Role ID.
✓
The Role ID is analogous to a username
Why this is correct
The Role ID functions as the public identifier a client presents during AppRole login, much like a username in credential pairs. It satisfies the stem's requirement for a true statement by naming the correct axis: Role ID is the non-secret identifier, paired with the Secret ID, which acts as the password equivalent.
✗
The Secret ID can only be used once
Why it's wrong here
A Secret ID is reusable until it expires or its secret_id_num_uses limit is reached; single use is configurable, not inherent. It tempts because short-lived, limited-use credentials are a core AppRole security feature, but the default permits multiple logins.

Visual reference

Go deeper

VA-003 Compare authentication methods Practice Question

Why each option matters

Option-by-option breakdown

Related to this question