Design for security and compliance Study Guide — Professional Cloud Architect

Design for Security and Compliance

This domain accounts for 20% of the GCP Professional Cloud Architect exam and tests your ability to select, configure, and reason about Google Cloud's security primitives. Questions focus on knowing which service solves which problem, understanding the hierarchy of controls (organization → folder → project → resource), and recognizing when a given architecture violates a compliance requirement. Expect scenario-based questions where you must justify a control choice against a named regulation or threat model.

Cloud IAM: Roles, Bindings, Conditions, Deny Policies

Identity and Access Management (IAM) controls who can do what on which resource. The data model is: principal (who) + role (what) + resource (where), expressed as a policy binding.

Role Types

IAM Conditions

Conditions attach attribute-based logic to a binding. Supported attributes include request.time, resource.name, resource.service, and resource.type. A binding with a condition is conditional; it only grants access when the CEL expression evaluates to true.

Deny Policies

Deny policies (distinct from allow policies) explicitly block permissions regardless of allow bindings. Key facts:

• Evaluated before allow policies — deny wins.
• Use roles/iam.denyAdmin to manage deny policies.
• Attached at organization, folder, or project level.
• Useful for enforcing "no one can delete projects" guardrails.

Common traps:

• Assuming removing a role binding immediately blocks access — a deny policy is the correct tool when you want an unconditional block.
• Confusing roles/owner (basic) with roles/resourcemanager.projectIamAdmin (predefined) — the exam tests least privilege.
• Thinking IAM conditions can reference user attributes (email) directly — conditions operate on request and resource attributes, not identity attributes.
• Deny policies cannot deny the iam.denyAdmin permission on the same resource (self-protection mechanism).

Worked scenario: A company wants to ensure no one—including admins—can delete production buckets except via an approved break-glass process. → Attach a deny policy at the project level denying storage.buckets.delete with a condition that matches the production project, and exempt only the break-glass service account.

Service Accounts: Best Practices, Workload Identity Federation

A service account is both a principal (can be granted roles) and a resource (can have IAM policies on it). Service account keys are the most common misconfiguration vector.

Key Concepts

Workload Identity Federation Flow

How external workloads authenticate to GCP without service account keys.

Common traps:

• Exam frequently offers "create a service account key and store in Secrets Manager" as a distractor — Workload Identity Federation is always preferred for external workloads.
• GKE Workload Identity and Workload Identity Federation are different — GKE-specific vs. general external identity.
• roles/iam.serviceAccountUser allows running as a SA; roles/iam.serviceAccountTokenCreator allows minting tokens for a SA — different attack surfaces.
• Default service accounts for Compute Engine and App Engine have Editor role by default — always disable or demote.