Reference

Domain 3: Designing for Security and Compliance (~17.5%)

This domain tests your ability to design secure architectures that meet compliance requirements. The v6.1 update adds AI security (Model Armor, Sensitive Data Protection for AI workloads) and expands software supply chain security.

3.1 Designing for Security

Resource Hierarchy and IAM

Google Cloud's resource hierarchy determines how IAM policies are inherited:

Organization (domain-level)
  └── Folders (departments, teams, environments)
       └── Projects (billing boundary, resource container)
            └── Resources (VMs, buckets, datasets)
Hierarchy Level Purpose IAM Inheritance
Organization Domain-wide policies, org admin Policies flow DOWN to all children
Folder Group projects by department/env Inherits from org, flows to projects
Project Billing and resource boundary Inherits from folder and org
Resource Individual service instances Inherits from project, folder, org

Key rule: IAM policies are additive only — you cannot remove a permission granted at a higher level. A user granted Editor at the folder level has Editor on every project in that folder.

Exam Trap: You cannot use a deny policy at a lower level to override an allow policy from a higher level using standard IAM. Use IAM Deny Policies (separate mechanism) to explicitly deny specific permissions regardless of allow policies.

IAM Roles

Role Type Scope Example When to Use
Primitive (Basic) Entire project Owner, Editor, Viewer Almost never — too broad
Predefined Specific service roles/compute.instanceAdmin Default choice — follows least privilege
Custom User-defined permissions roles/myorg.dbReader When predefined roles grant too much

Separation of duties — critical for the exam:

  • No single person should have both iam.serviceAccountAdmin and iam.serviceAccountKeyAdmin
  • Separate the roles that create resources from those that manage access to them
  • Use Organization Policy constraints to enforce boundaries

Exam Trap: Primitive roles (Owner, Editor, Viewer) should almost never be the answer. The exam strongly favors predefined roles with least privilege. If a question asks how to grant "minimal permissions," a primitive role is wrong.

Authentication Methods

Method Use Case Key Details
Google Account Human users (individual) Email-based identity, supports MFA
Google Workspace / Cloud Identity Managed user accounts Centralized admin, SSO, lifecycle management
Service Account Applications, VMs, workloads Key-based or metadata-based, acts as both identity and resource
Workload Identity Federation External workloads (AWS, Azure, OIDC) No service account keys needed, maps external identities
Titan Security Key Hardware MFA FIDO2/U2F, phishing-resistant

Service account best practices:

  • Prefer attached service accounts (metadata server) over service account keys
  • Use Workload Identity on GKE — maps Kubernetes SAs to Google Cloud SAs
  • Disable default Compute Engine and App Engine service accounts (too permissive)
  • Use short-lived credentials via generateAccessToken when possible

Exam Trap: Default service accounts have the Editor role. The exam expects you to know this is overly permissive and that best practice is to create custom service accounts with minimal permissions.

Workload Identity Federation

Enables external identities (AWS IAM, Azure AD, OIDC providers, SAML) to access Google Cloud resources without service account keys:

  1. Create a Workload Identity Pool
  2. Add a Provider (AWS, Azure AD, OIDC, SAML)
  3. Map external attributes to Google Cloud attributes
  4. Grant IAM roles on the service account to the federated identity

Key benefit: Eliminates long-lived service account keys for cross-cloud workloads.

VPC Service Controls

VPC Service Controls create security perimeters around Google Cloud resources to prevent data exfiltration:

Component Purpose
Service Perimeter Boundary around projects — restricts API access
Access Level Conditions that allow access into the perimeter (IP, device, identity)
Ingress Rule Allow specific external clients to access resources inside
Egress Rule Allow resources inside to access specific external resources
Bridge Connect two perimeters to allow cross-perimeter access
Dry Run Mode Test perimeter without enforcing — logs violations

