The brief
The client's requirement is the one that arrives after the first quiet outage nobody noticed for a day: "We have systems running unattended and no idea whether they are healthy or what they cost until something breaks or the bill lands. Give us eyes that see problems before customers do, alerts that we will actually answer, and a spend guardrail that warns us inside the month — and we never want another surprise invoice." Every phrase is a class you have sat; this build assembles them into the operational posture that separates an engineer who builds systems from one who can be trusted to run them.
- Deliverable
- Observability and cost guardrails laid over the Build I–III estate: a workspace collecting telemetry by policy, exactly three meaningful alerts, one dashboard built backwards from questions, and a budget with a forecasted threshold — all in the repository, deployed like everything else.
This build watches the previous three. There is nothing new to deploy underneath it — the estate, the network, the pipeline already exist; Build IV is the layer that makes them safe to leave alone.1 It is also the build that most rewards restraint: the failure mode here is not too little but too much — forty alerts nobody reads, sixteen dashboard tiles nobody understands — and the rubric marks the discipline of stopping.
Requirements — the ledger you build against
Rows in dependency order. R2 and R5 carry the most marks, because coverage-by-policy and shout-before-the-bill are the two claims a reviewer probes hardest.
| # | Requirement | Taught in | Evidence |
|---|---|---|---|
| R1 | A single Log Analytics workspace as the central reservoir, in the estate, deployed as code | Class 28 | The workspace in the repository's Bicep; one README line on why one workspace, not many |
| R2 | Telemetry flowing by policy: a DeployIfNotExists assignment that puts diagnostic settings on resources automatically, so coverage is a law, not a checklist | Classes 8, 28 | A newly created resource shown collecting logs without anyone opening a valve by hand |
| R3 | Application Insights on a workload, and one availability test from several regions with a content match and the certificate lifetime check on | Class 30 | The scatter plot of robot customers reporting in; one deliberate content-match failure captured |
| R4 | Exactly three alerts, each with a named owner and a runbook line, routed through action groups by severity — no more, on purpose | Classes 29–30 | The three rules; the 3am test applied in the README to a longer list that was cut down to three |
| R5 | A budget on the estate with actual thresholds at 80% and 100% and a forecasted alert, routed to an owner | Class 32 | The budget definition; one README paragraph on why a budget shouts but never stops spend |
| R6 | One dashboard or workbook, built backwards from named questions — each tile answering a question with an owner and a cadence | Classes 29–30 | The workbook; beside each tile, the question it answers and who asks it |
| R7 | One KQL query saved to the shared pack — the disk-space-low query or its cousin — and wired to R4's alerting | Class 29 | The saved query; the alert rule that runs it on a schedule |
Three alerts that fire beat forty that are ignored.
The boundaries, and this build's are about subtraction. Do not over-alert: the rubric caps any build with an alert that would not pass Class Thirty's "would you wake a colleague for this" test. Do not over-tile: a dashboard whose panels have no named question behind them is decoration, and decoration is a Reasoned-band deduction. The skill this build certifies is signal-to-noise — the discipline of collecting everything and alerting on almost nothing.
The rubric — how a reviewer marks it
The bands, tuned for a build graded on judgement more than plumbing.
- Functional — the floor
- Telemetry flows, an availability test runs, three alerts route, a budget warns. The machinery works; whether the choices were wise is not yet shown.
- Reasoned — the target
- Functional, plus the README defends the restraint: why coverage is by policy not by hand, why these three alerts and not the forty that were proposed, why each dashboard tile earns its pixels. The judgement is now visible, which is the whole point of this build.
- Professional — the ceiling
- Reasoned, plus a worked incident or a worked cost anomaly: the README walks one real signal from alert to workbook to root cause, or one budget forecast to the meter that caused it — proving the posture is used, not just installed. This is the version that answers "tell me about your monitoring" with a story instead of a product list.
The capping deduction is this build's contrarian heart: an alert channel nobody owns, or more alerts than a person can hold in their head, caps the build at Functional — because unowned noise is worse than silence, and a reviewer who has carried a pager knows it.
What an interviewer will ask
The questions this artifact provokes, in arrival order. The strong answers are all about what you chose not to do.
- "Tell me about your monitoring."
- The Class Thirty posture, in three legs: coverage by policy, one place where signals meet, and a habit of someone actually looking. Answer with the posture, not the product list, and you are already the senior-sounding candidate in the room.
- "Why only three alerts?"
- Because every alert is a claim on a human's attention, and a pager that cries wolf goes unread exactly when it matters. Three that always mean something beat forty that trained the team to ignore them. This is the answer that reads as scar tissue.
- "How do you know a new resource is being logged?"
- Because a DeployIfNotExists policy puts the diagnostic setting on automatically — coverage is a law of the subscription, not a thing someone remembered. Being born in the estate means being watched.
- "The budget was crossed — did anything stop?"
- No, and deliberately: a budget shouts, it does not throttle, because a self-inflicted outage from a spend ceiling is worse than the overspend. If you want spend to stop, that is automation you build on purpose. Knowing the difference is the mark.
- "Walk me through catching one real problem."
- The Professional-band story from your own README — alert to workbook to cause, or forecast to meter. A candidate who can narrate one incident end to end has demonstrated the entire phase in ninety seconds.
The posture that made the closet safe to leave
Campux built exactly this across Phase Four: one workspace in Class Twenty-Eight, the KQL query framed on the wall in Class Twenty-Nine, three alerts on purpose in Class Thirty, and the budget that caught the AI bill mid-month in Classes Thirty-Two and Thirty-Five. This build is you assembling the same watch over your own three builds. It is the last milestone before the job search, and not by accident — the Class Thirty-Seven interviewer asks "tell me about a system you run," and this is the build that lets you answer with a dashboard you can screen-share instead of a sentence you rehearsed.
- If the earlier builds' Azure resources were torn down, redeploy the estate from Build III's pipeline first — this build needs something to watch, and rebuilding it from code is the quickest way to have it back. Telemetry takes minutes to a day to appear, and cost data lags by up to a day, so start the collection early and do the alerting and dashboard work while the first rows arrive — the lag is itself a Class Twenty-Eight lesson worth feeling. ↩