User Accounts Domains And Directory practice questions

Email, Phone, Address

Why it fails: These are profile fields, not account creation fields.

FirstName, LastName, Password

Why it fails: Google requires spaces in headers, e.g., 'First Name'.

Username, Role, OU

Why it fails: Role and OU are optional, and Username is not a standard header.

The user is in a group

Why it fails: Group membership does not override OU hierarchy.

The domain is not verified

Why it fails: Verification affects account creation, not policy propagation.

The user has a suspended account

Why it fails: Suspended accounts still inherit policies.

Account Settings

Why it fails: Account settings cover organization profile information.

Organizational Units

Why it fails: OUs manage features and services, not network access.

Directory settings

Why it fails: Directory settings cover profile visibility and shared contacts.

Use the Security investigation tool

Why it fails: The investigation tool is for security events, not user lists.

Check the Billing report

Why it fails: Billing reports show costs, not individual user assignments.

Use the Directory API

Why it fails: While possible, the built-in report is easier for an administrator.

They need a higher license

Why it fails: Service access is usually license-agnostic for core apps.

The API is disabled

Why it fails: APIs manage data, not end-user feature visibility.

Their browser cache is full

Why it fails: This is unlikely to cause a persistent visibility issue.

Disable the domain

Why it fails: Disabling the domain affects all users.

Delete the OU

Why it fails: Deleting the OU is not required for offboarding.

Add the user as an alias

Why it fails: Aliases are for existing active users.

Editing the MX records

Why it fails: MX records are for routing mail, not verifying domains.

Uploading a file to the root of your domain

Why it fails: This is not a current Google Workspace verification method.

Emailing a verification code to the domain administrator

Why it fails: This is not a standard verification method.

Controlling access to shared files

Why it fails: File access is managed via Drive sharing settings, not OUs.

Creating automatic email forwarding rules

Why it fails: Forwarding is a user or admin-level email setting, not an OU setting.

Admin roles assigned to the OU

Why it fails: Admin roles are assigned to users, not OUs.

User email address

Why it fails: Email addresses are unique per user.

Google Workspace Admin SDK Directory API

Why it fails: The Admin SDK Directory API can update user attributes, but it requires programming or scripting to build and execute the requests. The scenario explicitly asks for a no-code method, so the API is technically capable but not the appropriate choice. It also demands OAuth setup and request handling that a typical administrator would not use for a simple spreadsheet update.

Google Workspace Admin console bulk update tool

Why it fails: The Admin console allows bulk updates only for a limited set of fields, such as moving users between organizational units or changing license assignments, and it does not support arbitrary custom attributes like employee ID. It also does not provide a spreadsheet-driven workflow for editing multiple directory fields simultaneously, so it cannot satisfy this scenario.

Google Workspace Directory Sync (GCDS)

Why it fails: Google Cloud Directory Sync is designed to synchronize users and groups from an external LDAP directory such as Active Directory into Google Workspace. It does not read from Google Sheets or let an administrator manually edit department and employee ID values in a spreadsheet. Using GCDS here would require changing the source LDAP data, which is not the requested method.

Use the Admin console to manually create each user account.

Why it fails: Manual creation in the Admin console is impractical for a large organization and does not provide automated synchronization with an HR system. It cannot propagate changes such as suspensions or updates automatically, so it fails to meet the requirement of scalable, hands-off provisioning.

Use Google Workspace Migration for Microsoft Exchange (GWMME) to provision users.

Why it fails: GWMME is a tool for migrating email, calendar, and contact data from Microsoft Exchange to Google Workspace. It does not handle ongoing user provisioning or synchronization of directory data, so it is not suitable for automating account lifecycle management.

Use the Directory API to create users programmatically.

Why it fails: The Directory API allows programmatic user creation, but it requires you to build and maintain a custom application that detects changes in the HR system and calls the API. This adds development overhead and does not provide out-of-the-box synchronization, so it is not the best method for automated provisioning at scale.

Delete the user account and rely on the 30-day recovery window to restore it if needed.

