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.serviceAccountAdminandiam.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
generateAccessTokenwhen 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:
- Create a Workload Identity Pool
- Add a Provider (AWS, Azure AD, OIDC, SAML)
- Map external attributes to Google Cloud attributes
- 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:
- Enable Data Access logs for all sensitive services
- Export logs to Cloud Storage (long-term retention) and BigQuery (analysis)
- Use Access Transparency to see when Google staff access your data
- Configure Access Approval to require your approval before Google support access
- Maintain asset inventory with Cloud Asset Inventory
- Run Security Command Center for continuous security posture assessment
- 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
- IAM Overview
- Resource Hierarchy
- VPC Service Controls
- Cloud KMS Concepts
- Default Encryption at Rest
- Compliance Offerings
- Sensitive Data Protection Overview
- Cloud Audit Logs
- Binary Authorization
- Identity-Aware Proxy
- Cloud Armor Overview
- Organization Policy Service
- Workload Identity Federation
- Secret Manager
- Assured Workloads