Associate Google Workspace Administrator: study path

Learn and apply

Work in a test tenant or on paper. Obtain permission before changing a real organisation's users, policies or data. Save each exercise with its assumptions, expected result, observed result and limitations.

1. Accounts, domains and Directory — guide section 1

   1. Govern the directory and user lifecycle

   Learning outcome: Design a repeatable joiner, mover and leaver process with traceable ownership and least privilege.

   Model identity before creating accounts

   List the charity's staff, volunteers and administrators, then identify who approves each account, what data the person needs and when access should end. An organisational unit is a policy inheritance boundary, while a group can grant access or distribute messages. Do not treat a person's department and permission set as the same thing. Keep administrative roles separate from routine collaboration and document exceptions.

   Control transitions, not just creation

   A joiner needs a unique account, appropriate licence, group membership and a secure first sign-in. A mover needs a review of old and new access. A leaver may need immediate suspension, ownership transfer and retention decisions before any deletion. The order matters: deleting before transferring a Shared Drive or delegated mailbox responsibility can interrupt work or lose access to evidence. Record the approver, time, affected objects and completion check.

   Treat domains and mail routing as dependencies

   A verified domain proves administrative control but does not by itself make mail flow. Document primary and secondary domains, aliases and the intended MX route. Test inbound and outbound delivery from an external mailbox after a controlled DNS change. Allow for propagation and preserve a rollback plan. A user alias is another address for an account; it is not a separate user with independent permissions.

   Worked case

   A volunteer becomes an employee. The administrator checks the new role's approved groups, moves the account to the appropriate policy OU, changes its licence if needed and removes the volunteer-only group. A second administrator verifies access from a test account and records the change. No new account is created merely because the role changed.

   Make your own evidence

   Draft a joiner, mover and leaver table for the charity. For each transition specify approval, account state, licence, OU, groups, data ownership, verification and rollback. Use fictional identities only.

   What to check in your answer

   The plan must distinguish suspension from deletion, an OU from a group, and an alias from a distinct account. Every critical step has an owner and a way to verify its result.

2. Core Workspace services — guide section 2

   2. Configure collaboration services deliberately

   Learning outcome: Choose safe defaults for mail, files, calendars and meetings, then verify their effect on real workflows.

   Understand the mail path

   Mail delivery depends on DNS, routing, spam and malware decisions, and sender authentication. SPF states authorised senders, DKIM signs messages and DMARC tells receivers how to handle authentication failures; each solves a different part of the trust problem. A blanket allowlist may hide phishing. When migrating mail or introducing split delivery, test both directions and watch for forwarding loops before a wider change.

   Design file sharing around ownership

   A shared drive is often a better home for team-owned documents than a personal drive because its files remain with the team when one person leaves. Define who can manage membership, which external domains may receive files, and whether sensitive data needs labels or stronger restrictions. Test sharing as an ordinary user and as an external recipient; an administrator view alone cannot prove that the intended boundary holds.

   Set calendars, Meet and Chat to suit the task

   Resource calendars need ownership, booking rules and conflict handling. Meet and Chat settings should match the organisation's recording, external participation and retention choices. A new setting can have different effects across OUs and groups, so name the scope and test with representative accounts. Document who is allowed to change the setting and how users can report a blocked legitimate workflow.

   Worked case

   The charity creates a shared drive for grant documents. External sharing is restricted to approved partners, a resource calendar handles interview-room bookings, and a test account verifies that volunteers cannot access the grant drive. The team records a support route for a partner whose invitation is rejected.

   Make your own evidence

   Draw a mail and file-sharing decision map: sender authentication, inbound routing, shared-drive ownership, external recipients, and test cases. Explain one trade-off between collaboration and protection.

   What to check in your answer

   A good answer names the exact service, policy scope, intended user experience and observable test. It does not rely on a broad allowlist or personal ownership of team records.

3. Data governance and compliance — guide section 3

   3. Protect, classify and retain information

   Learning outcome: Separate retention, legal hold, sharing restrictions and data loss prevention into the right decisions.

   Start with a defensible data inventory

   Identify grant records, volunteer details, safeguarding documents and routine communications. Record the owner, sensitivity, retention reason and permitted recipients for each category. A label makes classification visible, but it does not automatically impose every access rule; check the actual policy and licence features. Data-location choices and exports require a legal and operational decision beyond a console toggle.

   Distinguish the controls

   A retention rule preserves or removes information under an approved schedule. A legal hold preserves relevant material despite routine deletion, subject to authorised review. DLP detects and acts on content matching defined conditions; trust rules constrain who may share with whom. These controls can overlap but are not substitutes. Test a rule on representative synthetic data before expanding its scope, and monitor false positives that block legitimate work.

   Prove the rule without exposing data

   Use synthetic records containing harmless test markers rather than real personal data. Record the rule version, the test account, expected action, observed result and an exception route. A screenshot of a settings page shows configuration intent, not that the rule actually prevented disclosure. Ask a privacy or legal owner to approve retention periods and investigative access; the learner should not invent those obligations.

   Worked case

   A grant team must prevent an accidental external share of volunteer identity documents. The administrator labels a synthetic test file, applies a scoped sharing restriction and attempts to share it with a test external account. The blocked action and audit event are recorded, while a permitted public brochure still shares successfully.

   Make your own evidence

   Create a four-row control matrix for a synthetic grant file, volunteer record, public brochure and legal-hold item. Include owner, retention decision, sharing rule, DLP condition, test and escalation route.

   What to check in your answer

   The matrix distinguishes classification from enforcement and retention from legal hold. It includes both a blocked and an allowed test and avoids real sensitive content.

