Security Design

Four layers, four questions

A contractor can read your production bucket, a dataset must never leave the EU, a service account key turns up in a public repo. Each of these is a different security risk, and Google Cloud answers each with a different layer rather than one catch-all product. The Well-Architected Framework calls this defense in depth, and its security pillar leads with security by design and zero trust^[1]: never trust by default, verify every request, and assume any single control can fail.

The fastest way to pick the right service on the exam is to name the layer that owns the risk. There are four, and each answers one question:

Identity (IAM) answers who can do what. It grants roles to principals on resources.
Governance (resource hierarchy + Organization Policy) answers what configurations are even allowed. It sets guardrails that flow down the org tree.
Perimeter and context (VPC Service Controls, context-aware access, Identity-Aware Proxy) answers from where and under what conditions a request is allowed.
Data protection (Cloud KMS/CMEK, Secret Manager, Sensitive Data Protection) answers how the data itself is guarded even if a layer above is breached.

These layers are independent on purpose. IAM enables granular identity-based access control, while VPC Service Controls adds context-based perimeter security that is independent of IAM^[2]: a caller can hold valid IAM permissions and still be blocked at the perimeter. Read each scenario as 'which question is being asked' and the layer, then the service, follows. The rest of this page walks the four layers in that order, then the cross-cutting concerns of secure access, supply chain, and AI.

Defense in depth: four independent layers, each owning a distinct risk. Modeled on the Well-Architected Framework security pillar.

IAM: roles, allow, and deny

IAM controls who can do what on which resource. The unit you grant is a role, a bundle of permissions, and you bind it to a principal (a user, group, or service account) on a resource. You never grant a raw permission directly; you grant the role that contains it. This indirection is why role choice is the whole game.

Three tiers of roles, in order of preference for least privilege:

Basic roles (Owner, Editor, Viewer) are coarse, project-wide, and predate IAM granularity. Treat them as the wrong answer on the exam unless the scenario explicitly wants broad access.
Predefined roles are curated by Google for a service and a job (for example roles/storage.objectViewer). Prefer these.
Custom roles let you assemble an exact permission set when even a predefined role grants too much.

Allow policies inherit and are additive

An allow policy attaches to a node in the resource hierarchy and flows downward: a role granted on a folder applies to every project and resource beneath it. Allow policies are additive only, so a principal's effective access is the union of every allow that touches them anywhere up the tree. There is no 'subtract a permission' inside an allow policy.

Deny policies are evaluated first and override

To remove access regardless of any grant, you use a separate deny policy. The single most testable IAM fact: IAM always checks relevant deny policies before allow policies^[3], so a matching deny blocks the permission even if an inherited Owner role would otherwise allow it. Deny policies attach at the organization, folder, or project level and support exceptionPrincipals so you can deny broadly while exempting break-glass accounts. A deny rule can carry a condition; if the condition is true or cannot be evaluated, the deny applies.

The two policy types share one mental model: both are evaluated top-down across the hierarchy, but deny is consulted first and is the only one that can take access away. Allow says what you may do; deny says what you may never do, and deny wins.

IAM checks deny rules before allow grants; a matching deny overrides any role, and absence of an allow is an implicit deny.

Resource hierarchy and Organization Policy

The resource hierarchy is the backbone every other layer hangs off, so it is worth designing first. It has four levels^[4]: the organization at the root, optional folders for grouping, then projects, then the resources inside them. Every resource except the organization has exactly one parent, which makes the hierarchy a strict tree.

Two separate things inherit down this tree, and keeping them straight is a common exam distinction:

IAM allow policies flow down, granting who can act (the previous section).
Organization Policy constraints flow down, governing what configurations are allowed. IAM focuses on who, Organization Policy focuses on what; they are complementary, not substitutes^[5].

Organization Policy guardrails

An organization policy enforces a constraint against a resource and all its descendants. Constraints come in boolean form (a behavior is on or off) and list form (allow or disallow a set of values). The constraints the exam keeps returning to:

