Organization policies are needed to enforce what resources are available in a Google Cloud trust boundary (folder, project, or other organizational level).

Cloud Identity and Access Management (IAM) enables you to manage access control by defining who (identity) has what access (role) to which resource.

Policies

Top to bottom : Resources inherit the policies of their parent resource. 

Google Cloud Platform Policies are set at the highest level, like the organisation node are cascaded down to the project.

Inheritance is transitive, all the resources in a project inherit the policy.

However policies implemented at a higher level in this hierarchy can’t affect the access that’s granted exceptionally at a lower level. 

For example,

Policy A – Enforced at the Organisation Level – Users can view cloud storage buckets.

Policy B – Enabled at the Project Level – User can modify cloud storage buckets.

Since Project Level Policy B is granting a more generous access at a lower level, it shall take effect and override Policy A.

Cloud IAM

An IAM policy has the following :

1. “who” part, 
2. a “can do what” part, and
3. an “on which resource” part. 

Who

The “who” part of an IAM policy can be defined either by a

a. Google account

b. Google group

c. Service account

d. G Suite

e. Cloud Identity domain. 

Can Do What – Role

The “can do what” part is defined by an IAM role which is a collection of permissions.

To do any meaningful operations, you need more than one permission.For example, to manage instances in a project, you need to create, delete, start, stop, and change an instance. 

So the permissions are grouped together into a role that makes them easier to manage. 

There are three kinds of roles in Cloud IAM:

1. Primitive roles: Roles historically available in the Google Cloud Console. These roles are Owner, Editor, and Viewer. Avoid using these roles if possible, because they include a wide range of permissions across all Google Cloud services.
2. Predefined roles: Roles that give finer-grained access control than the primitive roles. For example, the predefined role Pub/Sub Publisher (roles/pubsub.publisher) provides access to only publish messages to a Pub/Sub topic.
3. Custom roles: Roles that you create to tailor permissions to the needs of your organization when predefined roles don’t meet your needs.

Reference : Concepts Related to Access Management