Specify a collector that cannot lie

Objectives

An engineer wired up the MFA evidence collector in an afternoon using her own API token and a single unpaginated request. It reports 100% coverage and the identity lead is delighted with "the automation".

Rewrite the collector specification so the run is trustworthy: a machine identity with a vaulted secret reference, pagination that follows every page, throttling handled with a real backoff strategy, a population floor the run must clear, run metadata and a payload hash on every record, and a schedule a scheduler understands.

source: okta-api  (tenant has 1,240 users; the endpoint returns 100 per page)
auth: personal token belonging to an engineer, pasted into the job config
request: GET /api/v1/users?limit=100      # 'link: rel="next"' header is never read
on 429: retried immediately three times, then exits 0 with whatever it has
stored: the raw payload only: no run id, no hash, no record count
runs: "when someone remembers"

Step-by-step hints

The guided walkthrough, in full. It is free: no XP cost, and it does not touch the paid hint ladder or the reveal gate.

1. Step 1

   Read the fixture as six independent failures

   Each line of the deployed collector fails for its own reason: who it runs as, how much it reads, what it does under pressure, what it proves about completeness, what it stores, and when it runs.

   Fix them one field at a time rather than rewriting the shape of the document: the starter already has the right shape.

   Machine identity with a vaulted secret referenceSchedule is a value a scheduler understands

2. Step 2

   Give the job its own identity

   Replace the personal-token method with the name of a machine-identity flow, the kind of credential that belongs to a system rather than a human, and point the secret reference at a resolvable location in a secret store using a scheme prefix.

   The value should read like an address, not like a sentence and not like a token.

   Machine identity with a vaulted secret reference

3. Step 3

   Decide how the loop knows it is finished

   Name the pagination style the endpoint offers, the fixture tells you it hands back a link to the next page, and flip the field that commits the collector to following every one of them.

   Ask yourself what the collector should do if page four fails: that answer belongs in the retry block, not here.

   Follows every page of the population

4. Step 4

   Survive throttling instead of ignoring it

   Immediate retries are the same burst again. Set an attempt count that gives the API room to recover, and name the backoff strategy that grows the wait between attempts.

   Throttling handled with a real backoff strategy

5. Step 5

   Make an incomplete run fail loudly

   The population floor is the guard against silent truncation: a number the run must reach before the evidence record is written. Pick a value that is plausibly below the real population in the fixture but far above a single page.

   Run must clear a population floor

6. Step 6

   Store what makes it evidence

   Turn on the run identifier so a stored record can be traced back to the execution that produced it, and name a standard cryptographic digest for the canonical payload so tampering is detectable.

   Finally, replace the human schedule with one of the fixed frequency values a scheduler accepts.

   Records carry a run id and a payload hashSchedule is a value a scheduler understands

Rules summary

• XP on pass

  40 bonus XP the first time every check goes green.

• Paid hints

  2 available. Each costs 25% of the lab XP (about 10 XP).

• Reveal solution

  Scores 0 XP and unlocks only after 3 check runs.

• Attempt cap

  60 check runs per learner. The runner warns you in the last 10.

• Drafts

  Your editor content is saved in this browser, so a reload will not lose work.

• Walkthrough

  Always free and never penalised: use it before spending a hint.