Domain 5: Configuring Access and Security (~17.5%)

Domain 5 accounts for approximately 17.5% of the Associate Cloud Engineer exam, translating to roughly 9-10 questions. This domain is entirely hands-on: you must know how to configure IAM policies, manage service accounts, and apply the principle of least privilege using gcloud commands. The exam tests two sub-domains -- IAM management and service account management -- with heavy emphasis on practical implementation and security best practices.

5.1 Managing Identity and Access Management (IAM)

The IAM Model: Who / What / Which

IAM controls access to Google Cloud resources through three components:

Permissions follow the format service.resource.verb (e.g., compute.instances.delete, storage.objects.get). You never grant permissions directly -- you grant roles that bundle permissions together.

IAM Policy Structure

An IAM allow policy is a JSON/YAML object that binds principals to roles on a resource. Every resource has exactly one allow policy.

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:alice@example.com",
        "group:data-team@example.com"
      ]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "serviceAccount:my-app@my-project.iam.gserviceaccount.com"
      ],
      "condition": {
        "title": "Business hours only",
        "expression": "request.time.getHours('America/New_York') >= 9 && request.time.getHours('America/New_York') <= 17"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Key elements:

• bindings: Array of role-to-members mappings
• role: The IAM role being granted
• members: List of principals receiving the role. Prefix indicates type: user:, serviceAccount:, group:, domain:, or the special values allUsers (anyone on the internet) and allAuthenticatedUsers (any authenticated Google account)
• condition: Optional CEL expression restricting when the binding applies
• etag: Concurrency control -- prevents overwriting concurrent policy updates
• version: Must be 3 if any binding uses conditions; otherwise 1

Exam trap: allUsers means literally anyone, including unauthenticated users. allAuthenticatedUsers means any Google account -- including personal Gmail accounts outside your organization. Both are dangerous in production. If the exam describes a publicly accessible resource, allUsers is the member value.

Viewing and Managing IAM Policies

Essential gcloud commands for the exam:

# View project IAM policy
gcloud projects get-iam-policy PROJECT_ID

# View organization IAM policy
gcloud organizations get-iam-policy ORG_ID

# View folder IAM policy
gcloud resource-manager folders get-iam-policy FOLDER_ID

# Add a role binding
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/storage.objectViewer"

# Remove a role binding
gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/storage.objectViewer"

# Set the entire policy from a JSON file (use with caution)
gcloud projects set-iam-policy PROJECT_ID policy.json

# View IAM policy for a specific resource (e.g., a bucket)
gcloud storage buckets get-iam-policy gs://BUCKET_NAME

Exam trap: add-iam-policy-binding is additive -- it adds to the existing policy. set-iam-policy replaces the entire policy. Using set-iam-policy without the current etag can overwrite other people's changes. The exam favors add-iam-policy-binding and remove-iam-policy-binding for safe modifications.

Role Types

Three categories of roles exist, and the exam heavily tests when to use each.

Basic Roles (Avoid in Production)

Basic roles are discouraged in production because they grant permissions across every service in the project. The Editor role alone includes thousands of permissions. The documentation explicitly states: "In production environments, do not grant basic roles unless there is no alternative."

Important restrictions on basic roles:

• Legacy basic roles (roles/viewer, roles/editor, roles/owner) cannot use IAM Conditions. If you need conditional access, use predefined or custom roles.
• Owner role can only be granted to Google Accounts, service accounts within your organization, or Google Groups in your organization.

Exam trap: Editor cannot modify IAM policies or manage billing. If a question asks "a user with Editor role needs to grant access to another user," the answer is they cannot -- they need Owner or a role with resourcemanager.projects.setIamPolicy.

Predefined Roles -- Common Examples

Exam trap: roles/bigquery.user does not include permission to read data in datasets. You need roles/bigquery.dataViewer in addition to roles/bigquery.user for a user to run queries and read data. The exam frequently tests this distinction.

Custom IAM Roles

Create custom roles when predefined roles grant more permissions than needed. Custom roles can be created at the organization or project level -- never at the folder level.

# Create a custom role at the project level
gcloud iam roles create myCustomRole \
  --project=PROJECT_ID \
  --title="My Custom Role" \
  --description="Limited compute access" \
  --permissions="compute.instances.get,compute.instances.list" \
  --stage=GA

# Create a custom role at the organization level
gcloud iam roles create myCustomRole \
  --organization=ORG_ID \
  --title="My Custom Role" \
  --permissions="compute.instances.get,compute.instances.list"

# List custom roles
gcloud iam roles list --project=PROJECT_ID

# Update a custom role (add permissions)
gcloud iam roles update myCustomRole \
  --project=PROJECT_ID \
  --add-permissions="compute.instances.start"

Custom role constraints:

Exam trap: Custom roles cannot be created at the folder level. Only project or organization level. Also: if a principal can edit custom roles in a project, they can add any permission to any custom role in that project -- this is a significant security consideration.

Policy Inheritance Through the Resource Hierarchy

IAM policies are additive and inherited down the resource hierarchy:

Organization  ->  Folder  ->  Project  ->  Resource

The effective policy on a resource is the union of all policies set on it and all its ancestors. A permission granted at the organization level cannot be revoked at the project level using allow policies alone.

Exam trap: A user granted roles/editor at the organization level has Editor on every project. You cannot fix this by removing them at the project level. You must either remove the org-level binding or create a deny policy.

IAM Deny Policies

Deny policies let you explicitly block specific permissions, overriding any allow policies. IAM always checks deny policies before checking allow policies.

Policy evaluation order:

1. Organization policy constraints -- resource creation restrictions
2. Deny policies -- checked first; if a deny rule matches, access is denied regardless of allow policies
3. Allow policies -- checked only if no deny rule blocked the request

Deny policy structure:

{
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": ["principalSet://goog/public:all"],
        "exceptionPrincipals": ["principalSet://goog/group/admins@example.com"],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "denialCondition": {
          "title": "Only prod tagged resources",
          "expression": "resource.matchTag('env', 'prod')"
        }
      }
    }
  ]
}

