Notes from Studying for the Professional ChromeOS Administrator Exam

I sat Google's Professional ChromeOS Administrator certification in 2023. What follows started life as a scrappy set of study notes from that prep — a mix of things I'd worked out myself, things pulled from Google's own documentation, and pointers to a handful of genuinely useful YouTube walkthroughs. I've tidied them up here, roughly following the exam's own structure, partly so future-me has a cleaner reference, and partly on the off chance it's useful to anyone else sitting the same exam.

Section 1: Admin console actions

Troubleshooting and day-to-day admin tasks

The bread-and-butter admin actions all live in fairly predictable places once you know where to look:

Wiping devices: Devices → Chrome → Devices or Devices → Overview → Mobile and Endpoints.
Collecting device logs: pulled from the device itself.
Raising tickets: the question-mark icon, top right of the console.
Connectivity issues: Devices → Networks.
First-time user login problems: usually comes down to Organisational Unit and user setup — Users → Manage Organisational Units / Add New User.
Manually checking for updates: Devices → Chrome → Reports → Versions.
Feature requests: the main menu's "Send Feedback" option.

Worth knowing about even if you never use them directly: the Trusted Tester Program, and the fact that partners are informed of release notes separately from the standard release channel.

For actual escalation to Google support: the support/help icon top-right, or support.google.com/chrome/a → "Contact us" → hardware, software/services, or troubleshooting. If self-service doesn't resolve it, "This didn't help, continue to support" gives you a phone option — you get a PIN valid for 60 minutes to call Google directly.

Update channels and rollout

This is a section worth knowing cold, since it comes up in scenario questions a lot.

Update settings live under Devices → Chrome → Settings (on a child OU) → Device Update Settings → Auto Update Settings.

Channels: Stable, Beta, Long Term Support, Long Term Support Candidate, Dev.
Rollout schedule options:
- Default — devices update as soon as a new version is available.
- Scatter updates — useful for bandwidth-constrained fleets; spreads updates over up to two weeks.
- Schedule — a staged rollout: update X% after Y days, then 100% after a further period.
Blackout windows stop automatic updates during specified times (manual updates are still possible).
Auto-reboot behaviour differs by session type: kiosk devices restart automatically after an update; user/managed guest sessions restart after the user's next sign-out. Both are configurable.
A good chunk of a typical fleet — 5% is the figure to remember — should sit on the Beta channel, to catch problems before they hit Stable.

One easy-to-miss detail: to stop an update being applied before a device is even enrolled, press Ctrl+Alt+E on the End User License Agreement screen. Skip this and a downloaded update that should have been blocked by policy can still apply itself on next restart.

