Playbook - AGWA Google Cloud Associate Google Workspace Administrator
Last reviewed: May 2026
A scannable reference of architectural patterns the AGWA exam tests. Read top-to-bottom, or jump to a section.
Manage user accounts and objects
Onboard hundreds of new users from an HR-provided CSV file.
Use the Admin Console Bulk Upload feature. Include the `Org Unit Path` column in the CSV to place users directly into correct OUs.
Why: Most efficient method for mass user creation with correct policy assignment without scripting. More direct than GCDS for one-off onboarding.
An employee is leaving. Preserve their Drive files and transfer them to their manager's control.
Before suspending or deleting the user, use the Admin Console Data Transfer tool to transfer ownership of all Drive files to the manager.
Why: Preserves data integrity and ensures business continuity. Direct ownership transfer is cleaner than sharing and maintains a clear audit trail.
Different departments and teams require unique service settings and security policies.
Create a hierarchical Organizational Unit (OU) structure (e.g., /Sales/East, /Sales/West). Apply broad policies at the parent OU and specific overrides at child OUs.
Why: OUs provide hierarchical policy inheritance, allowing for scalable and granular control over settings for different user populations.
Automate group membership for all users in the Engineering department, including new hires.
Create a Dynamic Group with a membership query based on the user attribute `department==Engineering`.
Why: Automatically manages membership based on user attributes, eliminating manual updates and ensuring consistency as user roles change.
Grant Help Desk staff the ability to reset passwords only for users in the main office OU.
Create a custom admin role with only the "Users > Reset Password" privilege. Assign this role to the Help Desk team and scope it to apply only to the target OU.
Why: Implements the principle of least privilege. Custom, scoped roles prevent delegated admins from affecting users or settings outside their responsibility.
Syncing from Active Directory via GCDS, but user UPNs have an old domain. Need to create users with the new, correct domain.
In GCDS, configure an attribute transformation rule for the email address attribute to replace the old domain string with the new one.
Why: Corrects data during the sync process without requiring modification of the source Active Directory, which is often not feasible.
A user was accidentally deleted 15 days ago. Their manager now needs a critical file from their Drive.
From the Admin console, restore the recently deleted user. The recovery window is 20 days. Once restored, transfer the data, then re-delete if necessary.
Why: Deleted users are recoverable for 20 days. This is the only way to recover their data if no Vault hold/retention was in place.
Manage core Workspace services
A support team needs a shared email address (support@) where multiple members can manage, assign, and track customer inquiries.
Create a Google Group and configure it as a "Collaborative Inbox".
Why: This group type is designed for shared workflows, allowing conversation assignment and resolution tracking, which is superior to a standard distribution list or shared user account.
Enforce a standardized legal disclaimer and branding on all outgoing emails from the Sales department.
In Gmail settings, configure a compliance rule with an "Append footer" action, scoped to the Sales OU.
Why: This appends a non-editable footer at the server level, ensuring 100% compliance. User-side solutions can be modified or bypassed.
Allow users to share Drive files externally, but only with specific, approved partner domains.
In Drive sharing settings, add partner domains to the "Allowlisted domains" list and set the sharing policy to "Allowlisted domains only".
Why: Provides a balance between security and collaboration, preventing data sharing with unauthorized external parties while enabling approved partnerships.
Allow external guests in Google Meet, but prevent them from joining before an internal host arrives.
In Google Meet safety settings, ensure "Host must admit people from outside your organization" (knocking) is enabled.
Why: Enhances meeting security by creating a virtual lobby, giving the host control over when and which external participants can join.
Migrating from an on-premises Exchange server to Gmail with zero downtime for inbound email.
Configure dual delivery. Set up a mail route in Workspace to forward mail to the legacy Exchange server, then point MX records to Google.
Why: Ensures users receive mail in both mailboxes during a phased migration, preventing lost messages and allowing a smooth transition.
Prevent users from installing unvetted third-party add-ons in Docs, Sheets, and Gmail.
In Marketplace settings, configure an allowlist of approved applications and set the policy to restrict users to only allowlisted apps.
Why: Reduces security risk from malicious or data-hungry third-party apps by creating a "walled garden" of IT-approved tools.
Support data governance and compliance
For compliance, all emails must be retained for 7 years, even if users delete them from their mailboxes.
In Google Vault, create a custom retention rule for Gmail with a 7-year duration. Do not set an expiration.
Why: Vault retention operates independently of user actions. It provides a legally defensible archive for eDiscovery and compliance, separate from live user mailboxes.
Legal department requires all data for specific employees (custodians) to be preserved indefinitely for pending litigation.
In Google Vault, create a Matter, identify the users as custodians, and place a Legal Hold on them.
Why: A Legal Hold overrides all retention and deletion policies. Data is preserved until the hold is explicitly released, ensuring legal preservation obligations are met.
Prevent users from accidentally sharing documents containing credit card numbers or PII with external parties.
Create a Data Loss Prevention (DLP) rule in `Security > Data protection`. Use predefined detectors (e.g., Credit Card Number) and set the trigger condition for external sharing. The action should be "Block external sharing".
Why: DLP scans content in real-time to automatically enforce data protection policies, reducing the risk of human error leading to data breaches.
To comply with GDPR, ensure all primary data for European employees is stored at-rest within European data centers.
Place European users in a dedicated OU. In `Account > Data regions`, apply a data region policy for "Europe" to that OU.
Why: This feature directly addresses data residency requirements by controlling the geographic storage location of primary data for specific services.
A user permanently deleted a critical Drive file 10 days ago. It is no longer in their trash.
If a Vault retention rule or hold was covering the user, search for the file in Vault and export it for recovery.
Why: Vault acts as a safety net. Data covered by retention/holds is preserved even after being "permanently" deleted by the user.
An employee under legal hold is leaving. You need to preserve their data and hold, but free up their full license.
Suspend the user account and assign an "Archived User" (AU) license. The data remains in Vault and subject to the hold.
Why: AU licenses are a cost-effective way to preserve data for former employees for compliance and legal purposes without consuming a full, active license.
Manage security policies and access controls
Allow access to Workspace only from corporate-managed devices or when connected to the office network.
Configure Context-Aware Access. Create access levels for "Compliant device" (from endpoint management) and "Corporate IP range". Apply a policy that requires one of these levels for access.
Why: This is the core of a zero-trust model for Workspace, shifting from a network perimeter to enforcing access policies based on device and user context, regardless of location.
A user account is suspected of being compromised. Attacker may have active sessions or app access.
Immediately: 1) Reset the user's password. 2) Revoke all third-party OAuth tokens. 3) Sign out all web sessions.
Why: This three-step process ensures the attacker is locked out of all access points: direct login, app-based access, and existing browser sessions.
Prevent users from granting corporate data access to risky or unvetted third-party OAuth applications.
In `Security > API controls`, configure "App access control" to block unconfigured apps by default, then add specific, vetted apps to the "Trusted" list.
Why: This moves from a default-allow to a default-deny security posture for third-party apps, giving IT full control over which applications can access company data.
Implement Single Sign-On (SSO) with a third-party IdP, but ensure admin access if the IdP is down.
Configure SAML SSO for the entire organization. Create a separate group or OU for Super Admins and configure a network mask or group setting to exclude them from the SSO requirement.
Why: Provides a critical "break-glass" procedure, allowing admins to log in with Google credentials during an IdP outage to manage the environment.
Prevent attackers from spoofing your domain in phishing attacks and improve email deliverability.
Properly configure SPF, DKIM, and DMARC DNS records for your domain. Set the DMARC policy to `p=reject` for full enforcement.
Why: These three standards work together to authenticate your outbound mail, allowing recipient servers to confidently reject fraudulent messages impersonating your domain.
Need proactive notification of security events like suspicious logins or government-backed attack warnings.
Regularly monitor the Alert Center. Configure alert rules to send email notifications for high-priority events to the security team.
Why: The Alert Center is the centralized hub for security-related events. Proactive notifications enable rapid incident response.
A user lost their phone and has no backup codes, locking them out of their 2SV-protected account.
As an admin, select the user and generate one-time use backup verification codes for them to regain access.
Why: This is the standard, secure procedure for user recovery without needing to temporarily disable 2SV, which would weaken security.
Mandate the strongest form of authentication to protect high-risk users from phishing.
Enforce a 2-Step Verification policy that requires the use of Security Keys (FIDO) only.
Why: Security keys are phishing-resistant because they use public-key cryptography and verify the origin of the login page, unlike TOTP or SMS which can be phished.
Manage endpoints
A company-managed mobile phone containing sensitive data has been lost or stolen.
Using the Admin console under Devices, locate the device and initiate a remote "Wipe device" command immediately.
Why: This is the primary security response for a lost managed device. It remotely factory resets the device or wipes the work profile, protecting corporate data from unauthorized access.
Enforce a standard set of security settings and mandatory extensions on all corporate Chrome browsers (Windows, Mac).
Enroll browsers into Chrome Browser Cloud Management (CBCM). Apply policies to the user/browser OU to force-install extensions, block others, and configure settings.
Why: CBCM provides centralized, cloud-based management of Chrome browsers on any platform, ensuring consistent policy and security posture.
Allow employees to use personal Android devices for work (BYOD) while keeping corporate data separate and secure.
Implement Advanced Mobile Management and enforce the creation of an Android Work Profile on employee-owned devices.
Why: A Work Profile creates an OS-level container that isolates work apps and data from personal data. The entire container can be remotely wiped without affecting the user's personal files.
A Context-Aware Access policy must verify that a device is company-owned and encrypted before granting access.
Deploy the Google Endpoint Verification extension/agent to all managed devices. Configure the CAA access level to require a "Compliant" or "Company-owned" device status.
Why: Endpoint Verification is the agent that gathers and reports device posture to the CAA engine, enabling device trust-based access control.
Troubleshoot common issues
Users report emails to a specific partner are being bounced or are severely delayed.
Use the "Email Log Search" tool in the Admin Console. Search for a sample message to see the full delivery path, timestamps, and any rejection errors from the recipient server.
Why: Email Log Search is the definitive tool for diagnosing delivery issues. It provides granular detail that confirms if the message left Google and why it was rejected.
Multiple users across the organization are suddenly unable to log in, reporting credential verification errors.
The issue is likely with the third-party Identity Provider (IdP). Check the status of the IdP service and the validity of the SAML certificate in the SSO configuration.
Why: Widespread, sudden login failures in an SSO environment almost always point to the external IdP, not individual user accounts.
A user reports that the 6-digit codes from their Google Authenticator app are consistently being rejected.
Instruct the user to check and sync the clock on their mobile device. The Authenticator app has a time correction feature.
Why: Time-based OTP (TOTP) codes are highly dependent on synchronized time. Clock drift is the most common cause of code rejection.
Users in a specific office complain of poor Google Meet video quality, while other offices are fine.
Investigate the local network at the affected office. Check for bandwidth saturation, high latency/jitter, and ensure firewall rules are not throttling or blocking Google Meet traffic.
Why: Location-specific performance issues are almost always caused by local network problems, not the Google service itself.
One user is not receiving emails from an external sender, but their colleagues are.
Check the user's personal Gmail settings for any filters or blocked sender rules that may be redirecting or deleting the incoming emails.
Why: When an issue affects only a single user, the cause is most often a user-level configuration rather than an org-level policy.
A user can start a Meet recording, but it fails to save after the meeting ends.
Check the user's Google Drive storage quota. Recordings fail if the user has insufficient space.
Why: Meet recordings are saved to the organizer's "My Drive" in a "Meet Recordings" folder. A full Drive quota is the most common reason for saving failures.