This is the smallest section, about 10% of the exam, but it is full of easy points. It has two halves: controlling cost and organising resources, and operations, reliability and SRE. Learn the terms precisely.
CapEx, OpEx and total cost of ownership
| Term | Meaning | Example |
|---|---|---|
| Capital expenditure (CapEx) | Upfront spend on long-lived assets, depreciated over time | Buying servers and building a data centre |
| Operational expenditure (OpEx) | Ongoing spend on running the business | Monthly cloud bills, subscriptions |
| Total cost of ownership (TCO) | The full cost of a solution over its life: hardware, software, space, power, cooling, staff, maintenance, downtime, refresh cycles | Compare on-premises TCO with cloud TCO |
Moving to the cloud shifts spend from CapEx to OpEx. Benefits: no large upfront purchase, pay for what you use, easier forecasting by usage, capacity matched to demand (no idle servers bought for peak). TCO can fall because you avoid hardware refreshes, data-centre costs and overprovisioning, and staff spend time on higher-value work. Cloud TCO is not automatically lower: unmanaged usage can overspend, which is why governance matters.
Cloud financial governance (FinOps)
Google-recommended practice: treat cost as a shared responsibility with clear ownership.
- Identify who manages cloud costs: a cross-functional team (finance, engineering, business owners), often called FinOps, with executive sponsorship.
- Use cost management tools: Cloud Billing reports, budgets and alerts, cost breakdown by project and label, recommendations, and the Cost Management tools.
- Visibility and accountability: label resources, assign costs to teams, and give owners their own numbers.
- Optimise continuously: right-size, remove idle resources, use discounts.
People, process and technology
| Pillar | Role in cost control |
|---|---|
| People | Define owners, train teams, build a culture of cost awareness |
| Process | Budget approvals, regular reviews, tagging standards, policies |
| Technology | Tools: billing reports, budgets, quotas, recommenders, automation |
Tools alone do not control cost; all three are needed.
The resource hierarchy
Google Cloud organises resources in a tree. Policies set higher in the tree are inherited by everything below.
| Level | Meaning |
|---|---|
| Organization node | The root, representing the company (tied to a Google Workspace or Cloud Identity domain). Central policies and visibility live here |
| Folders | Optional grouping of projects and other folders, such as by department, team or environment |
| Projects | The base unit for creating and using resources: enable APIs, billing, permissions. Every resource belongs to one project |
| Resources | The actual services: VMs, buckets, datasets |
Benefits:
- Access control with inheritance: grant an IAM role on a folder and it flows to all projects below. Policies propagate downward, and a child cannot remove a parent’s inherited permission.
- Security and compliance: apply organization policies (constraints such as allowed regions) once at the top.
- Visibility and auditing: see and report across the whole company; audit who changed what.
- Billing and cost allocation: link projects to billing accounts and view cost by project or folder.
- Separation of environments (dev, test, production) and teams.
Trap: permissions are granted down the hierarchy; a role at the project level does not give access to the whole organization.
Controlling cloud consumption
| Control | What it does |
|---|---|
| Resource quotas | Limits on how much of a resource a project can use (for example CPUs), preventing runaway use or accidental overspend |
| Budgets and threshold rules | Set a budget amount and alerts at percentages of it (50%, 90%, 100%). Budgets alert; they do not stop spending by default (automation can) |
| Cloud Billing reports | View and analyse costs over time, filter by project, service, label |
| Spot VMs | Deep discount for interruptible workloads |
| Dynamic Workload Scheduler | Schedules AI and batch accelerator capacity flexibly (for example waiting for capacity or reserving a window), improving access and cost for GPU/TPU jobs |
| Committed use discounts | Lower price for committing to usage for 1 or 3 years |
| Sustained use discounts | Automatic discount for running a VM a large part of the month |
| Recommender / right-sizing | Suggests smaller machines or removal of idle resources |
| Labels | Key-value tags to group and report costs |
Trap: a budget alert is a notification, not a hard cap. To enforce limits, use quotas or automated responses.
Observability and modern operations
Observability means understanding what is happening inside systems from the data they emit. Google Cloud’s Observability suite (previously the operations suite, and Stackdriver before that):
| Tool | Job |
|---|---|
| Cloud Monitoring | Collects metrics, builds dashboards, sets alerts and uptime checks |
| Cloud Logging | Collects, stores, searches and analyses logs from all services |
| Cloud Trace | Distributed tracing: follows a request across services to find latency |
| Cloud Profiler | Shows which functions use the most CPU and memory in production code |
| Error Reporting | Groups and surfaces application errors and exceptions, with alerts |
Memory aid: metrics (Monitoring), logs (Logging), traces (Trace), code performance (Profiler), crashes (Error Reporting). Benefits: find problems before customers do, shorten time to resolve, understand performance and spot trends.
Operations terms
| Term | Meaning |
|---|---|
| Operational excellence | Running workloads effectively: automation, monitoring, continuous improvement, learning from incidents |
| Reliability | A system does what it should, consistently, for as long as users expect |
| High availability (HA) | Designing so a service stays up despite failures, usually through redundancy, measured as uptime (such as 99.9%) |
| Resilience | Ability to withstand and recover from failures |
| Scalability | Ability to handle growth |
Designing resilient infrastructure
- Redundancy: duplicate components so one failure does not stop the service (multiple zones and regions).
- Replication: keep copies of data in several places.
- Scalable infrastructure: autoscaling and load balancing absorb spikes.
- Backups: copies for recovery after loss or corruption (replication alone does not protect against deletion or corruption that is copied everywhere).
- Disaster recovery: plan with a recovery time objective (RTO) (how fast to restore) and recovery point objective (RPO) (how much data loss is tolerable).
- Process: runbooks, testing failover, blameless postmortems.
Measuring performance and reliability
The four golden signals from SRE:
| Signal | Meaning |
|---|---|
| Latency | Time to serve a request (separate successful from failed requests) |
| Traffic | Demand on the system (requests per second) |
| Errors | Rate of failed requests |
| Saturation | How full the system is (CPU, memory, disk, queue depth) |
DevOps and Site Reliability Engineering
DevOps is a culture and set of practices that break down silos between development and operations, with automation, CI/CD and shared ownership. Site Reliability Engineering (SRE) is Google’s way of running operations: apply software engineering to operations, automate toil and balance reliability with release speed. A common phrase: SRE implements DevOps.
SLI, SLO, SLA
| Term | Meaning | Example |
|---|---|---|
| Service level indicator (SLI) | A measured number describing service behaviour | Percentage of requests served successfully, request latency |
| Service level objective (SLO) | The target for an SLI that the team commits to internally | 99.9% of requests succeed over 30 days |
| Service level agreement (SLA) | A contract with customers stating the promised level and the consequences (credits, penalties) if missed | Customer gets credits if availability falls below 99.5% |
Relationship: you measure SLIs, target SLOs, and promise SLAs. SLOs are set stricter than SLAs so you can fix problems before breaching the contract. The gap between 100% and the SLO is the error budget: the amount of unreliability you can spend on releases and experiments. If the budget is used up, slow releases and focus on reliability.
Trap: 100% availability is the wrong target. It is extremely costly and leaves no room to ship changes.
Exam checklist
- Cloud moves CapEx to OpEx; TCO covers all costs over the lifetime.
- FinOps needs people, process and technology; label resources and assign owners.
- Hierarchy: organization -> folders -> projects -> resources; policies inherit downward.
- Quotas limit use; budgets alert (do not cap); billing reports analyse; Spot VMs and committed use discounts cut price.
- Observability: Monitoring (metrics, alerts), Logging, Trace (latency across services), Profiler (code cost), Error Reporting.
- Resilience: redundancy, replication, backups, multiple zones and regions; know RTO and RPO.
- Golden signals: latency, traffic, errors, saturation.
- SLI = measurement, SLO = internal target, SLA = customer contract; error budget = allowed unreliability.