Task 3.1: Choose between service and batch tokens based on use case
Service tokens with renewal, children, accessors and cubbyholes versus lightweight batch tokens with fixed TTLs, and where each scales or fails.
Study it
Service and batch tokens: features, cost and scale
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
A serverless platform performs tens of thousands of short Vault logins a minute, each token used for a few seconds against Vault Enterprise performance secondary clusters in other regions. Creating tokens must cost as little storage as possible, and each token must work on any cluster in the replication set. Which tokens fit?
ABatch tokens issued as children of a service token
BOrphan batch tokens
COrphan service tokens with a 1-minute TTL
DPeriodic service tokens with a 1-minute period
Show the answer and why
ABatch tokens issued as children of a service token
Incorrect
A batch token with a parent can be used across performance clusters only if it is an orphan, since the parent's validity cannot be checked there.
BOrphan batch tokens
Correct
Batch tokens need no storage writes, and an orphan batch token can be used across performance replication clusters.
COrphan service tokens with a 1-minute TTL
Incorrect
Service tokens cost several storage writes each and cannot be used across performance replication clusters.
DPeriodic service tokens with a 1-minute period
Incorrect
Periodic service tokens are still heavyweight service tokens tied to the cluster that issued them.
Batch tokens are encrypted blobs with no storage cost, which suits high volume. Only orphan batch tokens are valid across performance replication clusters.
A team is deciding whether its token workflow can move from service tokens to batch tokens. Which two of its needs can only service tokens meet? (Choose TWO.)
AUsing the token on a performance replication secondary
BUsing the token to create child tokens
CCreating tokens without a write to storage
DStoring data in the token's own cubbyhole
EHaving the token stop working when its TTL ends
Show the answer and why
AUsing the token on a performance replication secondary
Incorrect
An orphan batch token can be used across performance replication clusters; a service token cannot.
BUsing the token to create child tokens
Correct
Service tokens can create child tokens; batch tokens cannot.
CCreating tokens without a write to storage
Incorrect
Batch token creation has no storage cost; service tokens need several writes.
DStoring data in the token's own cubbyhole
Correct
Service tokens have a cubbyhole; batch tokens have none.
EHaving the token stop working when its TTL ends
Incorrect
Both token types stop working at the end of their TTL.
Batch tokens trade features for scale: no renewal, children, accessors or cubbyhole, but no storage cost and use across performance clusters when orphaned.
A security architect proposes that the break-glass root token be created as a batch token, so that it needs no storage and simply runs out on its own. What is wrong with the plan?
ANothing; vault token create -type=batch -policy=root makes such a token
BBatch tokens cannot be root tokens, so such a token cannot exist
CA batch root token would never run out, since root tokens ignore TTLs
DA batch root token would work only on the node that created it
Show the answer and why
ANothing; vault token create -type=batch -policy=root makes such a token
Incorrect
Whatever policy is requested, a batch token cannot be a root token.
BBatch tokens cannot be root tokens, so such a token cannot exist
Correct
The token type comparison lists being a root token as a service token capability that batch tokens lack.
CA batch root token would never run out, since root tokens ignore TTLs
Incorrect
There is no batch root token to run out or not; the batch type cannot carry root.
DA batch root token would work only on the node that created it
Incorrect
There are no batch root tokens at all, on any node.
Root tokens are always service tokens, so the choice between batch and service tokens never arises for root access.
A batch token with 10 minutes of TTL left requests a database credential whose role has a 1-hour default TTL. How long does the credential's lease last?
ANo longer than the batch token's remaining TTL
B1 hour, the role's default TTL
CUntil the batch token is renewed
DUntil the 32-day system max TTL
Show the answer and why
ANo longer than the batch token's remaining TTL
Correct
Leases created by batch tokens are constrained to the batch token's remaining TTL.
B1 hour, the role's default TTL
Incorrect
A batch token's leases cannot outlive the batch token.
CUntil the batch token is renewed
Incorrect
Batch tokens cannot be renewed.
DUntil the 32-day system max TTL
Incorrect
The batch token's own remaining TTL is the limit.
With a batch token, a lease is capped at the token's remaining TTL and is tracked by the token's parent if it has one.