Review: Trust, security and operations

The last section review happens the week before the holiday break. Teresa Okonjo, Birchline's information security manager, joins Farah, and Dana Leclair, the chief financial officer, drops in for the second half because cost control is part of the same review. "Security and operations are where the cloud either earns trust or loses it," Teresa says. "Customers will forgive a slow page. They will not forgive a leak of their card details." This lesson reviews section 5, trust and security with Google Cloud, and section 6, scaling with Google Cloud operations. In the guide we read, section 5 had about the same weight as the other main sections and section 6 was smaller, but both are tested and both come up in real conversations about the cloud.

Section 5 has two objectives: describe fundamental cloud security concepts, and describe the business value of Google's defense-in-depth, multilayered approach to security. Section 6 has two: recognize how Google Cloud helps organizations control their costs, and describe fundamental concepts of modern operations, reliability and resilience. As with every section, the exam asks about concepts, value and fit rather than configuration.

Fundamental security concepts

Start with the classic goals of security: confidentiality, integrity and availability. Confidentiality means only the right people can see data. Integrity means data is accurate and has not been altered without authorization. Availability means systems and data are there when needed. Many exam questions are about one of these three, even if they do not name it. Encryption protects confidentiality; logging and controls on changes protect integrity; redundancy across zones and regions protects availability.

Identity is the foundation of cloud security. Identity and Access Management, or IAM, controls who can do what on which resources. The principle of least privilege says each person or service should have only the access needed for their job, and no more. In Google Cloud, you grant roles, which are collections of permissions, to members such as users, groups and service accounts, at a level of the resource hierarchy. Granting a narrow predefined role on one project is better than granting a broad basic role such as Owner across the organization. Multi-factor authentication, often called two-step verification, adds a second proof of identity and greatly reduces the risk from stolen passwords. Cloud Identity provides identity management for organizations that do not use Google Workspace.

Other concepts the guide expects include authentication and authorization, which are proving who you are and deciding what you may do; encryption at rest and in transit, which Google applies by default; customer-managed encryption keys with Cloud Key Management Service for organizations that want to control their own keys; and the zero trust model, which treats every access request as untrusted until verified, regardless of network location. Google's BeyondCorp approach, now delivered through its enterprise access products, is an example of zero trust in practice.

Defense in depth and shared responsibility

Defense in depth means protecting systems with several independent layers, so that if one control fails, others still stand. Google describes its own infrastructure this way: physical security at data centers, custom hardware designed with security in mind, a private global network, encryption by default, and strong identity controls for its own staff. On top of that, customers add their own layers: IAM, network controls, application security and monitoring. Products such as Cloud Armor protect web applications against attacks and help absorb distributed denial-of-service traffic, and Security Command Center gives a central view of misconfigurations, vulnerabilities and threats across an organization's Google Cloud resources.

Shared responsibility describes how the work is divided. Google secures the infrastructure; customers secure what they put on it, including their data, access, and configuration. The split depends on the service model: with IaaS, the customer also manages the operating system; with SaaS, the customer mainly manages data and users. Google also uses the phrase shared fate to describe actively helping customers with secure defaults, blueprints and guidance. Exam questions often describe a breach or a misconfiguration and ask whose responsibility it was, or which control would have prevented it.

Trust, compliance and data sovereignty

Trust also means meeting legal and regulatory needs. Organizations must often show that a provider meets recognized standards, and Google Cloud publishes certifications and audit reports, such as ISO 27001 and SOC reports, through its Compliance Reports Manager. Data residency, or keeping data in a chosen location, is supported by choosing regions and by organization policies that restrict where resources can be created. Data sovereignty goes further, covering who can access data and under which laws. For Birchline, customer data stays in US regions, and the company follows state privacy laws where it sells, and card payments follow the PCI DSS standard in both countries. Google also offers Assured Workloads for regulated environments, and Access Transparency logs that show when Google staff access customer content for support.

Controlling cloud costs

