All Google Cloud platform resources belong to a project.
Projects are the basis for enabling and using GCP services like managing APIs,
enabling billing and adding and removing
collaborators and enabling other Google services.
Each project is a separate compartment and each resource belongs to exactly one.
Projects can have different owners and users -
they're built separately and they're managed separately.
Each GCP project has a name and a project ID that you assign.
The project ID is a permanent, unchangeable identifier and it has to be unique across GCP.
You use project IDs in several contexts to tell GCP which project you want to work with.
On the other hand, project names are for your convenience and you can assign them.
GCP also assigns each of your projects a unique
project number and you'll see a display to you in various contexts.
But using it is mostly outside the scope of this course.
In general, project IDs are made to be
human readable strings and you'll use them frequently to refer to projects.
You can organize projects into folders, although you don't have to.
They're a tool at your disposal to make your life easier.
For example, you can use folders to represent different departments,
teams, applications or environments in your organization.
Folders let teams have the ability to delegate administrative rights,
so they can work independently.
The resources in a folder inherit IAM policies from the folder.
So, if project three and four are administered by the same team by design,
you can put IAM policies into folder B instead.
Doing it the other way,
putting duplicate copies of those policies on
project three and project four would be tedious and error prone.
One word of caution: to use folders,
you need an organization node at the top of the hierarchy.
So what's that? Let's talk about it now.
You probably want to organize all the projects in your company into a single structure.
Most companies want the ability to have centralized visibility
on how resources are being used and to apply policy centrally.
That's what the organization node is for.
It's the top of the hierarchy.
There are some special roles associated with it.
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.
So how do you get an organization node?
In part the answer depends on whether your company is also a G Suite customer.
If you have a G Suite domain,
GCP projects will automatically belong to your organization node.
Otherwise, you can use Google Cloud Identity to create one.
Here's a tip. When you get a new organization node,
it lets anyone in the domain create
projects and billing accounts just as they could before.
That's to avoid surprises and disruption.
But it'd be a great first step with a new organization node to
decide who on your team should really be able to do those things.
Once you have an organization node,
you can create folders underneath it and put it in projects.
Here's an example of how you might organize your resources.
There are three projects each of which uses resources from several GCP services.
In this example, we haven't used
any folders, although we could always move projects into folders.
Resources inherit the policies of their parent resource.
For instance, if you set a policy at the organization level,
it is automatically inherited by all its children projects.
And this inheritance is transitive,
which means that all the resources in those projects inherit the policy too.
