Observability, Feedback, and Governance
This domain links what the system tells you after deployment to how the organisation governs change. The exam tests signal selection, SLO arithmetic, and whether governance is automated or ceremonial.
Signals that matter
Logs (discrete events), metrics (aggregates over time) and traces (request paths across services). Instrument RED for services - rate, errors, duration - and USE for resources - utilisation, saturation, errors. Correlate by trace or request ID, and stamp deployment markers on dashboards so an error spike sits next to "v2.3.1 shipped at 14:02".
SLOs and error budgets
An SLI is the measured ratio (successful requests / total). An SLO is the target over a window. The error budget is 1 − SLO. A 99.9% monthly SLO permits about 43 minutes of unavailability. Burn-rate policies convert this into action: high burn freezes feature releases and prioritises reliability; healthy budget allows faster shipping. Alert on burn rate and user-visible symptoms, not on CPU.
Feedback loops
The pipeline reports to the committer within minutes; synthetic checks, canaries and business KPIs return production signal to the team. Failures get blameless postmortems with tracked actions, not blame.
Governance as guardrails
Governance means automated, auditable controls: policy-as-code gates, mandatory security scanning, separation of duties enforced by permissions (the human approver is not the pipeline service account), and an immutable trail of who deployed which digest when. Retain SBOMs and test evidence for audit.
Worked example
A 99.9% monthly SLO gives 43.2 minutes of budget. One bad release consumes 30 minutes in an hour - a burn rate roughly 30× sustainable. The policy fires: pause releases, roll back, schedule an error-budget review. That decision is executed by the pipeline from measured data, not by a committee meeting later in the week.
Traps that cost marks
- Alerting on causes (CPU, disk) instead of user-visible symptoms.
- Measuring lead time from pull-request merge, hiding the queue before merge.
- Governance by manual sign-off, which adds latency and produces no evidence.
- Dashboards without deployment markers, making cause and effect guesswork.
- Treating the error budget as a reporting figure rather than a trigger.