HashiCorp Vault Operations Advanced — Practice Questions and Mock Exam

Vault audit devices hash sensitive string values with a per-device salted HMAC-SHA256 before writing log entries. The auth.accessor field therefore contains the HMAC of the token's accessor, not the raw accessor. You can correlate a known accessor to its hashed form via the /sys/audit-hash endpoint. The option “The cleartext token that authenticated the request” is incorrect—raw tokens are never written to audit logs. The option “The IP address from which the request originated” describes request.remote_address, a separate field. The option “The list of policy names attached to the token” describes auth.policies, also a different field. The hmac_accessor option can disable this hashing but is not recommended. Ref: developer.hashicorp.com/vault/docs/audit; /vault/docs/audit/schema

When Vault wraps a response via wrap-ttl, it stores the actual response inside the cubbyhole of a single-use wrapping token at cubbyhole/response. Only the holder of that token can unwrap it via /sys/wrapping/unwrap (Ref: developer.hashicorp.com/vault/docs/concepts/response-wrapping). The cubbyhole is scoped exclusively to the wrapping token—no other token can access it, and data is destroyed when the token expires or is used. The option “In the requester's identity entity metadata, encrypted…” is wrong: identity entity metadata is not used for response storage. The option “In the audit log, retrievable by audit device path” is wrong: audit logs store hashed data for compliance, not retrievable secrets. The option “In the wrapping token's metadata field, accessible…” is wrong: token metadata fields are client-visible labels, not secret storage.