Key deny policy facts:

Common use cases for deny policies:

• Centralizing admin privileges: Deny custom role management to everyone except a designated admin group
• Creating exceptions: Grant broad permissions at org level, then selectively deny on specific resources (e.g., block access to production projects)
• Tag-based guardrails: Deny project deletion unless the resource is tagged for decommissioning

Exam trap: Deny policies are the only way to block inherited permissions from a parent resource. If an allow policy at the org level grants overly broad access, a deny policy at the project or folder level is how you restrict it.

IAM Conditions

IAM Conditions add attribute-based access control to role bindings. A condition is a CEL (Common Expression Language) expression that must evaluate to true for the binding to take effect.

A condition contains three fields:

• title (required): Human-readable identifier
• description (optional): Explanation of the condition
• expression (required): CEL logic statement

Common condition attributes:

Important condition limitations:

• Cannot be used with legacy basic roles (roles/owner, roles/editor, roles/viewer)
• Cannot apply conditions when granting access to allUsers or allAuthenticatedUsers
• Cloud Storage requires uniform bucket-level access enabled to use conditions on buckets
• An unconditional role binding overrides a conditional one for the same role -- if a principal already has the role unconditionally, adding a conditional binding has no effect

Exam trap: When a policy uses conditions, the policy version must be set to 3. Version 1 policies silently drop conditions, which can lead to granting broader access than intended. The exam tests this.

IAM Recommender

IAM Recommender analyzes permission usage patterns and recommends removing or replacing overly broad roles. It identifies:

• Roles with permissions never used in the last 90 days
• Opportunities to replace basic roles with more granular predefined roles
• Service accounts with excess permissions

Use IAM Recommender to enforce the principle of least privilege continuously, not just at initial setup.

5.2 Managing Service Accounts

What Service Accounts Are

Service accounts are special accounts used by applications and workloads -- not humans -- to authenticate to Google Cloud APIs. Each service account has a unique email address as its identifier.

Types of Service Accounts

