Lesson 2: Cloud Identity and the Super Administrator Account

Why identity comes before everything else

In Google Cloud, IAM decides what an identity can do. But IAM doesn't create users. User accounts and groups live in Cloud Identity (or in Google Workspace, which includes Cloud Identity along with Gmail, Calendar and the rest). Section 1 of the exam guide begins with item 1.1, Managing Cloud Identity, and that's where this level starts: what Cloud Identity gives Google Cloud, how it connects to the organization resource, and how to protect the most powerful account in it, the super administrator.

A quick reminder from Level 1: the exam guide belongs to Google and is free on the certification page. This course is independent of Google, isn't endorsed by it, and can't promise you a pass. Check the official exam page for the current length, price and languages.

The mental model: directory → organization → resources

Think of Cloud Identity as the HR department and the organization resource as the company building. HR issues the badges (accounts and groups). The building's security desk (IAM) decides which floors each badge opens.

• Cloud Identity manages users, groups, 2-step verification (2SV), sign-in policy and devices for a verified domain such as example.com. It comes in two editions, Free and Premium. You don't need Premium to use Google Cloud.
• The organization resource sits at the top of the Google Cloud resource hierarchy. Google creates it automatically once a Google Workspace or Cloud Identity account is linked to a domain. A new user triggers it by signing in to the Google Cloud console and accepting the terms. An existing user triggers it by creating a new project or billing account.
• The relationship is one-to-one. Each Google Workspace or Cloud Identity account is associated with exactly one organization resource. Every project and billing account created under that domain becomes a child of it. If you need separation, use folders. A second organization means a second Cloud Identity or Workspace account.

# Find your organization resource. Its display name is your verified domain.
gcloud organizations list
# DISPLAY_NAME   ID             DIRECTORY_CUSTOMER_ID
# example.com    123456789012   C0abc12de
#                ^ IAM uses this ID   ^ the Cloud Identity customer that owns it

Gotcha: When the organization is created, every user in the domain is granted Project Creator (roles/resourcemanager.projectCreator) and Billing Account Creator (roles/billing.creator). This keeps project creation working for existing users. A security engineer usually narrows these grants soon afterwards.

Two separate permission systems

This distinction catches a lot of exam candidates:

You need a super administrator account from Google Workspace or Cloud Identity to configure and manage an organization resource. The super admin who creates the organization is automatically given the IAM role Organization Administrator. Google recommends handing that role to other people so duties stay separate. The super admin controls identities. Organization Administrators control IAM on the hierarchy.

Walkthrough: hand off Organization Administrator to a group

Google's documented pattern is to create a private administrator group, add the Organization Administrator users to it, leave the super admin account out of it, and grant the IAM role to the group.

# 1. In the Admin console (as a super admin), create a private group such as
#    gcp-organization-admins@example.com and add alice@example.com and bob@example.com.
#    Do NOT add the super admin accounts.

# 2. Grant the IAM role to the group, not to individual users
gcloud organizations add-iam-policy-binding 123456789012 \
  --member="group:gcp-organization-admins@example.com" \
  --role="roles/resourcemanager.organizationAdmin"

# 3. Check the binding
gcloud organizations get-iam-policy 123456789012 \
  --flatten="bindings[].members" \
  --filter="bindings.role:organizationAdmin" \
  --format="table(bindings.members)"
# MEMBERS
# group:gcp-organization-admins@example.com

When someone joins or leaves the admin team, you change the group's membership and the IAM policy stays the same. Least privilege still applies: give people the narrowest role that does the job, and avoid broad roles where a narrower one exists.

Protecting the super administrator account

A super admin can reset any user's password, change SSO and 2SV settings, and take over any identity that holds an IAM role. Whoever compromises it effectively owns your cloud. Google's guidance:

1. Use dedicated accounts. Each super admin gets a separate account with its own login, for example alice@example.com for daily work and alice-admin@example.com for super admin tasks. Sign in to the admin account only when a super admin task needs it.
2. Have more than one, each held by a different person. If one account is lost or compromised, another super admin can carry on with critical work while it's recovered. Never share a super admin account: the audit log can't tell you who did what.
3. Use strong 2SV. Enforce multi-factor authentication on super admin and other privileged accounts. Use security keys, which resist phishing and are the most secure form of 2SV.
4. Shorten sign-in sessions for super admin accounts where the setting is available.
5. Know the recovery process, and keep self-recovery disabled. Organization Administrators should understand how super admin credentials are recovered. Self-service recovery for super admins should stay off.
6. Alert on IAM changes. Set up a Google Cloud Observability alert on SetIamPolicy API calls so you hear about every change to an allow policy.

Trade-off from production: Two people each holding a separate super admin account with registered security keys (ideally a spare key stored offline) beats one "break-glass" account whose password sits in a shared vault. Shared credentials break accountability and are a common way in for attackers.

What the exam asks about this

Expect scenarios such as "a new company is setting up Google Cloud; what should the super admin do first?" or "an auditor found the super admin used for daily IAM changes; what do you recommend?" The best answer usually: gives Organization Administrator to a group that doesn't contain the super admin, keeps at least two dedicated super admin accounts protected by security keys, and keeps super admins out of daily use. Watch for distractors that mix up the Admin console and IAM. Granting someone a Google Cloud IAM role, even Organization Administrator, doesn't make them a super admin. Also watch for answers that create a second organization when a folder would do.

Key takeaways

• Cloud Identity (or Workspace) holds users and groups. IAM grants them roles on the resource hierarchy.
• One Cloud Identity/Workspace account maps to exactly one organization resource. Use folders to separate workloads inside it.
• At creation, all domain users get Project Creator and Billing Account Creator. Review those grants.
• Grant Organization Administrator to a private group that excludes the super admin.
• Super admins: dedicated accounts, more than one, each held by a different person, security keys, short sessions, self-recovery off, no daily use.
• Alert on SetIamPolicy calls.