Constraint goal	Typical use
Restrict resource locations	Keep all resources in approved regions for data residency
Disable service account key creation	Force Workload Identity Federation or impersonation instead of exported keys
Restrict VM external IP access	Keep VMs private, reachable only through controlled paths
Disable serial port access	Remove a console backdoor across every project at once

Because the constraint inherits, one policy set at a folder covers every project beneath it, and a project later moved under that folder inherits it automatically. This is why a clean hierarchy that mirrors teams and environments is itself a security control: it lets you write the rule once, high up, instead of per project.

Separation of duties

The hierarchy also enables separation of duties. The classic pattern is a Shared VPC^[6]: a host project owns the subnets, routes, and firewall rules while service projects attach to it and run workloads, so a central network team controls the network and workload owners cannot change it. Granting the Organization Policy Administrator role to a governance team, distinct from the project owners who deploy, is the same principle at the policy layer.

The four-level resource hierarchy; IAM allow policies and Organization Policy constraints both inherit from any node to all descendants.

Perimeter and context controls

IAM and the hierarchy decide who may act and what is configurable. The perimeter and context layer decides from where and under what conditions, which is the answer when a scenario worries about valid credentials being used in the wrong place.

VPC Service Controls: stopping exfiltration

A VPC Service Controls service perimeter draws a boundary around a set of projects and the Google-managed services in them. Inside the perimeter, communication is free; by default, all communication across the perimeter is blocked^[2]. The point worth memorizing: the perimeter is independent of IAM, so a caller with perfectly valid IAM permissions is still blocked if the request crosses the boundary. That is exactly the data-exfiltration case, a stolen credential or a misconfigured export trying to copy data to an outside project.

Controlled holes in the boundary are ingress and egress rules: an ingress rule lets a specific client outside the perimeter reach resources inside, and an egress rule lets a resource inside reach specific resources outside. Always build a perimeter in dry-run mode first; it logs what would be blocked so you can find legitimate traffic before you enforce.

Do not confuse the perimeter with a firewall. VPC firewall rules and hierarchical firewall policy filter packet-level network traffic between VMs; VPC Service Controls governs API access to Google services. Different layer, different question.

Context-aware access and Identity-Aware Proxy

Context-aware access adds conditions on top of identity: allow the request only from a managed device, a corporate IP range, or a specific region. Identity-Aware Proxy (IAP) is how you apply this to applications. IAP provides a central authorization layer for applications^[7] accessed over HTTPS, so you use application-level access control instead of a network-level VPN. A user must hold the right IAM role and satisfy the context conditions to reach the app. IAP also does TCP forwarding for SSH and RDP to VMs, replacing bastion hosts and public IPs. This is the practical form of zero trust, sometimes branded Chrome Enterprise Premium (formerly BeyondCorp Enterprise) when bundled with endpoint and threat protections: trust nothing by network location, verify identity and context on every request.

VPC Service Controls perimeter: free communication inside, cross-boundary blocked by default, ingress and egress rules as the only controlled exceptions.

Data security: keys, secrets, and de-identification

The bottom layer assumes a breach above it and protects the data directly. Three concerns: the encryption keys, the application secrets, and the sensitive content itself.

Encryption keys: default, CMEK, HSM, EKM

Start from what is free: Google encrypts all customer content at rest by default^[8] with AES-256 and envelope encryption, where each data-encryption key (DEK) is itself encrypted by a key-encryption key (KEK). You do nothing. With default encryption Google owns the KEK and you cannot view or manage it.

The architectural decision is who controls the KEK, and it is a ladder of increasing control and cost:

Option	Who holds the key	Reach for it when
Google default	Google	No key-control requirement; the default is fine
CMEK (Cloud KMS)	You, software-protected key in KMS	You must rotate, disable, or destroy the key, or crypto-shred data
Cloud HSM	You, key in a FIPS 140-2 Level 3 HSM	A hardware-backed key is mandated by policy or regulation
Cloud EKM	You, key outside Google entirely	The key must never reside in Google Cloud