Exam trap: The Compute Engine and App Engine default service accounts are granted roles/editor when created. This means any VM using the default service account has Editor-level access to the entire project. The exam expects you to know this is a security risk and that you should create dedicated user-managed service accounts with minimum permissions instead.

Creating and Managing Service Accounts

# Create a service account
gcloud iam service-accounts create my-app-sa \
  --display-name="My App Service Account" \
  --description="Service account for my application"

# List service accounts in a project
gcloud iam service-accounts list --project=PROJECT_ID

# Grant a role to the service account (on a project)
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:my-app-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# Disable a service account (recommended before deletion)
gcloud iam service-accounts disable my-app-sa@PROJECT_ID.iam.gserviceaccount.com

# Delete a service account
gcloud iam service-accounts delete my-app-sa@PROJECT_ID.iam.gserviceaccount.com

Best practice: Disable unused service accounts before deleting them. This lets you verify nothing breaks before permanent deletion. Google also provides service account insights (90-day inactivity detection) and Activity Analyzer to identify unused accounts.

Exam trap: Recreating a deleted service account with the same email address does NOT restore old role bindings or resource attachments. Each service account receives a unique internal ID at creation time. Old bindings reference the old ID and will not apply to the new account.

Attaching Service Accounts to Resources

The most common and secure way for applications to authenticate is by attaching a service account to the resource running the application. The application automatically receives credentials without needing keys.

# Create a VM with a specific service account
gcloud compute instances create my-instance \
  --service-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com \
  --scopes=cloud-platform

# Deploy a Cloud Run service with a specific service account
gcloud run deploy my-service \
  --image=gcr.io/PROJECT_ID/my-image \
  --service-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com

# Deploy a Cloud Function with a specific service account
gcloud functions deploy my-function \
  --runtime=python311 \
  --service-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com

The --scopes flag on Compute Engine is a legacy access control mechanism. When set to cloud-platform, IAM roles alone determine what the service account can do. The exam may present scopes as a distractor -- IAM roles are the primary access control.

Managing IAM of a Service Account

A service account is both an identity and a resource. As an identity, it acts on resources. As a resource, other principals need IAM permissions to use or manage it.

# Grant a user permission to use (attach) a service account
gcloud iam service-accounts add-iam-policy-binding \
  my-app-sa@PROJECT_ID.iam.gserviceaccount.com \
  --member="user:alice@example.com" \
  --role="roles/iam.serviceAccountUser"

Exam trap: To attach a service account to a Compute Engine instance, the user needs both roles/iam.serviceAccountUser on the service account AND permission to create instances (roles/compute.instanceAdmin.v1 or similar) on the project. Having only one of the two is insufficient.

Service Account Impersonation

Service account impersonation allows an authenticated principal to act as a service account temporarily without using service account keys. The principal's actions are performed using the service account's identity and permissions.

Required role: roles/iam.serviceAccountTokenCreator on the target service account.

# Run a gcloud command as a service account
gcloud storage ls gs://my-bucket \
  --impersonate-service-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com

# Set impersonation as default for all gcloud commands
gcloud config set auth/impersonate_service_account \
  my-app-sa@PROJECT_ID.iam.gserviceaccount.com

Use cases:

• Temporary elevated access -- handle an incident using a privileged SA without permanent role grants
• Testing -- verify that a service account's permissions are sufficient before deployment
• Local development -- authenticate as a service account without downloading keys
• Audit trail -- both the caller's identity and the impersonated SA are recorded in audit logs

Exam trap: Service account impersonation is not available in the Google Cloud Console -- only via gcloud, client libraries, and REST APIs. Console actions always use the signed-in user's own identity.

Short-Lived Service Account Credentials

Short-lived credentials are the preferred alternative to service account keys. They expire automatically (typically within 1 hour) and do not require manual key management.

The --impersonate-service-account flag in gcloud uses generateAccessToken behind the scenes.

Service Account Keys: Why to Avoid Them

Service account keys are long-lived credentials (RSA key pairs) that can be used to authenticate as a service account. Google strongly recommends avoiding them.

When keys may be necessary: On-premises applications or third-party systems that cannot use Workload Identity Federation or any other keyless method.

