Managing User Accounts and Objects
Core concepts
Account lifecycle in Google Workspace rests on a small set of objects: users, groups, organizational units (OUs), and directory settings. A user belongs to exactly one OU at a time, and OUs form a tree that inherits settings downward. Groups are used for distribution, access, and policy targeting, and nested groups are resolved for membership but not for every policy type. Admin roles (predefined and custom) grant privileges, while delegated admin is scoped by role plus OU. Directory sync from an on-prem identity source (Google Cloud Directory Sync or an IdP via SSO) creates and updates users rather than manual entry at scale.
Traps
Questions often blur suspension vs deletion: suspending preserves data and frees a license only if you reassign it; deleting removes the account and starts a recovery window. Another trap is assuming OU membership can be multiple - it cannot. Renaming a user changes the primary address but aliases stay attached; changing the primary domain is a separate, disruptive operation. Group membership changes may take time to propagate to policy evaluation. Bulk operations via the Admin console, API, or CSV import have different limits, and a question may test which tool fits a large batch.
Rule of thumb
Model your OU tree around policy differences, not your org chart. If two teams need identical settings, put them in the same OU and separate them with groups for access. For a worked example: a departing employee should be suspended first, mailbox data delegated or migrated, then the account deleted after the retention need is satisfied - never delete first if data must be preserved.
Worked check
Before deleting any account, confirm: license reassignment, data ownership transfer, alias reuse, and audit retention.