Guardrails in a two-organization merger
Northwind Payments has run on Google Cloud for three years with a single organization, 14 projects, and no folders. It has just acquired a 90-person lender that has its own Google Cloud organization, six projects, and a PCI-scoped card-processing workload. Security wants: no external IP addresses on VMs anywhere, VPC Service Controls around cardholder data, all audit logs retained 400 days, and a shared VPC so egress is inspectable. Two data-science projects legitimately need public egress to pull third-party datasets. One acquired project runs a production Cloud SQL instance that cannot take a maintenance window for six weeks. The platform team is three engineers with no dedicated security staff.
1. Where do the external-IP and VPC Service Controls guardrails actually live, and what does the org policy on external IPs buy you?
Read the worked answer
Hierarchy: organization, then folders by business unit and environment, then projects. Put the external-IP deny at the organization node so all 20 projects inherit it; the data-science exception gets its own folder (egress-approved) and that folder carries a replacement policy.
The judgement call: organization policy is inherited and a policy set on a child replaces the inherited one. It is not a one-way ratchet. So the deny does not stop anyone holding orgpolicy.policy.set at a project from loosening it. Treat it as a guardrail, not a boundary. The boundary is IAM (that permission held only by a break-glass group, granted at org node, with no project-level grants), plus an alert on SetOrgPolicy audit events and Cloud Asset Inventory drift detection.
VPC-SC is separate and must sit on the folder containing the PCI projects, with the shared VPC host inside the same perimeter. Network policy cannot be expressed as an org policy, and a perimeter cannot span the two organizations, which drives the migration order.
For three engineers: express all of it in Terraform in a bootstrap repo, apply to the acquired projects with org policy dry-run first so you see the breakage before enforcing.
2. How do you sequence absorbing the acquired projects, given the Cloud SQL six-week constraint?
Read the worked answer
Separate the two moves, because only one of them needs a maintenance window.
- Run all target constraints in dry-run against the six acquired projects for a week and collect violations.
- Migrate the projects into the Northwind organization. This is a resource-hierarchy move: VMs and Cloud SQL instances keep running, but you need org admin on both organizations, the billing account must be re-linked, and anything resolving the old organization (VPC-SC access policy, legacy IAM grants, aggregated log sinks) changes underneath you. Do it early, in a quiet window, one project at a time, with a rollback plan.
- Leave the Cloud SQL instance on its own VPC for now. Attach the project to the shared VPC for compute immediately; reach the database over VPC peering or Private Service Connect from the host project. Note peering is non-transitive - if other spokes must reach it, plan a hub or NCC rather than chaining peerings.
- At the six-week window, migrate the instance into a shared VPC subnet (this is the step that needs an outage).
Do not delay the project migration to align with the database; you would run six weeks with two security postures.
3. Design the 400-day audit log requirement without letting logging cost run away.
Read the worked answer
Check what the requirement already covers before buying anything. Admin Activity audit logs are free and retained 400 days by default. The Data Access logs are the ones that cost money to ingest and default to 30 days. So the deliverable is a 400-day bucket for Data Access logs on the PCI projects only, not an all-logs all-projects sink.
Design: an organization-level aggregated sink with an inclusion filter of logName:cloudaudit.googleapis.com%2Fdata_access AND the PCI project IDs, writing to a custom log bucket with --retention 400d and a locked retention policy. Exclude health-check, readiness-probe, and high-volume read-only GCS data access on buckets that hold no card data.
Do the arithmetic to show why the filter matters: ingestion is about $0.50/GiB, retention beyond 30 days is about $0.01/GiB-month. If PCI Data Access traffic is 1.8 TiB/month, ingest is roughly 1,843 GiB x $0.50 = $920/month and the extra 370 days of retention adds roughly $18/month. Retention is nearly free; ingestion is not. So the decision is entirely about what you route, and the cost of a mistake is that excluded logs are gone - exclude by resource and method, never by severity alone.