Every resource you create in Google Cloud lives inside a project, and every project occupies a place in a hierarchy. That structure is not administrative bureaucracy: it determines who can do what, who pays for what, which quotas apply, which policies are inherited and which resources can see each other. Designing it well at the outset costs an afternoon; redesigning it two years later costs a quarter.

In this lesson we build AlpinaShop's structure in Google Cloud. We will look at the full Organization → Folders → Projects → Resources hierarchy, what exactly a project is and why the projectId is immutable and global, in what sense the project is a boundary for billing, quotas, permissions and networking, how billing accounts work and who can link them, how spend is apportioned with labels, how billing is exported to BigQuery and how to read the reports and configure budgets. We will finish with structural best practices and a complete worked example with gcloud.

1. The Google Cloud resource hierarchy
2. AlpinaShop's hierarchy
3. What exactly a project is: ID, number and name
4. The project as a boundary
5. Billing accounts
6. Labels for apportioning spend
7. Reports, export to BigQuery and budgets
8. Policy inheritance in the hierarchy
9. Best practices for project structure
10. A complete worked example with gcloud

Google Cloud organises everything in a four-level tree:

Each level can carry IAM policies and organization policies, and those policies are inherited downwards. That is the real reason the hierarchy exists: apply a rule once and have it cover everything underneath.

A few clarifications that prevent confusion:

• No organization means no folders. If you signed up with a personal account (lesson 01-02), your projects are loose and you cannot create folders. That is one of the main reasons for using Cloud Identity in a company.
• The organization creates itself. You do not create it: it appears automatically the first time a user of the verified domain creates a project.
• Resources do not hang from folders, only projects do. A VM is always inside a project, never directly in a folder.

Marta designs this structure for AlpinaShop, deliberately simple: for a 40-person company, a hierarchy of three folders and four projects is more than enough. Complex structures are for organizations with dozens of teams.

Why this structure and not another:

• Separate produccion and desarrollo make it possible to apply different policies to each world. In production, public IPs will be banned and audit logs required; in development, more freedom will be allowed and low budgets set.
• compartido houses what serves both environments: the CI/CD pipeline and the analytical warehouse. Separating analytics into its own project prevents Lucía's queries from eating production quotas and makes it easier to give her broad permissions there without giving them to her on the shop.
• One project per environment, not one project with "dev" and "prod" resources mixed together. It is the most important rule of all.

In this module we will work only with alpinashop-dev. The other projects will be created as the corresponding modules need them.

A project has three distinct identifiers and confusing them causes errors that are hard to diagnose.

Details about the projectId you need to internalise:

• It is unique across the whole of Google Cloud, not just within your organization. If another customer somewhere in the world already uses tienda, you cannot. That is why corporate IDs usually carry a company prefix.
• It can never be changed. Not by renaming, not through support. The only way out is to create another project and migrate the resources, which in many cases means recreating them.
• Format rules: between 6 and 30 characters, lower case, digits and hyphens, must start with a letter and cannot end in a hyphen.
• When you delete a project, its ID is not released immediately (and in practice it is better to assume it is never released for your own use).

About the projectNumber, it is worth knowing that it appears in the default service accounts, in forms such as [email protected] or [email protected]. When you see a long number in a service account address, it is your project's number.

The --format="table(...)" flag selects which fields to show and presents them in columns. Without it, gcloud would return a default table with less information. In lesson 01-06 we will look at --format and --filter in depth.

This is the central idea of the lesson: the project is simultaneously four distinct boundaries, and that is why deciding what goes in which project is an architectural decision.

Of these four, networking is the one that most surprises people coming from a traditional environment. Two VMs in different projects do not share a private network unless you configure it explicitly through Shared VPC or peering, topics covered in lessons 03-01 and 07-03. This is an isolation advantage, not an obstacle.

And a useful consequence that gets exploited constantly: deleting a project deletes everything it contains. It is the most reliable way to clean up a test environment and to guarantee that nothing is left generating spend.

That 30-day window is an important safety net: an accidental deletion is recoverable, as long as it is spotted in time.

A billing account defines who pays, by what payment method and to which tax details the invoice is issued. It is an object that lives outside the project hierarchy: it does not hang from a folder or a project, it is associated with them.

The relationship is N to 1: many projects can point at the same billing account, but each project has at most one.

Linking a project to a billing account requires permissions on both sides, and this is a deliberate separation of duties:

At AlpinaShop, Marta has billing.admin, the finance manager has billing.viewer so as to consult spend without being able to touch anything, and Dani has billing.user on the account so he can link test projects himself. The detail of how IAM roles work is studied in lesson 03-04.

unlink is a blunt and very useful tool: it is the "emergency cut-off" when a project's cost runs away. It stops consumption of billable services almost immediately, although it can also cause data loss in services that do not tolerate being left without billing. Use it knowing what you are doing.

Labels (labels) are key-value pairs that can be applied to projects and to most resources. Their superpower is that they appear in the billing reports and in the BigQuery export, which makes it possible to answer questions such as "how much did the development environment cost us last month?" or "what does the data team spend?".

