GCP Workspace Admin common mistakes
GCP Workspace Admin · Understand the traps and how to avoid them.
When asked to give a user access to a service, the candidate adds the user to a Google Group and then also assigns the service setting or role directly to the user's account, rather than resolving access through group membership alone.
Candidates default to direct per-user assignment because it feels explicit and verifiable, and they forget that Workspace settings, Drive sharing, and admin roles can all be granted to groups, which is the scalable pattern the exam prefers.
What to do instead
Before assigning anything, ask whether the requirement is for one person or a set of people with a shared function. If a set, create or reuse a group, assign the setting/role/sharing to the group, and manage membership instead of touching individual accounts. State explicitly in your answer that access is inherited via group membership.
The candidate deletes a user account to remove access, instead of suspending it, and does not account for what happens to the user's data and aliases.
Deletion and suspension both 'remove access' superficially, so candidates pick whichever they think of first and skip the consequences: deletion frees the username for reuse, removes the mailbox, and is irreversible after the recovery window, whereas suspension blocks sign-in while preserving data.
What to do instead
Match the action to intent: suspend for temporary or investigatory removal of access (sign-in blocked, data retained); delete only when the account must be retired permanently. For deletion, plan data transfer first (Drive ownership transfer, Gmail delegation or migration), then delete. Mention that a deleted username can be recreated and that a suspended user cannot sign in but still occupies the license.
When asked to route or filter mail, the candidate edits the user's Gmail filters or a content compliance rule when the requirement is really about envelope routing, or vice versa, and mixes up the order in which Gmail settings, routing, and compliance rules are evaluated.
Gmail administration exposes several similar-looking rule surfaces (content compliance, attachment compliance, routing, blocked senders, recipient address maps), and candidates treat them as interchangeable because they all 'act on mail'.
What to do instead
Classify the requirement first: is it about where mail is delivered (routing/recipient maps), whether it is accepted (blocked senders, inbound gateway), or what happens to accepted mail (compliance rules, quarantine, modify message). Then pick the matching surface and state the evaluation position (inbound vs outbound, before or after delivery). Do not propose user-level filters for organization-wide policy.
The candidate answers an organizational-unit question by changing a setting at the top-level organization and assumes it cascades to override a child OU that already has an explicit value, or conversely assumes a child inherits changes made after it was given its own value.
Candidates conflate 'inheritance' with 'live synchronization'. Inheritance applies only while the child has no explicit value; once an OU has its own setting, parent changes no longer flow down, and candidates forget this when predicting effective policy.
What to do instead
For any 'what is the effective setting for this user' question, walk the OU path from the user's OU up to the root and take the value from the most specific OU that has an explicit setting. When the requirement is a uniform policy, say to set it at the highest OU that covers all affected users and to clear or align child overrides. Explicitly note that a child override wins.
The candidate proposes deleting data to satisfy a retention requirement, or proposes keeping data indefinitely to satisfy a legal hold, without distinguishing retention rules, holds, and deletion.
Retention, hold, and deletion all sound like 'control how long data stays', so candidates collapse them. They forget that a hold suspends deletion regardless of retention policy and that retention policies define a minimum keep period, not an automatic purge trigger in every product.
What to do instead
Separate the three: retention sets a minimum period during which data cannot be removed; a hold preserves data for named users or matters and overrides deletion attempts; deletion removes data. For a legal matter, apply a hold to the custodians, not a retention rule, and state that holds must be lifted before deletion can proceed. For compliance minimums, apply a retention rule scoped to the right OU and note that scope determines who is covered.
The candidate answers an eDiscovery or audit question by pointing to the wrong tool: using Drive audit logs to find email content, or using eDiscovery for a routine admin action review, or assuming audit logs are retained forever.
Audit logs, eDiscovery, and export tools overlap in the data they touch, and candidates reach for the tool they know rather than the one scoped to the data type and purpose. They also assume logs persist indefinitely.
What to do instead
Map purpose to tool: content search and preservation for legal matters goes to eDiscovery (with matters, holds, and exports); admin activity and configuration change review goes to the audit log for the relevant service; bulk data extraction for migration or investigation goes to the data export tool. State that audit log retention is limited and that long-term preservation requires export or a hold, not reliance on logs.
The candidate enables a security control such as 2-Step Verification enforcement or a context-aware access policy at the top-level organization and reports the requirement as satisfied, without checking that it applies to the right population and without accounting for enforcement rollout or exceptions.
Enforcement settings look binary ('on' means done), so candidates skip the scoping step and the practical rollout: who is exempt, what happens to users without enrolled factors, and how the policy interacts with existing sessions.
What to do instead
State the scope explicitly (OU or group), name the enforcement mechanism (2SV enforcement, security keys, context-aware access), and describe the transition: grace period, enrollment requirement, and the exception path for break-glass accounts. Confirm the setting is applied at the OU that contains the target users and is not shadowed by a child override.
The candidate treats an OAuth app allowlisting or API access control question as a password/2SV question, or blocks a third-party app by disabling a user's account instead of restricting the app's access scope.
Both are 'access control', and candidates default to the identity controls they know best. They also miss that app access is governed by scopes, client trust, and API access settings rather than by user credentials.
What to do instead
Separate identity controls (password, 2SV, session length) from authorization controls (OAuth scopes, app allowlisting, API access, trusted apps). For a third-party app concern, identify the app and its requested scopes, then use app access control or API access settings to block or limit it, and note that revoking tokens or restricting scopes is the lever, not disabling users.
The candidate configures a device policy but does not connect it to the enrollment path, so devices never receive the policy, or they assume a policy applies to unmanaged devices.
Device management has a chain (enrollment, then policy assignment by OU or group, then compliance state), and candidates configure the middle link without verifying the first. They also assume policies reach devices that were never enrolled.
What to do instead
Describe the chain end to end: how devices enroll (user enrollment, auto-enrollment, or admin-driven), how policy is targeted (OU or group), and how compliance is verified (device state, screen lock, OS version). State that unmanaged or unenrolled devices are outside policy enforcement and must be handled by access controls (context-aware access) rather than device policy.
When troubleshooting, the candidate proposes a fix immediately based on the symptom (for example, resetting a password for a sign-in failure) without gathering the evidence that distinguishes causes, and without confirming which layer failed (identity, policy, client, or service).
Exam prompts describe symptoms that map to several causes, and candidates jump to the most familiar remedy. They also skip the diagnostic artifacts (audit logs, sign-in logs, message headers, device state) that would narrow the cause.
What to do instead
Structure the answer as: reproduce and scope (one user or many, one device or all, one service or all), gather evidence from the relevant log or header, identify the failing layer, then apply the smallest fix and verify. For sign-in issues, check the sign-in log for the specific rejection reason before resetting credentials; for mail issues, read the message headers before changing routing.