Customer-managed encryption keys^[9] are keys you own in Cloud KMS; you set the rotation period, trigger rotations, and can disable or destroy a key version. Destroying or disabling the CMEK makes the data it protected unreadable, which is the deliberate crypto-shredding technique for guaranteed data destruction. Note CMEK is distinct from customer-supplied encryption keys (CSEK), where you pass a raw key with each request and Google never stores it.

Secret Manager

Application secrets, API keys, passwords, and certificates do not belong in code, environment variables, or config files. Secret Manager^[10] stores them centrally, versions them, gates access with IAM, and logs access to Cloud Audit Logs. The exam answer to 'where do we keep the database password' is Secret Manager, not a file in the repo.

Sensitive Data Protection

To find and neutralize PII in data you already hold, Sensitive Data Protection^[11] (formerly Cloud DLP) discovers, classifies, and de-identifies sensitive data across BigQuery, Cloud Storage, and Datastore, or in streaming content. It matches against built-in infoTypes (such as credit card or national ID numbers) and then de-identifies with masking, redaction, bucketing, date shifting, or tokenization. Tokenization (pseudonymization) is the technique when you must preserve referential integrity, the same input maps to the same token, without exposing the raw value.

Envelope encryption: the KEK wraps the DEK, which encrypts the data; with CMEK you own the KEK, so destroying it crypto-shreds the data.

Secure remote access and identity for workloads

Two recurring scenarios sit at the edge of the identity layer: how a workload authenticates without a long-lived secret, and how a human reaches a private resource without a VPN. The unifying rule is the same one zero trust pushes everywhere: prefer short-lived, verifiable credentials over standing ones.

Kill the service account key

A downloaded service account key is a long-lived JSON credential. It is a security risk if not managed correctly^[12] because it is a bearer token that works until someone rotates it, and leaked keys are a top cloud breach cause. The design goal is to never create one. Two replacements, by where the workload runs:

Inside Google Cloud: attach a service account to the resource (VM, GKE workload, Cloud Run service) and let it obtain credentials automatically, or use service account impersonation so a principal temporarily acts as the service account and gets a short-lived token. No key file ever exists.
Outside Google Cloud (on-premises, AWS, Azure, GitHub Actions, any OIDC or SAML 2.0 provider): use Workload Identity Federation. The external identity presents its own token to Google's Security Token Service, which returns a short-lived federated token, no Google key to download or store. You manage the external identities in a workload identity pool, ideally one per environment.

Reach for a service account key only when a tool genuinely cannot do federation or impersonation, and then guard it: the Organization Policy constraint that disables service account key creation (covered earlier) makes 'no keys' the enforced default rather than a guideline.

Reach a private app without a VPN

For human access, Identity-Aware Proxy (IAP) (from the perimeter layer) is the standing answer: it authorizes by IAM role plus context at the application layer, so you publish an app or expose SSH/RDP without a public IP or a VPN. The candidate who picks 'open a firewall port' or 'set up a VPN' over IAP is usually choosing the network-perimeter answer the zero-trust scenario is steering away from.

Workload Identity Federation: the external token is exchanged at the Security Token Service for a short-lived Google token, so no service account key is downloaded.

Securing the software supply chain and AI

Two newer areas the PCA blueprint now tests, both extensions of the same defense-in-depth thinking applied to build pipelines and to models.

Software supply chain

The supply-chain question is: how do you ensure only trusted, vetted artifacts run in production. Binary Authorization is the deploy-time gate. It is a software supply-chain security control^[13] that lets only container images conforming to a policy deploy to GKE, Cloud Run, and Cloud Service Mesh; non-conforming images are blocked and the violation is logged. Conformance is proven by attestations: a trusted attestor signs a statement that an image cleared a stage (it was built by the approved CI pipeline, it passed vulnerability scanning, a QA lead approved it). Like a VPC SC perimeter, you run the policy in dry-run mode first to see what would be blocked. Binary Authorization pairs with Artifact Registry and Artifact Analysis (vulnerability scanning) so the attestation can reflect a clean scan, and with shift-left security from the Well-Architected Framework: catch the defect in the pipeline, not in production.

