Google Cloud Fundamentals: Core Infraestructure - Resource and access in the cloud -> Resource hierarchy

Google Cloud resource hierarchy contains four levels. Starting from the bottom they are: resources, projects, folders, Root Node (Organization)

Google Cloud resource hierarchy contains four levels. Starting from the bottom they are: resources, projects, folders, Root Node (Organization).

Resources:
At the first level are resources. These represent virtual machines, cloud storage buckets, tables in bigquery or anything else in the Google Cloud.

Projects:
Resources are organized into projects, which sit on the second level

Folder:
Projects can be organized into folders, or even subfolders. These sit at the third level.

Organization node:
And then at the top level is an organization node, which encompasses all the projects, folders, and resources in your organization.

Understanding policies or how it works?

It's important to understand this resources hierarchy because it directly relates to how can we manage the policies and applies it when we use Google Cloud. We need to know that some Google Cloud services allow policies to be applied to individual resources too. The policies are also inherited downward. This means that if we apply a policy to a folder, it will apply to all of the projects respectively.

Second level

Projects are the basis for enabling and using Google Cloud services, like managing APIs, enabling billing, adding and removing collaborators, and enabling other Google services. Thus, each project is a separate entity under the organization node, and each resource belongs to exactly one project. Thereby *projects* can have different owners and users because they're billed and managed separately.

Each project has three important attributes: a project ID, a project name andf a project number. These have special features, it's going show in the next picture:

Google cloud has a interesting tool to get easy way to handle the resources. Resource manager tool is designed to programmatically help you manage projects.
It’s an API that can gather a list of all the projects associated with an account, create new projects, update existing projects, and delete projects. It can even recover projects that were previously deleted,and can be accessed through the RPC API and the REST API.

Third level

Folders let you assign policies to resources at a level of granularity you choose. The resources in a folder inherit policies and permissions assigned to that folder. A folder can contain projects, other folders, or a combination of both. You can use folders to group projects under an organization in a hierarchy. For example, your organization might contain multiple departments, each with its own set Google Cloud resources. Folders allow you to group these resources on a per-department basis. Folders also give teams the ability to delegate administrative rights so that they can work independently.

As previously mentioned, the resources in a folder inherit policies and permissions from that folder. For example, if you have two different projects that are administered by the same team, you can put policies into a common folder so they have the same permissions. Doing it the other way--putting duplicate copies of those policies on both projects–could be tedious and error-prone. if you needed to change permissions on both resources, you would now have to do that in two places instead of just one.

To use folders, you must have an organization node, which is the very topmost resource in the Google Cloud hierarchy. Everything else attached to that account goes under this node, which includes folders, projects, and other resources. There are some special roles associated with this top-level organization node.

Four level

Organization node is neccesary to use folders, you must have an , which is the very topmost resource in the Google Cloud hierarchy. Everything else attached to that account goes under this node, which includes folders, projects, and other resources. There are some special roles associated with this top-level organization node. For example, you can designate an organization policy administrator so that only people with privilege can change policies. You can also assign a project creator role, which is a great way to control who can create projects and, therefore, who can spend money. How a new organization node is created depends on whether your company is also a Google Workspace customer. If you have a Workspace domain, Google Cloud projects will automatically belong to your organization node. Otherwise, you can use Cloud Identity, Google’s identity, access, application, and endpoint management platform, to generate one. Once created, a new organization node will let anyone in the domain create projects and billing accounts, just as they could before. Folders underneath it and put projects into it. Both folders and projects are considered to be “children” of the organization node.