Google Cloud Professional Cloud Security Engineer Ultimate Cheat Sheet
Your Quick Reference Study Guide
This cheat sheet covers the core concepts, terms, and definitions you need to know for the Google Cloud Professional Cloud Security Engineer. We've distilled the most important domains, topics, and critical details to help your exam preparation.
💡 Note: While this study guide highlights essential concepts, it's designed to complement—not replace—comprehensiv e learning materials. Use it for quick reviews, last-minute prep, or to identify areas that need deeper study before your exam.
About This Cheat Sheet: This study guide covers core concepts for Google Cloud Professional Cloud Security Engineer. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Google Cloud Professional Cloud Security Engineer
Cheat Sheet •
About This Cheat Sheet: This study guide covers core concepts for Google Cloud Professional Cloud Security Engineer. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Configuring Access
25%Workload Identity Federation (WIF) — External→Google Short Tokens
Exchange external OIDC/SAML credentials for short‑lived Google tokens via pools, providers and mapping.
Key Insight
WIF is an identity bridge: pools/providers + attribute mapping + service‑account impersonation produce short tokens; IAM roles still enforce access.
Often Confused With
Common Mistakes
- Don't mix WIF with Workforce Identity Federation — WIF is for non‑human workloads.
- Creating a provider/pool doesn't grant access — you must bind IAM roles to the target service account.
- WIF issues short‑lived tokens via token exchange; it does NOT create long‑lived credentials.
Google Cloud Identity — Managed Directory & Device Controls
Managed identity directory; Premium unlocks SCIM provisioning, Secure LDAP, advanced device policies and audit SLAs.
Key Insight
Premium adds SCIM, Secure LDAP, enhanced device management and audit retention — licensing enables features, it doesn't change IAM permissions.
Often Confused With
Common Mistakes
- Cloud Identity is NOT the same as Google Workspace — Workspace includes productivity apps.
- Secure LDAP and SCIM provisioning are NOT available in the Free tier — Premium required.
- Premium enables features and SLAs; it does not automatically grant extra GCP IAM roles.
Service Account Keys & Rotation
Manage lifecycle of long‑lived JSON keys; prefer short‑lived tokens or Workload Identity and scan repos for leaks.
Key Insight
Long‑lived service account keys are the biggest credential risk — rotate/retire them or replace with short‑lived tokens/Workload Identity.
Often Confused With
Common Mistakes
- Deleting a service account does NOT automatically revoke its existing keys
- Keeping old keys active during rotation still exposes credentials
- One-off repo scans miss leaked keys in branches, PRs and commit history
Service Accounts — Non‑Human Principals
Non‑human identities for workloads; grant least privilege, monitor in Cloud Audit Logs, use impersonation or Workload Id
Key Insight
Treat service accounts like users for IAM: least privilege, no broad default roles, avoid long‑lived keys and monitor audit logs.
Often Confused With
Common Mistakes
- Managing service accounts exactly like human users (no automated rotation or scoped roles)
- Assuming default/project service accounts are minimally privileged — they often have broad roles
- Believing service account keys auto‑rotate or are short‑lived
IAM Conditions — CEL Attribute Controls
Attach CEL predicates to IAM bindings to restrict access by context or mapped IdP claims; combine with Deny for fine-grn
Key Insight
Conditions limit when a binding applies (not role permissions); GCP evaluates mapped attributes at authz; Deny overrides Allow.
Often Confused With
Common Mistakes
- Attribute mapping doesn't grant access; IAM bindings do.
- Conditions are evaluated by GCP at authorization time, not by the IdP.
- Conditions restrict a binding's applicability; they don't change the role's permissions.
SAML SSO — EntityID / ACS / Certs
SAML 2.0 SSO uses signed XML assertions; configure exact metadata (EntityID, ACS URL, signing certs) and attribute-to-SS
Key Insight
EntityID, ACS URL and certs must match exactly; SAML authenticates only—authorization requires attribute mapping or SP-side roles; cert rotation musts
Often Confused With
Common Mistakes
- ACS URL must match exactly in metadata and SP config (protocol + path).
- Entity ID is a metadata identifier — it must match, not just be a friendly label.
- Rotating an IdP signing certificate requires coordinated metadata updates; it's not automatic.
Custom IAM Roles (Least-Privilege Packs)
User-defined sets of Google Cloud permissions to enforce least privilege when predefined roles are too broad.
Key Insight
Custom roles are static lists of valid permissions scoped to org/folder/project — changes can break access; always test and version before rollout.
Often Confused With
Common Mistakes
- Trying to edit Google-managed predefined roles instead of creating a custom role.
- Expecting custom roles to auto-update when permissions change in predefined roles.
- Assuming modifying or deleting a custom role is always non-disruptive to granted principals.
IAM Binding Scope — Project vs Folder vs Organization
Assign roles at the narrowest resource scope; higher-level bindings inherit downward and widen the blast radius.
Key Insight
Bindings inherit down (Org → Folder → Project). Lower-level bindings add permissions — they don't revoke higher-level grants; scope tightly to limit L
Often Confused With
Common Mistakes
- Granting broad roles (e.g., Editor) because a user is 'trusted'.
- Applying org or project-level grants by default — increases lateral movement risk.
- Believing a project-level binding overrides and removes higher-level grants.
Org Policy — Hierarchy Guardrails
Attach constraints at org/folder/project; children inherit limits — used to enforce config, not grant access.
Key Insight
Set restrictive rules at higher levels; children can only narrow settings — parents define the ceiling.
Often Confused With
Common Mistakes
- Thinking you must apply the same policy to every project — ancestor policies already apply.
- Assuming a lower-level policy can always override a parent — children cannot widen parent limits.
- Treating org policies like IAM role grants — they restrict config, they don't grant permissions.
Service Accounts — Scoped Identities
Project-scoped identities for workloads — place per-use, prefer Workload Identity, avoid long‑lived JSON keys.
Key Insight
Service accounts live in projects; prefer Workload Identity and enforce key restrictions via Org Policy (ban user keys).
Often Confused With
Common Mistakes
- Assuming service accounts are global/org-level reusable identities — they’re project-scoped resources.
- Believing disabling user-managed keys breaks all auth — workloads using Workload Identity or Google-managed creds still work.
- Relying on occasional rotation of long-lived JSON keys instead of moving to short-lived creds/Workload Identity.
Workload Identity Federation (WIF) — External→Google Short Tokens
Exchange external OIDC/SAML credentials for short‑lived Google tokens via pools, providers and mapping.
Key Insight
WIF is an identity bridge: pools/providers + attribute mapping + service‑account impersonation produce short tokens; IAM roles still enforce access.
Often Confused With
Common Mistakes
- Don't mix WIF with Workforce Identity Federation — WIF is for non‑human workloads.
- Creating a provider/pool doesn't grant access — you must bind IAM roles to the target service account.
- WIF issues short‑lived tokens via token exchange; it does NOT create long‑lived credentials.
Google Cloud Identity — Managed Directory & Device Controls
Managed identity directory; Premium unlocks SCIM provisioning, Secure LDAP, advanced device policies and audit SLAs.
Key Insight
Premium adds SCIM, Secure LDAP, enhanced device management and audit retention — licensing enables features, it doesn't change IAM permissions.
Often Confused With
Common Mistakes
- Cloud Identity is NOT the same as Google Workspace — Workspace includes productivity apps.
- Secure LDAP and SCIM provisioning are NOT available in the Free tier — Premium required.
- Premium enables features and SLAs; it does not automatically grant extra GCP IAM roles.
Service Account Keys & Rotation
Manage lifecycle of long‑lived JSON keys; prefer short‑lived tokens or Workload Identity and scan repos for leaks.
Key Insight
Long‑lived service account keys are the biggest credential risk — rotate/retire them or replace with short‑lived tokens/Workload Identity.
Often Confused With
Common Mistakes
- Deleting a service account does NOT automatically revoke its existing keys
- Keeping old keys active during rotation still exposes credentials
- One-off repo scans miss leaked keys in branches, PRs and commit history
Service Accounts — Non‑Human Principals
Non‑human identities for workloads; grant least privilege, monitor in Cloud Audit Logs, use impersonation or Workload Id
Key Insight
Treat service accounts like users for IAM: least privilege, no broad default roles, avoid long‑lived keys and monitor audit logs.
Often Confused With
Common Mistakes
- Managing service accounts exactly like human users (no automated rotation or scoped roles)
- Assuming default/project service accounts are minimally privileged — they often have broad roles
- Believing service account keys auto‑rotate or are short‑lived
IAM Conditions — CEL Attribute Controls
Attach CEL predicates to IAM bindings to restrict access by context or mapped IdP claims; combine with Deny for fine-grn
Key Insight
Conditions limit when a binding applies (not role permissions); GCP evaluates mapped attributes at authz; Deny overrides Allow.
Often Confused With
Common Mistakes
- Attribute mapping doesn't grant access; IAM bindings do.
- Conditions are evaluated by GCP at authorization time, not by the IdP.
- Conditions restrict a binding's applicability; they don't change the role's permissions.
SAML SSO — EntityID / ACS / Certs
SAML 2.0 SSO uses signed XML assertions; configure exact metadata (EntityID, ACS URL, signing certs) and attribute-to-SS
Key Insight
EntityID, ACS URL and certs must match exactly; SAML authenticates only—authorization requires attribute mapping or SP-side roles; cert rotation musts
Often Confused With
Common Mistakes
- ACS URL must match exactly in metadata and SP config (protocol + path).
- Entity ID is a metadata identifier — it must match, not just be a friendly label.
- Rotating an IdP signing certificate requires coordinated metadata updates; it's not automatic.
Custom IAM Roles (Least-Privilege Packs)
User-defined sets of Google Cloud permissions to enforce least privilege when predefined roles are too broad.
Key Insight
Custom roles are static lists of valid permissions scoped to org/folder/project — changes can break access; always test and version before rollout.
Often Confused With
Common Mistakes
- Trying to edit Google-managed predefined roles instead of creating a custom role.
- Expecting custom roles to auto-update when permissions change in predefined roles.
- Assuming modifying or deleting a custom role is always non-disruptive to granted principals.
IAM Binding Scope — Project vs Folder vs Organization
Assign roles at the narrowest resource scope; higher-level bindings inherit downward and widen the blast radius.
Key Insight
Bindings inherit down (Org → Folder → Project). Lower-level bindings add permissions — they don't revoke higher-level grants; scope tightly to limit L
Often Confused With
Common Mistakes
- Granting broad roles (e.g., Editor) because a user is 'trusted'.
- Applying org or project-level grants by default — increases lateral movement risk.
- Believing a project-level binding overrides and removes higher-level grants.
Org Policy — Hierarchy Guardrails
Attach constraints at org/folder/project; children inherit limits — used to enforce config, not grant access.
Key Insight
Set restrictive rules at higher levels; children can only narrow settings — parents define the ceiling.
Often Confused With
Common Mistakes
- Thinking you must apply the same policy to every project — ancestor policies already apply.
- Assuming a lower-level policy can always override a parent — children cannot widen parent limits.
- Treating org policies like IAM role grants — they restrict config, they don't grant permissions.
Service Accounts — Scoped Identities
Project-scoped identities for workloads — place per-use, prefer Workload Identity, avoid long‑lived JSON keys.
Key Insight
Service accounts live in projects; prefer Workload Identity and enforce key restrictions via Org Policy (ban user keys).
Often Confused With
Common Mistakes
- Assuming service accounts are global/org-level reusable identities — they’re project-scoped resources.
- Believing disabling user-managed keys breaks all auth — workloads using Workload Identity or Google-managed creds still work.
- Relying on occasional rotation of long-lived JSON keys instead of moving to short-lived creds/Workload Identity.
Securing Communications and Establishing Boundary Protection
22%Identity-Aware Proxy (IAP) — App & TCP Gatekeeper
Enforces IAM-based access at the app/TCP layer for App Engine, GCE (behind HTTPS LB), and GKE; prevents direct exposure.
Key Insight
IAP authenticates via Google's proxy and enforces IAM at the application/TCP layer — it requires an HTTPS load balancer and proper firewall rules.
Often Confused With
Common Mistakes
- Assuming IAP removes firewall rules — you must still allow LB/Google proxy traffic to backends.
- Assuming IAP secures arbitrary TCP/non-HTTP services by default — it needs HTTPS LB or configured TCP tunneling.
- Treating IAP as a replacement for VPN or network segmentation — it's an auth/access layer, not network isolation.
Google Cloud Armor — L7 WAF & DDoS Shield
Layer‑7 WAF and DDoS mitigation for HTTP(S) backends; enforces IP, rate, and managed WAF rules at the load balancer.
Key Insight
Cloud Armor inspects traffic only where TLS is terminated (the HTTP(S) load balancer); it's an application-layer defender, not an L3/L4 NIC firewall.
Often Confused With
Common Mistakes
- Attaching policy to a VM NIC protects it — Cloud Armor policies attach to load balancers or backend services, not NICs.
- Expecting protocol-agnostic protection — it only inspects HTTP(S) when TLS is terminated.
- Assuming it fixes app bugs or stops all DDoS — it's traffic mitigation, not application patching or guaranteed volumetric defense.
VPC Firewall Rules — Priority & Identity Micro‑segmentation
Stateful VPC allow/deny rules ordered by numeric priority; target by network tags or service accounts to apply identity‑
Key Insight
Lower numeric priority value is evaluated first; deny wins on tie; sourceServiceAccounts matches the source VM's attached SA.
Often Confused With
Common Mistakes
- Don't assume higher numeric priority runs first — LOWER number is evaluated first.
- Same priority: allow doesn't win — DENY takes precedence.
- sourceServiceAccounts filters the source VM's attached service account (not the API caller) and not all resources support SA targeting.
Global VPC & Regional Subnets — CIDR, Routing, Peering
One global VPC with regional subnets; plan CIDR, use custom routes (next‑hop/priority), and design non‑transitive peered
Key Insight
VPC peering is non‑transitive; instances without external IP need Cloud NAT; custom routes pick path but firewalls still block traffic.
Often Confused With
Common Mistakes
- Assuming VPC peering is transitive — it is NOT; peering doesn't forward traffic through a third network.
- Expecting VMs without external IPs to reach internet by default — they require Cloud NAT or a proxy.
- Thinking custom routes bypass firewall rules — routing chooses path but firewalls still enforce access control.
Private Google Access (PGA) — Subnet API Access
Subnet-level feature letting VMs without external IPs call Google APIs over Google’s internal network.
Key Insight
PGA only enables access to Google-managed APIs over Google’s network — it does NOT give general Internet or cross-project access.
Often Confused With
Common Mistakes
- Assuming PGA gives general Internet access for private VMs.
- Treating PGA as a drop-in replacement for Cloud NAT for all outbound traffic.
- Believing PGA bypasses IAM or auto-applies to peered VPCs/projects.
Cloud NAT — Regional outbound NAT (IP × ~64K ports)
Managed regional NAT for outbound Internet from private VMs; you must plan external IPs to meet ephemeral-port demand.
Key Insight
Available source ports scale with external IPs (≈64K ports per IP) — pre-allocate IPs per region to avoid port exhaustion.
Often Confused With
Common Mistakes
- Assuming Cloud NAT is a global service covering all regions.
- Expecting Cloud NAT to provide inbound Internet connectivity to VMs.
- Relying on Cloud NAT to auto-scale IPs/ports without manual planning.
Ensuring Data Protection
23%Cloud DLP — Discover, Classify, De‑ID
API-driven discovery, classification, and de-identification (redact/mask/tokenize) of sensitive data across GCP.
Key Insight
DLP finds and transforms sensitive data but does NOT stop exfiltration—pair it with IAM, VPC controls, logging and SIEM.
Often Confused With
Common Mistakes
- Assuming DLP alone prevents data exfiltration — it only detects and transforms data.
- Believing de‑identification permanently changes stored source data by default.
- Thinking DLP can inspect/en‑deidentify ciphertext without access to the KMS keys or custom tuning.
Secret Manager — Versioned Secrets & Access Control
Managed, versioned secret storage with per‑secret IAM, rotation, replication options, CMEK support and audit logging.
Key Insight
Secret Manager stores secrets; enforce least‑privilege access, automated rotation, and Cloud Audit Logs — combine with Workload Identity and KMS for安全
Often Confused With
Common Mistakes
- Treating env vars or config files as equally secure as Secret Manager.
- Skipping rotation and auditing because 'stored once' = secure.
- Granting broad read access to service accounts for convenience instead of least‑privilege.
Cloud KMS — Managed Keys (Software & HSM)
GCP API to create, store, use cryptographic keys; choose software or HSM-backed keys for different guarantees.
Key Insight
API abstracts backends, but HSM keys have real operational differences (attestation, import limits, latency, quotas).
Often Confused With
Common Mistakes
- Thinking imported keys become invisible/un-auditable to Google — audit and access still apply.
- Assuming HSM and software keys behave identically — HSMs add constraints and possible latency/quotas.
- Believing rotation immediately breaks/instantly changes all clients — clients that pin versions/cache metadata may need updates.
CMEK — Customer-Managed Keys in Cloud KMS
Use keys you control in Cloud KMS to encrypt supported GCP resources instead of Google-managed keys.
Key Insight
CMEK hands you key lifecycle/IAM/audit control but keys still live in Cloud KMS; service support and access policies determine protection.
Often Confused With
Common Mistakes
- Assuming CMEK stores keys on-premises by default — keys reside in Cloud KMS unless you use EKM/BYOK solutions.
- Thinking CMEK alone blocks Google from ever accessing plaintext — service behavior and granted IAM determine access.
- Believing CMEK covers all services automatically — only explicitly supported services can use CMEK.
Private Access: PGA / PSA / PSC
Private connectivity for Google APIs and publisher services; each option has different IP/endpoint semantics.
Key Insight
PGA gives VMs private Google API access; PSA uses a producer‑allocated CIDR + VPC peering; PSC exposes private service endpoints to consumers.
Often Confused With
Common Mistakes
- Treating PSA as PSC — PSA doesn't create consumer-side private endpoints.
- Assuming PSA assigns IPs from consumer subnets — it uses a producer‑allocated internal CIDR.
- Expecting Service Directory to enforce network ACLs — it's only for discovery/registration.
Vertex AI Security: IAM, VPC‑SC, CMEK, PSC
Identity, network, encryption and audit controls to protect Vertex models, data, and endpoints.
Key Insight
Combine least‑privilege IAM with network isolation (VPC‑SC/PSC), CMEK, and audit logs — no single control prevents all misuse or exfiltration.
Often Confused With
Common Mistakes
- Assuming CMEK encrypts every Vertex artifact/region by default.
- Relying on PSC/VPC‑SC instead of IAM — network isolation doesn't replace fine‑grained access.
- Believing VPC‑SC stops all exfiltration, even from allowed or compromised principals.
Managing Operations
19%Binary Authorization — Deploy-time Attestations (GKE/Cloud Run)
Enforces deploy-time attestation and signing policies so only trusted container images reach GKE/Cloud Run.
Key Insight
Attestations/signatures are separate from enforcement: policies + attestors (CI/KMS or third-party) decide if a deploy is allowed.
Often Confused With
Common Mistakes
- Assume Binary Authorization only checks cryptographic signatures.
- Think you must change or rebuild images to include attestations.
- Expect creating an attestation automatically enforces or blocks a deployment.
CI/CD Image Pipeline — Packer & Cloud Build (Scanning, SBOMs)
Automated bake/harden/scan/sign pipelines that produce SBOMs, attestations and hardened VM/container images for enforced
Key Insight
Shift-left: combine hardened base images, repeated scanning, SBOMs and KMS-signed attestations — scanning alone doesn't guarantee safety.
Often Confused With
Common Mistakes
- Assume a single static image scan finds every exploitable issue.
- Expect enabling signing/Binary Authorization alone to block untrusted images without policies and provenance.
- Trust popular public images are safe without verifying provenance or scanning.
Security Command Center (SCC) — Findings Hub
Centralizes GCP security findings; export or API-read for retention, forensics, and automation.
Key Insight
Exports are copies; SCC centralizes findings and feeds SIEMs but doesn't replace long-term archives or advanced SIEM analytics.
Often Confused With
Common Mistakes
- Thinking a one-time export removes findings — exports copy, they don't delete the source.
- Assuming continuous exports are real-time — sinks incur processing and delivery latency.
- Believing BigQuery sinks auto-handle retention/costs — you must configure dataset lifecycle and retention.
Log Router Exports — Sinks to SIEM/BigQuery/GCS
Use Log Router sinks and filters to export selected Cloud Logging entries to BigQuery, GCS, Pub/Sub, or SIEM.
Key Insight
Filters define what is copied: ':' = substring match, '=' = exact canonical match; always group with parentheses for complex logic.
Often Confused With
Common Mistakes
- Expecting a sink to export all logs — sinks only copy entries matching their filter and scope.
- Using ':' and '=' interchangeably — ':' substrings; '=' requires the exact canonical logName.
- Thinking sinks transform schemas — sinks select/exclude only; transformations need downstream processing.
Supporting Compliance Requirements
11%IAM RBAC — Roles, Bindings, Least-Privilege
Bind roles to principals via IAM policies; pick predefined or custom roles, scope with Conditions, and limit service‑acc
Key Insight
Permissions flow from bindings — prefer narrow custom or least‑privileged predefined roles, scope with Conditions, and use short‑lived service‑account
Often Confused With
Common Mistakes
- Treating predefined roles as automatically minimal — always review included permissions.
- Using long‑lived service‑account keys instead of short‑lived tokens/Workload Identity.
- Binding broad roles at org/folder for ‘manageability’ — increases blast radius; scope where possible.
Cloud Compliance — Scope, Map, Evidence
Identify in‑scope data/services, map controls to frameworks, apply shared‑responsibility, and collect audit evidence.
Key Insight
Provider certifications cover only the provider’s scoped services/regions — you must map your in‑scope assets, implement customer controls, and retain
Often Confused With
Common Mistakes
- Relying on provider attestations as proof your workloads are compliant.
- Assuming a compliance report covers all services/regions — always check the report scope.
- Treating scoping as one‑time; failing to re‑assess when architectures, data flows or regs change.
Certification Overview
Cheat Sheet Content
Similar Cheat Sheets
- CCNA Exam v1.1 (200-301) Cheat Sheet
- AWS Certified Cloud Practitioner (CLF-C02) Cheat Sheet
- Google Cloud Certified Generative AI Leader Cheat Sheet
- AWS Certified AI Practitioner (AIF-C01) Cheat Sheet
- Exam AI-900: Microsoft Azure AI Fundamentals Cheat Sheet
- Google Cloud Professional Cloud Architect Cheat Sheet