Securing AI

The AI-security question splits in two. To protect a model from malicious or unsafe traffic, Model Armor screens LLM prompts and responses^[14] for prompt injection and jailbreak attempts, sensitive-data leakage, malicious URLs, and harmful content. It is model- and cloud-agnostic and is invoked through templates over a REST API, so you sanitize the prompt before it reaches the model and sanitize the response before it reaches the user. To keep PII out of training data, prompts, and logs in the first place, use Sensitive Data Protection (the previous section) to discover and de-identify it. The two are complementary: Sensitive Data Protection cleans the data, Model Armor guards the live request and response.

Binary Authorization deploy-time gate: only an image carrying a valid attestation is admitted; others are blocked and logged.

Exam-pattern recognition

PCA security questions are scenario-shaped: a sentence of business context, a stated risk, and four plausible services. The reliable move is to name the layer the risk belongs to, then the service is usually forced. Common stems and the right read:

Map the cue to the layer

The scenario worries about	Layer	Answer
A principal can do too much	Identity	Tighter custom/predefined role, or a deny policy if you must override an inherited grant
Credentials valid but used to exfiltrate data	Perimeter	VPC Service Controls perimeter (independent of IAM)
A rule must hold across many projects	Governance	Organization Policy constraint at org or folder
Data must stay in-region	Governance	Organization Policy resource-location constraint
Key must be customer-controlled / destroyable	Data	CMEK in Cloud KMS (HSM if hardware-mandated, EKM if off-Google)
App secret in code	Data	Secret Manager
Workload outside Google needs access	Identity	Workload Identity Federation, not a downloaded key
Reach a private app or VM without a VPN	Perimeter	Identity-Aware Proxy
Only vetted images may deploy	Supply chain	Binary Authorization
LLM prompt injection or data leak	AI security	Model Armor (plus Sensitive Data Protection for the PII)

The traps that catch people

Firewall vs perimeter. A VPC firewall rule and a VPC Service Controls perimeter sound interchangeable but are not: firewalls filter VM network traffic, perimeters govern API access to Google services. The exfiltration scenario wants the perimeter.
Budget vs quota vs security. 'Prevent runaway cost' is a quota or budget question, not a security control; a budget only notifies, a quota actually caps. Do not pick an IAM answer for a spend problem.
CMEK vs Confidential VMs. CMEK controls keys for data at rest; protecting data while it is processed in memory is Confidential VMs. If the stem says 'data in use', it is not CMEK.
Service account key as the convenient answer. When a workload outside Google needs access, a downloaded key looks simplest and is the distractor. Federation or impersonation is the intended answer, and an Organization Policy can enforce that.
IAM allow cannot remove access. Allow policies only add; to strip a permission a principal inherits, you need a deny policy, which is evaluated first. 'Edit the allow policy to remove it' is the wrong mechanism when the grant comes from a parent.

Which security layer owns the risk

Layer	Question it answers	Primary services	Use it when
Identity (IAM)	Who can do what	IAM allow/deny policies, predefined & custom roles, service accounts	You must grant or revoke a principal's ability to act on a resource
Governance (hierarchy)	What configurations are allowed	Resource hierarchy (org/folders/projects), Organization Policy constraints	You must enforce a rule across many projects (locations, external IPs, key creation)
Perimeter & context	From where and under what conditions	VPC Service Controls, context-aware access, Identity-Aware Proxy	You must stop exfiltration or gate access by device, IP, or identity context
Data protection	How the data itself is guarded	Cloud KMS/CMEK, Cloud HSM, Cloud EKM, Secret Manager, Sensitive Data Protection	You must control encryption keys, store secrets, or de-identify sensitive data

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Match the risk to the security layer, then the service is forced