Why it fails: Deleting the account removes it and starts a recovery period, but the mailbox may not be available in the same way during that time, and the user is no longer suspended. This does not satisfy the requirement to stop delivery while retaining access for a delegate during a defined window.

Move the user to a suspended Organizational Unit (OU) that has Gmail turned off for all members.

Why it fails: Turning off Gmail for an OU affects service availability for all users in that OU and does not target a single suspended user. It also does not preserve mailbox access for a delegate in the way suspension does, making it the wrong approach for this scenario.

Archive the user in the Admin console, which moves the mailbox to a Google Vault archive and removes the user from the directory.

Why it fails: Archiving a user preserves their data and removes the account from the main directory view, but it is a separate state from suspension and is typically used after a user has left. It does not serve as the first step to stop new mail delivery for a suspended user in the described scenario.

A user can belong to multiple OUs simultaneously.

Why it fails: A user can belong to only one OU at a time. This is a fundamental rule of Google Workspace directory structure. If a user needs access to resources from multiple departments, you use groups instead. Allowing multiple OU memberships would complicate policy inheritance. This statement is false.

The root OU cannot have child OUs.

Why it fails: The root OU is the top-level container and can have child OUs. In fact, all OUs are descendants of the root OU. You can create multiple levels of OUs under the root. This statement is false because the root OU can and often does have child OUs.

Moving a user between OUs automatically updates their group memberships.

Why it fails: Moving a user between OUs does not affect their group memberships. Groups are independent of OUs. A user can be in a group regardless of their OU. This statement is false because group memberships are managed separately.

Configure a Google Group with automatic membership via a Google Workspace Directory sync.

Why it fails: Directory sync tools like GCDS or Microsoft Entra Connect can sync group memberships from an external directory, but they do not automatically add users to Google Groups based solely on OU membership within Google Workspace. This would require an external source of truth and additional configuration, not a native Google Workspace solution.

Create a dynamic group with a membership query based on the user's organizational unit.

Why it fails: Dynamic groups in Google Workspace are not natively supported for automatic membership based on organizational unit. While dynamic groups exist for some Google Groups, they rely on email addresses or domains, not OU membership. This approach would not automatically add users to the group upon creation, and would require manual updates or external scripting.

Use the Admin console to set up a default group membership for the Sales OU.

Why it fails: The Google Workspace Admin console does not provide a built-in feature to automatically assign group memberships based on organizational unit. While you can manage group memberships manually or via API, there is no native 'default group' setting for OUs. This method would not achieve the desired automation and consistency.

The organisational unit column must reference the OU by its full path starting with a forward slash.

Why it fails: The Org Unit Path column accepts the OU path, but a leading forward slash is not mandatory and the importer also accepts the OU name alone when it is unambiguous. Requiring the slash format would reject otherwise valid files and is not a documented constraint of the bulk uploader.

The CSV must be encrypted with a PGP key that Google can decrypt during import.

Why it fails: Bulk user uploads accept plain UTF-8 CSV files through the Admin console; no PGP encryption layer is involved. Encryption is used for other data-transfer scenarios, but requiring it here would block every normal onboarding workflow and is not part of the documented upload requirements.

Each row must include the user's password in plain text so that Google can hash and store it.

Why it fails: Passwords are optional in bulk uploads. If omitted, the account is created without a password and the administrator must trigger a reset or use a temporary password workflow. Supplying plain-text passwords in a spreadsheet is also a poor security practice and is not required for the import.

Configure an MX record for example.net that points to Google's mail servers.

Why it fails: While MX records are necessary for email delivery, when adding a domain alias, Google Workspace automatically handles the MX configuration for the alias domain after verification. You do not need to manually add MX records for the alias; Google sets them up as part of the alias configuration process.

Create a new user account for each user with the example.net domain.

Why it fails: Domain aliases do not require creating separate user accounts. Users automatically receive email at both the primary and alias domains. Creating duplicate accounts would be redundant and could cause confusion, as each user would have two separate mailboxes.

Set up a catch-all address for example.net to forward to example.com.

Why it fails: A catch-all address is used to capture email sent to non-existent addresses, but it is not required for domain aliases. Domain aliases automatically map existing users to the alias domain, so a catch-all is unnecessary and would not provide the desired one-to-one mapping.

