In this section of the course we’ll look at the functional structure of Google Cloud. Google Cloud’s resource hierarchy contains four levels, and starting from the bottom up they are: resources, projects, folders, and an organization node. At the first level are resources. These represent virtual machines, Cloud Storage buckets, tables in BigQuery, or anything else in Google Cloud. Resources are organized into projects, which sit on the second level. Projects can be organized into folders, or even subfolders. These sit at the third level. And then at the top level is an organization node, which encompasses all the projects, folders, and resources in your organization. It’s important to understand this resource hierarchy because it directly relates to how policies are managed and applied when you use Google Cloud. Policies can be defined at the project, folder, and organization node levels. Some Google Cloud services allow policies to be applied to individual resources, too. Policies are also inherited downward. This means that if you apply a policy to a folder, it will also apply to all of the projects within that folder. Let’s take a look at the second level of the resource hierarchy, projects, in a little more detail. 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. Each project is a separate entity under the organization node, and each resource belongs to exactly one project. Projects can have different owners and users because they’re billed and managed separately. Each Google Cloud project has three identifying attributes: a project ID, a project name, and a project number. The project ID is a globally unique identifier assigned by Google that can’t be changed after creation. They’re what we refer to as being immutable. Project IDs are used in different contexts to inform Google Cloud of the exact project to work with. Project names, however, are user-created. They don’t have to be unique and they can be changed at any time, so they are not immutable. Google Cloud also assigns each project a unique project number. It’s helpful to know that these Google-generated numbers exist, but we won’t explore them much in this course. They’re mainly used internally by Google Cloud to keep track of resources. Google Cloud’s 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. The third level of the Google Cloud resource hierarchy is folders. 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. 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.
