Google Cloud PCA - Section 5
Security, Identity, Governance, and Compliance
PCA lens: security questions are usually about choosing the right control boundary. The exam expects least privilege, defense in depth, auditability, data protection, and governance at scale. For most questions, the most Google-native, managed, policy-driven control is preferred over hand-built security logic.
Fast Decision Matrix
Service / Control | What it is | Pick it when... | Common PCA trap |
|---|---|---|---|
Resource hierarchy | Organization, folders, projects, resources | Need scalable access, billing, policy, and environment separation | Putting everything in one project or using projects as the only boundary |
IAM / allow policies | Who can do what on which resource | Grant least privilege across org/folder/project/resource levels | Using Owner/Editor/Viewer because it is quick |
IAM roles | Basic, predefined, and custom permission bundles | Prefer predefined roles, then custom roles when least privilege requires it | Overusing custom roles or primitive roles |
IAM Conditions | Attribute-based conditions on IAM grants | Restrict access by time, resource name, request attributes, or tags | Using conditions to replace network controls or data perimeters |
Service accounts | Non-human workload identities | Apps, VMs, GKE, CI/CD, and automation need Google API access | Long-lived keys, shared service accounts, or overbroad roles |
Service account impersonation | Short-lived access as a service account | Developers/automation need temporary delegated access without static keys | Giving users permanent broad roles instead |
Workload Identity Federation | External workloads authenticate without service account keys | AWS/Azure/on-prem/GitHub workloads need Google Cloud access | Creating downloadable service account keys |
Workforce Identity Federation | External users authenticate with corporate IdP | Employees/partners use SSO without Google-managed user accounts | Confusing workforce users with workload identities |
Organization Policy Service | Preventive guardrails | Enforce region, public IP, service account key, domain, and resource restrictions | Expecting org policy to grant permissions |
VPC Service Controls | Data exfiltration perimeter for supported Google services | Protect GCS, BigQuery, and other managed services from data copy/exfil paths | Thinking it is a firewall or subnet boundary |
IAP / Context-Aware Access | Identity-aware access to apps, SSH, and RDP | Secure admin/app access without traditional VPN exposure | Using public IPs and firewall allowlists as the only control |
Cloud KMS / CMEK / HSM / EKM | Key management and encryption control | Need customer control, rotation, auditability, HSM-backed keys, or external key custody | Assuming CMEK means Google cannot operate the service |
Secret Manager | Centralized secrets and versions | Store API keys, DB passwords, certs, and rotate access safely | Hardcoding secrets or storing them in code/env files |
Sensitive Data Protection | Discover, classify, mask, and de-identify sensitive data | Find PII/PCI/PHI and reduce sensitive data exposure | Thinking encryption alone solves data classification |
Security Command Center | Centralized security posture and findings | Org-wide visibility into misconfigurations, vulnerabilities, threats, and compliance | Treating SCC as a SIEM replacement only |
Audit Logs / Asset Inventory | Audit trail and resource inventory | Need investigation, compliance evidence, asset search, and change history | Not enabling Data Access logs where needed |
Binary Authorization / Artifact Analysis | Software supply-chain controls | Only trusted/signed/scanned images deploy to production | Scanning images but not enforcing deployment policy |
Model Armor | AI prompt/response protection | Protect GenAI apps from prompt injection and unsafe content/data exposure | Ignoring AI-specific security in architecture questions |
Exam shortcut: identity answers usually start with least privilege IAM, service accounts, impersonation, and federation. Governance answers usually start with resource hierarchy and Organization Policy. Data exfiltration answers often point to VPC Service Controls. Sensitive data answers point to Sensitive Data Protection. Security posture answers point to Security Command Center.
Service and Concept Deep Dives
Identity and Access
Service / Concept | Why an org uses it | PCA exam trigger | Common trap / confused with |
|---|---|---|---|
Cloud IAM | Organizations use IAM to centrally control access to Google Cloud resources. It answers who can do what on which resource, and it is the foundation for least privilege across projects, folders, and the organization. | Least privilege, RBAC, resource-level access, shared admin model, service access control. | Do not default to Owner/Editor. Prefer predefined roles, custom roles only when needed. |
IAM allow policies | Allow policies bind principals to roles on resources. Orgs use them to grant access at the narrowest practical level while inheriting broader policies from folders or the organization when appropriate. | Access inheritance, org/folder/project design, role bindings. | An allow policy grants access; it does not prevent other inherited access by itself. |
IAM deny policies | Deny policies create explicit guardrails that block specific permissions even if another policy grants them. They help enforce high-risk restrictions across many projects. | Need to block sensitive actions at scale, such as deleting critical resources or using risky permissions. | Do not use deny as the first answer for normal least-privilege design. Start with better allow-policy scoping. |
Predefined roles | Orgs use predefined roles because Google maintains them for common job functions and service-specific access patterns. They are usually the best balance of least privilege and manageability. | Need appropriate access without building permissions from scratch. | Predefined roles can still be too broad; verify the role matches the job. |
Custom roles | Custom roles are used when no predefined role matches the required least-privilege permission set. They are common for regulated teams or tightly scoped operations. | Strict least privilege, separation of duties, custom admin/operator roles. | Custom roles add maintenance overhead and can break if service permissions evolve. |
Basic / primitive roles | Basic roles are legacy broad roles like Owner, Editor, and Viewer. Orgs may encounter them in old environments, but they are generally avoided for production least privilege. | Exam may ask you to reduce overbroad access. | Wrong answer when a narrower predefined or custom role exists. |
IAM Conditions | Orgs use IAM Conditions to add context to access grants, such as time-based access, resource-name restrictions, or attributes. This reduces standing access without creating many one-off roles. | Temporary access, conditional access, scoped access by resource/tag/time. | Not a replacement for VPC-SC, firewall rules, or application authorization. |
Service accounts | Service accounts represent non-human identities for workloads and automation. Orgs use them so apps, VMs, GKE workloads, CI/CD pipelines, and jobs can access Google APIs without using user accounts. | Machine identity, app access to APIs, workload permissions. | Avoid shared service accounts and long-lived service account keys. |
Service account impersonation | Impersonation lets a user or workload get short-lived credentials for a service account. Orgs use it for temporary elevation, local development, CI/CD, and delegated access without static keys. | Need temporary admin/deploy access, auditable delegation, no downloaded keys. | The impersonating principal can access what the service account can access, so the service account still needs least privilege. |
Workload Identity Federation | External workloads can use their native identity from AWS, Azure, on-prem, GitHub, or another IdP to obtain short-lived Google credentials. Orgs use it to avoid service account keys. | External workloads need Google Cloud access securely without key rotation pain. | Do not confuse it with Workforce Identity Federation for human users. |
Workforce Identity Federation | Human users from an external IdP can use SSO to access Google Cloud resources. Orgs use it for employees, contractors, and partners without creating separate Google identities for everyone. | Corporate SSO, external workforce, identity provider integration. | Not for application workloads. Use Workload Identity Federation for workloads. |
Workload Identity for GKE | GKE workloads can authenticate to Google APIs as IAM service accounts without node-level keys. Orgs use it to separate pod identity from node identity and reduce credential exposure. | GKE pod needs Cloud Storage, Pub/Sub, BigQuery, Secret Manager, etc. | Do not attach broad permissions to the node service account and let every pod inherit them. |
Resource hierarchy | Organizations use org, folders, projects, and resources to model business units, environments, billing, ownership, IAM inheritance, and policy boundaries. | Need scalable landing zone, prod/dev separation, centralized governance. | Projects are not just folders. They are isolation, quota, billing, IAM, and API boundaries. |
Governance, Policy, and Perimeters
Service / Concept | Why an org uses it | PCA exam trigger | Common trap / confused with |
|---|---|---|---|
Organization Policy Service | Org Policy sets preventive constraints across the resource hierarchy. Orgs use it to stop risky configurations before they happen, such as external IPs, public sharing, unsupported regions, or key creation. | Hard guardrails, allowed regions, disable service account keys, restrict domains. | Org Policy does not grant access; IAM grants access. Org Policy restricts what can be configured. |
Policy constraints | Constraints are the specific rules enforced by Organization Policy. They can be inherited or overridden depending on hierarchy and policy design. | Need to enforce standards consistently across folders/projects. | Check inheritance and exceptions. A folder/project exception may change behavior. |
VPC Service Controls | VPC-SC creates service perimeters around supported Google-managed services to reduce data exfiltration risk. Orgs use it for sensitive GCS, BigQuery, and managed-service data. | Data exfiltration prevention, perimeter around managed services, regulated data. | It is not a network firewall and does not protect every service or every path automatically. |
Identity-Aware Proxy / IAP | IAP controls access to web apps and admin protocols based on identity and context. Orgs use it to avoid exposing apps, SSH, or RDP broadly and to reduce VPN dependence. | Secure web app access, SSH/RDP without public exposure, identity-aware access. | Not the same as a load balancer WAF. Cloud Armor handles edge web protection. |
Zero Trust, Workforce Access, and App Protection
Service / Concept | Why an org uses it | PCA exam trigger | Common trap / confused with |
|---|---|---|---|
Context-Aware Access | Orgs use Context-Aware Access to make access decisions based on user identity, device posture, IP, and other context, especially for zero-trust access patterns. | Access depends on device/user/location/risk context. | It complements IAM/IAP; it does not replace least privilege permissions. |
BeyondCorp Enterprise | BeyondCorp Enterprise is Google’s enterprise zero-trust access model/product family. Orgs use it to provide secure access to apps without relying on traditional network perimeter assumptions. | Zero-trust access, workforce access modernization, replace broad VPN access. | Do not treat it as a single firewall product. It is a broader access/security model. |
Chrome Enterprise Premium | Orgs use Chrome Enterprise Premium for secure enterprise access, browser-based security, and context-aware controls for workforce access to apps and data. | Secure remote access, context-aware enterprise app access. | More workforce/security access focused than core Google Cloud workload IAM. |
Cloud Identity | Cloud Identity provides identity management for Google Cloud and Workspace identities. Orgs use it to manage users, groups, SSO, MFA, and lifecycle controls. | Centralized identity management for Google Cloud users and groups. | For Microsoft-native domain services, Managed Service for Microsoft AD is different. |
Managed Service for Microsoft Active Directory | Orgs use managed AD for Windows workloads, domain join, LDAP/Kerberos, and Group Policy without running their own domain controllers on Compute Engine. | Windows workloads require AD, domain services, group policies. | Not the right answer for Google Cloud IAM authorization to Google APIs. |
Cloud Armor | Cloud Armor provides edge WAF and DDoS protection for external load-balanced apps. Orgs use it to block malicious web traffic, apply WAF rules, geo/IP controls, and protect internet-facing services. | WAF, DDoS, HTTP(S) load balancer protection, block bad IPs/geos. | Cloud Armor protects at the edge; it is not IAM and not data classification. |
Cloud KMS | Cloud KMS lets orgs create and manage cryptographic keys for Google Cloud services and custom apps. It centralizes key lifecycle, rotation, permissions, and auditability. | Need customer-controlled keys, rotation, audit logs, integration with CMEK services. | Google-managed encryption is already default; KMS is for additional control. |
Keys, Secrets, and Sensitive Data
Service / Concept | Why an org uses it | PCA exam trigger | Common trap / confused with |
|---|---|---|---|
CMEK | Customer-managed encryption keys give customers ownership/control over keys that protect supported Google Cloud data at rest. Orgs use CMEK for compliance, auditability, and key revocation requirements. | Customer-controlled encryption, compliance, key rotation/revocation. | CMEK adds control but also operational responsibility. Losing/disable keys can break access. |
CSEK | Customer-supplied encryption keys are supplied directly by the customer for some services. Orgs might use them for very specific legacy/compliance cases. | Strict customer-supplied key requirement. | Usually lower priority than CMEK. More operational burden and limited service support. |
Cloud HSM | Cloud HSM gives hardware-backed key protection managed through Cloud KMS. Orgs use it when compliance requires keys generated and stored in hardware security modules. | FIPS/HSM-backed key requirement, regulated workloads. | Do not choose HSM just because data is sensitive. CMEK may be enough. |
Cloud External Key Manager / EKM | Cloud EKM lets Google Cloud use keys managed outside Google Cloud. Orgs use it when they need external key custody or separation from the cloud provider. | External key custody, strict sovereignty/regulatory control. | Adds latency, availability, and operational dependency on the external key manager. |
Secret Manager | Secret Manager stores and versions secrets such as API keys, passwords, certificates, and tokens. Orgs use it to centralize secrets, control access with IAM, and audit access. | Need to remove secrets from code, env files, images, or config repos. | KMS encrypts keys/data. Secret Manager stores secret values and controls access to them. |
Cloud DLP / Sensitive Data Protection | Sensitive Data Protection discovers, classifies, masks, tokenizes, and de-identifies sensitive data. Orgs use it to find PII/PCI/PHI and reduce risk before storing or sharing data. | PII discovery, redaction, masking, tokenization, data classification. | Encryption protects data access; DLP tells you what sensitive data exists and can transform it. |
Security Command Center / SCC | SCC provides centralized security posture, asset visibility, vulnerability/threat findings, attack path context, and compliance posture depending on tier. Orgs use it as the Google Cloud security control plane. | Org-wide security posture, findings, misconfigs, vulnerabilities, threats, compliance. | It is not just a dashboard and not a replacement for all SIEM/SOAR workflows. |
Posture, Audit, Supply Chain, and Compliance
Service / Concept | Why an org uses it | PCA exam trigger | Common trap / confused with |
|---|---|---|---|
Cloud Audit Logs | Audit Logs provide records of admin activity, system events, policy decisions, and optionally data access. Orgs use them for investigation, compliance evidence, and accountability. | Need audit trail, who did what, compliance logging, incident investigation. | Data Access logs may need explicit enablement and can increase volume/cost. |
Cloud Asset Inventory | Asset Inventory stores metadata and history for Google Cloud assets and IAM policies. Orgs use it for inventory, search, change tracking, and governance reporting. | Need asset visibility, policy analysis, inventory history, security review. | Not a vulnerability scanner by itself. It tells you what exists and how it is configured. |
Assured Workloads | Assured Workloads helps configure and maintain workloads for compliance/data residency requirements. Orgs use it for regulated workloads needing location, personnel, and control restrictions. | Regulated industry, data residency, compliance boundary, sovereignty requirements. | It does not make the application compliant automatically. Customer architecture still matters. |
Binary Authorization | Binary Authorization enforces deployment policies for container images. Orgs use it so only trusted, signed, or approved images can deploy to GKE or Cloud Run. | Container supply-chain security, prod deployment gate, signed images. | Scanning alone is visibility. Binary Authorization is enforcement. |
Artifact Analysis / Container Analysis | Artifact Analysis provides vulnerability and metadata analysis for container/package artifacts. Orgs use it to identify vulnerable images and feed supply-chain policy decisions. | Image/package vulnerability metadata, CI/CD security, artifact risk. | Finding vulnerabilities does not block deployment unless enforcement is configured. |
Model Armor | Model Armor helps protect AI applications from prompt injection, malicious content, and sensitive data leakage patterns. Orgs use it for GenAI apps and agentic workflows. | GenAI security, prompt/response filtering, AI app guardrails. | Traditional IAM/network controls are not enough for prompt-layer risks. |
Separation of duties | Organizations split responsibilities so no single user or team can perform conflicting sensitive actions end-to-end. This reduces fraud, mistakes, and blast radius. | Approver/deployer split, auditor/admin split, prod access separation. | Do not solve separation of duties only with documentation. Use IAM, approvals, and policy controls. |
Data sovereignty | Orgs design where data is stored, processed, encrypted, and administered to meet legal/regulatory requirements. This often combines regions, Assured Workloads, KMS/EKM, IAM, and audit controls. | Data residency, regional restrictions, sovereign control, regulated customers. | Region selection alone may not satisfy sovereignty requirements. |
Auditability and log retention | Orgs keep logs long enough and route them to durable destinations for investigation and compliance. This usually combines Audit Logs, Logging sinks, Cloud Storage, BigQuery, and SCC exports. | Compliance evidence, incident response, retention requirements. | Default log retention may not meet compliance needs. Design sinks and retention intentionally. |
High-Value PCA Comparison Patterns
Comparison | How to choose on PCA |
|---|---|
IAM vs Organization Policy | IAM grants who can do something. Organization Policy restricts what can be configured. In exam wording, permissions = IAM; guardrails = Org Policy. |
IAM Conditions vs VPC Service Controls | IAM Conditions narrow access based on attributes. VPC-SC protects supported managed-service data from exfiltration across a service perimeter. |
Service account keys vs impersonation/federation | Keys are usually the risky/wrong answer. Prefer attached service accounts for Google Cloud workloads, impersonation for delegated access, and Workload Identity Federation for external workloads. |
Workload vs Workforce Identity Federation | Workload = applications/machines outside Google Cloud. Workforce = human users from an external identity provider. |
IAP vs Cloud VPN | IAP is identity-aware access to apps/SSH/RDP. VPN is network connectivity. If the goal is user access without broad network exposure, IAP is often the better PCA answer. |
Cloud KMS vs Secret Manager | KMS manages encryption keys. Secret Manager stores secret values. They are related but not interchangeable. |
CMEK vs HSM vs EKM | CMEK is customer-controlled keys in Cloud KMS. Cloud HSM is HSM-backed keys. Cloud EKM is external key custody outside Google Cloud. |
Sensitive Data Protection vs encryption | Encryption protects data from unauthorized access. Sensitive Data Protection discovers and transforms sensitive fields such as PII, PCI, and PHI. |
SCC vs Audit Logs vs Asset Inventory | SCC tells you risk/findings/posture. Audit Logs tell you activity. Asset Inventory tells you what exists and how it changed. |
Artifact Analysis vs Binary Authorization | Artifact Analysis detects and records risk metadata. Binary Authorization enforces whether images are allowed to deploy. |
Common PCA Traps
- Choosing primitive roles because they are easy. PCA usually expects least privilege with predefined or custom roles.
- Using service account keys when impersonation, attached service accounts, or Workload Identity Federation would avoid long-lived credentials.
- Confusing VPC Service Controls with firewall rules. VPC-SC is a managed-service data perimeter, not subnet traffic filtering.
- Thinking encryption solves classification. Sensitive Data Protection is for discovering, classifying, masking, and de-identifying sensitive data.
- Treating Organization Policy as IAM. Org Policy prevents configurations; IAM grants access.
- Leaving all workloads in one project. PCA expects projects/folders to support isolation, billing, IAM, policy, and blast-radius control.
- Scanning containers but not enforcing anything. Artifact Analysis finds issues; Binary Authorization can block untrusted deployments.
- Ignoring auditability. For regulated workloads, design logs, sinks, retention, and access reviews intentionally.
- Using a VPN for every workforce access problem. IAP and BeyondCorp-style access may be better when the business wants identity-aware access without broad network reachability.
- Overusing advanced controls. If Google-managed encryption and predefined IAM roles meet the requirement, do not add HSM/EKM/custom roles just because they sound more secure.
Cram Summary
Need | Think... |
|---|---|
Least privilege access | IAM predefined/custom roles, scoped at the narrowest resource level |
Prevent risky configurations | Organization Policy constraints |
Avoid service account keys | Attached service accounts, impersonation, Workload Identity Federation |
External workload access | Workload Identity Federation |
External user SSO | Workforce Identity Federation / Cloud Identity |
GKE pod access to Google APIs | Workload Identity for GKE |
Protect managed-service data from exfiltration | VPC Service Controls |
Secure app/admin access without broad VPN | IAP, Context-Aware Access, BeyondCorp / Chrome Enterprise Premium |
Customer control of encryption keys | Cloud KMS with CMEK |
HSM-backed or external keys | Cloud HSM / Cloud EKM |
Store secrets | Secret Manager |
Find and mask PII/PCI/PHI | Sensitive Data Protection |
Org-wide security posture/findings | Security Command Center |
Who did what | Cloud Audit Logs |
What exists and changed | Cloud Asset Inventory |
Regulated workload boundary | Assured Workloads |
Only trusted containers deploy | Binary Authorization plus Artifact Analysis |
Secure GenAI prompts/responses | Model Armor |
Bottom line: for PCA, do not memorize security products in isolation. Read the prompt for the control boundary: identity, resource hierarchy, preventive policy, data perimeter, encryption/key control, secret storage, data classification, posture detection, audit evidence, or deployment enforcement.
Question Wording Cheat Codes
If the prompt says... | Likely PCA answer |
|---|---|
Users need secure access to an internal web app without broad VPN access | IAP with Context-Aware Access / BeyondCorp pattern |
An AWS, Azure, GitHub, or on-prem workload needs Google Cloud access without static keys | Workload Identity Federation |
Employees or partners need SSO into Google Cloud from a corporate IdP | Workforce Identity Federation / Cloud Identity |
Stop teams from creating resources in unapproved regions or with external IPs | Organization Policy constraints |
Protect BigQuery/GCS managed-service data from copy or exfiltration paths | VPC Service Controls |
Find, classify, redact, tokenize, or mask PII/PCI/PHI | Sensitive Data Protection |
Customer must own and rotate the encryption key | Cloud KMS with CMEK |
Keys must be HSM-backed or controlled outside Google Cloud | Cloud HSM or Cloud EKM |
Store and version API keys, DB passwords, certificates, or tokens | Secret Manager |
Get org-wide misconfiguration, vulnerability, threat, and compliance findings | Security Command Center |
Show who changed IAM, deleted resources, or accessed sensitive data | Cloud Audit Logs, plus Data Access logs when needed |
Only signed/trusted container images can deploy to prod | Binary Authorization with Artifact Analysis |
Protect GenAI app prompts and responses from injection/data leakage | Model Armor |