Dataplex shows up on the Professional Data Engineer exam in a way that catches a lot of candidates off guard. You can know what a data mesh is, you can know what a lake and a zone are, and you can still miss a question because the prompt is really asking about IAM. Dataplex roles are not just another list of GCP permissions to memorize. They are the mechanism Google uses to grant access across BigQuery, Cloud Storage, and other services in one shot, without you touching the underlying resources. That behavior, called unified access management, is the part the exam likes to test.
In this post I want to walk through the Dataplex roles you should have committed to memory before sitting the Professional Data Engineer exam, and then explain how those roles propagate down into the assets they govern.
In most GCP services, the IAM model is self-contained. You grant roles/bigquery.dataViewer on a BigQuery dataset and that grant applies to that dataset only. If the same person also needs to read a Cloud Storage bucket that backs an external table, you grant roles/storage.objectViewer on the bucket separately. Two grants, two services, two audit trails.
Dataplex flips this around. When you organize BigQuery datasets and Cloud Storage buckets into a Dataplex lake and zone as assets, you can grant Dataplex data roles at the lake, zone, or asset level, and those grants automatically apply to the underlying resources. One IAM binding, multiple services covered.
That is the part the exam tests. If a question describes a data mesh with assets spanning BigQuery and GCS and asks how to give a domain team write access without managing IAM on each underlying resource, the answer is almost always to grant a Dataplex data role at the appropriate scope.
There are six Dataplex roles I would have ready to recognize on the exam. The first three are governance and visibility roles. The last three are the data access roles that drive unified access management.
roles/dataplex.admin) gives full control over all Dataplex resources. This is the role for the platform team building out the mesh, creating lakes and zones, registering assets, and configuring policies. It is not a role you hand to analysts.roles/dataplex.viewer) lets the holder see the mesh structure, the configured zones, and the assets, but does not grant any access to the data inside those assets. Useful for read-only architectural visibility.roles/dataplex.metadataReader) grants read access to metadata without the underlying data itself. This is the role for lineage tools, discovery scenarios, or anyone who needs to understand schema and tags without seeing the rows.roles/dataplex.dataOwner) is the manage tier. The holder can manage data assets in the mesh, including the lifecycle and policies on the data those assets point to. A Data Owner on a BigQuery dataset asset can manage the underlying tables.roles/dataplex.dataWriter) grants write access to data assets in the mesh but no administrative privileges. The holder can add or modify data, but cannot change higher-level settings or asset configuration.roles/dataplex.dataReader) is read-only access to data assets in the mesh. The holder can query the underlying BigQuery tables or read the underlying GCS objects, but cannot write or modify.Here is the mental model I use for the exam. Think of a Dataplex lake as a logical wrapper around resources that already live in BigQuery and Cloud Storage. When you register a BigQuery dataset as an asset in a zone, you are not moving the data and you are not duplicating it. You are telling Dataplex that this dataset is part of the mesh.
Once that asset is registered, granting dataplex.dataReader on the asset, the zone, or the lake gives the principal read access to the BigQuery dataset itself. You do not need to also grant bigquery.dataViewer. Dataplex handles the propagation. The same holds for Cloud Storage assets, where the Dataplex data role grants the corresponding read, write, or manage access on the bucket and its objects.
This is what the documentation and the exam call unified access management. One Dataplex role, applied at the appropriate scope in the mesh, translates into the equivalent permissions on the underlying services. It is the operational payoff of organizing your data into a mesh in the first place.
A couple of nuances are worth filing away.
First, unified access management does not replace fine-grained controls inside a service. If a BigQuery table has column-level security or a policy tag restricting access to PII columns, those controls still apply. Granting dataplex.dataReader gets the principal into the dataset, but a policy tag on a sensitive column will still block them from that column. The exam may describe a sensitive-data scenario and the right answer is usually that domain teams still need to layer service-level controls on top of Dataplex roles.
Second, the data roles are scoped to the asset. They do not give Dataplex Administrator-style privileges, and they do not let the holder change the mesh structure. If a question asks who should be able to create new zones and register assets, that is the Administrator role, not Data Owner.
Third, Metadata Reader is the answer when a scenario calls for visibility without data access. Compliance teams or catalog tooling that needs to inspect schemas and tags without seeing rows is the classic use case.
If you can recognize those six roles, explain what unified access management propagates, and remember that fine-grained service-level controls still apply on top, you are in good shape for the Dataplex questions on the Professional Data Engineer exam.
My Professional Data Engineer course covers Dataplex IAM, the data mesh model, and the broader governance services like Data Catalog and Dataproc Metastore in the depth the exam expects.
