Google Cloud Associate Google Workspace Administrator (GWS-ADMIN) (GWS-ADMIN) — Questions 76–150

Suspending rather than deleting users who disappear from the source directory preserves their data and allows recovery if the removal was a mistake. This setting directly addresses the requirement to avoid accidental data loss from source-side deletions while still reflecting legitimate departures by blocking their sign-in.

Placing contractors in a dedicated OU lets you apply an authentication policy scoped to that group alone, satisfying the requirement that only contractors are restricted. Within Security > Authentication > 2-step verification, limiting allowed methods to security keys enforces phishing-resistant hardware authentication, while employees in other OUs retain prompts and authenticator apps.

Suspending the account immediately invalidates active sessions and blocks further authentication, containing the suspected compromise before investigation. This satisfies the stem's requirement to prevent further unauthorised access, since password resets alone leave existing tokens valid.

Managed app installation depends on the device being enrolled and compliant, so verifying enrolment first confirms the device can receive configuration profiles and policies. Without enrolment, the management console cannot push the app or evaluate compliance, making this the logical initial check.

Context-Aware Access evaluates conditions like IP subnet and device management status before granting access to Google Workspace apps. By creating an access level that includes the corporate IP range and requires a managed device, then applying it to Gmail, the administrator can block all other access. This directly meets the scenario's need for granular, attribute-based control.

Configuring the SAML Single Logout URL in the SSO profile makes Google Workspace redirect the user's browser to the IdP's SLO endpoint on sign-out, terminating the IdP session. This directly satisfies the stem's requirement that IdP sessions also end.

Directory settings govern what profile fields users may edit themselves, such as name, photo, and phone number. This is configured per OU or group, directly satisfying the stem's requirement for items manageable through the Directory section.

A passcode policy in the iOS device management settings enforces encryption, satisfying the requirement that all corporate-owned iOS devices are encrypted. On iOS, setting a passcode automatically enables hardware-based data protection encryption; without a passcode, files remain unencrypted. No separate encryption toggle exists, so the passcode policy is the mechanism.

SAML application metadata supplies the entity ID, ACS URL and signing certificate that Microsoft Entra ID relies on when issuing assertions. Inspecting it verifies the service provider's configuration matches the trust established in Entra ID, directly satisfying the stem's requirement to check causes of SAML application errors.

The Admin console exposes each user's 2-Step Verification status under Directory > Users > [User] > Security, where enrolment state and enforcement details are shown. This path satisfies the stem's requirement to view enrolment status directly, without relying on reports or audit logs.

The service status being OFF for the user's organizational unit or access group prevents the SAML app from being served to that user, producing the 'app_not_configured_for_user' 403. Google Workspace evaluates service status per OU before SAML authentication, so users outside the enabled scope cannot access the app regardless of valid credentials.

Vault Admin is a predefined role that grants access to Google Vault for eDiscovery and legal holds, but does not include permissions to modify Workspace settings or access user passwords. It is specifically designed for legal and compliance teams who need to search and preserve data without administrative control over the Workspace environment.

Approved senders bypass the spam filter entirely, so messages from that sender are delivered rather than rejected. Adding the address to this allowlist directly resolves the rejection shown in the logs, satisfying the requirement to receive mail from the specific sender.

Chrome browser cloud management applies policies directly to signed-in browser instances, so enforcement works on unmanaged devices where you lack OS-level control. This satisfies the stem's constraint: securing Chrome without device management. Enrol browsers via a token, then push policies from the Google Admin console, independent of Microsoft Entra ID or Intune.

Data Migration Service transfers Drive files owned by the departing user to another user, satisfying the requirement to migrate their data. It preserves sharing permissions and folder structure during the transfer, unlike simple ownership reassignment or manual downloads. This makes it the appropriate tool for migrating a leaver's Drive content to a colleague.

Context-Aware Access access levels combine IP subnet conditions with device policy compliance, and assigning them to targeted apps enforces both constraints at access time. This satisfies the requirement that access occur only from managed corporate devices within the corporate IP range.

The Security Investigation Tool queries the same Drive log events but supports custom filters, nested conditions and bulk actions such as deleting or restricting sharing, letting an admin audit access and remediate in one place rather than only viewing raw entries.

Vault retention rules can cover Gmail messages, holding them for a set period or indefinitely regardless of user deletion. This satisfies the stem's requirement to name three supported data types, alongside Drive and Hangouts/Meet records.

Work profile data sharing settings block copy-and-paste and data transfer between the managed work profile and personal apps on Android devices, directly satisfying the requirement to prevent copying from managed apps into personal apps. This control operates at the OS profile boundary, unlike app-level policies that cannot restrict cross-app sharing on the device.

