Instiq
Chapter 1 · Configuring access·v1.0.0·Updated 6/15/2026·~16 min

What's changed: Created Professional Cloud Security Engineer Chapter 1 (Domain 1 "Configuring access": Cloud Identity/GCDS/SSO(SAML/OAuth)/super admin/user lifecycle/Workforce Identity Federation; service accounts/default SA/key auditing/Workload Identity Federation/short-lived credentials/impersonation/2SV; IAM predefined-custom/separation of duties/IAM conditions/IAM deny policies/groups/Access Context Manager/Policy Intelligence/Privileged Access Manager; resource hierarchy/folders/projects/organization policies (pre-built-custom)/inheritance).

1.1Cloud Identity, service accounts, and authentication

Key points

Understand Cloud Identity management (Google Cloud Directory Sync, SSO with third-party IdPs, super admin, user-lifecycle automation, Workforce Identity Federation), securing service accounts (default SAs, key auditing/mitigation, short-lived credentials, Workload Identity Federation, impersonation), and authentication (password/session policy, SAML/OAuth, 2-step verification).

A Professional Cloud Security Engineer designs, implements, and operates secure Google Cloud. The first pillar is identity: who represents workloads and people, and how they authenticate. Avoid key leakage and master federation and short-lived credentials.

1.1.1Cloud Identity and human authentication

Manage human identities with Cloud Identity. Sync on-prem AD users/groups via Google Cloud Directory Sync (GCDS) and delegate authentication with SSO (SAML/OAuth) to a third-party IdP. Tightly protect the most powerful super administrator account (fewest people, 2SV, break-glass) and automate user-lifecycle create/disable. To use external IdP human identities directly in Google Cloud without creating accounts, use Workforce Identity Federation. Raise authentication strength with 2-step verification (2SV) and password/session management policy. Map "federate external-IdP people = Workforce Identity Federation" and "most powerful = tightly protect super admin."

1.1.2Service accounts and workload authentication

Represent workload identity with service accounts. Default service accounts tend to be over-privileged—disable/minimize them, and create/disable/authorize dedicated SAs only where needed. The biggest risk is leaked service account keys, so avoid creating keys; from external/on-prem/CI/CD use Workload Identity Federation for keyless federation, and obtain temporary privileges via short-lived credentials and service account impersonation. If keys are unavoidable, limit damage with auditing, rotation, and disabling. Map "no keys = Workload Identity Federation/impersonation" and "temporary privilege = short-lived credentials."

Exam point

Common: requirement → means. E.g., "sync on-prem AD to Google" = GCDS; "use external-IdP people without creating accounts" = Workforce Identity Federation; "authenticate external/CI/CD workloads keyless" = Workload Identity Federation; "run temporarily with another SA's privileges" = impersonation/short-lived credentials; "tightly protect the most powerful role" = minimize super admins + 2SV.

Warning

Watch the mix-ups: (1) Do not confuse Workforce Identity Federation (people/external IdP) with Workload Identity Federation (workloads/external systems). (2) Downloading service-account keys is a last resort—a leak source. (3) Default SAs tend to be over-privileged—disable/minimize them.

Diagram of Cloud Identity/GCDS/SSO with super-admin protection, Workforce Identity Federation (people) vs Workload Identity Federation (workloads), and service accounts/impersonation/short-lived credentials/2SV.
Avoid keys

1.1.3Section summary

  • People = Cloud Identity/GCDS/SSO; external-IdP people = Workforce Identity Federation; tightly protect super admin
  • Workloads = service accounts; avoid keys via Workload Identity Federation/impersonation/short-lived credentials
  • Auth strength = 2SV + password/session policy; SSO via SAML/OAuth

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. To let human users managed in an external IdP access Google Cloud resources without creating Google accounts, which is best?

Q2. To authenticate on-prem/external workloads to Google Cloud without service-account keys, which is best?

Q3. A CI/CD job must temporarily run with a specific service account's privileges. Without creating keys, which is best?

Q4. To sync on-prem Active Directory users and groups into Cloud Identity, which tool?

Q5. Which is the best practice to reduce risk of the most-powerful super administrator account?

Check your understandingPractice questions for Chapter 1: Configuring access