Trust & Security
Every security idea in this domain serves the CIA triad
Confidentiality, integrity, and availability (the CIA triad) are the three goals all security serves: confidentiality means only authorized parties can read data, integrity means data is accurate and untampered, and availability means data and services are reachable when needed. The whole domain hangs on this spine: Cloud Security Concepts defines the triad and the threats that violate each property, Trusted Infrastructure shows the Google controls that defend each one (encryption for confidentiality, auditing for integrity, Cloud Armor for availability), and Trust Principles & Compliance proves those controls work. When a scenario describes data exposure, tampering, or an outage, the first move is to name the violated property; that classification is what the exam rewards.
Security in the cloud is shared, and the customer's side is the one that fails
The shared responsibility model splits security between provider and customer: Google secures the infrastructure (data centers, hardware, the global network) while the customer secures what they run on it (their data, access, and configuration). The dividing line slides toward the provider as you move from IaaS to PaaS to SaaS, but it never disappears: treating a cloud move as outsourcing all security is the classic trap, since the majority of real-world cloud incidents trace to customer misconfiguration rather than a provider breach. Google extends this with shared fate: it supplies secure defaults, vetted blueprints, and guidance so the customer's side of the line is easier to get right. Trust Principles & Compliance is this same model seen from the data layer: the customer owns the data, Google is the processor.
Protection is layered, defense in depth so no single safeguard is a single point of failure
Defense in depth means stacking independent controls so that if one is bypassed, others still protect the system. Because Google designs and builds its own data centers, server boards, networking, and custom security chips (such as the Titan hardware root of trust), it can embed protection at every layer rather than bolting it on: custom hardware, encryption of data at rest and in transit by default, identity controls (authentication, authorization, auditing), edge defense with Cloud Armor, and detection-and-response through Google Security Operations. The leadership takeaway is that an attacker who defeats one layer still faces the rest: the security story is the whole stack, not any one product.
Trust is earned by transparency and independent proof, not asserted
A control reduces risk; compliance demonstrates to an outside party that the required controls exist and work against a standard such as ISO/IEC 27001, SOC 2, GDPR, or HIPAA. Google does not self-certify. Its products are verified by independent third-party auditors, and customers self-serve those certificates and reports on demand from the Compliance Reports Manager at no extra cost. Transparency reinforces this: Access Transparency logs the actions Google personnel take on your data and the reason for each, mirroring the Cloud Audit Logs that record your own organization's actions. The exam distinction to hold onto is that compliance is necessary evidence of security, not a guarantee of it, and that Google's certifications give a compliant foundation: the customer still has to configure their own workloads correctly.
The three subtopics map to a security question lifecycle
| Question the learner is answering | Subtopic | Core idea |
|---|---|---|
| What are we protecting, against whom, and whose job is it? | Cloud Security Concepts | CIA triad, common threats and business impact, shared responsibility, security vs. compliance |
| How does Google actually protect it? | Trusted Infrastructure | Purpose-built hardware (Titan), default encryption, the three A's, Cloud Armor, Google SecOps |
| How do we prove it and meet the law? | Trust Principles & Compliance | Data ownership, transparency, independent audits, residency vs. sovereignty |