4. Security policies and access controls — guide section 4

   4. Secure access and investigate changes

   Learning outcome: Apply proportionate authentication and delegated administration, then investigate a suspicious event without overclaiming.

   Minimise powerful roles

   A super administrator can change tenant-wide controls and should not be the default help-desk account. Map routine tasks to narrower prebuilt or custom roles. Separate the person approving access from the person applying it where feasible. Two-step verification and recovery methods need rollout support, test accounts and an exception process so that stronger security does not strand legitimate users.

   Use context and evidence

   Context-aware access can take device or sign-in conditions into account, but the policy must be tested for remote staff and accessible working arrangements. An alert is an investigation trigger, not proof of compromise. Correlate sign-in logs, admin audit events, user reports and the timing of any approved change. Preserve timestamps, scope and limitations when documenting findings.

   Treat third-party apps as access decisions

   A Marketplace or SAML app can receive permissions and data even when it looks like a productivity convenience. Review the app's requested scope, owner, purpose and removal route before allowing it. Recheck integrations when a staff member leaves or the vendor changes its behaviour. A browser extension deployment is also a policy change and needs testing before wide rollout.

   Worked case

   A sign-in alert appears for the charity's finance lead. The team first checks whether travel or a known device explains it, then reviews sign-in and admin events, limits the account if justified and records the evidence. It does not announce a breach solely from an unfamiliar IP address.

   Make your own evidence

   Build an access review for three roles: super administrator, help desk and grant manager. Add authentication method, delegated privileges, recovery route, monitoring signal and one test that would catch excessive access.

   What to check in your answer

   The design avoids routine super-admin use, documents an exception path, and separates a suspicious signal from a confirmed incident.

5. Endpoints — guide section 5

   5. Manage mobile and browser endpoints

   Learning outcome: Choose proportionate device and browser policies for owned devices and bring-your-own-device access.

   Identify ownership and capability

   A company-owned laptop, a volunteer's personal phone and a shared kiosk have different management boundaries. Inventory what the organisation owns, what it can inspect and what it may erase. Basic and advanced management offer different controls and may depend on edition and licence; verify actual availability before promising a feature. Obtain an explicit policy decision before enrolling personal devices.

   Protect data through a device's life

   Plan enrolment, update, lost-device response and offboarding together. A remote wipe may affect personal content if applied to the wrong management mode, so the runbook must identify device ownership and the exact intended action. Test with a non-production device and document how access is revoked if the device itself cannot be reached.

   Treat browser policy as code-like change

   Chrome browser settings can control updates, extensions and offline access. Pilot a policy with a small OU or group, record the before and after state and check that essential accessibility or collaboration tools continue working. Define rollback to the previous policy and monitor the effect after rollout.

   Worked case

   A volunteer loses a personal phone used for charity mail. The administrator checks the registered device record, revokes the account session and applies only the authorised work-data action supported by the management mode. The volunteer receives a clear explanation of the action and how to restore access on a replacement device.

   Make your own evidence

   Write a comparison table for an owned laptop, personal phone and shared kiosk. Include enrolment permission, update control, lost-device response, offboarding, privacy boundary and evidence of a successful test.

   What to check in your answer

   The response does not assume all devices can be fully wiped and does not apply an owned-device policy silently to a personal device.

6. Troubleshooting — guide section 6

   6. Diagnose and resolve Workspace issues

   Learning outcome: Use a repeatable evidence-led method to isolate mail, access, Drive, Calendar and Meet failures.

   Reproduce and bound the fault

   Start with who is affected, the first observed time, the exact action and expected result. Check whether the service status page reports an incident before changing configuration. Compare an affected user with a working user in a similar OU or group. This narrows the fault to account, policy, device, network or service without guessing from one symptom.

   Choose the right diagnostic evidence

   For rejected mail, inspect the non-delivery reason, message headers, DNS authentication records and email logs before changing spam policy. For Drive, inspect ownership and sharing permissions. For Calendar, separate visibility from event synchronisation. For Meet, use quality and network evidence for audio or video problems. Redact personal content in shared support records and document each query's time window.

   Make the fix reversible

   Change one scoped setting at a time, record its previous state, retest with the original user and a control account, then watch for unintended effects. Escalate when the evidence points to a service incident or a legal, security or privacy decision outside the help desk's authority. Close the ticket with cause, verification, user confirmation and prevention, or clearly label the cause as unconfirmed.

   Worked case

   A partner says a grant message never arrived. The administrator checks service status and the message log, then finds that the external recipient server rejected the message. The team shares the delivery evidence with the sender, avoids weakening spam controls and asks the partner to investigate its receiving service.

   Make your own evidence

   Prepare a troubleshooting decision tree for one missing email and one denied Drive share. State the first three observations, a safe test, a reversible fix and when to escalate.

   What to check in your answer

   The decision tree distinguishes delivery from acceptance and configuration from service outage. It records verification after the change and does not expose message content unnecessarily.