Operations, Monitoring, and Billing
What this domain covers
Operations questions test whether you can observe a system, restore it, and control spend. Monitoring is not just CPU graphs; billing is not just the monthly total. The exam expects RPO and RTO thinking and cost attribution.
Core rules
- Collect metrics at the right layer: hypervisor metrics for host health, guest or agent metrics for memory and disk, application logs for errors, and synthetic checks for user-facing availability.
- Alarms should be actionable and tied to a runbook. A CPU alarm without a scale-out or restart action is noise.
- Backup and DR: define RPO (acceptable data loss) and RTO (acceptable downtime), then test restores. Snapshots are not backups until restored and verified.
- Patch via immutable images and rolling replacement; keep maintenance windows and rollback images.
- Billing is pay-as-you-go by resource and usage. Use tags or projects for cost allocation, budget alerts for anomalies, and regular cleanup of unattached block volumes, idle global IPs, old snapshots, and stopped servers that still incur storage charges.
- Review invoices and usage reports against architecture changes; data transfer and retrieval can dominate.
Worked example
A monthly bill jumps after a test. The team finds unattached block volumes, idle global IPs, and archive retrieval from a misconfigured lifecycle rule. Fix: snapshot and delete orphan volumes, release unused IPs, correct the lifecycle transition, and add a budget alarm at 80% of forecast. Reasoning: the largest avoidable costs were idle resources and unintended retrieval, not compute.
Traps
Assuming a stopped server stops all charges; monitoring only CPU; never testing restore; deleting snapshots before retention; and lacking tags so no one owns the spend.