Hard Difficulty Questions

Security > Compliance > Gateway

Why it fails: Gateway sits under Apps > Google Workspace > Gmail, not Security > Compliance, so no outbound routing rule can be created here. It is tempting because Security holds alert centre and dashboard tooling, which would be the right area for threat investigation, not mail flow configuration.

Apps > Google Workspace > Gmail > Compliance

Why it fails: Gmail compliance settings host content compliance, objectionable content and attachment rules, which act on message content rather than routing mail to an external host. It tempts because compliance is where outbound filtering lives, but the correct choice is the Gmail routing setting specifying the gateway as smart host.

Account > Network > SMTP relay

Why it fails: SMTP relay under Account > Network authenticates and relays mail from devices and scanners through Google's servers; it does not redirect user mail to a third-party gateway. It tempts because relay configuration involves external hosts, but the correct setting is Gmail routing with the gateway as the outbound smart host.

Account > Security > App access

Why it fails: App access controls which third-party OAuth apps users may grant, not scopes for a service account. It is tempting because it governs OAuth authorisation, and it would be correct for restricting marketplace app access for human users rather than service-account API scopes.

Directory > Users > Service Accounts

Why it fails: Directory > Users holds human user accounts and cannot register service accounts or their scopes. It is tempting because it manages identities, and it would be correct for creating or editing a person's profile and organisational attributes, not for API authorisation.

Apps > Google Workspace > Gmail > API

Why it fails: Gmail > API settings govern end-user access to Gmail services, not service-account OAuth scopes. It is tempting because it sits under Gmail administration, and it would be correct for enabling or disabling Gmail API access for the domain's users rather than configuring a service account.

Enable two-step verification for the user and require it immediately.

Why it fails: Enabling two-step verification is a good security practice, but it does not prevent failed login attempts that cause lockouts. The attacker could still attempt to sign in with the correct password (if compromised) and be prompted for a second factor, but the failed attempts would be logged. Lockouts occur before the second factor. This does not mitigate the immediate lockout issue.

Temporarily suspend the user's account to stop the lockouts.

Why it fails: Suspending the account would stop the lockouts, but it also prevents the legitimate user from accessing their account. This is a drastic measure that should be used only if the account is confirmed compromised and immediate containment is necessary. It does not address the root cause and disrupts the user's work. The administrator should first investigate before taking such action.

Reset the user's password and enforce a password change at next login.

Why it fails: Resetting the password might temporarily stop the lockouts if the attacker is using the old password, but if the attacker is just trying random passwords, lockouts will continue. Also, the user is not attempting to sign in, so the lockouts are likely due to an external attack. Resetting the password does not address the source of the failed attempts. It is a reactive measure, not the first step.

Create a content compliance rule that adds a header to matching messages.

Why it fails: A content compliance rule can add headers or route messages, but it cannot inspect message bodies for a pattern and hold them for review. It is designed for routing and labeling decisions, not for quarantining content matches, so it would not satisfy the quarantine requirement.

Add the pattern to the blocked senders list in Gmail settings.

Why it fails: A blocked senders list rejects mail from specific addresses; it does not evaluate message content for patient identifiers. This would only stop known bad senders and would allow internal or external messages containing identifiers to be delivered, so it does not meet the requirement.

Use an attachment compliance rule to reject messages with matching attachments.

Why it fails: Attachment compliance rules apply only to attachments, not to message body text. Patient identifiers often appear in the body, so this rule would miss the majority of cases and would not reliably quarantine matching messages for review.

DLP policy

Why it fails: A DLP policy inspects content to prevent sharing of sensitive data across Gmail and Drive; it never evaluates the connecting IP address, so it cannot restrict Admin Console access. DLP is correct when the requirement is detecting and blocking exposure of regulated or confidential information.

2-Step Verification

Why it fails: 2-Step Verification strengthens authentication by requiring a second factor, but it does not evaluate the source network, so a user authenticating from any IP address still reaches the Admin Console. It is the right control for protecting against compromised passwords, not for enforcing IP-based access restrictions.

Vault access settings

