The Principle of Least Privilege shows up on the Google Cloud Professional Data Engineer exam often enough that I treat it as a guaranteed topic. The questions are rarely phrased as pure security questions. They tend to hide inside scenarios about service accounts, BigQuery datasets, Dataflow pipelines, or Cloud Storage buckets, and the right answer almost always involves cutting back permissions rather than handing them out. If you understand why over-privileged access is dangerous and how privilege escalation actually happens, the exam questions resolve quickly.
Imagine a developer who has write access to DEV, SIT, and PROD environments. The normal flow is fine. Push to DEV, run tests, promote to SIT, run more tests, then promote to PROD. The risk shows up on the bad day. One typo, one wrong environment flag, and that same developer pushes untested code straight to PROD because nothing stopped them. The tests never ran because the gate that should have caught the problem was bypassed by the fact that the developer already had the keys to every environment.
That is the first reason least privilege matters. Over-privileged humans cause accidents. They are not malicious, they are just busy, and the system allowed the action to succeed. If the developer's account only had write access to DEV, the same typo would have produced a permission error instead of a broken production system.
The second risk is about attackers. Consider a service account that has read and write access to BigQuery, Cloud SQL, Dataflow, Cloud Run, Cloud Storage, and App Engine. In practice it only ever reads from BigQuery and Cloud SQL and writes intermediate results through Dataflow. The Cloud Run, Cloud Storage, and App Engine permissions are leftover from an old project nobody cleaned up.
If an attacker compromises that service account, they do not get access to just the three services it actually uses. They get all six. The blast radius of the compromise is defined by the permissions on the account, not by what the account does day to day. Trimming the unused permissions does not slow the legitimate work down at all, and it strictly shrinks what the attacker can touch.
Privilege escalation is the scenario the Google Cloud Professional Data Engineer exam likes to test most directly. Picture an account that only has access to two services. On the surface that sounds narrow and safe. The problem is that one of those services is Cloud IAM.
Once an attacker is inside an account that can modify IAM, the rest of the project is reachable. They grant themselves whatever roles they want, and from there they can read from any dataset, write to any bucket, and impersonate any service account. The narrow access turned into total access because one of the two permissions controlled access itself. This is why I tell people to treat roles/iam.securityAdmin, roles/resourcemanager.projectIamAdmin, and anything with setIamPolicy on a resource as restricted by default. Those are the permissions that turn a small compromise into a project-wide one.
The principle itself is simple. Give a user or a service account the minimum permissions it needs to do its job, and nothing else. The implementation is where you have to make choices. There are two practical paths and the exam expects you to recognize when each one fits.
The rule I use is to start with predefined roles, then move to custom roles only when a predefined role grants something that genuinely matters to keep out. A service account that needs to read from BigQuery should get roles/bigquery.dataViewer, not roles/bigquery.admin, and if even dataViewer feels too broad because it sees every dataset in the project, you scope the binding to a specific dataset instead of granting it at the project level.
Following least privilege gives you four practical wins that the exam likes to surface.
Professional Data Engineer questions on this topic tend to give you a scenario with too much access and ask you to fix it. The answer is almost never to leave the permissions alone. Watch for service accounts with broad project-level roles when a resource-level binding would do, watch for human accounts with both IAM admin and data access, and watch for Dataflow or Composer service accounts that have write access to systems they only read from. When you spot any of those, the correct answer is to narrow the role or scope it down to the specific resource.
My Professional Data Engineer course covers IAM scoping, custom versus predefined roles, and the service account patterns that the exam tests around least privilege.