Google Cloud security is defense in depth across four independent layers, and most PCA scenarios resolve once you name which layer owns the stated risk. Identity (IAM) answers who can act, the resource hierarchy plus Organization Policy answers what configurations are allowed, VPC Service Controls and context-aware access answer from where and under what conditions, and Cloud KMS, Secret Manager, and Sensitive Data Protection answer how the data itself is guarded. The layers are independent by design, so picking the layer first stops you from reaching for an IAM answer to a perimeter problem.

A deny policy overrides any allow because IAM evaluates deny first

IAM always checks relevant deny policies before allow policies, so a matching deny blocks a permission no matter what role granted it, including an inherited Owner role. Allow policies are additive only and cannot subtract a permission, which is why removing access a principal inherits from a parent requires a separate deny policy rather than editing the allow. Deny policies attach at the organization, folder, or project level and support exceptionPrincipals so you can deny broadly while exempting break-glass accounts.

Trap Editing the allow policy to take away a permission a principal inherits from a folder; allow policies only add, so the inherited grant survives and you need a deny policy.

Grant predefined or custom roles, not basic roles, for least privilege

IAM grants roles, which are bundles of permissions, to principals rather than granting permissions directly. Basic roles (Owner, Editor, Viewer) are coarse and project-wide and are almost always too broad for production. Prefer Google's predefined roles scoped to a service and job, and drop to a custom role when even a predefined role grants more than the task needs. Least privilege is the recurring correct answer whenever a scenario says a principal can do more than required.

Trap Granting Editor to give a service write access; Editor is a project-wide basic role that also permits far more than the one resource, breaking least privilege.

5 questions test this

The resource hierarchy is org > folders > projects > resources, single-parent

The hierarchy has four levels: organization at the root, optional folders for grouping, then projects, then resources, and every resource except the organization has exactly one parent, making it a strict tree. Both IAM allow policies and Organization Policy constraints inherit downward, so where a project sits decides what it inherits. A project moved under a folder automatically picks up that folder's policies, which is why a clean hierarchy mirroring teams and environments is itself a control.

1 question tests this

Your organization has a complex structure with multiple business units, each with different data residency requirements. The finance unit…

Organization Policy governs what is configurable; IAM governs who can act

Organization Policy sets constraints on how resources can be configured and inherits down the hierarchy, where IAM sets who can take actions. They are complementary, not substitutes: IAM answers who, Organization Policy answers what. A constraint set at a folder applies to every project beneath it, so it is the tool for enforcing a rule across many projects at once rather than configuring each project by hand.

Trap Reaching for an IAM role to stop projects from creating resources in the wrong region; resource location is an Organization Policy constraint, not a permission.

2 questions test this

Enforce data residency with the Organization Policy resource-location constraint

When data must stay in a region or jurisdiction, set the resource-location constraint in Organization Policy at the org or folder level so every project below can only create resources in approved locations. Because the constraint inherits, you write it once high in the tree instead of per project, and new or moved projects pick it up automatically. This is governance, not an access decision, so no IAM change is involved.

Disable service account key creation with an Organization Policy to enforce keyless access

An Organization Policy constraint can disable service account key creation across the hierarchy, turning no-downloaded-keys from a guideline into an enforced default. This pushes teams to Workload Identity Federation for external workloads and impersonation inside Google Cloud, removing the long-lived credential a leaked key represents. Pair it with break-glass exceptions only where a tool genuinely cannot federate.

2 questions test this

VPC Service Controls blocks data exfiltration even from callers with valid IAM

A VPC Service Controls service perimeter draws a boundary around projects and the Google-managed services in them, allowing free communication inside and blocking all communication across the boundary by default. The point that makes it the exfiltration answer is that it is independent of IAM: a caller holding valid IAM permissions is still blocked when the request crosses the perimeter. Controlled exceptions are ingress and egress rules, and you build the perimeter in dry-run mode first to log what would be blocked before enforcing.