# Create a key (avoid if possible)
gcloud iam service-accounts keys create key.json \
  --iam-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com

# List keys for a service account
gcloud iam service-accounts keys list \
  --iam-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com

# Delete a key
gcloud iam service-accounts keys delete KEY_ID \
  --iam-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com

Exam trap: The exam strongly favors answers that avoid service account keys. If a question offers both "create a service account key" and "use Workload Identity Federation" or "attach a service account to the resource," the keyless option is almost always correct.

Workload Identity Federation

Workload Identity Federation allows external workloads (AWS, Azure, on-premises, GitHub Actions, GitLab CI) to access Google Cloud resources without service account keys. It exchanges external credentials for short-lived GCP tokens using the OAuth 2.0 token exchange specification (RFC 8693).

How it works:

1. External workload obtains a credential from its identity provider (AWS STS, Azure AD, OIDC, SAML)
2. Workload presents credential to Google's Security Token Service (STS)
3. STS validates the credential and returns a federated token
4. Federated token is exchanged for a short-lived GCP access token (via service account impersonation or direct resource access)
5. Workload uses the access token to call GCP APIs

Key components:

Two access models:

Supported identity providers: AWS, Azure AD, any OIDC provider, any SAML 2.0 provider, GitHub Actions, GitLab CI, Kubernetes clusters, Okta, AD FS, X.509 certificates.

Workload Identity for GKE

Workload Identity for GKE maps Kubernetes service accounts to Google Cloud service accounts, enabling pods to authenticate to GCP APIs without service account keys.

# Enable Workload Identity on a GKE cluster
gcloud container clusters update my-cluster \
  --workload-pool=PROJECT_ID.svc.id.goog

# Create a Kubernetes service account
kubectl create serviceaccount my-ksa --namespace=default

# Create a GCP service account
gcloud iam service-accounts create my-gsa

# Bind the K8s SA to the GCP SA
gcloud iam service-accounts add-iam-policy-binding \
  my-gsa@PROJECT_ID.iam.gserviceaccount.com \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[default/my-ksa]" \
  --role="roles/iam.workloadIdentityUser"

# Annotate the K8s SA with the GCP SA email
kubectl annotate serviceaccount my-ksa \
  --namespace=default \
  iam.gke.io/gcp-service-account=my-gsa@PROJECT_ID.iam.gserviceaccount.com

Pods using the annotated Kubernetes service account automatically authenticate as the linked GCP service account. No keys are involved.

Exam trap: Workload Identity for GKE requires the cluster to have Workload Identity enabled (--workload-pool). The mapping is bidirectional: the GCP SA must grant roles/iam.workloadIdentityUser to the K8s SA, and the K8s SA must be annotated with the GCP SA email. Missing either side breaks the link.

5.3 Additional Security Topics (Cross-Cutting)

These topics are not listed as explicit sub-domains but regularly appear in ACE exam questions.

Cloud KMS and Encryption

Cloud KMS is Google Cloud's cryptographic key management service. It manages encryption keys for Google Cloud services and custom applications.

Key hierarchy:

Encryption options comparison:

Key facts for the exam:

• All data in Google Cloud is encrypted at rest by default using Google-managed keys. CMEK does not add encryption -- it changes who controls the keys.
• CMEK uses envelope encryption: Cloud KMS manages the Key Encryption Key (KEK) that wraps Data Encryption Keys (DEKs) managed by the service. This separation enables crypto-shredding (destroying the KEK makes all data encrypted with it permanently inaccessible).
• Automatic rotation is available for symmetric keys only. Asymmetric and external keys require manual rotation.
• Cloud KMS Autokey automates key provisioning by creating key rings and keys as resources are created -- eliminates pre-provisioning.
• Protection levels: Software (FIPS 140-2 Level 1), Cloud HSM (FIPS 140-2 Level 3), Cloud EKM (external).

Exam trap: CSEK is only supported by Cloud Storage and Compute Engine. If a question asks about CSEK with BigQuery, Cloud SQL, or other services, the answer is that CSEK is not supported -- use CMEK instead.