In the Admin console, go to Directory > Users > Sales OU and enable 'Extended audit log retention' for each user in the OU.

Why it fails: There is no per-user 'Extended audit log retention' setting in the user directory. Audit log retention is configured at the organizational unit level under Reporting, not on individual user profiles. Enabling such a fictitious setting would not change retention and would leave the compliance requirement unmet.

In the Admin console, go to Security > Access and data control > Data protection, and create a rule that applies to the Sales OU and retains login audit events for 12 months.

Why it fails: Data protection rules do not control audit log retention for login events; they are designed for content like Drive and Gmail. Login audit events are managed by the audit log retention settings found under Reporting, not by data protection rules. This option misplaces the control and would not meet the requirement.

In the Admin console, go to Security > Access and data control > Data protection, and create a rule for the Sales OU that sets retention to 12 months for Drive files.

Why it fails: Data protection rules govern Drive file retention and sharing, not sign-in audit logs. They cannot extend the retention of login events, which are stored in the Reports API audit log. Applying a Drive retention rule would not satisfy the compliance requirement for sign-in activity and would be the wrong data domain entirely.

Super Admin

Why it fails: Super Admin grants full access to all Google Workspace services and settings, including billing, security, and all organizational units. This violates the principle of least privilege because it gives the user far more permissions than needed to manage users and groups in a single OU. It is not appropriate for delegated administration with limited scope.

Help Desk Admin

Why it fails: The Help Desk Admin role is designed to reset passwords and perform other limited user support tasks, but it does not include the ability to manage groups or user accounts beyond password resets. It would not allow the user to create or modify groups, so it does not meet the requirement of managing both users and groups within an OU.

Services Admin

Why it fails: The Services Admin role allows management of service settings for the entire organization or specific OUs, such as enabling or disabling services like Gmail or Drive. It does not include permissions to manage user accounts or groups, so it is irrelevant to the task of delegating user and group management within an OU.

A Google Group that includes those users, with GCDS configured to ignore group members

Why it fails: Google Groups are used for mailing lists and access control, not for protecting accounts from directory synchronization deletions. GCDS does not use group membership to decide whether to delete a user. Configuring GCDS to ignore group members is not a supported mechanism for preventing deletion, so this option does not achieve the goal.

Exclusion rules that filter out those users from the synchronization scope

Why it fails: Exclusion rules prevent users from being synchronized at all, but they do not protect already-synchronized users from deletion. If a user is excluded, GCDS may treat them as no longer in scope and delete them, depending on settings. Exclusion rules are about what to sync, not about preserving existing accounts, so they do not solve the deletion risk.

A Google Workspace organizational unit that contains only those users

Why it fails: Organizational units control policy application and do not affect GCDS deletion behavior. Placing users in a specific organizational unit does not prevent GCDS from deleting them when they vanish from the LDAP source. The deletion policy in GCDS is the relevant setting, not the organizational unit structure, so this approach does not meet the requirement.

In the Admin console, go to Domains, select 'newdomain.com', and click 'Set as primary domain'.

Why it fails: The Google Workspace Admin console does not provide a direct option to promote a secondary domain to primary. While you can add and manage domains, changing the primary domain requires a specific process that involves removing the current primary domain or using the domain switch feature, which is not as simple as clicking a button. This option is incorrect because it misrepresents the available functionality.

Contact Google Workspace support to change the primary domain, as it cannot be done self-service.

Why it fails: Changing the primary domain is a self-service operation in the Google Workspace Admin console. Administrators can perform this task without contacting support, as long as the secondary domain is verified and meets the requirements. This option is incorrect because it suggests that support intervention is required, which is not the case.

Remove the secondary domain 'newdomain.com', then add it as the primary domain after removing 'example.com'.

Why it fails: Removing and re-adding domains is not the correct method and can cause service disruptions. You cannot simply remove the primary domain without first assigning a new primary. The proper process involves using the 'Change primary domain' feature in the Admin console, which allows you to switch the primary domain to an existing secondary domain without removing it.