Workspace Admin · Domain 4 of 6

Workspace Admin Domain 4: Managing security policies and access controls

This section covers protecting sign-in and administration: password and 2-step verification policy, context-aware access, admin roles and session control, the security and investigation tools, and controls for Marketplace, OAuth and SAML apps.

Exam weight
~20%
Official objectives
3
Estimated questions estimate
11
Suggested study time estimate
10–14 hrs

About 12 min read Reviewed October 2026

Overview

Section 4 carries about 20% of the exam across only three sub-objectives, so each one is dense. The first, securing user access, covers password policy, 2-step verification (2SV) enforcement and methods, recovery options, context-aware access, prebuilt and custom admin roles, delegation and session control. The second covers reporting, auditing and investigating risks with the audit and investigation tools, the security center, the security health page, and activity rules and alerts.

The third deals with applications beyond the core services: allowlisting Google Workspace Marketplace apps, deploying or restricting Marketplace and Play apps, setting up SSO to third-party apps with Google as the identity provider, turning additional Google services such as YouTube on or off, and removing connected apps that users have authorised.

How it's tested

Section 4 scenarios mix prevention and response. Some ask how to tighten sign-in or admin access without locking users out, others describe a suspicious event and ask which tool reveals what happened or which action contains it. Look for the least privilege, the strongest practical method, and the narrowest scope that meets the need.

  • Harden sign-in

    Accounts are at risk, and you choose 2SV enforcement, allowed methods, password rules, recovery options or context-aware access.

  • Least-privilege administration

    A team needs partial admin rights, and you choose a prebuilt or custom role and scope it to an OU.

  • Investigate and contain

    A phishing or data event is reported, and you choose the investigation tool, alert or app control that finds and stops it.

Reasoning it through

The help desk needs to reset passwords for staff in the Paris office but must not change any security settings. Making them super admins would work but grants far too much. A prebuilt Help Desk Admin role, or a custom role with only the password reset privilege, assigned to the Paris OU, gives exactly the needed rights. Scoping the role to the OU keeps them away from executives' accounts elsewhere.

Objectives 3

Official objectives from the Google Cloud outline, in outline order.