For diagnostics: the Log Analyzer tool, network logs at /var/log (accessible via file:///var/log), and chrome://network for live inspection. Requesting exported logs needs the Export Logs Action admin privilege specifically.

Wiping, deprovisioning and disabling — know the difference

These three get confused easily, and the exam leans on the distinction:

Action	What it does
Clear user profiles	Removes user profile data, keeps device policy and enrollment
Factory reset	Wipes everything, returns to factory state — unless the device is subject to automatic re-enrollment
Deprovision	Can be with or without a factory reset; requires a reason (e.g. retiring from fleet, ChromeOS Flex upgrade)
Disable	Locks the device with a lock screen, optionally with factory reset

On-device, a factory reset is Ctrl+Alt+Shift+R, then Restart → Powerwash → Continue. From the Esc + Refresh + Power recovery screen you can also recover via internet connection, or press Ctrl+D to enter developer mode (blocked if forced re-enrollment is set). On tablets, the equivalent is volume up + volume down + power.

Setting up a trial

Trials hinge on domain verification: Home → Domains → Manage Domains → Add Domain, then verify ownership — either linking through your DNS provider directly, or adding a TXT record (google-site-verification). Verification can take up to 12 hours, and every user on the domain gets a notification email once it completes.

Before verification, the Chrome devices tile in the admin console sits greyed out. Once verified, the setup wizard walks you through DNS-provider-specific instructions, the tile unlocks, and you get access to Google support proper.

Pushing applications

This is another heavily-tested area — pay close attention to which method a question specifies (Chrome Web Store, Google Play Store, or App ID), and to any mention of installation policy or version pinning.

Application settings live under Devices → Chrome → Apps and Extensions, and apply to whichever OU you're configuring.

Chrome extensions: add from the Chrome Web Store. Default policy is "allow installation"; you can also force-install, or force-install and pin to the shelf.
Android apps: added via Google Play. Only apps approved in Play are available, same installation options apply, and there's a JSON configuration option for pre-setting app config.
Progressive Web Apps: added by URL, which unlocks PWA features like real-time notifications and offline access, and can open in its own window for an app-like feel.
OU-level policy: "Allow users to install other apps and extensions" can be set to allow all, Play only, Chrome only, or block all others.
Advanced settings (gear icon): granular allow/block per app, and permission-based blocking of extensions — e.g. blocking anything that requests video capture.

Device actions and licensing

Most per-device actions (gathering logs, deprovisioning, moving OU, remote desktop, screenshots, resetting profiles) live under Devices → Chrome → Devices → [select device]. Zero-Touch Enrollment tokens come from the same area, scoped to an OU: generate a 30-character pre-provisioning token, which you can copy, revoke, or regenerate. Devices show as "pre-provisioned" until they check in. ZTE itself needs a capable device, an approved manufacturer that's pre-enrolled it, and a partner relationship.

On licensing, the distinction that matters is:

Bundled/perpetual license — tied to the device for its lifetime, non-transferable.
Chrome Education Upgrade — purchased separately, transferable to another device of the same model.
Annual licenses — bought per term (e.g. for kiosk/signage use), also transferable.

Devices must be enrolled before anyone signs in — if that's missed, the only fix is wiping and restarting enrollment. A summary of assigned vs. purchased licenses lives under Devices → Chrome → Devices → Upgrades.

Admin roles

Custom roles are created under Accounts → Admin Roles, then applied to a user via Users → [select user] → Admin Roles and Privileges → Assign roles. Roles can be scoped to a specific OU — with one important exception: the support ticket privilege is organisation-wide and can't be OU-scoped. Don't mix OU-scoped and organisation-wide permissions on the same custom role.

Super Admin is a separate tier entirely: full access to everything, must be a native Google identity (not usable with SSO), and best practice is to create super admin accounts with distinct UPNs from everyday admin accounts. Certain actions — billing, accepting terms and conditions — require super admin specifically.

Section 2: Security processes

Certificates and VPN

Certificate deployment lives under Devices → Networks → Certificates. For automatic user/device certificate provisioning via SCEP (Simple Certificate Enrollment Protocol): select the OU, upload a certificate authority, then create a SCEP profile — profile name, fully distinguished name, common name (${USER_EMAIL}), subject alternative name, SCEP server URL, extended key usage (client and/or server authentication), and usually a static challenge.

Wiring that certificate into a Wi-Fi network: create the network under Devices → Networks, choose 802.1X with EAP-TLS, set the username field to ${LOGIN_ID}, and select the SCEP profile and root cert you just created.

Android VPN requires the "Advanced" tier of mobile management (toggled under Mobiles and Endpoints → Settings → Universal), and requires users to install an app to use it.

Core security tenets

A few things worth internalising rather than memorising as menu paths:

No antivirus needed — every page and app runs sandboxed.
Verified boot — every startup runs an integrity self-check; if tampering or corruption is detected, ChromeOS attempts to repair and restore itself automatically.
Client-side encryption settings live under Security → Access and Data Control.
Forced re-enrollment and Verified Access both sit under Devices → Chrome → Settings → Device.

Section 3: ChromeOS policies

Enrollment permissions are set through Chrome user/browser policies rather than an admin privilege as such: Users → [user] → Chrome User Policies → Devices → User and Browser Settings, then search "Enrollment." From there you can force devices into a specific enrollment OU, or lock enrollment down entirely at the top-level OU.

The policy surface itself is large. The practically useful thing to know going in is where a given policy lives — device-level, user-level, or specifically for kiosk mode — since kiosk-related questions came up a lot when I sat the exam. If you've never had to configure kiosk mode for real, it's worth deliberately spending time there rather than assuming general ChromeOS familiarity will cover it.

One small shortcut worth remembering: Alt+V shows system info on the sign-in screen.

Section 4: Identity management

New users are created under Directory → Users → Add New — name, auto-generated username, optional photo, OU assignment, optional secondary email for sending credentials, and an 8-character minimum password. Bulk creation uses a CSV template: first name, last name, email, password, and OU path.

Setting up SSO is a longer sequence worth having as a checklist:

Configure the identity provider (SAML or OIDC).
Enable SAML-based SSO under Devices → Chrome → User & Browser Settings → Security.
Enable transfer of SAML SSO cookies into the user session at sign-in, if wanted.
Optionally keep local ChromeOS and SAML passwords in sync — choosing whether to enforce online sign-in at the login screen only, or both login and lock screen.
Set up password expiration notifications via the passwordExpirationTimestamp attribute.
Enable IdP redirection, so users go straight to the SAML page rather than seeing a Google-branded intermediate screen.
Enable username passthrough, so the username auto-fills on the IdP's login page.
Control what's reachable from the sign-in/lock screen via blocked URLs and exceptions.

Third-party IdP configuration (sign-in URL, sign-out URL, certificate, change-password URL) lives under Security → Authentication → SSO with third-party IdP. Domain-specific service URLs can either redirect straight to the third-party IdP or prompt for a Google username.

Section 5: General tenets and hardware

Test domains: added as a secondary domain under Domains.
OS update cadence: new milestone releases roughly every 4 weeks; Long Term Support gets milestone updates every 6 months.
Password manager policy: Devices → Chrome → User and Browser Settings, search "Security" → Password Manager, with an option to disable it outright.
Lock screen: configurable idle timeout before the screen locks.
Keeping devices managed: forced re-enrollment (Devices → Chrome → Device Settings → Enrollment and Access) is on by default, and pairs with requiring verified boot mode for Verified Access.
Disabling a device: Devices → [select device] → Disable, with an optional custom message, and it's reversible.

On hardware selection, the exam expects general awareness of ChromeOS device specs, hardware capability tiers, and ChromeOS Flex as a route for repurposing existing (non-Chromebook) hardware — rather than deep specifics.

A few loose scenario notes

A couple of specific scenario-style points that stuck with me from prep:

Migrating email from IMAP into Google Workspace: the correct tool is Google's native Data Migration service, not a manual export/import.
Within the security investigation tool, one of the available actions on a user in the search results is "Restore user."
Manual enrollment shortcut: Ctrl+Alt+E on the sign-in/enrollment screen.

Further resources

A handful of the videos and docs I found genuinely useful while studying: