Google Cloud IAM for the ACE Exam: Roles, Bindings, and Service Accounts

Identity and Access Management (IAM) is one of the most heavily tested topics on the Google Associate Cloud Engineer (ACE) exam. You must understand how roles, bindings, and service accounts work to design secure and efficient access control. This post covers primitive, predefined, and custom roles, how to assign bindings at the right resource level, and how to use service accounts safely.

IAM Roles: Primitive, Predefined, and Custom

IAM roles are collections of permissions. There are three types:

• Primitive roles: roles/owner, roles/editor, roles/viewer. These are legacy roles that apply at the project level. They grant broad permissions (e.g., roles/editor includes all permissions except those for IAM and billing). Avoid using them in production; they are too permissive.
• Predefined roles: Fine-grained roles created by Google, such as roles/storage.objectViewer or roles/compute.instanceAdmin.v1. They are the recommended way to grant permissions for specific services.
• Custom roles: User-defined roles that combine specific permissions. Use them when predefined roles are too broad or too narrow. Custom roles can be applied at the organization, folder, or project level.

Exam tip: Know that primitive roles are not recommended, but you may see them in legacy scenarios. Predefined roles are preferred. Custom roles require managing permissions manually.

Resource Hierarchy and Role Bindings

IAM bindings associate a principal (user, group, or service account) with a role at a specific resource level. The resource hierarchy is:

Organization > Folder > Project > Resource

Permissions are inherited downward. For example, granting roles/compute.admin at the organization level applies to all folders, projects, and Compute Engine resources underneath.

Best practice: Grant roles at the lowest necessary level. For instance, if a user only needs to manage a single Cloud Storage bucket, bind roles/storage.objectAdmin on that bucket rather than at the project level.

Example: To grant a user read-only access to a specific bucket, use the gcloud command:

gcloud storage buckets add-iam-policy-binding gs://my-bucket \
    --member=user:alice@example.com \
    --role=roles/storage.objectViewer

Exam tip: Understand that IAM policies are additive. There is no deny in IAM (except with Organization Policies). The effective permissions are the union of all roles granted at all levels.

Service Accounts

Service accounts are identities used by applications and virtual machines (VMs) to call Google Cloud APIs. They are not users; they are resources with their own IAM policies.

Creating and Managing Service Accounts

You can create a service account via the console or gcloud:

gcloud iam service-accounts create my-sa \
    --display-name="My Service Account"

Granting Roles to Service Accounts

Service accounts need roles to access resources. For example, to allow a service account to write to Cloud Storage:

gcloud projects add-iam-policy-binding my-project \
    --member=serviceAccount:my-sa@my-project.iam.gserviceaccount.com \
    --role=roles/storage.objectCreator

Using Service Accounts with Compute Engine

When creating a VM, you can attach a service account. The VM then uses that identity to call APIs. Use the --scopes flag to limit API access, but note that scopes are deprecated in favor of IAM roles. Always grant the minimal roles via IAM and use the cloud-platform scope for simplicity.

Example: Create a VM with a custom service account:

gcloud compute instances create my-vm \
    --service-account=my-sa@my-project.iam.gserviceaccount.com \
    --scopes=cloud-platform

Key Management

Service account keys are used for authentication outside Google Cloud (e.g., on-premises apps). Avoid creating keys if possible; use workload identity federation or attach the service account to a resource. If you must create a key, download it securely and rotate it regularly.

gcloud iam service-accounts keys create key.json \
    --iam-account=my-sa@my-project.iam.gserviceaccount.com

Security tip: Never embed keys in code or store them in source control. Use Secret Manager or a secrets vault.

Exam Tips: What to Watch For

• Least privilege: Always choose the most restrictive role at the lowest resource level. For example, use roles/pubsub.subscriber on a specific subscription, not roles/pubsub.editor at the project level.
• Custom roles: You cannot create custom roles at the resource level (only at organization, folder, or project). Also, custom roles cannot include permissions from primitive roles.
• Service account impersonation: Understand that a service account can impersonate another if granted roles/iam.serviceAccountTokenCreator.
• IAM conditions: ACE may ask about conditions (e.g., granting access only from a specific IP range). Conditions are part of the IAM policy and can be added to bindings.
• Audit logging: IAM changes are logged in Cloud Audit Logs. Know how to enable and view them.
• gcloud commands: Practice gcloud projects get-iam-policy, set-iam-policy, and add-iam-policy-binding. Also, gcloud iam roles for listing and describing roles.

Conclusion

Mastering IAM is essential for the ACE exam. Focus on understanding the role types, the resource hierarchy, and service account best practices. Practice with gcloud commands and review sample scenarios. For more practice, check out our collection of ACE-style questions to test your knowledge.

---

Ready to test your IAM skills? Try our free ACE practice questions covering roles, bindings, and service accounts.