4.1 Securing user accessPasswords, 2SV, recovery, context-aware access, admin roles, delegation and session control.
What it means
This objective covers enforcing strong passwords and 2-step verification, setting password policy and recovery options, choosing 2SV methods such as authenticator apps, text messages and passkeys, configuring context-aware access, applying policies to users and groups, using prebuilt and custom admin roles, delegating admin tasks, and using session control to sign users out.
What to understand
2SV enforcement can be scoped by OU or group and given an enrollment period so users can register a method before the deadline. Passkeys and security keys resist phishing best, while SMS codes are the weakest option. Context-aware access uses attributes such as device security status, IP range and location to allow or deny access to apps. Admin roles bundle privileges; custom roles can be scoped to an OU. Session length controls how often users re-authenticate, and signing out a user ends sessions on a lost device.
How it shows up
An access or admin delegation request is described, and you choose the 2SV, password, context-aware or role setting.
Common confusion
Assigning super admin when a scoped custom role meets the need.
4.2 Reporting, auditing, and investigating security risks and eventsAudit and investigation tools, security center, security health and alerts.
What it means
This objective covers using the audit and investigation tools to review events, using the security center to detect risks, reviewing the security health page for configuration gaps, and creating activity rules and alerts that notify admins or take action when certain events occur.
What to understand
Audit logs record events per service, such as Drive sharing, admin changes or sign-ins. The security investigation tool, available in higher editions, lets admins query those events and act directly, for example by deleting a phishing message from many inboxes. The security dashboard visualises risks, and the security health page compares settings with Google's recommendations. The alert center collects alerts such as suspicious sign-ins, and activity rules can trigger alerts or actions automatically.
How it shows up
A suspicious event is reported, and you choose the tool that finds it or the rule that would detect it next time.
Common confusion
Expecting the security health page to show incidents; it shows configuration recommendations, not events.
4.3 Enabling additional Google and third-party applicationsMarketplace allowlist, app deployment, SAML apps, additional services and connected apps.
What it means
This objective covers allowlisting Marketplace apps, deploying or restricting Marketplace and Google Play apps, setting up SSO to third-party apps, granting access to additional Google services such as YouTube or AdSense for certain users, and removing connected apps and sites that users have authorised.
What to understand
Marketplace settings can let users install any app, only allowlisted apps, or none, and admins can install apps for users by OU. API controls classify third-party OAuth apps as trusted, limited or blocked, which decides whether they can reach Workspace data. Custom SAML apps let Google act as the identity provider for services such as a ticketing system. Additional Google services, such as YouTube and Blogger, can be turned on or off by OU, and admins can revoke tokens for apps a user has connected.
How it shows up
A third-party app or extra Google service needs to be allowed, restricted or removed, and you choose the control.
Common confusion
Blocking an app in Marketplace and assuming its existing OAuth tokens stop working; revoke access through API controls.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • 2SV enrollment period

    A window that lets users register a 2SV method before enforcement starts.

    Remember
    Prevents lockouts on enforcement day.
    Tested as
    Rollout questions.
    Trap
    Enforcing immediately for all users.

  • Passkeys and security keys

    Phishing-resistant 2SV methods.

    Remember
    Strongest available options; can be required for high-risk users.
    Tested as
    Method selection questions.
    Trap
    Choosing SMS for administrators.

  • Password policy

    Minimum length, strength enforcement, reuse and expiry settings.

    Remember
    Can force a change at next sign-in.
    Tested as
    Account hardening.
    Trap
    Relying on expiry instead of 2SV.

  • Context-aware access

    Allows or blocks app access based on device, IP or location attributes.

    Remember
    Assigned to apps per OU or group.
    Tested as
    Conditional access scenarios.
    Trap
    Using it as a substitute for 2SV.

  • Prebuilt admin roles

    Ready-made roles such as Help Desk Admin, User Management Admin and Groups Admin.

    Remember
    Many can be scoped to an OU.
    Tested as
    Delegation questions.
    Trap
    Giving super admin for routine tasks.

  • Custom admin roles

    Roles built from selected privileges.

    Remember
    Use when no prebuilt role fits exactly.
    Tested as
    Least privilege questions.
    Trap
    Adding more privileges than the task needs.

  • Super admin recovery

    Self-service recovery options for super admins.

    Remember
    Keep more than one super admin and secure their recovery details.
    Tested as
    Account recovery questions.
    Trap
    Using a super admin account for daily work.

  • Session control

    Sets web session length and lets admins sign a user out.

    Remember
    Signing out resets sign-in cookies on all devices.
    Tested as
    Lost device scenarios.
    Trap
    Only resetting the password and leaving sessions active.

  • Security investigation tool

    Queries log events and takes bulk actions such as deleting messages.

    Remember
    Edition-dependent.
    Tested as
    Phishing response.
    Trap
    Asking users to delete the phishing mail themselves.

  • Security health page

    Shows how settings compare with recommendations.

    Remember
    Configuration view, not an event log.
    Tested as
    Posture review questions.
    Trap
    Looking there for a specific incident.

  • Alert center

    Central list of system and rule-based security alerts.

    Remember
    Alerts can be assigned and tracked.
    Tested as
    Detection questions.
    Trap
    Expecting email alerts without configuring them.

  • API controls

    Mark third-party OAuth apps as trusted, limited or blocked.

    Remember
    Controls access to Workspace data.
    Tested as
    App risk questions.
    Trap
    Relying on the Marketplace allowlist alone.

  • Custom SAML app

    Lets Google sign users in to a third-party service.

    Remember
    Google acts as the identity provider.
    Tested as
    SSO questions.
    Trap
    Confusing it with using a third-party IdP for Google sign-in.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

2SV methods

ConceptMeaningKey differenceCommon trap
Passkey or security key Cryptographic credential bound to the site Phishing resistant Not requiring it for admins
Google prompt or authenticator app Prompt on a phone or time-based code Stronger than SMS, weaker than keys Assuming prompts cannot be phished
Text message code Code sent by SMS Weakest method Allowing it for high-risk users

Security health vs. security investigation tool vs. alert center

ConceptMeaningKey differenceCommon trap
Security health Settings compared with recommendations Posture, not events Looking for incidents there
Investigation tool Query events and act on them Response and bulk actions Assuming every edition has it
Alert center List of alerts from Google and activity rules Notification and tracking Ignoring alert assignment and status

Google as IdP vs. third-party IdP