Exam Trap: VPC Service Controls protect against data exfiltration at the API level, not at the network level. They complement (don't replace) firewall rules. A user with valid IAM permissions can still be blocked by VPC Service Controls if they're outside the perimeter.

Organization Policies

Organization Policy Service enforces constraints across the resource hierarchy:

Common Constraint What It Does
constraints/compute.disableSerialPortAccess Prevents SSH via serial console
constraints/compute.vmExternalIpAccess Restricts which VMs can have external IPs
constraints/iam.disableServiceAccountKeyCreation Prevents creating SA keys
constraints/gcp.resourceLocations Restricts where resources can be created
constraints/compute.requireShieldedVm Requires Shielded VMs
constraints/sql.restrictPublicIp Prevents public IPs on Cloud SQL

Policies are inherited down the hierarchy. Override is possible at lower levels if allowed by the constraint type (list constraints support merging, boolean constraints support override).

Identity-Aware Proxy (IAP)

IAP provides context-aware access to applications without a VPN:

  • Verifies user identity AND device context before granting access
  • Works with App Engine, Compute Engine (via load balancer), GKE
  • Supports BeyondCorp zero-trust model
  • Uses OAuth 2.0 for authentication
  • Integrates with Access Context Manager for device posture checks

Exam Trap: IAP replaces VPN for application access in zero-trust architectures. If a question asks about secure access to internal web apps without VPN, IAP is the answer.

Cloud Armor

Cloud Armor provides WAF and DDoS protection:

Feature Description
Pre-configured WAF rules OWASP Top 10 (SQLi, XSS, RCE, LFI)
Custom rules CEL-based expressions for IP, geo, header matching
Adaptive Protection ML-based anomaly detection for L7 DDoS
Rate limiting Throttle requests by IP or other attributes
Bot management reCAPTCHA Enterprise integration
Named IP lists Allow/deny by third-party IP lists

Cloud Armor attaches to external HTTP(S) load balancers and external proxy load balancers only. It does not protect internal load balancers.

Encryption

State Default Customer-Managed (CMEK) Customer-Supplied (CSEK)
At rest AES-256, Google-managed keys Customer controls key in Cloud KMS Customer provides key with each API call
In transit TLS 1.2+ between services N/A N/A
In use Not encrypted by default N/A Confidential VMs — AMD SEV / Intel TDX

Cloud KMS key management:

Protection Level Description Use Case
SOFTWARE Keys stored in software General purpose, lowest cost
HSM Hardware Security Module (FIPS 140-2 Level 3) Regulatory requirements
EXTERNAL Key stored in external KMS (EKM) Data sovereignty, keep-your-own-key
EXTERNAL_VPC EKM over VPC network EKM with private connectivity

Key rotation: Automatic rotation is supported. Old key versions are retained for decryption but new data uses the primary version.

Exam Trap: Default encryption (Google-managed) is always on — you cannot disable it. CMEK adds customer control over key lifecycle. CSEK means Google never stores the key. Know the trade-offs: CSEK offers maximum control but key loss = permanent data loss.

Secret Manager

Secret Manager stores API keys, passwords, certificates:

  • Automatic versioning — pin to specific version or use latest
  • IAM-based access control (per-secret granularity)
  • Automatic rotation via Cloud Functions
  • Regional and multi-regional replication policies
  • Audit logging of all access

Securing AI (NEW in v6.1)

Service Purpose
Model Armor Screens prompts and responses for harmful content, injection attacks
Sensitive Data Protection Inspect and de-identify PII in training data and model outputs
Secure model deployment VPC Service Controls around Vertex AI endpoints
Data governance Data lineage, access controls on training datasets

Security Command Center (SCC)

Security Command Center is Google Cloud's centralized security and risk management platform. It provides visibility into security posture, threat detection, and compliance monitoring across your organization.

Tier Key Capabilities
Standard (free) Security Health Analytics (misconfigurations), Web Security Scanner (basic), asset inventory, IAM anomaly detection
Premium All Standard features plus Event Threat Detection (ETD), Container Threat Detection, Virtual Machine Threat Detection, Rapid Vulnerability Detection, compliance monitoring (CIS, PCI DSS, NIST), attack path simulation
Enterprise All Premium features plus Mandiant threat intelligence, Chronicle SIEM/SOAR integration, posture management, toxic combination detection

Key features for the exam:

  • Security Health Analytics: Identifies misconfigurations (public buckets, open firewall rules, unencrypted disks)
  • Event Threat Detection: Detects threats in real-time from Cloud Logging data (cryptomining, malware, data exfiltration attempts)
  • Container Threat Detection: Monitors GKE for suspicious container behavior (reverse shells, unexpected binaries)
  • Attack path simulation: Identifies paths an attacker could take to reach high-value resources

Exam Trap: SCC Standard is free but limited to misconfiguration detection. SCC Premium adds threat detection (ETD) and compliance monitoring. If a scenario asks about detecting active threats (not just misconfigurations), the answer requires SCC Premium or Enterprise tier.

Access Context Manager

Access Context Manager defines fine-grained, attribute-based access policies. It is the policy engine behind VPC Service Controls access levels and IAP context-aware access.

Component Purpose
Access Level Conditions based on IP ranges, device posture, user identity, or geographic location
Access Policy Organization-level container for access levels and service perimeters

Access Context Manager integrates with:

  • VPC Service Controls: Defines who can cross a service perimeter
  • IAP: Defines context requirements for application access
  • Chrome Enterprise Premium: Device trust assessment

Chrome Enterprise Premium

Formerly BeyondCorp Enterprise. Extends zero-trust to endpoints:

  • Device trust assessment (managed, encrypted, patched)
  • URL filtering and malware protection
  • Data loss prevention in the browser
  • Integrates with IAP for context-aware access

Software Supply Chain Security

Component Purpose
Binary Authorization Enforce deploy-time policy — only signed container images can deploy
Artifact Registry Store container images with vulnerability scanning
Container Analysis Automated vulnerability scanning on push
SLSA framework Supply chain Levels for Software Artifacts — attestation chain
Software Delivery Shield End-to-end supply chain security across SDLC

Exam Trap: Binary Authorization enforces that only attested (signed) images deploy to GKE or Cloud Run. It does NOT scan for vulnerabilities — that's Container Analysis / Artifact Registry scanning. They work together but are separate services.

3.2 Designing for Compliance

Compliance Frameworks

Framework Type Key Requirements
HIPAA Legal (healthcare) BAA required, PHI encryption, access controls, audit logging
GDPR Legal (EU data privacy) Data residency, right to erasure, consent management, DPO
CCPA Legal (California privacy) Consumer data rights, opt-out of sale, privacy notices
PCI DSS Commercial (payment card) Network segmentation, encryption, access controls, logging
SOC 2 Industry audit Security, availability, confidentiality, processing integrity, privacy
ISO 27001 Industry standard Information security management system (ISMS)
FedRAMP Government (US) Security controls for federal data, Assured Workloads

Shared Responsibility Model

Layer Google's Responsibility Customer's Responsibility
Physical infrastructure Data centers, hardware, networking N/A
Storage encryption Default encryption at rest Key management choices (CMEK/CSEK)
Network security Global backbone, DDoS protection Firewall rules, VPC design, IAM
Identity Authentication infrastructure IAM policies, MFA enforcement, user lifecycle
Data Infrastructure availability Data classification, access controls, retention
Application Managed service security patches Application-level security, code vulnerabilities
Compliance Certifications, BAAs, audit reports Configuration, evidence collection, policy enforcement

Cloud DLP / Sensitive Data Protection

Sensitive Data Protection (formerly Cloud DLP) inspects and transforms sensitive data:

Capability Description
Inspection Detect PII (SSN, credit cards, emails) in text, images, structured data
De-identification Mask, tokenize, or redact sensitive data
Re-identification Reverse tokenization (with appropriate key)
Risk analysis Assess re-identification risk of datasets
InfoTypes 150+ built-in detectors, plus custom patterns

Supported data sources: Cloud Storage, BigQuery, Datastore, and any text/image via API.

Cloud Audit Logs

Log Type Enabled By Default Retention Content
Admin Activity Always on, cannot disable 400 days Resource configuration changes
Data Access Off by default (except BigQuery) 30 days (default) Read/write of resource data
System Event Always on, cannot disable 400 days Google-initiated system events
Policy Denied Always on, cannot disable 30 days Access denied by policy

Exam Trap: Data Access logs are OFF by default (except for BigQuery, which has them on by default). You must explicitly enable them. They can generate high volume and cost. Admin Activity logs are always on and free.

Data Residency and Sovereignty

Service Data Location Control
Cloud Storage Region or multi-region selection at bucket creation
Cloud SQL Regional selection at instance creation
Spanner Regional or multi-region configuration
BigQuery Dataset-level region selection
Assured Workloads Enforced data residency with org policy constraints

Assured Workloads creates compliance-controlled environments:

  • Enforces data residency via organization policies
  • Restricts personnel access by nationality (for government workloads)
  • Supports FedRAMP, IL4/IL5, CJIS, ITAR, and regional compliance
  • Automatic guardrails — prevents misconfiguration that would violate compliance

Exam Trap: Assured Workloads is the answer when questions ask about meeting government compliance requirements (FedRAMP, IL4) on Google Cloud. It's not just a label — it enforces actual technical controls.

Audit Readiness

Preparing for compliance audits on Google Cloud:

  1. Enable Data Access logs for all sensitive services
  2. Export logs to Cloud Storage (long-term retention) and BigQuery (analysis)
  3. Use Access Transparency to see when Google staff access your data
  4. Configure Access Approval to require your approval before Google support access
  5. Maintain asset inventory with Cloud Asset Inventory
  6. Run Security Command Center for continuous security posture assessment
  7. Document all controls, exceptions, and risk acceptances

Exam Traps — Quick Reference

Trap Correct Answer
Use primitive roles for quick setup Never — always use predefined roles with least privilege
VPC Service Controls = firewall rules No — VPC-SC operates at the API level, firewalls at network level
Default encryption can be disabled No — always-on AES-256, CMEK/CSEK adds control on top
Data Access logs are on by default Off by default (except BigQuery) — must be explicitly enabled
Service account keys are best practice No — prefer attached SAs, Workload Identity, or WIF
Binary Authorization scans for vulnerabilities No — it enforces attestation policies; Container Analysis scans
IAP requires a VPN No — IAP replaces VPN with identity-based access
Deny policies override allow policies Standard IAM is additive only; IAM Deny is a separate mechanism
CSEK keys are stored by Google No — customer supplies key with each API call, Google never persists it
Assured Workloads is just a compliance label No — it enforces actual technical controls (data residency, personnel access)

References