Configuring access and security Study Guide — ACE

Configuring Access and Security

This domain accounts for 20% of the Associate Cloud Engineer exam — the largest single domain. It tests your ability to manage who can do what on GCP resources, how workloads authenticate without human credentials, how to enforce organizational guardrails, and how to observe and audit activity. Expect scenario-based questions that require you to choose the minimum permission, the correct log type, or the right mechanism for a specific authentication pattern.

IAM Policy Bindings, Least Privilege, and Policy Troubleshooting

Core Concepts

IAM (Identity and Access Management) controls access to GCP resources through policy bindings. A binding maps one or more members (identities) to a role at a specific resource level.

A policy is a collection of bindings attached to a resource. Policies are inherited down the resource hierarchy: Organization → Folder → Project → Resource. A permission granted at a higher level flows down; you cannot deny an inherited permission by setting a more restrictive policy lower in the hierarchy (with the exception of Deny policies, discussed below).

Resource hierarchy inheritance:

Bold caption: IAM policy inheritance flows from Organization down to individual resources — permissions only accumulate, never subtract, without Deny policies.

Role Types

Least privilege requires predefined or custom roles. Basic roles grant far too many permissions for production use.

Deny Policies

Introduced to allow explicit DENY of permissions regardless of ALLOW bindings. Deny policies are evaluated before allow policies. Use gcloud iam deny-policies commands. A deny policy can block even Organization Admins unless exceptions are specified.

Policy Troubleshooting

• Policy Analyzer: query-based tool to determine who has what access to which resources.
• Policy Troubleshooter: input a principal + permission + resource → get an allow/deny answer with the binding that caused it.
• IAM Recommender: uses ML to recommend revoking excess permissions (flags permissions not used in 90 days).

Common Traps

• Giving roles/editor instead of a specific predefined role — the exam always prefers least privilege.
• Believing a restrictive project-level policy can block an org-level roles/owner binding — it cannot without a Deny policy.
• Confusing Policy Analyzer (find access) with Policy Troubleshooter (debug a specific access question).
• Custom roles at project scope cannot be used in another project; org-scoped custom roles can.
• allUsers grants access to unauthenticated users; allAuthenticatedUsers requires a Google account but no specific identity check.

Worked Scenario

Requirement: A developer needs to upload objects to a specific Cloud Storage bucket but must not be able to delete them or access any other GCP service.

Reasoning: roles/storage.objectCreator grants storage.objects.create only. roles/storage.objectAdmin would allow deletion. Apply the binding at the bucket level, not the project level, to restrict scope. Answer: bind roles/storage.objectCreator to the developer's identity on the bucket resource.

Service Account Keys, Impersonation, and Attaching to Resources

What Is a Service Account?

A service account is an identity for a workload (VM, Cloud Function, container). It is both a principal (can be granted roles) and a resource (can have IAM policies set on it).

Service account email format: SA_NAME@PROJECT_ID.iam.gserviceaccount.com

Key Management

User-managed keys:

• Max 10 keys per service account
• Keys do not expire by default — must be rotated manually
• Stored as JSON; if leaked, immediately usable
• Organization policy iam.disableServiceAccountKeyCreation can block creation entirely

Service Account Impersonation

A principal (human or SA) with roles/iam.serviceAccountTokenCreator on a target SA can generate tokens for that SA. This avoids downloading key files.

gcloud storage ls --impersonate-service-account=TARGET_SA@PROJECT.iam.gserviceaccount.com

iam.serviceAccountUser role lets a principal use a service account (e.g., attach it to a VM). iam.serviceAccountTokenCreator lets a principal impersonate it by generating tokens.

Attaching Service Accounts to Resources

• Compute Engine VM: set at creation or update with --service-account flag; VM uses the attached SA for all API calls via the metadata server.
• Cloud Run / Cloud Functions: each revision/deployment has exactly one SA.
• GKE nodes: node pool SA (default: Compute Engine default SA — should be replaced with a least-privilege SA).

Common Traps

• Default Compute Engine SA is PROJECT_NUMBER-compute@developer.gserviceaccount.com with roles/editor — always replace with a custom SA for production.
• Granting roles/iam.serviceAccountUser at the project level gives the principal the ability to use all SAs in the project — grant at the SA resource level instead.
• Service account key rotation is not automatic — you must create a new key and delete the old one.
• A deleted service account cannot be undeleted after 30 days; its email is permanently unusable.

Worked Scenario

Requirement: A Cloud Run service needs to read from BigQuery. A developer proposes downloading a JSON key and storing it in the container image.

Reasoning: This is a security anti-pattern. Cloud Run supports attaching a service account directly. The runtime obtains short-lived tokens automatically via the metadata server. Grant roles/bigquery.dataViewer to the attached SA. No key file needed.