Constrain the booking service and its recovery

Objectives

Halcyon Clinics needs a machine-readable database control plan. The service owner suggests sharing the migration administrator account and says nightly backups meet every recovery target. Translate the requirements beside the editor into explicit fields rather than accepting either shortcut.

Use YAML booleans for switches, numeric minutes for objectives and a list for audit event categories. This is a plan, not a live configuration: grants, log collection and replay capability still need implementation and testing against the database.

Runtime account: booking_runtime; never shared with migrations.
Allowed runtime operations on appointments: SELECT, INSERT, UPDATE only.
Runtime schema changes: prohibited.
Recovery objectives: RPO exactly 5 minutes; RTO exactly 60 minutes.
Recovery source: daily base backup plus continuous transaction-log archival.
Required recovery capability: restore to an instant before a destructive commit.
Required verification: isolated restore test.
Audit categories: authentication, privilege_change, sensitive_read.
Audit destination: protected central collector, outside runtime deletion authority.

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

   Separate deployment from runtime

   Which named identity belongs to normal requests, and should that identity be able to change table definitions? Use a real boolean for the permission switch.

   Dedicated runtime identity and no schema changes

2. Step 2

   Bound the operation set

   Copy only the permitted operation categories from the requirements into the list. Check that destructive and administrative powers have not slipped into it.

   Runtime operations match the approved set

3. Step 3

   Read the units

   Which requirement limits lost committed work and which limits outage duration? Put each numeric target under its matching objective, using the requested units.

   Data-loss and restoration objectives stay distinct

4. Step 4

   Bridge the space between copies

   Identify the base-copy cadence, the ongoing change-capture switch and the method capable of stopping before a bad commit. Describe capabilities, not a promise that the job is green.

   Backup and log strategy supports a selected recovery instant

5. Step 5

   Demand a rehearsal

   What exercise proves the copy and change chain are usable without overwriting the live service? State both the recovery action and its safe environment.

   Recovery is verified in isolation

6. Step 6

   Keep the trail independent

   Compare the event list with every required category. Describe where events go and decide whether the actor being monitored should be able to destroy them.

   Required audit events are protected from runtime deletion

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.