Hierarchy & policy logic
Resource ancestry, inheritance, allow, deny, least privilege, and why scope is the first security decision.
Learn to reason about security boundaries—not merely memorize product names.
Resource ancestry, inheritance, allow, deny, least privilege, and why scope is the first security decision.
Cloud Identity, SSO, SAML, OAuth, 2-step verification, lifecycle automation, and Workforce Identity Federation.
Service accounts, impersonation, short-lived credentials, Workload Identity Federation, and the keyless default.
Cloud NGFW, Armor, IAP, Shared VPC, VPC Service Controls, private access, NAT, VPN, and Interconnect.
Sensitive Data Protection, Secret Manager, CMEK/EKM, key lifecycle, Confidential Computing, and storage controls.
AI workload controls, vulnerability scanning, Binary Authorization, hardened images, patching, and drift detection.
Audit logs, log sinks, VPC Flow Logs, Cloud IDS, Security Command Center, monitoring, investigation, and remediation.
Shared responsibility, Assured Workloads, Access Transparency, Access Approval, data residency, and scenario synthesis.
Before asking who can do what, Google Cloud forces a quieter question: where does the rule live? A permission granted at the organization can affect thousands of resources. The same permission at one project has a much smaller blast radius.
The hierarchy is an inheritance tree. Organizations contain folders; folders contain projects; projects contain resources. Policies attached higher in the tree flow downward unless a more restrictive control blocks the action.
Scope is not bookkeeping. Scope is blast radius.
IAM allow policies are additive across the ancestry chain. If a principal receives a useful permission from any applicable role at any ancestor, that permission is available—unless an applicable deny policy forbids it.
A child resource does not “override” a parent allow by simply omitting it. This is a common exam trap. To reduce inherited access, change the parent grant, narrow it with a condition, redesign group membership, or use an appropriate deny or organization-policy control.
IAM allow answers which principals may perform which actions. IAM deny names permissions that must not be exercised even when an allow exists. Organization Policy constrains how resources may be configured—for example, whether service-account keys may be created.
They sound similar because all restrict behavior, but they operate on different questions. Product selection questions often hinge on that distinction.
A data-science group needs BigQuery job permissions only in its sandbox project.
The security team must prevent creation of service-account keys across the enterprise.
An inherited role allows deletion, but a regulated folder must prohibit deletion for a named principal set.
Access is the largest single section in Google’s current exam guide. It covers Cloud Identity, service accounts, authentication, authorization, Policy Intelligence, Privileged Access Manager, and resource hierarchy. This first module builds the reasoning substrate for all of it.
The exam rarely rewards “most secure sounding.” It rewards the control that meets the stated requirement with the least operational and access scope.
Yes, absent a relevant deny or other boundary. The organization-level allow is inherited. Missing a child binding does not cancel a parent grant.
The project grant reaches fewer descendants, so an error or compromised identity has a smaller blast radius. Least privilege includes least scope, not just the narrowest role.
Organization Policy. The requirement constrains how resources may be configured across the hierarchy. IAM deny is for denying specified IAM permissions to principals.
Module 1 showed that a grant can travel down thousands of resources. That makes the identity behind the grant just as important as its scope. If a departed employee survives in a forgotten directory, perfect IAM roles still protect the wrong person.
Cloud Identity is Google’s directory layer for users and groups. In an enterprise, the usual goal is not to create a second independent identity universe; it is to connect the authoritative HR or identity-provider lifecycle to Google Cloud.
Authentication proves who a user is. Authorization decides what that identity may do. SAML commonly carries enterprise sign-in assertions; OAuth delegates access to applications. Confusing those jobs is a reliable way to miss scenario questions.
Choose the population. The best answer minimizes duplicated identity lifecycle.
Humans sign in interactively; workloads need a non-human principal. A service account supplies that identity. The dangerous shortcut is a downloadable service-account key: it is long-lived, copyable, hard to attribute once leaked, and valid wherever the file travels.
The preferred pattern is to attach a narrowly scoped service account to a Google Cloud workload and let the metadata service issue short-lived credentials. For administration, use service-account impersonation. For external clouds, CI systems, or Kubernetes identities, use Workload Identity Federation to exchange an external assertion for temporary Google credentials.
Select a situation.
IAM answers whether an identity may call an API. Networking answers whether packets can reach an endpoint. A secure design usually needs both. Private IPs reduce exposure, but “private” is not an authorization model.
Cloud NGFW filters network traffic and can perform layer-7 inspection. Cloud Armor protects internet-facing applications at the edge. IAP places identity-aware access in front of applications and administrative tunnels. VPC Service Controls reduce data-exfiltration risk around supported Google-managed services; they are not a replacement for IAM or a general packet firewall.
Shared VPC centralizes network ownership across service projects. Private Google Access lets resources without external IPs reach Google APIs. Private Service Connect exposes services through private endpoints. Cloud NAT provides outbound internet access without inbound reachability. HA VPN encrypts traffic over the internet; Cloud Interconnect supplies private physical connectivity, with encryption added when required.
The exam often presents several secure products. Match the product to the threatened path: inbound web attack, administrative access, east-west segmentation, Google API exfiltration, or hybrid transport.
Scenario: a private payroll app serves employees and reads a regulated BigQuery dataset.
Google encrypts customer data at rest by default, but encryption alone does not tell you where sensitive data exists, who can access it, how long it remains, or whether an attacker can ask the authorized service to decrypt it.
Sensitive Data Protection discovers and transforms sensitive values through inspection, redaction, tokenization, pseudonymization, and format-preserving encryption. Secret Manager stores application secrets with versions, IAM, auditability, and rotation workflows. Storage lifecycle policies enforce retention or deletion behavior.
Google-managed encryption is the operational default. CMEK gives the customer control over key location, IAM, rotation, and revocation in Cloud KMS. Cloud EKM keeps key material in an external key manager when contractual control requires it, at the cost of availability and operational complexity. Hardware-backed protection uses Cloud HSM.
Confidential Computing protects data in use by isolating memory during processing. It complements—not replaces—encryption at rest and in transit.
A secure source repository does not guarantee the running container came from that source. The supply-chain question is: can you prove what was built, what was scanned, who approved it, and whether the runtime admitted exactly that artifact?
Scan dependencies and images for known vulnerabilities during CI/CD. Produce hardened, reproducible images. Sign or attest trusted artifacts. Use Binary Authorization to make GKE or Cloud Run reject images that lack required attestations. Patch running systems and use posture management to detect configuration drift after deployment.
AI security includes training-data access, model artifacts, prompt and response data, service perimeters, endpoint IAM, and protection against unintended model or data exposure. IaaS-hosted models give more infrastructure control and more patching responsibility; managed platforms shift infrastructure operation to Google but leave data, identity, configuration, and application risks with the customer.
The common misconception is that a model endpoint is “just another API.” It is also a data-processing system whose prompts, retrieval sources, tools, and outputs may cross trust boundaries.
Protect branches, review changes, and bind the build to an identified revision. This establishes what you intended to produce.
Logging is not “turn everything on.” A useful strategy identifies which actions matter, where logs must be retained, who may read them, which detections require low latency, and how evidence leaves a compromised project.
Cloud Audit Logs record administrative and data-access activity; Data Access logs often require deliberate enablement and cost planning. Aggregated sinks at the folder or organization can route logs into a centralized project that workload administrators cannot alter. VPC Flow Logs show sampled network flows; Firewall Rules Logging records rule decisions; Packet Mirroring copies traffic for inspection; Cloud IDS detects network threats.
Security Command Center aggregates asset, vulnerability, misconfiguration, and threat findings. Findings are not remediation by themselves: an operating model needs triage ownership, severity criteria, playbooks, automation boundaries, and evidence preservation.
During an incident, contain without destroying the evidence you need. Prefer reversible isolation, snapshotting, credential revocation, and centralized logs. Then eradicate the cause, recover safely, and turn lessons into new preventive and detective controls.
Select the question an investigator must answer.
Google secures the cloud infrastructure; customers secure their data, identities, workloads, configurations, and use of services. Managed services move the dividing line, but they do not move accountability for choosing and configuring the service appropriately.
A compliance requirement becomes implementable only after you translate it into technical controls and evidence: resource scope, regions, access rules, network segmentation, key ownership, log coverage, approval workflow, and retention.
Assured Workloads helps configure regulated environments with supported guardrails. Access Transparency records actions by Google personnel. Access Approval lets customers approve eligible support access. Resource locations and service availability determine data residency—not a label in a policy document.
Audit readiness is continuous architecture. If a control cannot produce reliable evidence, the organization cannot confidently demonstrate that the control operated.
Use Workload Identity Federation so GitHub’s OIDC assertion can be exchanged for short-lived Google credentials, usually followed by service-account impersonation with narrow permissions.
VPC Service Controls around the supported services and projects reduce data-exfiltration paths. IAM still controls who can query; the service perimeter addresses where protected API data may move.
No. Use CMEK in Cloud KMS for customer-controlled IAM, rotation, and revocation. Use Cloud EKM only if the requirement specifically demands externally held key material.
It separates evidence from the workloads and administrators being observed, supports centralized retention and analysis, and reduces the chance that a compromised project can erase its own history.