The Data Migration Service is designed to migrate email, calendar, and contacts from various sources, including Microsoft Exchange, into Google Workspace. It supports calendar migration, preserving recurring events and resource bookings, and runs server-side, minimizing user intervention. This aligns perfectly with the scenario's requirements.

The Account Activity report in the Admin Console exposes each user's recent security events, including sign-in timestamps, device details and access type. This directly satisfies the requirement to show a user their own login history, since the report surfaces authentication events tied to that specific account without needing separate audit log queries.

If the Calendar app lacks permissions for background data or storage, it may not sync properly. On Android, background data restrictions or battery optimization can prevent the app from syncing in the background. The administrator should check the app's permissions and ensure background data is allowed. This is a frequent cause of sync issues on mobile devices, especially after OS updates or battery-saving modes are enabled.

A secondary domain is a distinct domain added to a Workspace account that shares the same user directory and administrative console as the primary domain, satisfying the stem's requirement for a recognised domain type. Unlike a domain alias, it can host its own users and is treated as a separate domain for routing and identity.

Drive audit events in the Admin Console capture the actor, target file, recipient, and timestamp for external shares. By setting the log retention period for Drive to three years, the firm meets both the content and the retention requirement without exporting data to a third party.

Groups Admin grants domain-wide creation and management of Google Groups, including membership and settings, without conferring super admin or other service privileges. It satisfies the constraint of delegating group management across the entire domain while withholding full admin rights.

Email log search queries message delivery across all recipients, including external domains, and reports the delivery status per message. This satisfies the need to confirm whether a specific email reached an external address, which mailbox-level views cannot show.

The group resource's `name` field stores the group's display name, a core attribute returned by the Directory API. Satisfying the stem's requirement for a genuine group resource component, it is distinct from membership or metadata fields, and administrators rely on it to identify groups during provisioning and licence assignment.

The Directory API exposes programmatic user provisioning, and a service account authenticates without interactive consent, enabling event-driven automation via Pub/Sub or scheduled scripts. This satisfies the requirement to create accounts automatically in response to a specific trigger.

Endpoint Verification collects device attributes and reports them to Google. To enforce access based on those attributes, you must create an access level in Context-Aware Access that requires the device to be verified, and then assign it to the desired apps. This ensures only devices with a valid endpoint verification certificate can access Workspace apps.

The Endpoint Verification extension reports device attributes, including is_encrypted, to Google Workspace, letting Context-Aware Access evaluate encryption state in its access level conditions. Without that signal, the access level cannot determine whether a device meets the encryption requirement.

Creating the user account, setting its organizational unit to Sales, and assigning a license directly satisfies both requirements. The organizational unit placement controls policy inheritance and the license enables Gmail and other services. This is the standard workflow in the Admin console and ensures the mailbox is provisioned in the correct location with the right service access.

Selecting Services > Google Meet hardware grants only the privileges needed to manage Meet hardware devices and view their health, satisfying the least-privilege constraint. It excludes unrelated services, so the custom role cannot administer Gmail, Drive or other workloads.

The SPF record authorises the third-party gateway's sending IP addresses to send on the domain's behalf. If it omits the gateway, Google's receiving servers see unauthorised senders and flag messages as spam. Updating the SPF record to include the gateway satisfies the requirement that Google trusts mail routed through it.

Work profiles on Android create a separate, encrypted container where corporate apps and data reside, isolating them from personal apps. This satisfies the requirement to protect corporate data on mobile devices, since administrators can enforce policies within the work profile without touching personal content.

Context-Aware Access lets you define access levels based on device attributes, such as whether a device is company-owned and managed. By requiring these attributes, you ensure only corporate Windows laptops that are enrolled can access Workspace apps, effectively blocking personal devices. This is the correct approach for granular, identity-aware access control.

Managed Google Play hosts approved Android apps; selecting the app under Apps in the Admin console and assigning it to the target organisational unit scopes distribution precisely. This satisfies the requirement to deploy the application to a subset of users rather than the whole organisation.

Drive labels provide a structured way to classify files, such as marking them with sensitivity levels. When combined with DLP, labels can be automatically applied based on content. The label itself is a metadata field that can be used for policy enforcement and reporting, making it essential for the classification requirement.

A recent password reset invalidates existing refresh tokens, so the mobile client's cached credentials fail and mail stops syncing until re-authentication. This directly satisfies the stem's non-syncing device constraint, since Microsoft Entra ID revokes tokens on password change, forcing the profile to prompt for updated sign-in details.