Why it fails: Vault access settings govern retention, holds, and search permissions over Vault data; they do not gate Admin Console sign-in by network origin. Vault is the correct tool when the requirement concerns legal holds, eDiscovery, or controlling which users can access retained mail and Drive content.

The message size exceeds the limit.

Why it fails: A 550 5.7.1 response indicates the receiving server rejected the message on policy grounds, typically a relay or spam-filtering decision, not transport size. Oversized messages return a size-related code such as 552. Message size limits would be the cause when senders receive explicit maximum-size rejections.

The user's storage quota is exceeded.

Why it fails: Exceeding a storage quota blocks the user from sending or receiving at their own mailbox; it does not produce a 550 5.7.1 rejection from a remote domain, which is generated by the recipient's server. Quota problems are the cause when the affected user alone cannot send or receive any mail.

The recipient's mailbox is full.

Why it fails: A full recipient mailbox returns a mailbox-full code such as 552 or 452, not 550 5.7.1, which signals a policy rejection by the receiving server. Mailbox capacity is the cause when a specific recipient stops accepting mail while other addresses at that domain still receive messages.

Enable 'Advanced' mobile management for Windows devices in the Admin console.

Why it fails: Advanced mobile management is not available for Windows devices. Windows devices are managed via Endpoint Verification and Context-Aware Access, not through mobile management. Enabling mobile management for Windows would not enforce the extension requirement and is not a supported configuration.

Configure a device policy that blocks access to Google Drive unless the device is company-owned.

Why it fails: Device policies for mobile devices do not apply to Windows laptops. Blocking based on ownership would not verify the presence of the Endpoint Verification extension or its sync status. This approach would incorrectly restrict personal devices without addressing the actual requirement of extension verification.

Set up a SAML SSO profile that requires device certificate authentication for Google Drive.

Why it fails: SAML SSO profiles are used for third-party identity providers and do not natively check for the Endpoint Verification extension. Device certificate authentication is not a feature of Google Workspace for this purpose. This method would not validate the extension's presence or its sync status.

The user's computer operating system

Why it fails: The client operating system does not participate in SAML assertion exchange, so it cannot cause the signature, audience, or attribute errors that break sign-in. Troubleshooting checks the IdP configuration, certificate, and attribute mapping. It is tempting because OS-specific browser behaviour occasionally affects sessions, but that concerns local authentication, not SAML.

The user's physical location

Why it fails: A user's physical location plays no part in SAML assertion validation; errors arise from mismatched entity IDs, expired certificates, or incorrect attribute mappings between the IdP and service provider. It is tempting because geo-restrictions exist in some access policies, but those are enforced separately from the SAML protocol exchange.

The user must re-verify their identity

Why it fails: The migration renames the mailbox onto the primary domain and retains the account, so no identity re-verification step is triggered; re-verification applies when adding or confirming an alternate address. It tempts because users sign in with a changed address, but authentication continues with existing credentials.

Data is lost

Why it fails: Google Workspace migration renames the user's primary address while retaining mail, Drive content and calendar data, so nothing is deleted. It tempts because the old address stops receiving new mail, which looks like loss, but the data simply moves with the account.

The user is automatically suspended

Why it fails: Migrating a user to the primary domain renames the mailbox and preserves mail, so the account is not suspended; suspension is an administrative action taken for policy or billing reasons. It tempts because migration briefly interrupts access, but that transient state is not suspension.

Device management status is 'Managed'.

Why it fails: Device management status indicates whether the device is under management (e.g., enrolled in advanced mobile management or Chrome management), but it does not guarantee disk encryption. A managed device could still lack encryption. This condition would not enforce the encryption requirement and could allow unencrypted devices if they are managed.

Device operating system is 'Windows' or 'macOS' or 'Linux'.

Why it fails: Specifying operating systems does not check encryption. All three OS types can have encryption, but this condition would allow any device of those OSes regardless of encryption status. It does not enforce the encryption requirement and would not block unencrypted devices.

Device screen lock is 'Enabled'.

Why it fails: Screen lock status is a separate attribute from disk encryption. A device may have a screen lock but not have disk encryption enabled. Using this condition would not block unencrypted devices; it would only require a screen lock, which is insufficient for the encryption policy.

Grant 'Super Admin' privileges and restrict access using Context-Aware Access.

