The principle of least privilege is simple to state and harder to get right in practice: always grant the minimum permissions needed for someone, or a service account, to do their job. Nothing more. The Associate Cloud Engineer exam applies this principle across nearly every IAM scenario it presents, and understanding it at a practical level — not just as a definition — is what separates correct answers from plausible-sounding wrong ones.
The risk of granting too many permissions comes from two directions: accidents and attacks.
Accidents happen when users have access they did not expect to have. A developer with Editor access to a project can modify production resources they thought were in a different project. A script running as a service account with broad permissions might accidentally delete data in a bucket that was in its path. The more permissions a principal has, the larger the set of things that can go wrong through misuse, misconfiguration, or simple human error.
Attacks happen when a compromised account is used by a bad actor. If a developer's credentials are stolen and that developer has Editor access to the entire project, the attacker has Editor access too. They can read data, modify configurations, spin up resources, and cause damage limited only by the Editor role's scope. If the same developer had only the specific predefined roles needed for their work, the blast radius of that compromise shrinks dramatically.
Privilege escalation is a related concern. An attacker who gains access to an account with limited permissions may look for ways to use those permissions to acquire broader ones. Minimizing the permissions of every account reduces the available escalation paths.
In practice, least privilege means using predefined or custom roles instead of basic roles wherever possible, scoping role grants to the lowest level in the resource hierarchy that satisfies the requirement, and regularly reviewing and removing access that is no longer needed.
A data analyst who needs to query BigQuery datasets should get the BigQuery Data Viewer and BigQuery Job User predefined roles, not the Editor basic role. A Cloud Function that writes to a Pub/Sub topic should run as a service account with only the Pub/Sub Publisher role, not the default Compute Engine service account with its broad permissions.
The resource hierarchy matters for scoping. Granting a role at the project level gives access to all resources in the project. Granting the same role at the dataset level in BigQuery gives access only to that dataset. When a user needs access to one specific resource, grant the role at that resource level, not at the project level.
Custom roles are the most precise tool for implementing least privilege. They let you bundle exactly the permissions a user or service account needs, with nothing extra. However, they require ongoing maintenance. When a service adds new permissions that your users need, you have to update the custom role manually.
The exam presents this trade-off directly. A question might describe a scenario where exact permission control is critical (financial services, healthcare, highly regulated industry) and ask what role type to use. Custom roles are the right answer when the requirement cannot be met with any predefined role and precision matters more than convenience.
When predefined roles get close enough to the requirement, using them is often preferable to maintaining custom roles. The key question is whether the extra permissions in the predefined role represent an acceptable risk for the specific use case.
The Associate Cloud Engineer exam does not just test whether you know the definition of least privilege. It tests whether you apply it correctly when choosing between role options in a scenario. A question presents a requirement and four possible IAM configurations. The correct answer is always the one that grants sufficient permissions for the task and the fewest unnecessary ones.
Common patterns: a question gives someone a basic role where a predefined role would suffice (too permissive), or gives someone a role at the project level where a resource-level grant would be appropriate (too broad), or gives someone a role that does not include a required permission (too restrictive). Recognizing which failure mode each option represents is the skill being tested.
One phrase that reliably points toward least privilege in exam questions is "minimum necessary permissions." When you see that phrase in a scenario, it is telling you explicitly that the correct answer is the most restrictive option that still allows the task to complete.
Least privilege is not a one-time configuration. It degrades over time through a phenomenon called privilege creep: as team members change roles, as projects evolve, and as temporary access grants are forgotten, users accumulate permissions beyond what their current responsibilities require. A developer who was granted Compute Admin during an incident response six months ago may still hold that role today even though the incident is long resolved.
The antidote is periodic access reviews. GCP provides IAM Policy Analyzer and the IAM Recommender to help identify over-privileged accounts. The IAM Recommender analyzes actual usage patterns and suggests removing permissions that have not been used in the past 90 days. For the Associate Cloud Engineer exam, knowing that IAM Recommender exists and that its purpose is to identify unused permissions is useful context for questions about maintaining least privilege in an existing organization.
The exam sometimes describes a scenario where an organization wants to identify accounts with excessive permissions without manually auditing every IAM binding. The IAM Recommender is the answer to that scenario. Running it across a project surfaces suggestions like "this service account has BigQuery Admin but has only ever used BigQuery Data Viewer permissions — consider reducing the role."
My Associate Cloud Engineer course covers least privilege scenarios across all the IAM topics on the exam, with worked examples that show why the most permissive-looking answer is usually wrong.
