Cloud Operations & Scaling

The earlier domains decide what to build and how to secure it; Cloud Operations & Scaling is about keeping it healthy, affordable, and responsible once it is live. Google organizes that ongoing discipline in its Well-Architected Framework, and three of that framework's pillars line up exactly with this domain's three subtopics: cost optimization maps to financial governance, the reliability and operational-excellence pillars map to operational excellence, and the sustainability pillar maps to sustainability. The three are loosely coupled (money, uptime, and carbon are separate concerns) but they share one mental model: a repeating loop of get visibility into what is happening, set controls and targets, then continuously optimize. At Cloud Digital Leader level you are tested on recognizing which lever each scenario calls for, not on operating any of them by hand.

You cannot control what you cannot see, so each subtopic starts from a measurement before it acts. Financial governance starts with Cloud Billing Reports breaking spend down by project and service; operational excellence starts with a service level indicator (SLI), the quantitative measure of one aspect of service that everything else is built on; sustainability starts with Carbon Footprint, which reports the greenhouse-gas emissions of your Google Cloud usage. The pattern to carry into the exam is that the right first answer to "we have a cost, reliability, or carbon problem" is almost always "measure it" (a reporting or monitoring tool) before any corrective control.

A recurring exam discriminator across this domain is whether a control actually stops something or merely tells you about it. On the cost side, a resource quota is a hard limit that blocks the request when exceeded, whereas a budget only fires alerts at threshold rules and never caps spending on its own. On the reliability side the parallel distinction is the measurement chain: an SLI measures, a service level objective (SLO) sets an internal target for that measurement, and a service level agreement (SLA) wraps a target in a contract that carries a consequence such as a refund if it is missed, so the test for an SLA is simply "what happens if it is breached." Matching the verb in the question ("prevent/cap" versus "notify/alert", "target" versus "contract") to the right mechanism is how most of these questions are won.

None of these levers is a purely technical knob; each is a deliberate trade-off a leader signs off on. Reliability is bounded by an error budget (an availability target set deliberately below 100% because perfect uptime is unattainable and not worth its cost) so teams spend the remaining slack on shipping features until it runs out. Disaster-recovery design is sized by business targets, the recovery time objective (RTO, tolerable downtime) and recovery point objective (RPO, tolerable data loss), where tighter targets cost more. Support is bought to match downtime cost, from free Basic up to Premium with its 15-minute critical-case response and assigned Technical Account Manager. Cost itself is shaped by choosing committed-use discounts for predictable workloads versus automatic sustained-use discounts when you cannot commit. The leader's job is to balance the cost of each against the business value it protects.