Review: Data access and protection

This review covers three sections of the guide together, because they protect the same things from different directions. Section 4, security policies and access controls, decides who gets in and what administrators can do (about 20 in 100). Section 3, data governance and compliance, decides what data can do once people are in (about 15 in 100). Section 5, browsers and endpoints, decides which devices and browsers can be trusted (about 10 in 100). Together they are worth about 45 in every 100 questions, so this is the longest review lesson.

Section 4: securing user access

Objective 4.1 covers password rules and 2-step verification, recovery options, the methods users can choose, context-aware access, applying policies to users and groups, admin roles, and Google session control. GCP-212 covered most of it in depth; the exam points are summarized here.

The 2SV questions usually test the rollout: you cannot enforce 2SV the same day you turn it on for people who have not enrolled, or they are locked out. The safe pattern is to let users enroll, give an enrollment period, enforce on a date, and give new users a short window before enforcement applies to them. The passkey questions test a subtle point: allowing users to skip passwords at sign-in with a passkey does not remove their passwords, and enrolling a passkey does not by itself turn on 2SV for that user.

Admin role questions test least privilege. A help desk that only needs to reset passwords for store staff gets a role with only that privilege, scoped to the Stores OU, not super admin. At Birchline, the regional coordinators have a custom role scoped to their region's store OUs. Owen remembers the guard rails too: keep at least two super admins, keep super admin accounts separate from daily accounts, and require security keys for them.

Section 4: reporting, auditing and investigating

Objective 4.2 lists audit and investigation tools, the security center, the security health page, and activity rules and alerts. The point the exam tests most is which tool does which job.

Edition matters here, and Owen marks it as the clue to watch. The security center and the investigation tool are not in every edition; audit and investigation logs and the alert center are much more widely available. A question set in a Business Starter organization cannot have the investigation tool as its answer.

Section 4: third-party and additional apps

Objective 4.3 covers the Marketplace allowlist, deploying and restricting Marketplace apps and Play Store apps, single sign-on for third-party apps, access to additional Google services such as YouTube or AdSense for selected users, and removing connected apps and sites. From GCP-211, the key ideas are: an allowlist lets administrators permit only approved Marketplace apps; API controls decide which third-party apps can access Workspace data and whether unconfigured apps are allowed; SAML apps let users sign in to services like a payroll system with their Google account; and additional Google services such as YouTube or Blogger are turned on separately per OU, because they are not core Workspace services.

Section 3: Vault

Objective 3.1 covers Vault for eDiscovery and retention: archive licenses, retention rules by date or content, holds, search and export, export location, and audit reports. The points from GCP-212 that the exam tests most often are these. Vault keeps nothing until a retention rule or a hold exists. Holds override retention rules, custom rules override the default rule for the data they cover, and the longest applicable custom rule usually wins. Exports are available for download for a limited time, 15 days in Google's documentation. Vault actions, including searches and exports, are themselves audited, so access to Vault should be limited to a few people with custom Vault roles.

The Archived User license links section 3 to section 1: a departed employee's data can be kept, and held, without paying for a full license.

Section 3: DLP, trust rules and labels

DLP covers Drive, Gmail and Chat, with different capabilities in each. Rules should start in audit mode, move to warn and then to block once false positives are understood; when two rules match, the stricter action wins. Notifications to users can be customized, which matters for questions about explaining a block. Trust rules are newer than the older external sharing settings and give finer control: allow or block sharing between specific OUs, groups, domains or users. Labels connect the two, because a DLP rule can act on a label, and a label can be applied automatically by a DLP rule or by AI classification where available.

Section 3: storing and exporting data

Objective 3.4 covers Google Takeout settings, the Data Export tool, data regions and legal and compliance settings. Google Takeout lets individual users download their own data; administrators can turn it on or off per OU and per service. The Data Export tool lets a super admin export the whole organization's data, for example when leaving Workspace, and has its own requirements and limits. Data regions let some editions store covered data at rest in the United States or Europe, or with no preference; there is no option for other countries.

That last point is simple for Birchline in the US: GCP-212 set its data region to the United States for the editions that support it.

Section 5: mobile devices

Objective 5.1 covers choosing basic, advanced or third-party mobile management, security policies under basic management, company-owned and personal devices, and offboarding devices. Basic management needs no agent and enforces simple rules such as a screen lock; advanced management uses device policies, work profiles on Android, and the ability to wipe a company-owned device or only the work account on a personal one. The exam's favorite question is what to do with a lost device: block and sign out first if it may be found, wipe the account on a personal phone, wipe the whole device if it is company-owned.

Section 5: Chrome browser management

Objective 5.2 is the gap Owen identified in lesson 1. It covers browser policies such as offline access and updates, enrolling browsers, and allowing, blocking or force-installing extensions by OU or group. Sofia takes him through the essentials.

The distinction between a managed browser and a managed profile is the one Owen expects to be tested. Machine-level enrollment makes policies follow the computer: a shared store computer at Birchline would be enrolled so that every person who uses it gets the same safe settings. User-level management through sign-in makes policies follow the person. Google's name for the free browser management service has changed over the years; in GCP-210 it appeared as Chrome Enterprise Core. Owen writes himself a note to check the current name and the policy list in the documentation.

For extensions, Sofia states a rule of thumb: in organizations with sensitive data, block all extensions by default and allow only those on an approved list, and force-install the few that everyone must have. A question that describes a data leak through a browser extension usually expects that pattern, applied by OU so that, for example, developers can have a wider list than store staff.

Owen's unsure list for sections 3 to 5

• Exact differences between trust rules and the older external sharing settings, and which wins if both are set.
• Which labels can be applied by AI classification, and in which editions.
• The Data Export tool's requirements and what it exports compared with Takeout.
• How Chrome browser enrollment tokens are deployed on Windows and macOS, and how browsers are moved between OUs.
• Which editions include the security center, the investigation tool and context-aware access.
• How to give YouTube access to some users only, and what the YouTube settings for the organization control.