YAML lab 40 bonus XP

Specify the job that runs the control

Objectives

You are automating the cloud drift control. The platform lead sketches it out: "run it some time overnight, email the team, and if it fails just retry until it goes green so we don't get noise".

Retrying until green is how a control learns to lie. Write the job specification: when it runs, what it reads, what it asserts, what happens when the assertion is false, and how long the result is kept.

Available systems and conventions

source systems: aws-config-api | okta-api | github-api

schedule format: standard five-field cron, UTC
  (minute hour day-of-month month day-of-week)

failure actions in use elsewhere:
  open_ticket | page_oncall | email_team | retry | suppress

Evidence retention agreed with the audit firm: 7 years.
The control asserts that no production resource is publicly
exposed at the moment of the run.

Checks the server runs (5)

  • Schedule is a cron expression a scheduler accepts
  • Source is the system that holds the answer
  • Assertion is a computable comparison
  • Failure produces a durable record, not a retry
  • Results are stored for the agreed retention

Check names are all you see here: the expectations that decide pass or fail, and the reference solution, stay on the server.

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

    Re-read the brief and name the trap

    Retrying a failing control until it passes deletes the finding. The signal you most need, that the environment was non-compliant at the moment of the run, is exactly what the retry erases.

  2. Step 2

    Make the schedule machine-readable

    The fixture names the format and the field order. Pick a fixed time and express it in all five fields, remembering that the run is daily rather than tied to a weekday or a month.

    Schedule is a cron expression a scheduler accepts

  3. Step 3

    Read from the system of record

    The starter reads from a wiki. Choose the system in the fixture that can answer a question about cloud resource exposure right now.

    Source is the system that holds the answer

  4. Step 4

    Turn the intent into a comparison

    "Look fine" cannot be evaluated. State the property as a count or a set relation with an explicit boundary, so the job can decide true or false with no human in the loop.

    The last line of the fixture tells you what the control is asserting; your job is to express it as arithmetic.

    Assertion is a computable comparison

  5. Step 5

    Decide what failure does

    Pick an action from the fixture list that leaves a durable, assignable artefact behind. Ask: six months from now, could someone reconstruct that this run failed and what happened next?

    Email leaves no state a pipeline can query, and two of the listed actions actively destroy the signal.

    Failure produces a durable record, not a retry

  6. Step 6

    Keep the result

    A control that does not persist its outcome produces no evidence. Store the result and set retention to match the number the audit firm agreed, converted into the unit this field uses.

    Results are stored for the agreed retention

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.