Observability, Cost Management, and Operational Best Practices
What this domain tests
Questions here test whether you can observe a running system and control its cost using native services: metrics and alarms, log routing, tagging for chargeback, and budgets and quotas that constrain spend.
Core rules
- Monitoring emits platform metrics for free; agent-based metrics require the Unified Monitoring Agent on the instance.
- Alarms evaluate a metric query against a threshold and publish to a Notifications topic. Topics are regional, and an alarm with no subscription notifies nobody.
- Logging captures service logs, audit logs, and custom logs. Service Connector Hub routes them to Object Storage, Streaming, or Functions for retention or automated response.
- Cost control: one compartment per team or project, cost-tracking tags from a defined tag namespace, budgets with alert rules, cost analysis, and quotas to cap resource creation.
- Audit records every API call against the tenancy and is the first place to look for unauthorised changes.
Worked example
A project compartment gets cost-tracking tags env and cost-center. A budget scoped to that compartment publishes to a Notifications topic at 50% and 90% of forecast spend, and a quota caps GPU instances. When the 90% alert fires, cost analysis grouped by the cost-center tag identifies the offending resources, and the quota prevents further runaway creation.
Traps
Believing a budget stops spending - it only alerts; leaving resources untagged so cost lands in an unallocated bucket; creating an alarm without a subscribed topic; forgetting that defined tags must be flagged as cost-tracking in the tag namespace before they appear in cost analysis.