Secret Manager

Secret Manager stores API keys, passwords, certificates, and other sensitive data. It provides versioning, rotation, and IAM-based access control.

# Create a secret
gcloud secrets create my-secret --replication-policy="automatic"

# Add a secret version
echo -n "my-password" | gcloud secrets versions add my-secret --data-file=-

# Access a secret version
gcloud secrets versions access latest --secret=my-secret

# Access a specific version
gcloud secrets versions access 2 --secret=my-secret

Key features:

Secret Manager vs. Cloud KMS: Secret Manager stores and retrieves actual secret values. Cloud KMS manages cryptographic keys used for encryption/decryption -- key material in Cloud KMS is not directly viewable or exportable. Use Secret Manager for passwords and API keys; use Cloud KMS for encryption operations.

VPC Service Controls

VPC Service Controls create security perimeters around Google Cloud resources to prevent data exfiltration via API calls.

VPC Service Controls operate at the API level, not the network level. They complement VPC firewall rules, which control network-level traffic. Use both for defense-in-depth.

Exam trap: VPC Service Controls protect Google-managed services only (BigQuery, Cloud Storage, Pub/Sub, etc.). They do not protect third-party APIs or internet-facing services. For HTTP-level protection, use Cloud Armor instead.

Cloud Armor

Cloud Armor provides DDoS protection and WAF (Web Application Firewall) capabilities for applications behind Google Cloud load balancers.

• Security policies: Rules with match conditions (IP, geography, headers) and actions (allow, deny, rate-limit)
• Preconfigured WAF rules: Based on OWASP ModSecurity Core Rule Set for SQL injection, XSS, etc.
• Adaptive Protection: ML-based anomaly detection (Enterprise tier)

Cloud Armor protects only resources behind external HTTP(S) load balancers. For VM-level firewall rules, use VPC firewall rules instead.

Organization Policy Service

Organization policies enforce constraints across an organization, overriding individual project settings. Common constraints for the exam:

Organization policies are evaluated before IAM. Even if IAM allows an action, an organization policy constraint can block it.

Quick-Reference: Decision Tree

Common Exam Traps Summary

1. Default service accounts have Editor role -- the Compute Engine and App Engine default SAs get roles/editor. Always create dedicated SAs with least privilege.
2. Editor cannot manage IAM -- roles/editor does not include setIamPolicy. Only roles/owner or specific IAM admin roles can modify IAM policies.
3. Basic roles in production -- if the answer uses roles/owner, roles/editor, or roles/viewer in a production scenario, it is almost certainly wrong.
4. Service account keys vs. keyless -- the exam strongly prefers Workload Identity Federation, attached SAs, or impersonation over downloading key files.
5. Policy version 3 for conditions -- if a policy uses conditions but version is 1, conditions are silently dropped, granting broader access than intended.
6. allUsers vs. allAuthenticatedUsers -- allUsers is public (no auth). allAuthenticatedUsers requires a Google account but includes anyone with one (including personal Gmail).
7. Custom roles cannot exist at the folder level -- only project or organization level.
8. Deny policies override allow policies -- the only way to block inherited permissions from a parent resource.
9. Workload Identity for GKE is bidirectional -- both the IAM binding and the K8s annotation are required.
10. add-iam-policy-binding vs. set-iam-policy -- use add/remove for safe incremental changes; set replaces the entire policy.
11. CSEK only works with Cloud Storage and Compute Engine -- not with BigQuery, Cloud SQL, or other services.
12. Recreating a deleted service account does not restore old bindings -- the new account gets a new internal ID.
13. Legacy basic roles cannot use IAM Conditions -- use predefined or custom roles for conditional bindings.
14. Organization policies override IAM -- even if IAM allows an action, an org policy constraint can block resource creation.

References

• IAM Overview
• IAM Roles Overview
• IAM Deny Policies Overview
• IAM Conditions Overview
• Service Account Overview
• Workload Identity Federation
• Cloud KMS Concepts
• Secret Manager Overview
• VPC Service Controls Overview
• Cloud Armor Overview
• GCP Associate Cloud Engineer Certification