Google Cloud Landing Zones: Governance Before Growth
A landing zone is the foundation that determines how new cloud projects inherit identity, network, security, billing, logging, and policy decisions. Its purpose is not to make every workload identical. It is to make safe, supportable defaults available before hundreds of teams create their own incompatible versions.
For the Professional Cloud Architect exam and the Google Professional Cloud Architect role, this is architecture at organizational scale. A single application can be designed well and still create enterprise risk if projects have inconsistent IAM, unrestricted networking, unclear ownership, or no cost attribution.
Governance is cheapest when it is built into the foundation. Retrofitting it after growth usually means migrations, policy exceptions, and political negotiation.
Resource hierarchy is an operating model
Google Cloud organizations, folders, projects, and resources create a hierarchy through which policies and access can be applied. The hierarchy should reflect stable administrative and policy boundaries rather than temporary org-chart details.
Common patterns separate production from nonproduction, central platform capabilities from application projects, and regulated workloads from general workloads. The exact structure depends on who needs delegated authority and which controls must inherit downward.
Good information-security governance makes ownership visible. Every major folder and project pattern should have an accountable team, a purpose, and rules for who may create exceptions.
Use organization policy for preventive guardrails
Organization Policy lets platform teams enforce constraints across the resource hierarchy. This is powerful because a restriction applied high in the hierarchy can protect new projects automatically instead of relying on every engineer remembering a checklist.
Preventive controls are best for rules the organization is not willing to negotiate on each deployment: allowed locations, restricted services, external IP behavior, key requirements, or other policy constraints. But guardrails should be tested carefully because a broad policy can also block legitimate workloads.
Create a documented exception path. Governance without exceptions becomes shadow IT; exceptions without review become governance theater.
Identity design should minimize standing privilege
Human access, workload identity, CI/CD identity, and emergency access should be treated separately. Groups are usually easier to govern than direct user bindings, and service accounts should represent workloads rather than become shared credentials.
Central roles can provide platform-wide capabilities, while project roles allow teams to operate their own services. Avoid broad basic roles when narrower predefined or custom roles can express the actual job.
The broader governance, risk, and compliance discipline is useful here because access control is not just a technical configuration. It needs approval, evidence, periodic review, and a process for people who change roles.
Network foundations should enable teams without erasing boundaries
A landing zone should define how projects connect to shared networks, the internet, on-premises systems, and each other. Shared VPC can centralize network administration while service projects retain workload ownership, but the model needs clear responsibilities for routes, firewalls, DNS, private access, and hybrid connectivity.
Default-deny thinking is useful, but connectivity must remain operable. If every application requires a one-off ticket for routine communication, teams will seek shortcuts. Provide reusable network patterns for common cases.
Separate sensitive environments where policy or blast radius requires it. Network architecture should reflect trust, not merely convenience.
Centralize the evidence needed to operate and audit
Logging, asset inventory, security findings, billing exports, and monitoring should have organization-level patterns so teams do not lose evidence when a project is deleted or misconfigured. Central sinks and designated projects can provide durable collection while workload teams retain local visibility.
Decide what must be retained, for how long, and who can access it. Centralization can create a powerful forensic capability, but it can also create a high-value store of sensitive operational data.
A mature risk-management approach ties the evidence to named risks. Collecting every possible signal forever is expensive; collecting nothing leaves the organization unable to prove or investigate important events.
Billing structure should make accountability possible
Cloud cost is easier to manage when projects, labels, and billing accounts map cleanly to owners and environments. A landing zone should require enough metadata that finance and engineering can answer who owns a resource, why it exists, and which product or cost center benefits from it.
Budgets and alerts should be available from the beginning. They are not hard spending caps, but they create feedback before a forgotten test environment or runaway query becomes a large surprise.
Chargeback is not required for every organization, but showback is valuable. Teams change behavior when they can see the cost of their architectural choices.
Security services need a shared responsibility model
Platform teams may centrally manage organization policies, security findings, key management patterns, vulnerability tools, and network controls, while application teams remain responsible for code, data classification, service configuration, and application authorization.
The skills associated with Google Cloud security engineering help define that boundary. Central controls should reduce the chance of catastrophic mistakes without creating the illusion that applications are secure merely because they were deployed inside an approved folder.
Write the responsibility model down. Incidents become worse when the platform team assumes an application team owns a control and the application team assumes the opposite.
Automation should create compliant projects by default
The best landing zone is easy to consume. Project factories, infrastructure-as-code modules, approved templates, and automated onboarding can create projects with required APIs, logging, budgets, network attachment, IAM groups, labels, and policy inheritance already in place.
This is more scalable than asking every team to copy a document. It also makes improvements easier because the foundation can evolve through versioned automation rather than manual configuration drift.
Do not hide every detail from consumers. Teams need to understand which controls exist and why, especially when a policy blocks a design choice.
A mature landing zone also needs a controlled exception path. Preventive policies are valuable precisely because they stop unsafe configuration, but there will be legitimate cases in which a research workload, migration tool, acquired business, or regulated application cannot immediately fit the standard pattern. The exception should identify the control being relaxed, the business owner, the compensating safeguard, the review date, and the condition for returning to the baseline. Time-bounded exceptions are easier to govern than permanent manual overrides that nobody remembers. Apply the same discipline to foundational automation: test changes to project factories, organization policies, network modules, and IAM defaults in a representative environment before broad rollout, and retain a rollback path for changes that unexpectedly block teams. Governance scales when the standard path is fast and the exception path is visible, accountable, and temporary.
Design governance for change, not permanence
Cloud services, regulations, organizational structure, and risk appetite all change. A landing zone should therefore be treated as a product with owners, versioning, documentation, testing, and a roadmap.
The strategic lesson in cloud governance and sustainable growth is that growth magnifies weak foundations. A control that is mildly inconvenient at ten projects can be unmanageable at a thousand; a good default can save thousands of repeated decisions.
Measure the foundation by outcomes: how quickly a compliant project can be created, how many manual exceptions exist, how much privileged access is standing, whether owners and costs are identifiable, and how consistently logs and security findings reach the right teams.
A landing zone succeeds when it makes the safe path the easy path. Resource hierarchy, IAM, networking, policy, logging, and billing should work together so new workloads inherit a reasonable baseline without waiting for a governance project to catch up later. Growth then becomes an expansion of a controlled system instead of a collection of unrelated projects.
Exception management is where many landing zones either mature or decay. Each exception should name the blocked control, the business reason, the compensating safeguard, the owner, and an expiry or review date. Permanent undocumented exceptions slowly turn a standard foundation into a collection of special cases that no central team can reason about.
Test new guardrails against representative workloads before organization-wide enforcement. Development platforms, data services, third-party appliances, and regulated applications may depend on capabilities that a generic policy accidentally blocks. Policy-as-code and staged deployment make it possible to detect those collisions before a central change disrupts production.
Recovery of the foundation itself also matters. Central DNS, identity integrations, network hubs, security projects, CI/CD systems, and logging sinks can become organization-wide dependencies. Their availability and break-glass procedures deserve a higher standard than ordinary workload projects because a failure can affect many teams at once.
Good landing zones also shorten decommissioning. When project ownership, data classification, network attachments, and billing metadata are standardized, teams can retire an environment with greater confidence that hidden dependencies and retained data have been addressed. Governance should make both creation and removal predictable.
Platform teams should publish a small number of supported patterns instead of an enormous catalog of options. A standard internet-facing application pattern, private application pattern, data platform pattern, and sandbox pattern can cover much of an organization while leaving room for reviewed exceptions. Too many ‘standards’ recreate the complexity the landing zone was meant to remove.
Track policy drift and orphaned resources continuously. Projects without owners, service accounts without recent use, external IPs outside approved patterns, and resources missing required labels are signs that the foundation is being bypassed. Governance is healthier when these signals trigger repair before an audit or incident forces a large cleanup.