Why it fails: Super Admin grants every privilege, including password and organisational unit modification, which Context-Aware Access cannot subtract from an already-granted role. It is tempting because Context-Aware Access controls sign-in conditions, but it is an access-evaluation layer, not a privilege-scoping mechanism; a custom role with only the required Security Center privileges satisfies the stem.

Assign the 'Helpdesk Admin' role combined with 'Security Center Reader'.

Why it fails: Helpdesk Admin grants password-reset rights, directly violating the stem's prohibition on modifying user passwords. It is tempting because combining a helpdesk role with Security Center Reader appears to cover investigation and alert duties, but the correct custom role assigns only the specific Security Center and audit privileges without any user-management permissions.

Assign the built-in 'Security Admin' role and remove user management privileges via override.

Why it fails: Google Workspace built-in roles cannot be modified by removing individual privileges; overrides are not supported, so this approach is impossible. Security Admin suits broad security administration, but granular least-privilege requirements demand a custom role with exactly the needed privileges.

Force all files to be stored in a specific shared drive regardless of where the user creates them.

Why it fails: Google Workspace does not provide a setting that forces all user-created files into a specific shared drive. Shared drives are separate containers, and users choose where to create files. Administrators can control access to shared drives and set defaults, but they cannot redirect all file creation to one shared drive through sharing settings.

Set a maximum file size limit for uploads to Drive for the organizational unit.

Why it fails: Drive sharing settings do not include a maximum file size limit for uploads. File size limits are governed by the service itself and the user's license, not by sharing configuration. Administrators cannot set an arbitrary upload size cap per organizational unit through the sharing settings interface.

Require that all shared files be reviewed by an administrator before external sharing is allowed.

Why it fails: Google Drive does not provide a built-in approval workflow that routes external sharing requests to an administrator for review. While third-party tools or custom workflows might approximate this, the native sharing settings do not include an admin approval step. This is not a valid action in the Drive sharing settings for an organizational unit.

The account is suspended

Why it fails: Suspension does not place data in the global region; a suspended account retains its assigned region. It tempts because suspended users appear inactive in reports, but the actual cause is that the user is not covered by the policy — for example, they belong to an organisational unit outside its scope.

The user hasn't logged in recently

Why it fails: Login activity is irrelevant to region assignment; data location follows policy coverage, not recent sign-in. It tempts because inactive accounts often look misconfigured, but the real cause is that the user sits in an organisational unit the Data Region policy does not include, leaving their data in the global region.

Vault hold is preventing the move

Why it fails: Vault holds preserve data for legal retention; they do not pin data to the global region or block a region move. It tempts because holds restrict deletion, but the actual cause is that the user falls outside the Data Region policy's organisational-unit scope, so no region is applied.

Manually run a data export in Vault

Why it fails: Vault exports copy data out for eDiscovery; they do not relocate a user's stored data between regions. It tempts because Vault surfaces where data resides, but migration is triggered by changing the user's region assignment, which prompts Google to move existing data automatically.

Re-provision the user account

Why it fails: Re-provisioning deletes and recreates the account, losing the user's existing data rather than migrating it. It tempts because region assignment follows the account, but the actual trigger is updating the user's location in the Data Region policy, which initiates the move without deletion.

Contact Google Support to initiate a manual migration

Why it fails: Support cannot manually relocate a user's data between regions; the migration is automated once the user's region assignment changes. It tempts because support handles complex data-governance cases, but the correct action is reassigning the user's location in the Data Region policy, which triggers the move.

Groups Admin

Why it fails: Groups Admin can manage groups and group memberships, but does not have the ability to manage user accounts or reset passwords. This role is focused on group administration, not user lifecycle management. It would not fulfill the helpdesk team's required tasks.

Services Admin

Why it fails: Services Admin can turn services on or off for users and manage service settings, but cannot manage user accounts or reset passwords. This role is about service availability, not user administration. It would not provide the necessary permissions.

Super Admin

Why it fails: Super Admin has full access to all features, including Gmail content and security settings. Assigning this role would violate the principle of least privilege and grant far more access than needed. It is not appropriate for helpdesk staff.

Require a password change every 30 days for all users.