Trap Tightening IAM roles to stop a stolen credential from copying data to an outside project; the credential is still valid, so only a VPC Service Controls perimeter stops the cross-boundary API call.

29 questions test this

A service perimeter governs Google API access; a firewall governs VM traffic

VPC Service Controls and VPC firewall rules sound interchangeable but operate at different layers: a service perimeter controls API access to Google-managed services, while VPC firewall rules and hierarchical firewall policy filter packet-level network traffic between VMs. Per-instance network filtering is a firewall job; stopping data from leaving via a Google API is a perimeter job. Reading the layer keeps these apart.

Trap Using a VPC firewall rule to stop data exfiltration through the BigQuery or Cloud Storage API; firewalls do not see Google API access, so the perimeter is required.

Identity-Aware Proxy gates app and SSH access by identity and context, no VPN

IAP provides a central authorization layer at the application level, so a user must hold the right IAM role and satisfy context conditions to reach an HTTPS app, rather than relying on a network-level VPN or open firewall port. IAP also does TCP forwarding for SSH and RDP to VMs, removing the need for bastion hosts and public IPs. This is the practical form of zero trust: trust nothing by network location, verify identity and context on every request.

Trap Opening a firewall port or standing up a VPN to expose an internal app when the scenario wants zero-trust access; IAP authorizes at the application layer by identity and context instead.

Context-aware access adds device, IP, and location conditions on top of identity

Context-aware access lets you allow a request only when extra conditions hold, such as a managed device, a corporate IP range, or an approved region, layered on top of the IAM identity check. It is applied to applications through IAP and is bundled with endpoint and threat protections as Chrome Enterprise Premium (formerly BeyondCorp Enterprise). The model is that a valid identity is necessary but not sufficient; the access context must also pass.

6 questions test this

Encryption at rest is automatic with AES-256 and envelope encryption

Google encrypts all customer content at rest by default with AES-256, using envelope encryption where each data-encryption key (DEK) is wrapped by a key-encryption key (KEK), with no customer action required. With the default, Google owns and you cannot view or manage the KEK. The architectural decision is never whether to encrypt at rest but who controls the key, which is what CMEK changes.

Use CMEK when you must own, rotate, or destroy the encryption key

Customer-managed encryption keys (CMEK) in Cloud KMS are keys you own, letting you set a rotation period, trigger rotations, and disable or destroy a key version. Disabling or destroying the CMEK makes the data it protected unreadable, which is the deliberate crypto-shredding technique for guaranteed data destruction. Reach for default encryption when there is no key-control requirement; reach for CMEK when compliance or revocation demands customer control of the key.

Trap Choosing CMEK to protect data while it is being processed in memory; CMEK controls keys for data at rest, but data in use needs Confidential VMs.

10 questions test this

Cloud HSM for FIPS 140-2 Level 3 keys, Cloud EKM for keys outside Google

CMEK has protection-level options that form a ladder of control. Cloud HSM stores the key in a FIPS 140-2 Level 3 hardware security module when a hardware-backed key is mandated by policy or regulation. Cloud EKM (External Key Manager) keeps the key in an external system outside Google Cloud entirely, for when the key must never reside in Google. Plain CMEK is a software-protected key in KMS, sufficient when you need control but not a specific hardware or off-cloud requirement.

Trap Picking Cloud EKM when the requirement is only a hardware-backed key; EKM is for keys held outside Google, while a FIPS 140-2 Level 3 hardware key inside Google is Cloud HSM.

12 questions test this

Store application secrets in Secret Manager, never in code or config

Secret Manager centrally stores API keys, passwords, and certificates, versions them, gates access with IAM, and logs access to Cloud Audit Logs. Putting a secret in source code, an environment variable, or a config file makes it leak with the repo or image, which is exactly the risk Secret Manager removes. The exam answer to where the database password lives is Secret Manager.

Prefer Workload Identity Federation over downloading a service account key

A downloaded service account key is a long-lived bearer credential and a top cause of cloud breaches when it leaks, so the design goal is to never create one. For a workload outside Google Cloud (on-premises, AWS, Azure, GitHub Actions, any OIDC or SAML 2.0 provider), Workload Identity Federation exchanges the external token at Google's Security Token Service for a short-lived federated token, with no key to store. External identities are managed in a workload identity pool, ideally one per environment.

Trap Downloading a service account key and shipping it to an external CI system because it looks simplest; the key is a standing credential, and federation gives short-lived tokens with nothing to leak.

Use service account impersonation, not keys, for access inside Google Cloud

Inside Google Cloud, attach a service account to the resource (VM, GKE workload, Cloud Run service) so it gets credentials automatically, or use service account impersonation so a principal temporarily acts as the service account and receives a short-lived token. Neither approach ever creates a key file. Impersonation also gives an audit trail of who acted as the service account, which a shared exported key cannot.

Binary Authorization admits only attested container images at deploy time

Binary Authorization is a deploy-time software supply-chain control that lets only container images conforming to a policy deploy to GKE, Cloud Run, and Cloud Service Mesh; non-conforming images are blocked and the violation is logged. Conformance is proven by an attestation, a signed statement from a trusted attestor that the image cleared a stage such as the approved build pipeline or vulnerability scanning. Run the policy in dry-run mode first to surface what would be blocked, mirroring the shift-left principle of catching defects before production.

Trap Relying on Artifact Analysis vulnerability scanning alone to keep bad images out of production; scanning reports findings but does not block a deploy, whereas Binary Authorization enforces the gate.

3 questions test this

Admin Activity audit logs are always on; Data Access logs are off by default

Cloud Audit Logs answer who did what, where, and when, and are the backbone of security auditing. Admin Activity audit logs are always written and cannot be disabled, while Data Access audit logs are off by default and must be explicitly enabled because they can be high volume. A scenario that needs to prove who read sensitive data, not just who changed configuration, requires turning on Data Access logs.

Trap Assuming Data Access logs already capture who read a dataset; they are off by default, so reads go unlogged until you explicitly enable them.

1 question tests this

EHR Healthcare stores protected health information (PHI) in Cloud Storage and BigQuery. The compliance team requires visibility into when…

Separate duties with Shared VPC and split administrative roles

Separation of duties keeps one person or team from holding end-to-end control. Shared VPC implements it for networking: a host project owns the subnets, routes, and firewall rules while service projects attach and run workloads, so a central network team controls the network and workload owners cannot change it. The same principle at the policy layer gives the Organization Policy Administrator role to a governance team distinct from the project owners who deploy.

After key rotation the new version encrypts; old enabled versions still decrypt, and existing data is not re-encrypted

When you rotate a Cloud KMS key, the new key version becomes the primary version used for new encryption operations, but all enabled previous versions stay available so existing ciphertext keeps decrypting. Rotation never re-encrypts data already at rest, so to move existing data onto the new version you must explicitly decrypt and re-encrypt it (and only then disable or destroy the old versions).

Trap Assuming rotation automatically re-encrypts existing objects or that old versions are disabled — they remain active (and billable) until you act.

9 questions test this

Cloud KMS automatic rotation works only for symmetric keys; asymmetric keys must be rotated manually

Cloud KMS supports a scheduled automatic-rotation period (e.g. 90 days) only for symmetric encryption keys. Asymmetric keys used for signing or encryption require manual rotation because extra steps are needed first — such as distributing the new public key — so you create new versions and promote them by hand.

Trap Setting an automatic-rotation schedule on an asymmetric key and expecting it to rotate — it silently won't.

13 questions test this

Disable to reverse instantly; scheduled-for-destruction versions can be restored during the grace period, and policy can enforce a longer delay