Section 6 starts with cost. In the cloud, costs follow usage, so control comes from visibility and good habits. Google Cloud's billing reports show spending by project, service and label, and billing data can be exported to BigQuery for deeper analysis, which Birchline does. Budgets with alerts warn when spending approaches a planned amount, and quotas limit how much of a resource can be used, which also prevents runaway costs. Labels on resources show which team or product a cost belongs to. FinOps is the practice of bringing finance, technology and business teams together to manage cloud spending as a shared responsibility, and Dana has asked Farah to start a monthly FinOps meeting.

Google Cloud also offers ways to pay less. Sustained use discounts apply automatically to some Compute Engine resources that run for a large part of the month. Committed use discounts give lower prices in exchange for committing to a level of use for one or three years, which suits steady workloads. Spot VMs offer much lower prices for work that can be interrupted, such as batch processing. Rightsizing recommendations suggest smaller machines when resources are underused. The exam often asks which lever fits a described pattern of use: steady and predictable, short and interruptible, or unknown.

# Illustrative comparison: on-demand versus a committed use price for a steady workload
hours = 24 * 365
on_demand_rate = 0.20   # invented price per hour
committed_rate = 0.13   # invented committed price per hour
print("On demand per year:", round(hours * on_demand_rate))
print("Committed per year:", round(hours * committed_rate))
print("Saving per year:", round(hours * (on_demand_rate - committed_rate)))

On demand per year: 1752
Committed per year: 1139
Saving per year: 613

Modern operations, reliability and resilience

Modern operations treat reliability as something designed and measured, not hoped for. Google's site reliability engineering, or SRE, practice is central here. A service level indicator, or SLI, is a measurement of service behavior, such as the share of requests answered successfully. A service level objective, or SLO, is the target for that measurement, such as 999 successful requests out of every 1,000 over a month. A service level agreement, or SLA, is a contract that promises a level of service, often with penalties. The error budget is the amount of unreliability an SLO allows; when it is used up, a team slows releases and focuses on reliability. Blameless postmortems after incidents focus on fixing causes rather than blaming people.

Resilience comes from design. Running across multiple zones protects against the failure of one; running across regions protects against larger outages. Backups and disaster recovery plans, described by a recovery time objective, how quickly a service must be restored, and a recovery point objective, how much data loss is acceptable, set expectations before something goes wrong. Google Cloud Observability, which includes Cloud Monitoring and Cloud Logging, collects metrics and logs, raises alerts and helps teams find problems quickly. Sustainability is also part of operations: Google reports on the carbon impact of its cloud and provides a carbon footprint report so customers can see and reduce theirs.

Practice scenarios

Security operations and resilience in practice

Security is not only prevention; it is also detection and response. Logs record who did what and when. Cloud Audit Logs record administrative actions and data access in Google Cloud, which helps investigate incidents and meet compliance requirements. Security Command Center brings findings together, and Google offers security operations products that help teams detect and investigate threats across their environment. For the exam, connect each to its value: faster detection, faster response and evidence for auditors. Teresa's team at Birchline reviews high-severity findings every morning and has a written plan for who does what if customer data might be exposed.

Resilience and security meet in backups. Ransomware attacks encrypt or delete data and demand payment, and the best defense includes backups that attackers cannot change, kept separate from production, and tested by actually restoring them. Birchline's plan keeps backups of the order database in its second region with retention locks, and Owen's team runs a restore test every quarter. A backup that has never been restored is a hope, not a plan.

More practice scenarios

Three more original scenarios. First: a retailer's online shop is hit by a flood of malicious traffic during a sale. Which product helps protect the web application at the edge? Cloud Armor. Second: a finance team wants to know which product line drove a sudden rise in cloud spending last month. What helps most? Labels on resources combined with billing reports or billing data exported to BigQuery. Third: an online service promises customers an availability level in its contract and wants its engineers to have an internal target that leaves a safety margin. What should the internal target be? An SLO stricter than the SLA.

The third scenario shows a subtle point. An SLO is usually set tighter than the SLA, so that the team gets warning and time to act before it breaks a promise to customers. If the SLO and SLA were the same, the first sign of trouble would be a contract breach.

Reliability also has a cost. Each extra nine of availability, moving from 99 successful requests in every 100 to 999 in every 1,000 and then 9,999 in every 10,000, usually costs more in design, redundancy and staff time. Good operations match reliability to the business need instead of aiming for perfection everywhere.