Cloud Composer IAM Roles for the PDE Exam

Cloud Composer is one of the orchestration services the Professional Data Engineer exam expects you to know cold, and IAM questions on Composer are a favorite trap. The scenarios sound innocent. A team needs to author DAGs. A platform engineer needs to spin up a new environment. A scheduler service account needs to actually run the workers. Each of those maps to a different role, and picking the wrong one is how exam takers lose points on otherwise easy questions.

I want to walk through the Composer IAM roles you need to recognize on the exam, what each one actually grants, and the least-privilege patterns the exam tends to reward.

The six Composer IAM roles to memorize

Every Composer-related IAM role is granted at the project level. That detail matters because the exam sometimes asks where you bind a role, and Composer roles are not bucket-scoped or environment-scoped through IAM directly. You bind them on the project and they apply across Composer resources in that project.

Here are the six roles to lock in.

• Composer Admin. Full control over creating, updating, and managing Composer environments. This is your platform-team role. Anyone who provisions environments, resizes them, upgrades Airflow versions, or tears them down needs Admin.
• Composer Developer. Lets a user deploy, modify, and manage DAGs within Composer environments. This is the pipeline-author role. Developer can ship code to the environment but should not be provisioning new environments.
• Composer Viewer. Read-only access to view Composer environments and configurations. Good for auditors, support staff, or anyone who needs visibility without write paths.
• Composer User. Lets a user run and schedule DAGs without modifying the environment itself. This is the operational role for people who trigger workflows but should not be touching infrastructure or DAG source.
• Composer Environment and Storage Object User. Grants access to the Cloud Storage buckets that Composer environments use for DAGs, logs, and other files. Composer stores DAG source and run logs in a managed GCS bucket, and this role is how you give a principal access to those bucket objects without granting broader environment privileges.
• Composer Worker. Permissions to run a Composer environment VM. This one is for service accounts, not human users. The worker nodes that actually execute your DAGs run as a service account, and that account needs the Worker role to function.

The service account requirement that trips people up

The Composer Worker role is the part of Composer IAM that most exam takers underprepare for. When you create a Composer environment, you have to specify a service account for the workers. That service account needs the Composer Worker role on the project, plus whatever permissions your DAGs actually need to do their jobs (read from BigQuery, write to a bucket, publish to Pub Sub, and so on).

A common exam scenario looks like this. A team creates a new Composer 2 environment using a custom service account, the environment fails to start, and you need to pick the most likely cause. The answer is almost always that the service account is missing roles/composer.worker. The default Compute Engine service account has broad permissions, which is why most starter environments come up fine, but the moment you switch to a least-privilege custom service account you have to grant Worker explicitly.

Granting Worker to the environment service account looks like this.

gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:composer-env-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/composer.worker"

Least-privilege patterns the exam rewards

The Professional Data Engineer exam consistently rewards least-privilege answers. If two options both technically work and one grants a narrower role, pick the narrower one. Here is how that plays out for Composer.

Pipeline authors who write DAGs get Composer Developer, not Admin. They need to push DAG code and manage their pipelines, but they should not be able to provision or delete environments. If the scenario says "data engineers who write and deploy DAGs," Developer is the answer.

Operational users who trigger and monitor runs get Composer User, not Developer. If the scenario describes someone who clears failed tasks, reruns DAGs, or kicks off backfills but does not author pipeline code, User is correct. The exam likes this distinction because it mirrors the real split between pipeline development and pipeline operations.

Auditors and support engineers get Composer Viewer. Anyone who needs to look at run history or environment config but should never be able to change anything ends up here.

External principals who only need DAG source or logs get Composer Environment and Storage Object User. If a question describes a separate service or team that needs to pull log files or sync DAGs from the Composer bucket, this is the right role. It is narrower than Developer because it does not grant any environment-level operations.

The environment service account gets Composer Worker, plus the specific data-access roles its DAGs need. Never grant Worker to a human user. If you see an answer that gives a developer the Worker role, that is a distractor.

A quick mental checklist for exam questions

When you see a Composer IAM question on the Professional Data Engineer exam, run through these in order.

• Is this a human or a service account? If service account, Worker is almost always part of the answer.
• Does the principal need to provision environments? If yes, Admin. If no, never Admin.
• Does the principal write DAG code or just run existing DAGs? Developer writes, User runs.
• Is the principal read-only? Viewer.
• Does the principal only touch the GCS bucket? Environment and Storage Object User.

That sequence covers the vast majority of Composer IAM questions you will see.

My Professional Data Engineer course covers Cloud Composer end to end, including environment architecture, DAG authoring patterns, and the IAM scenarios that show up on the exam.