Format rules:

• Key and value in lower case, with digits, hyphens and underscores.
• A maximum of 63 characters each; up to 64 labels per resource.
• The key cannot be empty; the value can.

A reasonable labelling scheme for AlpinaShop:

Tips on labelling, learned the hard way by many teams:

• Define the scheme before you start creating resources. Labelling 300 resources after the fact is a project in itself.
• Be strict about values. dev, desarrollo and Desarrollo are three different labels and will break your reports.
• Do not put sensitive information in labels. They are visible to anyone with read permissions on the resource.
• Do not confuse labels with tags. Google Cloud also has tags (governed labels) that serve to apply policies conditionally, not for billing. They are covered in lesson 07-07.

In the console, Billing → Reports offers an interactive view of spend with filters by project, service, SKU, region, labels and period, and configurable grouping. It is where most day-to-day questions are answered.

Concepts that appear in those reports and are worth distinguishing:

A very concrete tip: when spend does not add up, group by SKU, not by service. "Compute Engine: €210" tells you nothing; "Storage PD Capacity: €140" tells you that you have orphaned disks.

The console reports are convenient but limited. For serious analysis, Google lets you export billing data to a BigQuery dataset, where it arrives with daily detail by SKU, project, label and region, and where it can be queried with SQL.

It is enabled under Billing → Billing export, choosing the destination project and dataset. AlpinaShop will send it to the alpinashop_analitica dataset in the alpinashop-datos project, so that Lucía can cross spend with business data.

Two warnings:

• The export is not retroactive: it only brings in data from the moment you enable it. That is another reason to configure it early even if you are not going to use it yet.
• The data takes several hours to appear and is corrected during the month, so it is no good for real-time alerts.

Analysing that data with SQL belongs to lesson 04-01 (BigQuery) and using it to optimise costs to lesson 07-05. Here it is enough to enable it.

We already created a basic budget in lesson 01-02. Now we can take advantage of the hierarchy and the labels to refine it:

Points to note about the command:

• --filter-labels limits the budget to spend on resources carrying that label, rather than to a specific project. It is more flexible: if tomorrow there are three development projects, the budget covers them all without any changes.
• basis=forecasted-spend changes the nature of the warning: instead of warning you when you have already spent 90 %, it warns you when the end-of-month projection reaches that percentage. It gives you days of leeway instead of hours.
• Remember from lesson 01-02: budgets warn, they do not block.

Depending on the SDK version, this command group may require the alpha prefix (gcloud alpha billing budgets ...). Check with gcloud billing budgets --help.

The hierarchy exists, above all, so that policies are applied once and cover everything below. There are two types of policy and both are inherited:

Inheritance rules that need to be well understood:

• IAM permissions accumulate downwards and cannot be subtracted. If you grant someone the editor role at organization level, they will be an editor in every project, and you cannot take it away in a specific one through IAM. That is why granting broad roles at high levels is dangerous.
• Organization policies do restrict. They are the right tool for banning things, and by default a policy defined at a node replaces or combines with the inherited one depending on its configuration.
• The practical rule: grant permissions at the lowest possible level and restrictions at the highest possible level.

Both topics are studied in depth later: IAM in lesson 03-04 and organization policies and governance at scale in 07-07. What you need to retain now is that where you place a project in the hierarchy determines what it inherits, and that is why moving a project between folders changes its effective policies.

On the last point: there is a school of thought that argues for one project per microservice and environment. For a large organization with autonomous teams that can make sense; for AlpinaShop it would be a disproportionate maintenance burden. The structure should be proportional to the size of the team. Four projects for 40 people is reasonable; forty would not be.

Marta is going to set up AlpinaShop's structure from Cloud Shell. This block brings together everything we have seen.

gcloud organizations list returns the organizations you have permissions on. With --format="value(ID)" we extract only the numeric identifier, without headers, so it can be stored in a variable. If the output is empty, you have no organization (a personal account) and you will have to skip the folder steps.

Here --filter and --format appear together for the first time. --filter="displayName=desarrollo" narrows the list down to the folder we are interested in, and --format="value(name)" extracts only its identifier. It is the scripting pattern we will use throughout the course.

If the project already existed from lesson 01-02 without a folder, it can be moved instead of recreated:

The parent.type field should show folder and parent.id the identifier of the development folder. billingEnabled should be True: if it is False, the link did not complete and practically no API will work.

With this, AlpinaShop has a real hierarchy, a correctly placed and labelled project, billing linked and an economic alarm active.

