CDL
Deep Dive
How to control who can do what in Google Cloud. Principals, roles, policies, service accounts, and security best practices.
IAM controls access with a simple formula: WHO (Principal) can do WHAT (Role) on WHICH RESOURCE (Binding).
Principal (Who)
The identity that receives the permission: Google account, group, service account, Workspace domain, or "allUsers".
Role (What they can do)
A collection of permissions. E.g.: roles/storage.objectViewer includes storage.objects.get and storage.objects.list.
Resource (On what)
The resource it applies to: organization, folder, project, or individual resource (bucket, VM, dataset).
Basic roles (Legacy)
Existed before IAM. Very broad, affecting all resources in the project.
Avoid in production: they violate the principle of least privilege.
Predefined roles
Created by Google for each service. Granular and specific. Recommended practice.
Custom roles
You define exactly which permissions to include. For very specific least-privilege requirements.
Higher management overhead — use predefined roles if they cover the case.
A service account is an identity for an application or VM, not for a person. It allows GCP resources to authenticate and access other GCP services without hardcoded credentials.
Application identity
A VM with an attached SA can read Cloud Storage without needing a username/password. GCP manages the credentials.
JSON key (avoid)
An SA can have downloadable keys. Risk: if leaked, they compromise access. Prefer Workload Identity Federation.
Least privilege
Each SA should have only the minimum permissions for its function. Do not reuse SAs across different apps.
Impersonation
A user or SA can temporarily impersonate another SA for specific tasks, without permanent credentials.
IAM policies are inherited downward. A role assigned at the Organization applies to all projects and resources within it.
Inheritance rule: the most permissive access wins
If a user has roles/storage.objectViewer on the project, but roles/storage.admin on a specific bucket, they have admin access on that bucket. Permissions are additive — there is no explicit "deny" in standard IAM.
Authentication (AuthN)
Who are you? The process of verifying the identity of a user or system before granting access.
In GCP
Google Cloud Identity, Cloud IAP (Identity-Aware Proxy), Workload Identity Federation, service account keys.
Authorization (AuthZ)
What can you do? Once authenticated, which actions are you allowed to perform on which resources.
In GCP
IAM: roles, policies, and bindings. VPC Service Controls for data perimeters.
Auditing
What did you do? A record of all actions performed for traceability, anomaly detection, and regulatory compliance.
In GCP
Cloud Audit Logs: Admin Activity (who changed configuration), Data Access (who read data), System Events.
Two-Step Verification (2SV)
Adds a second layer of authentication in addition to the password: SMS code, Google Authenticator, or physical keys (Titan Security Key). Google recommends 2SV for all accounts with access to GCP. A compromised password is not enough to get in if 2SV is active. For administrator accounts, physical keys (FIDO2) are the highest security standard.
Did you get this topic?
Test what you just learned
An analytics team needs to read data from BigQuery but must not be able to create or delete tables. The principle of least privilege must be applied. Which IAM role is most appropriate?
Put what you learned to the test with original CDL exam questions.
Start CDL mock examUnlimited mock exams with the Pro plan
Log in to track your progress.