Review six access changes

Objectives

The change board labels all six proposals identity hardening because every proposal mentions a security feature. Approve only changes meeting the stated requirements; judge each independently with no unstated compensating controls.

Routine jobs must have only necessary permissions, role trust must identify the authorized caller, sessions must expire, and emergency access must be tested and monitored. For each rejection choose the single most direct defect code.

Verdicts are accept or reject. Every rejection needs one reason code from: excess-permissions | broad-trust | persistent-key | ungoverned-recovery.

CI-1 Invoice job needs only reads; proposal grants object.* on invoices/* because its script currently reads only.
CI-2 Role grants only invoice reads; trust accepts every subject from a shared issuer although only billing-exporter is approved.
CI-3 Job exchanges its validated runtime identity for a scoped 10-minute role session; it has no static cloud key.
CI-4 Permanent cloud key stays embedded in a deployment file; proposal renames the file encrypted-secrets without adding encryption or access restrictions.
CI-5 Emergency account avoids the normal federation dependency, has protected recovery material and strong multifactor authentication, alerts on every use, and a successful quarterly test with independent post-use review.
CI-6 Root account is reserved for emergencies but recovery instructions have never been tested and successful logins produce no alert.

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 request before the artefact

   Use the change-board requirements as acceptance criteria. Do not invent missing controls to rescue a proposal.

2. Step 2

   Judge every line, including the boring ones

   Give each proposal exactly one verdict so that the board can distinguish reviewed changes from omissions.

   Every line in the fixture carries a verdict

3. Step 3

   Separate what is wrong from what is merely ugly

   Trace what the identity could do, who could obtain it and how long credentials remain usable. For recovery, ask whether access would work during an outage and produce an attributable alert.

   Accept and reject land on the right lines

4. Step 4

   Say why, in the vocabulary the programme uses

   Choose the code corresponding to the defective control: authority, admission, credential persistence or emergency governance. Do not use a storage defect to describe a trust defect.

   Each rejection cites a valid reason code

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.