• Choosing the projectId badly. It is immutable and global. Adopt the company-workload-environment convention and apply it without exception.
• Confusing projectId with projectNumber. When an API or an error message asks for a specific one, give it that one: they are not interchangeable in every context.
• Mixing development and production in one project. The day someone deletes the wrong database by mistake you will understand why. It also makes it impossible to separate quotas, permissions and cost.
• Granting broad roles at organization or folder level. IAM permissions are inherited downwards and cannot be subtracted at a lower level.
• Labelling late or inconsistently. A scheme defined from the start and respected is worth more than a sophisticated one applied half-heartedly.
• Enabling the billing export to BigQuery once you already need it. It is not retroactive: the previous months are lost.
• Assuming the budget cuts off spend. It does not. It remains a smoke detector.
• Tip: use gcloud projects delete to clean up test environments. It is the only reliable way to make sure nothing is left billing, and you have 30 days to change your mind.
• Tip: do not create more projects than you can govern. Each one drags along permissions, networking, quotas and a budget.

AlpinaShop grows and opens a subsidiary in Portugal that will run its own shop (alpinashop.pt) with its own database, but will share the CI/CD pipeline and the analytical warehouse with the parent company. On top of that, management insists on being able to see at a glance what each country costs separately.

Design the resulting hierarchy (folders and projects), state which labels you would add, and explain at which level you would place the policy banning the creation of VMs with a public IP in production, and why.

Answer with reasoning:

1. Marta has made a mistake and created the project with the ID alpinshop-dev (an a is missing). Can she correct it? What options does she have?
2. Dani sees the address [email protected] in a log. What is that number and how would he check which project it belongs to?
3. Marta wants spend on the alpinashop-dev project to stop immediately because a process has run out of control. What command does she run and what risk does she take on?

Write a bash script that creates a project called alpinashop-pruebas with these characteristics, checking at every step that the operation succeeded:

• Located in the desarrollo folder.
• Labelled with entorno=pruebas, equipo=infraestructura and responsable=marta.
• Linked to the billing account.
• With a budget of 10 EUR and warnings at 50 %, 90 % (on forecast) and 100 %.

And add at the end the command you would use to remove that environment completely when you have finished testing.

Solution 1

A reasonable structure:

Labels: to the existing ones (entorno, equipo, centro-coste) a pais label is added with values es and pt. With that label, management gets the breakdown by country in the billing reports without having to look at the hierarchy, and budgets can be created per country with --filter-labels=pais=pt.

The policy banning public IPs is placed on the produccion folder, not on each project. The reasons: it is defined once, it is inherited automatically by es and pt and by any country added in the future, and it does not affect development, where that restriction would get in the way of the work. Placing it on the organization would be excessive (it would break development) and placing it on each project would be fragile (the next project would be created without it).

Solution 2

1. She cannot correct it. The projectId is immutable. Her options are: (a) create a new project with the correct ID and recreate or migrate the resources, which is cheap if the project is newly created and practically empty; or (b) keep the wrong ID and correct only the display name, which is editable with gcloud projects update alpinashop-dev --name="...". Given that the project is young, the sensible thing is to recreate it and delete the wrong one.
2. It is the projectNumber, the project's numeric identifier, and that address corresponds to that project's default Compute Engine service account. To find out which project it belongs to:

   gcloud projects list --filter="projectNumber=482913057261" \\
     --format="value(projectId)"
   

3. She runs gcloud billing projects unlink alpinashop-dev. Unlinking billing means paid services stop working almost immediately and spend halts. The risk is that some services do not tolerate being left without billing and may lose data or resources: stopped instances, cancelled jobs, and in certain cases deletion of resources if the situation drags on. It is an emergency measure, not a way to "pause" a project. A less aggressive alternative is to identify and stop the specific resource that has run out of control.

Solution 3

To remove the environment completely when you have finished:

This single command removes the project and all its resources, guaranteeing that nothing is left generating spend. The project stays 30 days in DELETE_REQUESTED state and can be recovered within that window with gcloud projects undelete alpinashop-pruebas.

This lesson has established the skeleton on which everything else will rest. We have gone through the Organization → Folders → Projects → Resources hierarchy and applied it to AlpinaShop with the produccion, desarrollo and compartido folders; we have distinguished a project's three identifiers and fixed in our minds that the projectId is immutable and unique across the whole of Google Cloud; we have seen that the project is simultaneously a boundary for billing, quotas, permissions and networking, and that deleting it is the most reliable way to clean up an environment; we have understood billing accounts, their N-to-1 relationship with projects, who can link them and what unlink means as an emergency cut-off; we have defined a labelling scheme for apportioning spend by environment, team and cost centre; we have enabled the export to BigQuery into alpinashop_analitica and refined the budgets with forecast-based warnings; and we have reviewed how each type of policy is inherited and what project structure is proportional to a 40-person company.

We now know who owns what and who pays. The other coordinate is still missing: where the resources live. In the next lesson, Regions, Zones and the Shared Responsibility Model, we will look at Google Cloud's geography —multi-region, region and zone—, what it means for a service to be zonal, regional or global, how Google's private backbone network works, what criteria lead AlpinaShop to decide between europe-west1 and europe-southwest1 (latency, price, available services and data residency under the GDPR), what deploying across several zones really protects against, and how security responsibility is divided between Google and you depending on the type of service.