Disabling a key version blocks all cryptographic use immediately and is fully reversible, so it is the right move for a suspected compromise. Destruction is delayed: a version sits in the scheduled-for-destruction state (30 days by default) and can be reverted to disabled with RestoreCryptoKeyVersion until that period expires. Enforce constraints/cloudkms.minimumDestroyScheduledDuration to require a longer minimum delay, and constraints/cloudkms.disableBeforeDestroy to force a version to be disabled before it can be scheduled for destruction.

Trap Destroying a key version to take it out of service — disabling is the reversible action; destruction risks permanent data loss after the grace period.

6 questions test this

Single-tenant Cloud HSM gives dedicated, quorum-controlled hardware; Autokey defaults keys to HSM protection

Single-tenant Cloud HSM provisions a dedicated cluster of HSM partitions for one customer's exclusive use, each partition cryptographically isolated from others, with a quorum approval model using asymmetric control keys for critical administrative operations, while keeping the standard Cloud KMS API (no code changes). Cloud KMS Autokey automates CMEK provisioning and creates keys at the HSM protection level by default (AES-256-GCM, one-year rotation); to create CMEK in locations where Cloud HSM is unavailable you must create the key manually.

Trap Reaching for multi-tenant Cloud HSM when the requirement is dedicated isolation plus quorum control — that calls for single-tenant Cloud HSM.

5 questions test this

Security Command Center threat detection splits across Event, Container, and VM Threat Detection

Security Command Center (Premium/Enterprise) detects threats with three distinct services: Event Threat Detection scans Cloud Logging for things like anomalous IAM grants and data exfiltration, Container Threat Detection analyzes GKE container runtime behavior, and Virtual Machine Threat Detection scans VM memory from the hypervisor (agentless) for malware such as cryptominers and rootkits. Match each requirement (logs / containers / VMs) to the corresponding service.

Trap Expecting one detector to cover all three layers — VM cryptomining needs VM Threat Detection, not Event or Container Threat Detection.

3 questions test this

Cloud Armor Adaptive Protection uses ML to detect L7 DDoS and emits Security Command Center findings with suggested WAF rules

Cloud Armor Adaptive Protection (Cloud Armor Enterprise) applies machine learning to baseline traffic on a backend service, detect Layer 7 (HTTP) DDoS attacks, and generate alerts with attack signatures, confidence scores, and suggested WAF rules. Findings surface in the Cloud Armor dashboard, Security Command Center (Application DDoS Attacks category), and Cloud Logging; deploy a suggested rule in preview mode first and enable auto-deploy only once you confirm legitimate traffic is unaffected.

Trap Confusing Adaptive Protection (L7/HTTP application DDoS on load balancers) with advanced network DDoS protection, which guards passthrough Network Load Balancers and public-IP VMs.

6 questions test this

Use one unified VPC-SC perimeter and always include the Shared VPC host project

Google recommends a single large common unified service perimeter over many small ones for the most effective exfiltration protection and lower management overhead; isolate any workload needing a service not supported by VPC Service Controls into a separate project (or move it out of the perimeter). With Shared VPC you must include the host project in the perimeter alongside the projects that belong to the Shared VPC — omitting the host project leaves their network endpoints outside the perimeter because the subnets belong to the host project.

Trap Putting only the service projects in the perimeter under Shared VPC — omitting the host project makes service-project VM traffic look external and gets blocked.

5 questions test this

Four layers, four questions

IAM: roles, allow, and deny

Allow policies inherit and are additive

Deny policies are evaluated first and override

Resource hierarchy and Organization Policy

Organization Policy guardrails

Separation of duties

Perimeter and context controls

VPC Service Controls: stopping exfiltration

Context-aware access and Identity-Aware Proxy

Data security: keys, secrets, and de-identification

Encryption keys: default, CMEK, HSM, EKM

Secret Manager

Sensitive Data Protection

Secure remote access and identity for workloads

Kill the service account key

Reach a private app without a VPN

Securing the software supply chain and AI

Software supply chain

Securing AI

Exam-pattern recognition

Map the cue to the layer

The traps that catch people

Which security layer owns the risk

Decision tree

Cheat sheet

Also tested in

References