Why it fails: Forced 30-day rotation does not prevent unauthorised admin access; it often weakens passwords through predictable increments. Admin protection requires 2-Step Verification enforcement, super admin role limitation and recovery options. Password rotation would be correct where a compliance standard explicitly mandates periodic credential expiry.

Disable all non-Google apps in the Marketplace.

Why it fails: Marketplace app restrictions govern third-party OAuth access, not admin authentication. Unauthorised admin access is mitigated by enforcing 2-Step Verification, strong admin passwords and role scoping. Disabling Marketplace apps would be correct when the requirement is limiting third-party data access or OAuth scopes.

Set the 'Default storage' path in Apps > Google Workspace > Meet

Why it fails: Meet's Default storage setting only chooses Drive versus local recording storage; it cannot target a specific shared folder. It is tempting because it governs recording location, but folder-level automation requires a Drive API script or Workspace add-on reacting to recording creation.

Configure the 'Recording location' in Meet settings

Why it fails: Meet settings control where recordings are stored for the organiser's Drive, not a shared folder, and cannot target a specific shared drive location. It is tempting because recording location settings genuinely determine storage destination, which would be correct if recordings only needed to land in the organiser's own Drive.

Create a Drive retention policy for Meet

Why it fails: Drive retention policies govern how long files are kept before deletion, not where recordings are saved. It is tempting because retention rules genuinely manage Meet recording lifecycle and storage, and would be the right control if the requirement were automatic deletion after a set period.

The number of unread emails in the user's Gmail inbox.

Why it fails: Inbox unread counts are mailbox state, not a device, network, or user identity signal, so no Context-Aware Access access level can reference them. Gmail content filters are tempting because they govern mail handling, but access levels evaluate endpoint, IP, and identity attributes instead.

The user's local operating system password complexity and history length.

Why it fails: Context-Aware Access evaluates device, network, user and location attributes; local password complexity and history length are endpoint policy settings, not signals sent in access level expressions. It is tempting because password strength relates to authentication security, but that is enforced by device management, not Context-Aware Access.

The user's direct manager name listed in the directory schema.

Why it fails: Access level expressions evaluate device, IP, geographic and user-identity attributes; a manager's name from the directory schema is not one of the supported signals. It is tempting because directory data feeds user-based conditions, but manager relationships are organisational metadata, not a Context-Aware Access criterion.

Enable 'Force re-enrollment' to apply the version pin.

Why it fails: Force re-enrollment is used to require devices to re-enroll after being wiped or deprovisioned; it does not control update versions. Enabling it would disrupt users and not achieve version pinning. The update version is controlled by the auto update policy and release channel, not by re-enrollment.

Set 'Update policy' to 'Manual' and push updates via Google Admin console.

Why it fails: There is no manual update policy that lets you push specific ChromeOS updates from the Admin console. Updates are managed through the auto update policy and release channel. Setting updates to manual would prevent automatic updates entirely, which is not the goal here.

Configure 'Scheduled update window' to delay updates by 30 days.

Why it fails: A scheduled update window controls when updates are applied, not which version is installed. Delaying updates does not pin devices to a specific major version; they will still eventually update to the latest available version on the channel. This setting is useful for timing but not for version control.

Change the user's profile country to the United States, and the Data Region will automatically update to keep data in the EU.

Why it fails: Changing the profile country does not control Data Region placement. Data Regions are determined by the organizational unit's policy, not the user's profile location. The profile country is used for other purposes like localization, but it does not trigger data migration or change data residency.

No action is needed; Data Regions automatically follow the user regardless of their physical location.

Why it fails: Data Regions do not automatically follow the user. They are tied to the organizational unit and the policies applied to it. If the user's OU changes, the Data Region may change. Additionally, new data may be stored in the region where the user is located if the policy is not correctly applied. Therefore, action is required to maintain EU residency.

Disable Data Regions for the user, allow data to be stored globally, and then re-enable EU Data Region to force migration.

Why it fails: Disabling Data Regions would temporarily allow data to be stored globally, which violates compliance. Re-enabling might not automatically migrate existing data; a manual migration is required. This approach risks data being stored outside the EU during the disabled period, which is unacceptable.