Google Cloud

Organization Policy & Security — Hierarchy, VPC-SC & SCC

Organise projects under an organization, set constraints nobody can escape, and detect what IAM cannot prevent.

GCP's resource hierarchy is its governance mechanism, and IAM and policy both inherit down it.

Separate buildings on a campus with site-wide rules that apply to everyone including the manager, a fence that stops material leaving regardless of who is carrying it, and cameras for what the rules did not anticipate.

Key Concepts

1
    Organization
      +-- Folder: Platform      shared networking, logging
      +-- Folder: Production
      |     +-- Project: orders-prod
      |     +-- Project: billing-prod
      +-- Folder: Sandbox       capped budgets, short-lived
2
A project is the strongest practical boundary. Its own IAM, quotas, billing and API enablement — and projects are cheap, so one per environment per service is normal rather than extravagant.
3
Organization Policy constrains resources, IAM constrains people.
    IAM                 who may perform an action
    Organization Policy what is ALLOWED TO EXIST, regardless of IAM
4
So an Owner can still be refused. The constraints that earn their place immediately:
5
    disableServiceAccountKeyCreation   no long-lived key files
    requireShieldedVm
    vmExternalIpAccess                 deny public IPs by default
    resourceLocations                  restrict to allowed regions
    storage.publicAccessPrevention     no public buckets ever
6
publicAccessPrevention is the one that prevents the classic headline. A world-readable bucket becomes impossible rather than merely discouraged.
publicAccessPrevention
7
VPC Service Controls are the GCP-specific control worth knowing. They draw a perimeter around services so data cannot be read out to a project outside it, even with valid credentials:
8
    perimeter: { projects: [orders-prod], services: [storage, bigquery] }
9
That defends against exfiltration using stolen credentials, which IAM alone cannot — because the credentials are legitimate. It is also the control most likely to break a legitimate integration, so it needs a dry-run phase.
10
Security Command Center is the detection layer: misconfiguration findings, vulnerability scanning, and threat detection from logs. Premium adds Event Threat Detection and compliance reporting.
11
Logging belongs outside the project it describes. An aggregated log sink at the organization level writes to a separate project or bucket, so someone with project admin cannot erase the evidence.
12
Essential Contacts and budget alerts complete it, so the right people hear about security and spend without watching a console.
13
What the interviewer is probing.1. "What does Organization Policy do that IAM does not?" Probing: the two controls. Stalls: "Both restrict access." Moves up: IAM decides who may act; Organization Policy decides what may exist, so an Owner can still be refused a public IP or a public bucket.
14
2. "What threat do VPC Service Controls address?" Probing: exfiltration with valid credentials. Stalls: "Unauthorised access." Moves up: a leaked credential is legitimate, so IAM allows the read; a perimeter blocks the data moving to a project outside it.
15
3. "How do you roll out VPC-SC safely?" Probing: dry run. Stalls: "Enable it." Moves up: dry-run mode logs what would be blocked, and the first run always surprises you — it is the control most likely to break a working integration.
16
4. "Why are projects the main boundary on GCP?" Probing: the hierarchy. Stalls: "They are just folders." Moves up: each has its own IAM, quotas, billing and API enablement, and they are cheap — so one per environment per service is normal rather than extravagant.