ConceptMeaningKey differenceCommon trap
Custom SAML app in Workspace Google signs users in to another service Google is the identity provider Configuring it when the IdP is external
Third-party SSO profile Another IdP signs users in to Google Google is the service provider Expecting it to provision accounts

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Immediate 2SV enforcement

    What candidates pick
    Turn on 2SV enforcement for the whole company today.
    Why it looks right
    It closes the risk fastest.
    Why it's wrong
    Users without a registered method are locked out; set an enrollment period and a start date, and pilot with an OU.

    Clue to watch for Many users have not enrolled yet.

  2. Super admin for convenience

    What candidates pick
    Make the regional IT lead a super admin.
    Why it looks right
    It avoids permission errors.
    Why it's wrong
    Super admin cannot be scoped and grants every privilege; a prebuilt or custom role scoped to the OU is safer.

    Clue to watch for The tasks are limited and regional.

  3. Password reset is enough

    What candidates pick
    Reset the password of a user whose laptop was stolen.
    Why it looks right
    It invalidates the old password.
    Why it's wrong
    Existing sessions may stay signed in; signing the user out and reviewing 2SV is also needed.

    Clue to watch for A device with active sessions is lost.

  4. Security health for incidents

    What candidates pick
    Check the security health page to see who opened a phishing email.
    Why it looks right
    It is under the security menu.
    Why it's wrong
    Security health shows configuration posture; the investigation tool or Gmail logs show message events.

    Clue to watch for A specific event must be traced.

  5. Marketplace block covers OAuth

    What candidates pick
    Block an app in the Marketplace allowlist to stop it reading users' Drive files.
    Why it looks right
    Blocking sounds complete.
    Why it's wrong
    Apps can be authorised through OAuth outside Marketplace; API controls must mark the app blocked.

    Clue to watch for The app already has access to user data.

  6. SMS for executives

    What candidates pick
    Require text message codes for executives because they travel.
    Why it looks right
    SMS works anywhere.
    Why it's wrong
    SMS is the weakest method; security keys or passkeys resist phishing.

    Clue to watch for The users are high-value targets.

Answer framework

Use these steps for any Section 4 scenario about access, admin rights, investigation or apps.

  1. Decide whether the scenario is prevention (sign-in, roles, apps) or response (investigate, contain, alert).
  2. For sign-in, enforce 2SV with an enrollment period, prefer passkeys or security keys for high-risk users, and add context-aware access when device or location matters.
  3. For admin rights, choose the narrowest prebuilt or custom role and scope it to the right OU, keeping super admin for a few protected accounts.
  4. For incidents, use audit logs and the investigation tool to find affected users, then sign them out, reset credentials or delete malicious messages.
  5. For apps, set Marketplace allowlisting, classify OAuth apps in API controls, use custom SAML apps for SSO, and revoke connected apps that are no longer trusted.

Practice question

A phishing email reached 400 employees an hour ago. Several users clicked the link. The organisation uses Enterprise Plus. The security team wants the message removed from every inbox and the users who clicked identified as quickly as possible. What should the administrator use?

Want more like this? The Workspace Admin practice test has questions for every domain.

Checklist

0 of 14

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Treat this section as three mini-topics. For securing user access, practise in a test tenant: enforce 2SV for a pilot OU with an enrollment period, require security keys for an admin group, and set a password policy. Create a custom admin role with password reset only, assign it to one OU, and test it with a second account. Then sign that account out from the Admin console and confirm the effect.

For reporting and investigation, browse every report under the security menu and write one line on what each is for, since many wrong options are real tools used for the wrong job. Create an activity rule that alerts on a Drive sharing event and see it appear in the alert center. For third-party apps, configure a Marketplace allowlist, mark one OAuth app as blocked in API controls, and add a custom SAML app. Review the edition requirements for the investigation tool and context-aware access, as questions often name the edition in the scenario.

FAQ

How much of the Workspace Admin exam is Section 4?

Managing security policies and access controls is about 20% of the exam, roughly 11 questions, spread across three dense sub-objectives.

Which 2SV method does Google consider strongest?

Passkeys and hardware security keys, because they resist phishing. Text message codes are the weakest option.

What is context-aware access?

A control that allows or blocks access to Workspace apps based on attributes such as device security status, IP address or location, assigned by OU or group.

Should help desk staff be super admins?

No. Use the Help Desk Admin role or a custom role with only the needed privileges, scoped to the OUs they support.

Is the security investigation tool available in every edition?

No. It requires higher editions such as Enterprise. Lower editions rely on the audit and investigation logs without the same bulk actions.

How do I stop a third-party app from reading users' Drive files?

Mark the app as blocked in API controls, and revoke its access for users who already connected it.

What is the difference between a custom SAML app and SSO with a third-party IdP?

With a custom SAML app, Google signs users in to another service. With third-party SSO, another identity provider signs users in to Google.

Other Cloud Computing certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 4 knowledge

You have covered 2SV, passwords, context-aware access, admin roles, security tools and third-party app controls. Test your judgment on access and incident scenarios.

Take the Workspace Admin practice test Check your Workspace Admin readiness

Keep going