All Google Cloud platform resources belong to a Google Cloud platform project project are the basis of enabling and using GCP services like managing apis enabling billing adding and removing collaborators and their assigned permissions and enabling other Google services. Each project is separated is a separate logical compartment with an individual Cloud resource for instance cloud storage buckets virtual machine etcetera. And all of them belong to exactly one project different projects can have different owners and users. They are billed separately and they're managed separately. Each gcp project has a name and a project ID. You can choose the project ID is a permanent unchangeable identifier and it has to be unique across gcp. You will use project IDs in the several context context to tell gcp which project you want to work with on. The other hand project names are for your convenience and you can change them DCP also assign each of your projects a unique Nick number which you will see displayed in various contexts, but using it is mostly outside of the scope of this course. In general project IDs are made to be human readable and you will use them frequently to refer to projects. projects can be nested inside folders for those let you assign policies to resources at the level of granularity you choose. The resources in the folder inherent I am policies assigned to the folder a folder can contain projects other folders or 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 of which has its own set of gcp resources. Folders allow you to group these resources on a per department basis or in a structure that maps to your organization's business or operational model. Folders gives teams the ability to delegate administrative rights so that they can work independently, but with consistency with regards to enforcing proper Cloud governance. The resources in a folder inherent, I am policies from the folder. So if project 3 and project for are administered by the same team by Design, you can apply I am policies to folder be instead which implies these policies within all projects. within folder be Without the ability to apply policies at the folder level you would have to apply duplicate copies of the policy to both project 3 and project for individually which would be a tedious and error-prone process. It is important to note that each to use folders. You need an organizational node at the top of the hierarchy. You probably want to organize all the projects in your company into a single structure. Most companies want to have a centralized visibility of how resources are being used and also to apply policies centrally. This is exactly what the organization node is designed for. It is the top of the Google Cloud platform hierarchy. There are some special roles associated with the 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 spend money and delegate permissions. So how do you get an organization node in part the answer depends? Whether the your company is also a g sweet customer if you have a GC domain gcp projects will automatically belong to your organization node, which is typically the domain name of your G. Sweet. If you do not have a Gmail account, you can leverage Google Cloud identity to create the organization node. We will introduce Cloud identity later in this course. Here is an example of how you might organize your resources in this example, there are three projects each of which uses resources from several gcp services. You will notice in the diagram that we have not used any folders in the current organization structure. If the use of folders would be helpful in the future. We can always Implement them to apply policies as needed. Resources inherent the policies of their parent resource. For instance, if you set a policy at the organizational level, it is automatically inherited by all children projects. And this inheritance is transitive, which means that all the resources in these projects inherent the policy tube. There is one important rule to keep in mind the privilege granted at the higher level in this hierarchy can be taken away by a policy at the lower level. For example suppose that a policy applied on the bookshelf project gives user pad only the right to modify a cloud storage bucket, but a policy at the organizational level says that Pat has full admin ride on the cloud storage bucket. The more generous policy takes effect. Keep this in mind as you design your policies.