Email Log Search queries Google's mail infrastructure directly, showing whether inbound messages from the vendor reached Google's servers and what happened afterwards. This satisfies the need to verify server-side delivery before investigating the recipient's mailbox or vendor-side sending issues.

When a device shows as 'Pending' in the Admin console, it means enrollment has not been completed. The user must open the Google Device Policy app and follow the prompts to finish enrollment. This app is required for advanced mobile management and ensures the device is properly registered and policies are applied, allowing access to work email and other services.

Gmail filters can automatically archive, delete, or label messages based on sender or subject. If the user has a filter that affects messages from the group's address, those messages may not appear in the inbox. The administrator should check the user's Gmail settings under Filters and Blocked Addresses. This is a common cause when group settings and spam filters are ruled out, as the issue is specific to the user's mailbox configuration.

Mobile sync halts when a device falls out of compliance: Google Mobile Management blocks Exchange ActiveSync and Drive access once policy checks fail, such as a missing passcode or failed device attestation. The reported loss of corporate data sync therefore points to a compliance-state change rather than a network fault.

The User accounts report lists each account's last login timestamp, letting you filter or sort for anyone inactive beyond 30 days. It directly satisfies the stem's requirement to identify dormant users from the Admin console's reporting section.

Shared drives are treated as separate entities and are not automatically covered by a Data Region policy applied to an organizational unit. If Finance users are creating files in a shared drive, those files will not be stored in the specified region unless the shared drive itself is explicitly included in the policy. This is the most likely cause.

The SMTP relay service accepts mail from allowed IP addresses, but it also requires either SMTP authentication with a valid Workspace account or explicit configuration to permit unauthenticated messages from those IPs. If the relay settings do not allow unauthenticated senders and no credentials are supplied, the server rejects the message with an authentication error, matching the symptom.

Google Vault provides eDiscovery for legal requests, letting administrators search Gmail, Drive, and Chat data by user, date, or term, then export results for litigation holds. It satisfies the stem's requirement to search and export user data specifically for legal requests, unlike standard Workspace admin tools that lack retention and export controls.

The Two-step verification enforcement setting is located under Security > Authentication in the Admin console. From there, you can set enforcement to 'On' for the entire organization or for specific organizational units, requiring users to enroll in 2-Step Verification. This is the correct control for mandating two-step verification across users.

Context-Aware Access lets you define access levels based on device attributes, such as whether the device is encrypted, has a screen lock, or is managed. If a user can access Drive from a laptop but not from a mobile device, a context-aware access level applied to Drive that requires certain device conditions is the likely cause. Checking this section is the correct first step.

Drive sharing options govern external sharing permissions for Google Drive content, letting administrators restrict files from being shared beyond the organisation's domain. This directly satisfies the requirement to prevent sensitive files leaving the organisation, since the setting controls whether users can grant access to external recipients.

Mobile devices must have an active internet connection to receive policy updates from Google's servers. If the device is offline or not syncing, new policies will not be applied. This is the most common and basic cause of policy not being applied, so it should be checked first before investigating more complex issues.

Force-installing apps and extensions via the Admin console ensures they are automatically installed and cannot be removed by users. This is the correct method to deploy essential apps to ChromeOS devices and prevent uninstallation, as the policy enforces installation and locks the apps in place.

Creating an access level alone does not enforce anything; it must be assigned to specific Google Workspace applications and scoped to an organizational unit. By assigning the device-based access level to Gmail and Drive for the desired organizational unit, the policy becomes active. Users on personal devices will be denied access, while managed devices meeting the criteria are allowed.

The most common cause of this error is that the user is signed in with a personal Google account instead of their Workspace account. The file is shared with the organization, so only the Workspace account has access. Checking the signed-in account is the quickest and most likely resolution. This directly addresses the access request prompt.

Shared drives are owned by the organization, not by individual users. By enforcing that files are created in a shared drive, you ensure organizational ownership. You can configure policies to restrict file creation to shared drives only. This meets the requirement that files remain owned by the organization even if the user leaves. This is the correct approach.

The security investigation tool allows you to search Drive audit logs by document ID and filter events such as view, and specify a date range. This provides a report of users who accessed the document, meeting the auditor's request. It is the appropriate tool for this level of detail.

When a file owner's account is suspended or the owner's Drive service is disabled, files owned by that user can become inaccessible to others even if permissions remain listed. Checking the owner's account status and Drive service enablement is a logical first step because it directly explains why previously shared files stopped working while other files remain accessible.

