Domain 5: Trust and Security with Google Cloud (~17%)
Domain 5 accounts for approximately 17% of the Google Cloud Digital Leader exam, translating to roughly 9-10 questions. This domain tests your understanding of cybersecurity threats, Google Cloud's security infrastructure and tools, and how compliance and trust principles govern data protection.
5.1 Trust and Security in the Cloud
Top Cybersecurity Threats
The exam expects you to identify common cybersecurity threats and articulate their business impact. Know these threats by name and how they work.
| Threat | Description | Business Impact |
|---|---|---|
| Phishing | Fraudulent emails or messages tricking users into revealing credentials or clicking malicious links | Credential theft, unauthorized access, data breaches |
| Malware | Malicious software (viruses, trojans, worms) that infects systems | Data corruption, system downtime, intellectual property theft |
| Ransomware | Malware that encrypts data and demands payment for decryption keys | Operational shutdown, financial loss, reputational damage |
| DDoS | Distributed denial-of-service attacks flooding systems with traffic to make them unavailable | Service outages, revenue loss, customer churn |
| Insider threats | Malicious or negligent actions by employees, contractors, or partners with legitimate access | Data exfiltration, sabotage, compliance violations |
| Data exfiltration | Unauthorized transfer of data out of an organization | Regulatory penalties, loss of competitive advantage |
| Supply chain attacks | Compromising third-party software or services to infiltrate target organizations | Widespread impact across multiple organizations |
Cloud Security vs. On-Premises Security
The exam tests whether you understand the fundamental differences in security posture between cloud and traditional environments.
| Aspect | On-Premises | Cloud (Google Cloud) |
|---|---|---|
| Physical security | Organization manages data center access, surveillance, hardware | Google manages purpose-built data centers with biometrics, access cards, vehicle barriers |
| Patching | Organization responsible for all OS and software patches | Provider handles infrastructure patching; customer patches what they control |
| Scaling security | Must provision security hardware ahead of demand | Security scales automatically with workloads |
| Encryption | Must implement and manage encryption manually | Encryption at rest is automatic and default |
| Capital costs | High upfront investment in security appliances | OpEx model; security tooling included or pay-per-use |
| Expertise | Must hire and retain security specialists | Provider employs world-class security teams; customer supplements with own staff |
| Visibility | Full control but limited threat intelligence | Massive global threat intelligence from Google's scale |
The CIA Triad
The CIA triad is foundational to cloud security. Every security control maps back to one or more of these three pillars.
- Confidentiality: Ensuring data is accessible only to authorized parties. Implemented through encryption, IAM policies, and access controls.
- Integrity: Ensuring data has not been tampered with or altered without authorization. Implemented through checksums, audit logs, and version control.
- Availability: Ensuring systems and data are accessible when needed. Implemented through redundancy, load balancing, and DDoS protection.
Defense in Depth
Google Cloud employs a defense-in-depth strategy that layers multiple security controls so that the failure of any single control does not compromise the entire system. The layers include:
- Physical security -- data center access controls, biometrics, surveillance
- Hardware security -- custom Titan security chips on servers for secure boot and cryptographic attestation
- Network security -- Google Front End (GFE) servers, firewalls, Cloud Armor DDoS protection
- Identity and access -- IAM, two-step verification, BeyondCorp zero-trust
- Data security -- encryption at rest, in transit, and in use
- Application security -- Binary Authorization, vulnerability scanning, WAF rules
- Operations security -- Security Command Center, Chronicle SecOps, incident response
Exam trap: Defense in depth is not about having one strong perimeter. It is about multiple independent layers. If the exam presents a single "silver bullet" security measure as sufficient, that answer is wrong.
5.2 Google's Trusted Infrastructure
Encryption: At Rest, In Transit, and In Use
Google Cloud encrypts data in three states by default. This is a heavily tested topic.
| State | Method | Default Behavior |
|---|---|---|
| At rest | AES-256 at the storage layer using Data Encryption Keys (DEKs) wrapped by Key Encryption Keys (KEKs) | Automatic; no configuration required. Google manages the keys. |
| In transit | TLS for external traffic; ALTS (Application Layer Transport Security) for internal Google network traffic | Automatic for HTTPS/HTTP2/HTTP3 connections to Google services. Internal traffic encrypted by ALTS. |
| In use | Confidential Computing with Trusted Execution Environments (TEEs) providing hardware-based isolation | Not automatic; must be explicitly enabled for Confidential VMs, Confidential GKE Nodes, etc. |
Key Management Options
| Option | Who Manages Keys | Use Case |
|---|---|---|
| Google-managed encryption (default) | Standard workloads; no key management overhead | |
| Customer-managed encryption keys (CMEK) | Customer via Cloud KMS | Regulatory requirements; customer needs control over key lifecycle (create, rotate, revoke, destroy) |
| Customer-supplied encryption keys (CSEK) | Customer provides key material directly | Maximum control; keys never stored in Google infrastructure |
| External key manager (EKM) | Customer via third-party key manager | Keys remain outside Google Cloud entirely |
Exam trap: All Google Cloud data is encrypted at rest by default using AES-256. You never have "unencrypted" data at rest in Google Cloud. CMEK does not add encryption -- it changes who controls the keys.
Authentication vs. Authorization vs. Auditing
The exam explicitly tests whether you can distinguish these three concepts.
| Concept | Question Answered | Google Cloud Implementation |
|---|---|---|
| Authentication | Who are you? | Google Sign-In, two-step verification (2SV), SAML/OIDC federation, Titan security keys |
| Authorization | What are you allowed to do? | IAM roles and policies, allow/deny policies, organization policies |
| Auditing | What did you do? | Cloud Audit Logs, Access Transparency logs, Cloud Logging |
Identity and Access Management (IAM)
IAM is Google Cloud's central access control system. It determines who (principal) can do what (role/permissions) on which resource.
IAM Components
- Principal: The identity requesting access (Google Account, service account, Google Group, Google Workspace domain, Cloud Identity domain)
- Role: A named collection of permissions
- Resource: The Google Cloud asset being accessed (project, bucket, VM, etc.)
- Policy: A YAML/JSON binding that attaches principals to roles on a resource
Role Types
| Role Type | Description | Example | When to Use |
|---|---|---|---|
| Basic roles | Broad, legacy roles: Owner, Editor, Viewer | roles/editor |
Testing and development only. Too permissive for production. |
| Predefined roles | Granular roles managed by Google for specific services | roles/storage.objectViewer |
Most production workloads |
| Custom roles | User-defined roles with only the permissions you specify | roles/myCustomRole |
When predefined roles grant more permissions than needed |
Principle of Least Privilege
Grant only the minimum permissions necessary for a principal to perform its job. This is a core IAM design principle and a recurring exam theme.
- Prefer predefined roles over basic roles
- Prefer custom roles when predefined roles are still too broad
- Use IAM Conditions for attribute-based access control (e.g., grant access only during business hours or from specific IP ranges)
- Use IAM deny policies to explicitly block permissions even if an allow policy grants them
Resource Hierarchy and Policy Inheritance
Policies set at a higher level in the resource hierarchy are inherited by all child resources.
Organization
└── Folder
└── Project
└── Resource (e.g., Cloud Storage bucket)
A role granted at the organization level applies to every folder, project, and resource beneath it. A role granted at the project level applies only to resources in that project. You cannot restrict inherited permissions at a lower level using allow policies alone -- you need deny policies for that.
Exam trap: If a user has the Editor role at the organization level, they have Editor on every project. You cannot remove that access by changing project-level policies -- you must remove the organization-level binding or use a deny policy.
Two-Step Verification (2SV)
Two-step verification adds a second factor beyond a password. Google supports multiple 2SV methods:
- Security keys (Titan Security Keys) -- strongest; hardware-based, phishing-resistant
- Push notifications via Google prompts on trusted devices
- Authenticator apps generating time-based one-time passwords (TOTP)
- SMS codes -- weakest of the options; vulnerable to SIM-swapping
Exam trap: The exam may ask which 2SV method is most secure. Security keys (hardware-based) are the strongest. SMS is the weakest.
Google Cloud Armor
Google Cloud Armor provides DDoS protection and web application firewall (WAF) capabilities at the edge of Google's global network.
| Feature | Description |
|---|---|
| DDoS protection | Always-on volumetric DDoS protection for applications behind load balancers |
| WAF rules | Preconfigured rules based on OWASP Core Rule Set (CRS) to mitigate SQL injection, XSS, and other OWASP Top 10 risks |
| Security policies | Custom rules with match conditions (IP ranges, geography, headers) and actions (allow, deny, rate-limit) |
| Adaptive Protection | ML-based analysis that detects Layer 7 DDoS patterns and auto-generates mitigation rules (Enterprise tier) |
| Edge enforcement | Rules evaluated at Google's network edge before traffic reaches your infrastructure |
Exam trap: Cloud Armor protects applications behind load balancers. It is not a general-purpose firewall for all traffic. If the exam asks about protecting VMs not behind a load balancer, Cloud Armor is not the answer -- VPC firewall rules are.
Security Operations (SecOps) / Chronicle
Google Security Operations (formerly Chronicle) is Google's cloud-native SIEM and SOAR platform for threat detection and response.
| Capability | Description |
|---|---|
| SIEM | Ingests and normalizes security telemetry at scale using the Universal Data Model (UDM) |
| Threat detection | Curated detection rules maintained by Google threat researchers; supports YARA-L rule language for custom detections |
| Threat intelligence | Integrated with Mandiant threat intelligence for frontline threat data |
| Investigation | Case management, timeline reconstruction, and natural-language search powered by Gemini AI |
| SOAR | Automated response playbooks to contain and remediate threats |
For the exam, know that SecOps/Chronicle is Google's answer to "How do you detect and respond to active threats?" It is distinct from Security Command Center, which focuses on posture management and vulnerability detection.
Security Command Center (SCC)
Security Command Center is a centralized risk management platform for Google Cloud environments.
| Feature | Description |
|---|---|
| Vulnerability scanning | Detects misconfigurations, exposed resources, leaked credentials |
| Threat detection | Identifies active threats: malware, crypto miners, container attacks, data exfiltration |
| Compliance monitoring | Monitors against NIST, HIPAA, PCI-DSS, CIS benchmarks |
| Posture management | Defines and enforces security postures; prevents permission drift |
SCC tiers: Standard (basic vulnerability detection), Premium (advanced threat detection), Enterprise (full SOAR integration and analytics).
BeyondCorp Enterprise (Zero Trust)
BeyondCorp is Google's implementation of the zero-trust security model, originally developed for Google's own workforce.
Core zero-trust principles:
- Access to services must not be determined by the network you connect from
- Access is granted based on contextual factors: user identity, device health, location, time
- All access must be authenticated, authorized, and encrypted
| Traditional VPN Model | BeyondCorp Zero-Trust Model |
|---|---|
| Trust anyone inside the network perimeter | Trust no one by default; verify every request |
| VPN grants broad network access | Access granted per-application based on context |
| Device location determines trust | Device health and identity determine trust |
| Perimeter is the security boundary | Identity is the security boundary |
BeyondCorp uses Access Context Manager as its policy engine, allowing administrators to define fine-grained conditions (IP range, device OS version, encryption status) for application access. Employees access applications through Chrome with built-in threat and data protection.
Exam trap: BeyondCorp eliminates the need for a traditional VPN. If the exam presents a scenario where remote workers need secure application access, BeyondCorp or IAP (Identity-Aware Proxy) is the zero-trust answer, not VPN tunnels. Identity-Aware Proxy (IAP) is a Google Cloud service that controls access to cloud applications and VMs based on user identity and context (device, location, IP) rather than network location -- it enforces per-request authentication without requiring a VPN.
5.3 Google Cloud's Trust Principles and Compliance
Google's Trust Principles
Google Cloud makes explicit commitments about how it handles customer data. These are testable facts.
| Principle | What It Means |
|---|---|
| Customer data ownership | You own your data, not Google. Google does not scan data for advertising and does not sell it to third parties. |
| No data selling | Google will never sell customer data or use it to train AI models without explicit customer permission |
| Transparency | Google publishes transparency reports about government data requests and notifies customers unless prohibited by law |
| Data portability | Customers can export their data at any time without penalty |
| Access Transparency | Access Transparency logs show when Google personnel access customer data and why |
| Access Approval | Customers can require explicit approval before Google support staff can access their data |
Transparency Reports and Third-Party Audits
Google undergoes independent third-party audits to validate its security controls. Know these certifications by name.
| Certification / Standard | Scope |
|---|---|
| SOC 1 / SOC 2 / SOC 3 | Controls over financial reporting (SOC 1), security and availability (SOC 2), and public-facing summary (SOC 3) |
| ISO/IEC 27001 | Information security management system (ISMS) |
| ISO/IEC 27017 | Cloud-specific security controls |
| ISO/IEC 27018 | Protection of personally identifiable information (PII) in public clouds |
| ISO/IEC 27701 | Privacy information management |
| HIPAA | Health Insurance Portability and Accountability Act; Google Cloud signs Business Associate Agreements (BAAs) |
| FedRAMP | Federal Risk and Authorization Management Program; required for US government workloads |
| PCI DSS | Payment Card Industry Data Security Standard; for handling credit card data |
| CSA STAR | Cloud Security Alliance Security, Trust, Assurance, and Risk registry |
Google also holds ISO 9001 (quality management), ISO 22301 (business continuity), and ISO/IEC 42001 (AI management system) certifications.
Data Sovereignty and Data Residency
These two concepts are related but distinct. The exam may test whether you know the difference.
| Concept | Definition |
|---|---|
| Data residency | The physical location where data is stored. Google Cloud allows you to choose the region where your data is stored. |
| Data sovereignty | The legal principle that data is subject to the laws of the country where it is stored. Choosing a region determines which country's laws apply. |
Google Cloud tools for data residency and sovereignty:
- Organization policies -- restrict which regions resources can be created in
- Assured Workloads -- configures compliant environments with data residency controls, personnel access restrictions, and encryption requirements for regulated industries (government, healthcare, financial services)
- VPC Service Controls -- creates security perimeters around Google Cloud resources to prevent data exfiltration. Unlike VPC firewall rules (which control network traffic), VPC Service Controls restrict API-level access to services like BigQuery and Cloud Storage, preventing data from being copied or accessed outside the perimeter
Compliance Resource Center and Compliance Reports Manager
| Tool | Purpose |
|---|---|
| Compliance Resource Center | Central hub for exploring Google Cloud's compliance certifications, audit reports, and regulatory mappings by industry and region |
| Compliance Reports Manager | Self-service tool for downloading audit reports (SOC, ISO, etc.) and compliance documentation directly from the Google Cloud console |
The Shared Responsibility Model
Google Cloud uses a shared responsibility model where security duties are divided between Google (the provider) and the customer. The exact split depends on the service type.
| Responsibility | IaaS (Compute Engine) | PaaS (App Engine) | SaaS (Google Workspace) |
|---|---|---|---|
| Physical infrastructure | |||
| Network infrastructure | |||
| Hardware / firmware | |||
| Operating system | Customer | ||
| Middleware / runtime | Customer | ||
| Application code | Customer | Customer | |
| Data | Customer | Customer | Customer |
| Access policies / IAM | Customer | Customer | Customer |
| Content | Customer | Customer | Customer |
The customer is always responsible for their data, access policies, and content regardless of service model.
Google extends this model with the concept of shared fate, which means Google actively invests in tooling, blueprints, and best-practice guidance (like Security Foundations Blueprint) to help customers meet their security responsibilities -- rather than simply drawing a line and leaving customers to figure out their side alone.
Exam trap: In a shared responsibility model question, "Google handles all security" is always wrong. The customer is always responsible for data, access policies, and user management. Even with SaaS, you manage who can access what.
Quick-Reference: Which Service Solves Which Problem
| Problem | Google Cloud Service |
|---|---|
| Control who can access which resources | IAM |
| Protect web apps from DDoS and application attacks | Cloud Armor |
| Detect misconfigurations and vulnerabilities in your cloud environment | Security Command Center |
| Detect and respond to active security threats (SIEM/SOAR) | Google Security Operations (Chronicle) |
| Enable zero-trust access without VPN | BeyondCorp Enterprise / Identity-Aware Proxy |
| Manage encryption keys with customer control | Cloud KMS (CMEK) |
| Process data while encrypted in memory | Confidential Computing |
| Restrict where resources can be created (data residency) | Organization Policies + Assured Workloads |
| Prevent data from leaving a security perimeter | VPC Service Controls |
| Download compliance and audit reports | Compliance Reports Manager |
Common Exam Traps Summary
- "Google encrypts everything, so security is handled" -- Wrong. Encryption is default, but access control, application security, and data classification are your responsibility.
- Basic roles in production -- Owner/Editor/Viewer are too broad. The correct answer for production is predefined or custom roles.
- Cloud Armor for all traffic -- Cloud Armor works with load balancers. For VM-level firewall rules, use VPC firewall rules.
- VPN as the zero-trust answer -- BeyondCorp and Identity-Aware Proxy are the zero-trust answers. VPN is the legacy approach.
- CMEK adds encryption -- No. All data is already encrypted. CMEK changes who controls the encryption keys.
- Security Command Center vs. Chronicle -- SCC is for posture and vulnerability management. Chronicle/SecOps is for threat detection and incident response (SIEM/SOAR).
- Shared responsibility = Google does everything -- Never true. Customer always owns data, access policies, and content.
- Data residency vs. data sovereignty -- Residency is where data physically lives. Sovereignty is which laws govern that data. Choosing a region addresses both.
References
- Google Cloud Digital Leader Certification Guide
- Google Cloud Security Overview Whitepaper
- IAM Overview
- Cloud Armor Overview
- Default Encryption at Rest
- Encryption in Transit
- Customer-Managed Encryption Keys (CMEK)
- Security Command Center Overview
- Google Security Operations (Chronicle) Overview
- BeyondCorp Enterprise
- Shared Responsibility and Shared Fate
- Google Cloud Compliance
- Google Cloud Trust Center