Overview
Configuring access and security covers controlling who and what can access Google Cloud resources. It has two areas. Managing IAM covers viewing and creating IAM policies and managing the role types, basic, predefined and custom, including defining custom roles. Managing service accounts covers creating service accounts, using them in IAM policies with minimum permissions, assigning them to resources, managing the IAM of a service account, managing service account impersonation, and creating and managing short-lived service account credentials.
At about 17.5%, this section tests least-privilege access design and the correct use of service accounts, which are how applications and resources authenticate to Google Cloud. The exam rewards granting the narrowest role that meets a need, choosing predefined over broad basic roles, and using service accounts securely with impersonation and short-lived credentials rather than long-lived keys.
How it's tested
GCP ACE questions in this section describe an access or service-account need and ask which role, scope or service-account approach to use. GCP ACE questions are practical and scenario-based, often involving a gcloud command, so read the requirement and choose the service or action it points to before answering.
-
Right role and scope
An access need is described, and you choose the basic, predefined or custom role at the right level.
-
Service account design
A resource-authentication need is described, and you choose and configure a service account with least privilege.
-
Secure credentials
A credential need is described, and you choose impersonation or short-lived credentials over long-lived keys.
A Compute Engine VM must access a Cloud Storage bucket and a Pub/Sub topic with only the permissions it needs. Using a user's credentials or broad roles is insecure. Creating a service account, granting it the predefined least-privilege roles for Storage and Pub/Sub, and assigning it to the VM lets the VM authenticate as that service account with exactly the needed permissions, which is the service-account approach the exam expects.
Sections 2
Official sections from the Google Cloud outline, in outline order.
5.1 Managing Identity and Access Management (IAM)IAM policies and the basic, predefined and custom role types.
- What it means
- This covers viewing and creating IAM policies, and managing the role types, basic (Owner, Editor, Viewer), predefined (granular per-service roles), and custom (roles you define with specific permissions), including defining custom IAM roles.
- What to understand
- IAM policies bind members to roles at a scope in the resource hierarchy, inheriting downward. Basic roles are broad and discouraged for production; predefined roles grant least-privilege per-service access; custom roles let you specify exact permissions when no predefined role fits. The goal is always least privilege.
- How it shows up
- An access requirement is described, and you must choose the role type and the policy.
- Common confusion
- Using broad basic roles where a predefined role fits; basic roles grant wide access, while predefined roles are least-privilege per service.
5.2 Managing service accountsCreating service accounts, least-privilege use, impersonation and short-lived credentials.
- What it means
- This covers creating service accounts, using service accounts in IAM policies with minimum permissions, assigning service accounts to resources, managing the IAM of a service account, managing service account impersonation, and creating and managing short-lived service account credentials.
- What to understand
- A service account is an identity for an application or resource, not a person. Assigning it to a resource such as a VM lets that resource authenticate with the service account's permissions. Granting least privilege limits exposure. Impersonation lets a principal act as a service account temporarily, and short-lived credentials avoid long-lived keys, which are a security risk.
- How it shows up
- A resource-authentication or credential need is described, and you must choose the service account configuration, impersonation or short-lived credentials.
- Common confusion
- Using long-lived service account keys where impersonation or short-lived credentials are safer.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
IAM policy binding
Binds a member to a role at a scope.
- Remember
- Roles inherit down the hierarchy.
- Tested as
- Access questions.
- Trap
- Granting at too broad a scope.
-
Basic roles
Owner, Editor and Viewer, broad access.
- Remember
- Discouraged for production.
- Tested as
- Role questions.
- Trap
- Using them where predefined fit.
-
Predefined roles
Granular least-privilege per-service roles.
- Remember
- Prefer them over basic roles.
- Tested as
- Role questions.
- Trap
- Defaulting to basic roles.
-
Custom roles
Roles you define with specific permissions.
- Remember
- Use when no predefined role fits.
- Tested as
- Role questions.
- Trap
- Creating custom where predefined works.
-
Least privilege
Granting only the permissions needed.
- Remember
- The core access principle.
- Tested as
- Access questions.
- Trap
- Over-granting access.
-
Service account
An identity for an application or resource.
- Remember
- Not a person; authenticates workloads.
- Tested as
- Service account questions.
- Trap
- Using user credentials for apps.
-
Assigning a service account
Attaching it to a resource such as a VM.
- Remember
- The resource authenticates as it.
- Tested as
- Service account questions.
- Trap
- Hard-coding credentials instead.
-
Service account impersonation
Acting as a service account temporarily.
- Remember
- Avoids distributing keys.
- Tested as
- Credential questions.
- Trap
- Sharing keys instead.
-
Short-lived credentials
Temporary credentials for a service account.
- Remember
- Safer than long-lived keys.
- Tested as
- Credential questions.
- Trap
- Using long-lived keys.
-
Service account keys risk
Long-lived keys are a security liability.
- Remember
- Avoid where impersonation fits.
- Tested as
- Security questions.
- Trap
- Distributing long-lived keys.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Basic vs. predefined vs. custom roles
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Basic | Owner, Editor, Viewer | Broad, discouraged | Using in production |
| Predefined | Granular per-service | Least privilege | Defaulting to basic |
| Custom | Defined permissions | When no predefined fits | Overusing custom |
User credentials vs. service account
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| User credentials | A person's identity | For human access | Using for applications |
| Service account | An application identity | For workloads | Using user credentials for apps |
Long-lived key vs. impersonation vs. short-lived credentials
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Long-lived key | Static credential | Risky, avoid | Distributing widely |
| Impersonation | Act as the SA temporarily | No key distributed | Sharing keys instead |
| Short-lived credentials | Temporary credentials | Safer, time-bound | Using long-lived keys |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Basic role for a task
- What candidates pick
- Grant the Editor basic role for a task needing only Storage access.
- Why it looks right
- Editor covers it.
- Why it's wrong
- A predefined Storage role grants least-privilege access for the task; basic roles are too broad.
Clue to watch for The task needs access to one service, not everything.
-
User creds for an app
- What candidates pick
- Have an application authenticate with a user's credentials.
- Why it looks right
- The user has access.
- Why it's wrong
- Applications should use a service account, which is an identity for workloads with least-privilege permissions.
Clue to watch for A workload, not a person, needs to authenticate.
-
Long-lived key
- What candidates pick
- Distribute a long-lived service account key for a process to authenticate.
- Why it looks right
- It works immediately.
- Why it's wrong
- Long-lived keys are a security risk; impersonation or short-lived credentials avoid distributing static keys.
Clue to watch for A process needs credentials and security matters.
-
Custom where predefined fits
- What candidates pick
- Create a custom role when a predefined role already matches the need.
- Why it looks right
- Custom is precise.
- Why it's wrong
- Predefined roles should be used when one fits; custom roles are for when none does.
Clue to watch for A predefined role already grants the needed permissions.
-
Too broad a scope
- What candidates pick
- Grant a role at the organization level for access needed in one project.
- Why it looks right
- It is simpler.
- Why it's wrong
- Granting at the project level limits the access to where it is needed, following least privilege.
Clue to watch for Access should be limited to one project.
Answer framework
For any Section 5 scenario, use these steps to find the answer the exam expects.
- Apply least privilege by granting the narrowest role at the narrowest scope in the hierarchy that meets the stated access need.
- Prefer predefined roles over broad basic roles, and use custom roles only when no predefined role fits.
- For applications and resources, use a service account rather than user credentials, granting it least-privilege roles and assigning it to the resource.
- Avoid long-lived service account keys, using impersonation or short-lived credentials where possible.
- Manage the IAM of service accounts carefully, controlling who can impersonate or manage them. Where several options could fit, choose the one the requirements make defensible, often confirmable with the matching gcloud command.
Practice question
Want more like this? The GCP ACE practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Approach this section as least-privilege access design. Start with IAM roles, learning the three role types and firmly preferring predefined least-privilege roles over broad basic roles, with custom roles only when no predefined role fits. Practice granting roles at the narrowest scope.
Then master service accounts, which are central: understand that they are identities for applications and resources, not people, and practice creating one, granting it least-privilege roles, and assigning it to a VM. Learn impersonation and short-lived credentials, and why long-lived service account keys are a security risk to avoid.
Because the exam tests secure access design, practice these in a free-tier account and reason through least privilege for each scenario. This is the final section, so finish with full practice tests spanning all five, remembering the exam is hands-on and command-line heavy throughout. Because GCP ACE is hands-on and command-line heavy, practice every task in a free-tier account and Cloud Shell, and review missed practice questions by section to find weak spots.
FAQ
How much of the GCP ACE exam is Section 5?
Configuring access and security is about 17.5% of the exam, covering IAM and service accounts.
What is the difference between basic, predefined and custom roles?
Basic roles (Owner, Editor, Viewer) grant broad access and are discouraged for production. Predefined roles grant granular least-privilege access per service. Custom roles let you define exact permissions when no predefined role fits.
What is a service account?
An identity for an application or resource, rather than a person. Assigning it to a resource such as a VM lets that resource authenticate to Google Cloud with the service account's permissions.
Why avoid long-lived service account keys?
They are static credentials that, if leaked, grant ongoing access. Impersonation and short-lived credentials provide temporary, safer access without distributing permanent keys.
What is service account impersonation?
Allowing a principal to act as a service account temporarily, obtaining its permissions without a distributed key, which is more secure than sharing long-lived credentials.
When should I create a custom role?
Only when no predefined role grants the exact permissions needed. Predefined roles should be preferred because they are maintained by Google and follow least privilege.
How does Section 5 connect to the rest of the exam?
Access and security control who and what can set up, plan, deploy and operate the resources in the other sections, so IAM and service accounts apply throughout.
Other Cloud Computing certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- AWS Certified Solutions Architect - Associate Study guide
- AWS Certified Cloud Practitioner Study guide
- AWS Certified SysOps Administrator - Associate Study guide
- AWS Certified Solutions Architect - Professional Study guide
- Microsoft 365 Fundamentals Study guide
- Azure Developer Associate Study guide
- CompTIA Cloud+ Study guide
- Microsoft Certified: Azure Fundamentals Study guide
- AWS Certified Developer - Associate Study guide
- HashiCorp Certified: Terraform Associate Study guide
- Azure Administrator Associate Study guide
- Azure Solutions Architect Expert Study guide
Test your Domain 5 knowledge
You have covered IAM roles and secure service account use. Test whether you can design least-privilege access under exam conditions.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the GCP ACE AI tutor Get any concept explained your way