The error 'Service not enabled for this account' often indicates that the user lacks the necessary license to access the service. Even if Drive is enabled for the OU, the user must have a license that includes Drive, such as Google Workspace Business Standard or higher. If the user is unlicensed or has a license without Drive (e.g., a Cloud Identity Free license), they will see this error. Checking the user's license is the next logical step.

ExtensionInstallAllowlist specifies which extensions are permitted to be installed. When this policy is set, only extensions on the list can be installed, effectively blocking all others. This is a key policy for controlling extension installation and ensuring users can only add approved extensions. It works in conjunction with other extension policies to enforce a secure browsing environment.

Suspending the account immediately blocks all sign-in attempts, satisfying the requirement to revoke access without deleting the identity. Unlike deletion, suspension preserves the mailbox, OneDrive files and audit history for legal hold or handover, while Microsoft Entra ID tokens are invalidated on next refresh.

Disabling Google Meet at the OU level prevents contractors from using Meet while leaving the service enabled for other OUs. This satisfies the requirement to block Meet for the Contractors OU specifically and is a valid configuration step.

Chrome user policies allow administrators to enforce browser settings for users signed in to Chrome with their managed Google Account. You can set policies to block third-party cookies and prevent users from changing the setting. This is the correct location to enforce such a policy across the organization.

Data Region policies in Google Workspace apply to data at rest based on the user's assigned data region, not their physical location. Once a user is assigned to the EU data region, their existing and newly created Drive files are stored in the EU even when they access Drive from the US. No action is needed to maintain the region.

A custom admin role scoped to the Marketing OU grants management rights only within that organisational unit, satisfying the requirement to limit the user's authority to that OU alone. Built-in roles cannot be scoped this narrowly, so a custom role with OU scope is required.

Device details show sync status, last contact time, policy compliance and any blocked or wiped state for that Android work profile. Reviewing them first identifies whether the fault is device, policy or account related before further changes.

Restricting Admin console sign-in to trusted IP ranges blocks credential use from unauthorised networks, directly limiting where admin authentication can succeed. This satisfies the stem's goal of preventing unauthorised admin access by constraining the source network.

A Vault retention rule applies directly to Chat messages, satisfying the five-year retention requirement. Unlike Google Takeout exports or user-driven holds, Vault retention governs messages in place, preventing deletion until the specified period expires regardless of user action.

Assigning Security Center privileges for the Investigation Tool and Alerts plus Reporting audit log access grants the analyst the required visibility. Leaving User Management and OU privileges unchecked enforces least privilege, preventing password or organisational unit modifications.

The Admin console provides a user accounts report that includes last login information. An administrator can filter by organizational unit and sort or filter by last login date to identify users who have not signed in within 30 days. This directly answers the manager's question and is the appropriate administrative action.

Zero-touch enrollment allows you to pre-register ChromeOS device serial numbers with Google so that when the devices are first powered on and connected to the internet, they automatically enroll into your organization's domain. This eliminates manual enrollment steps and ensures devices are enterprise-managed from the start. It requires coordination with the device reseller or uploading serial numbers in the Admin console.

Context-Aware Access access levels can be assigned per app and per organizational unit. Applying the managed-device access level to Drive for the main OU blocks unmanaged access, while contractors in a separate OU without that access level can still use Gmail from personal devices, meeting both requirements.

Suspending a user in the Admin console immediately blocks sign-in and produces exactly this 'Account temporarily unavailable' error. Checking the account status there confirms whether the account is active, suspended or archived, which is the primary cause to verify before investigating password or device issues.

Google requires proof of ownership before a domain can be used. Adding the provided TXT record to the domain's DNS configuration verifies that the administrator controls the domain. Without verification, the domain remains unverified and cannot be used for user accounts or mail delivery. This step is mandatory for every new domain added to Google Workspace.

A verified secondary domain needs its own MX records before Google will accept inbound mail for it. Verification alone proves ownership but does not route mail, so without MX records for example.net, messages to the new hires bounce with a DNS error even though the accounts exist and can send outbound mail.

Security Center's dashboard surfaces recent security alerts alongside proactive recommendations, directly satisfying the stem's requirement to review both. Unlike the alert centre or investigation tool, which focus on triaging active incidents, the dashboard aggregates posture findings and remediation guidance, making it the correct first stop for improvement recommendations.

Because the partner users authenticate in their own domain, only their administrators can apply Context-Aware Access or device policies to their sign-ins. By sharing the folder with the partner domain and asking them to enforce managed-device access on their side, both organizations contribute the controls they each own, satisfying the requirement.