HashiCorp Vault Associate (003) Question 83
Single answer3c Explain the purpose of token accessorsA security team is investigating a suspected credential leak from an application that authenticates to Vault. The team wants to identify and revoke the application's token without exposing the actual client token value to operators or storing that token in ticketing systems. Which Vault feature best supports this requirement?
- A
Use the token accessor to look up the token's properties and revoke the token indirectly
- B
Use the token's lease ID because token lease IDs can be used to revoke any token without the token value
- C
Use the token's entity ID because revoking an entity ID automatically revokes only the suspected token
- D
Use the token's policy name because policies uniquely identify a token and can be used to revoke it
Show answer and explanation
Correct answer: A
Explanation
Token accessors exist so Vault operators and systems can reference a token for certain management tasks without handling the sensitive token value itself. This reduces the chance of accidental exposure while still allowing actions such as token lookup and token revocation by accessor. In real environments, accessors are useful for audit-driven investigations, help desk workflows, and automation where storing the real token would be unsafe. HashiCorp Vault documentation describes token accessors as secondary values associated with tokens that can be used for lookup and revocation operations, while noting that they are less sensitive than token IDs but still should be protected appropriately because they enable management of the token.
- A. Correct.
Correct. A token accessor is a reference to a token that can be safely used for limited management operations without revealing the full token ID. Operators can use an accessor to perform lookup and revoke actions on the associated token. This is exactly why accessors are useful in incident response and operational workflows where exposing the actual token would increase risk.
- B. Incorrect.
Incorrect. Tokens are not managed through a lease ID in the way dynamic secrets are. Although tokens have TTL-related behavior, the practical management mechanism for indirect token operations is the token accessor, not a lease ID. This option reflects a common confusion between token lifecycle and secret leases.
- C. Incorrect.
Incorrect. An entity ID represents the identity in Vault's identity system, not a specific token handle for lookup or revocation. An entity can be associated with multiple tokens over time, so using an entity ID would not target just the leaked token. This distractor plays on confusion between identity objects and token objects.
- D. Incorrect.
Incorrect. Policies are attached to many tokens and are not unique identifiers. Knowing a policy name does not identify a specific token and cannot be used to revoke one token. This is a common misconception when candidates confuse authorization metadata with token management primitives.