Google Cloud / Basic: Resource and Access Boundaries / Lesson 1

Projects and the Resource Hierarchy

Use the hierarchy to assign ownership and policy scope without confusing a project with an application, network, or billing account.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish organization, folder, project, and service resource.
Explain inherited controls and project identifiers.
Build an offline inventory with explicit owners.

Hierarchy organizes ownership and policy

Google Cloud organizes many resources beneath projects, with optional folders and an organization above them. A project is a major administrative boundary for enabled services, identity grants, quotas, and billing association. It is not automatically one application, one environment, or one network. Choose those relationships from lifecycle and ownership requirements rather than a naming shortcut.

An organization provides central ownership and policy attachment points when available. Folders can group projects by business or environment. Some users can have projects without an organization, while managed organizations impose their own creation rules. Never assume a personal project and a centrally governed project have identical constraints.

Display names and stable identifiers differ

A project has a display name, project ID, and numeric project number with different roles. A friendly name is not a reliable unique reference, and changing a display name does not rename every resource. API resource names can incorporate project numbers or IDs according to the service. Record the exact identifier expected by a document or interface.

The first example validates only an invented inventory’s uniqueness and required metadata. It does not verify real project existence or Google’s naming rules. Local checks can catch duplicate bookkeeping before a design review, but cloud identity, organization placement, permissions, and lifecycle require authorized service evidence.

python Check a synthetic project inventory

projects = [{"id": "study-dev", "owner": "team-a", "environment": "dev"}, {"id": "study-prod", "owner": "team-a", "environment": "prod"}]
ids = [project["id"] for project in projects]
assert len(ids) == len(set(ids))
assert all(project["owner"] and project["environment"] for project in projects)
print(f"inventory={len(projects)} unique={len(set(ids))}")

Expected output

inventory=2 unique=2

Two invented records have distinct IDs and explicit owners; no account or API is consulted.

Ancestor controls remain relevant below

IAM allow grants can be inherited from ancestors. A narrow project policy does not cancel a broader inherited grant. Deny policies, organization constraints, conditions, and service-specific controls have their own evaluation rules; do not reduce effective access to reading one local allow-policy file. A resource move can change the ancestors whose controls apply.

The second offline program traces an invented project to its parents. It is a graph exercise, not an IAM evaluator. Its value is showing which policy attachment points a reviewer must consider. A complete evaluation also needs principal, permission, resource, request context, and current policy state.

python Trace local policy attachment points

parents = {"project-study": "folder-apps", "folder-apps": "organization-study", "organization-study": None}
path = []
node = "project-study"
while node is not None:
    if node in path:
        raise ValueError("cycle in synthetic hierarchy")
    path.append(node)
    node = parents[node]
print(" -> ".join(path))

Expected output

project-study -> folder-apps -> organization-study

The model exposes project, folder, and organization ancestors without evaluating cloud access.

Choose boundaries by lifecycle and responsibility

Separating development and production projects can clarify access, quotas, and incident scope, but shared dependencies still cross boundaries. Define who approves creation, maintains contacts, labels resources, reviews access, and owns deletion or migration. A project can contain resources with independent retention and recovery requirements.

Do not treat project deletion as an ordinary cleanup instruction for a lesson. Designs should describe dependencies, retention, and recovery before any real lifecycle action. A change in hierarchy or billing association can have operational consequences even when application code is untouched. Review it as an infrastructure change.

Keep a reviewable resource map

A useful resource map names the project, parent, owner, environment, billing relationship, data classification, and required locations. Distinguish organizational tags and labels according to their documented purposes; a cost label is not automatically an access restriction. Keep identifiers and policy assumptions separate from human descriptions.

For each design claim, say whether it is an offline inventory fact or a cloud fact still requiring verification. This distinction prevents a neat diagram from being mistaken for evidence that permissions or restrictions are enforced. The course’s synthetic checks make bookkeeping reviewable without touching a real organization.

Common errors and fixes

A project-level grant is assumed to remove inherited access.

Why it happens: Allow inheritance was ignored.
How to fix it: Review ancestors and applicable deny/constraint rules.
Prevent it next time: Record effective-policy scope in the design.

A friendly project name identifies the wrong target.

Why it happens: Display name and unique identifiers were conflated.
How to fix it: Record the ID or number required by the interface.
Prevent it next time: Keep names and identifiers in separate fields.

A local inventory is called proof of enforcement.

Why it happens: Metadata validation was mistaken for cloud evaluation.
How to fix it: Label the check and list external verification still required.
Prevent it next time: Separate design evidence from service-state evidence.

Check your understanding

1. A team wants one project for every developer and another for shared production. What questions precede that choice?

Show worked solution

Identify lifecycle owners, access boundaries, shared data, quota needs, billing attribution, policy inheritance, and recovery responsibilities. Separate projects can help isolation but do not automatically isolate a shared database or grant correct permissions. Record which dependencies remain shared and how each project is created, reviewed, and retired under the organization’s authorized process.

2. Why cannot the ancestor-tracing program tell whether a principal may read an object?