Professional Cloud DevOps Engineer

Designing the Overall Resource Hierarchy for an Organization

Organizing Resources

The GCP resource hierarchy begins at the Organization node, which represents the entire company and acts as the root of trust. Below the organization, folders allow teams to group projects logically, mirroring corporate departments or business units. At the base of the hierarchy, projects act as the fundamental enabling unit, housing the actual resources such as virtual machines or databases.

Designing this hierarchy requires choosing between an environment-centric approach and an application-centric approach. An environment-centric structure separates production from development at the folder level, isolating sensitive environments early. An application-centric structure groups all environments of a single application under one folder, making it easier for a dedicated team to manage their specific system's lifecycle.

Shared Networking

Centralized networking relies on a Shared VPC, where a designated host project controls the network configuration, subnets, and firewalls. Separate service projects attach to this host project, allowing application developers to deploy resources into pre-configured subnets without giving them control over the core network settings. This setup establishes a clear boundary between network administrators and application developers, ensuring security policies are enforced uniformly.

When projects must remain completely independent but still communicate, organizations choose between VPC Network Peering and Private Service Connect. VPC Network Peering connects two networks directly so they can exchange traffic using internal IP addresses, though it requires non-overlapping IP ranges. Private Service Connect offers a more flexible alternative by using IP addresses in the consumer network to access services in a producer network, bypassing the need for complex peering relationships.

Multi-Project Monitoring and Logging

Managing logs across an organization requires routing data from individual projects to a centralized repository using log sinks. Organizations configure aggregated sinks at the folder or organization level to automatically intercept and copy logs from all underlying projects. These logs flow securely into destination resources like Cloud Storage for long-term archiving, BigQuery for analysis, or Pub/Sub for real-time security monitoring.

To monitor performance metrics across several applications, teams use a scoping project to define a monitoring scope. This scoping project functions as a single pane of glass, pulling metrics, dashboards, and uptime checks from multiple monitored projects. This separation ensures that operators can view holistic system health without needing direct access to the sensitive host projects where the workloads actually run.

Identity and Access Management and Organization-Level Policies

Identity and Access Management (IAM) controls who can take action on specific resources, and these permissions inherit downward through the resource hierarchy. A role granted at the organization level automatically applies to all folders, projects, and resources beneath it. Because IAM policy inheritance is strictly additive, a permission granted at a higher level cannot be stripped away or restricted at a lower level.

To enforce strict guardrails that IAM roles cannot manage, administrators deploy organization policies. These policies apply constraints, such as disabling external IP addresses on virtual machines or restricting which public images can be booted. While IAM dictates who can perform an action, organization policies dictate what can be done, defining the boundaries of compliance for all projects under the hierarchy.

Creating and Managing Service Accounts

Workloads and applications use a service account to authenticate and gain access to resources without relying on individual user credentials. Service accounts act both as an identity that can hold IAM roles and as a resource that users can manage or impersonate. Security teams should prefer Google-managed keys, which rotate automatically, over user-managed keys that must be downloaded and stored securely to prevent leaks.

To follow the principle of least privilege, administrators configure service account impersonation rather than distributing permanent keys. Developers or service accounts can temporarily assume the identity of a more privileged service account to perform specific tasks, generating short-lived credentials that expire automatically. This practice eliminates long-term secrets, significantly shrinking the attack surface if a system is compromised.

Data Residency

Many compliance frameworks require strict control over data residency, ensuring that customer data is physically stored and processed within specific geographical boundaries. To guarantee compliance, organizations must specify whether resources are deployed in a single region or across a multi-regional footprint. This decision directly impacts latency, disaster recovery capabilities, and legal compliance.

Administrators use the resource location constraint within the Organization Policy Service to enforce data residency rules across the entire resource hierarchy. This constraint blocks users from creating storage buckets, virtual machines, or databases outside of allowed physical regions, regardless of their IAM permissions. Consequently, the organization policy acts as a hard boundary, keeping all sensitive data locked within approved sovereign borders.