Troubleshooting practice questions

Admin Activity logs

Why it fails: Admin activity logs track changes made by administrators in the console.

OAuth token logs

Why it fails: While related, SAML application logs are more specific for SSO troubleshooting.

Drive Audit logs

Why it fails: Drive logs only track file-related activity.

Use the 'Restore' option in the User's Drive.

Why it fails: The user can restore their own items from the Trash, but admins can restore from the console.

Ask Google Support to restore the file.

Why it fails: Admins have the capability to perform this restoration without contacting support.

Recreate the folder manually.

Why it fails: This does not restore the original permissions or contents.

Google Drive sync tool.

Why it fails: Drive sync is separate from email/calendar sync.

Password reset tool.

Why it fails: Password issues are not related to sync delays.

Admin Console Reports

Why it fails: Reports do not show local GWSMO sync status.

The user's calendar sharing settings.

Why it fails: Sharing settings do not affect receipt of new invites.

The organization's MX records.

Why it fails: MX records affect general email, not specific calendar invites.

The user's password.

Why it fails: Password issues would prevent access to the entire account.

Check the Gmail Audit logs.

Why it fails: Gmail Audit logs record message delivery, admin actions and login events, not per-file storage consumption, so they cannot identify large Drive files. They would be the correct source when investigating suspicious sign-ins or deleted messages, but the storage report in Drive is what lists files by size.

Delete all files and re-upload.

Why it fails: Deleting and re-uploading every file destroys data without revealing which items consumed the quota, and the same files simply refill the storage. Bulk deletion is the right action only after the Drive storage report has identified obsolete large files you intend to remove permanently.

Use the Security Investigation Tool.

Why it fails: This tool is for security events, not storage analysis.

User's password

Why it fails: Password issues usually give 'Incorrect password' errors.

Domain's DNS records

Why it fails: DNS issues affect mail flow, not user sign-in.

User's mobile phone number

Why it fails: Phone numbers are for recovery, not sign-in status.

The user's browser is outdated.

Why it fails: Browser version does not govern group membership or access; Google Groups access depends on the user's membership and permissions, not client software. An outdated browser would be relevant only when a supported feature fails to render after the user already has access.

The group email is invalid.

Why it fails: An invalid group email address would prevent the group being created or mail being delivered, not block an existing group's access. The likely cause is that the user has not been added as a member, or the group's access permissions exclude them. Invalid addresses matter when provisioning or sending mail.

The group needs to be added to an OU.

Why it fails: Groups are not placed in organisational units; OUs contain users and control policy inheritance. A group's visibility and posting permissions come from its access settings and members. OU placement would matter for applying configuration or policies to user accounts, not for granting group access.

Confirm that the user has the 'Google Meet' app installed on their mobile device.

Why it fails: The Google Meet mobile app is not required to add a Meet link to a Calendar event on the web. The link generation is a server-side setting controlled by the Admin console and Calendar settings. Installing the app would not restore the missing link in Calendar events.

Check the user's Google Calendar sharing settings to ensure they have 'Make changes to events' permission.

Why it fails: Calendar sharing permissions affect access to calendars, not the ability to add Meet links to events. Since the user can create events and other users in the same OU can add Meet links, sharing settings are unlikely to be the cause. This option does not address the missing Meet link functionality.

Review the user's Google Drive storage quota to ensure they have not exceeded their limit.

Why it fails: Drive storage quota does not affect the ability to add Meet links to Calendar events. Meet links are generated independently of Drive storage. Even if the user is over quota, Calendar events can still be created with Meet links if the service is enabled. This is not a relevant troubleshooting step.

Ensure that the user has the 'Drive and Docs' service enabled for their OU.

Why it fails: If the Drive and Docs service were disabled for the user's OU, they would not be able to access any Drive content, not just this shared drive. Since other members can access the shared drive and the user presumably can access other Drive items, this is unlikely to be the cause. Checking service status is a broader step.

Check the user's Google Drive storage quota to ensure they have not exceeded their limit.

Why it fails: Storage quota does not affect access to shared drives. Users can access shared drives even if their personal Drive storage is full, as shared drive content does not count against individual quotas. This is not a relevant troubleshooting step for access denial.

Confirm that the shared drive is not set to 'Restricted' in the sharing settings.

Why it fails: The shared drive's sharing setting (Restricted vs. Anyone with the link) affects external sharing and link access, but internal members with explicit access can still access it regardless. Since the user is a member with Content manager access, this setting is not the cause of the access issue.

The external recipient's server is misconfigured and is incorrectly enforcing DMARC.

Why it fails: The error is explicitly a DMARC policy rejection, which occurs when the receiving server evaluates the message against the sender's published DMARC record. While a recipient server could have issues, the presence of a p=reject policy and missing DKIM strongly points to authentication failure on the sending side. Blaming the recipient does not address the root cause.

SPF is not aligned because the sending IP is not included in the domain's SPF record.

Why it fails: SPF misalignment can cause DMARC failures, but the scenario states DKIM is not configured. In DMARC, if either SPF or DKIM passes with alignment, the message passes. Without DKIM, SPF must pass and align. However, the most direct cause given the missing DKIM is that there is no authenticated path at all, so SPF alone may not be sufficient if the sending IP is not authorized.

The domain's DMARC record is incorrectly formatted, causing all messages to be rejected.

Why it fails: A malformed DMARC record would typically result in no DMARC policy being applied, not a rejection. The error indicates a DMARC policy rejection, meaning the record is being parsed and enforced. The issue is authentication failure, not record syntax. Formatting errors would more likely cause the record to be ignored.

Check the Google Workspace SMTP relay service settings to ensure the application's IP is allowed.

Why it fails: The SMTP relay service is used for sending mail from devices or applications that relay through Google's servers, but it requires configuration of allowed IPs. However, if the application is using SMTP authentication with the user's credentials, it is not using the SMTP relay service. This option is only relevant if the application is configured to use the relay service without authentication.

Verify that the user has 'Send email as' permission for the application's domain.

Why it fails: The 'Send email as' setting allows users to send from alternate addresses, but it does not affect incoming mail from an application. The issue is about not receiving emails, not sending. This setting is irrelevant to the problem of missing incoming notifications.

Verify that the application's sending IP address is included in the user's SPF record.

Why it fails: SPF records are used for authentication of incoming mail, not for outbound mail sent through Google Workspace. Since the application is sending via SMTP through Google Workspace, the sending IP will be Google's, and SPF is not relevant. This is not a valid troubleshooting step for outbound mail delivery.

The former employee's account is suspended rather than active, and Vault excludes suspended accounts from mail searches.

Why it fails: Vault does not exclude suspended accounts from searches. Suspended users can still be searched and their data exported, which is a common reason administrators suspend rather than delete accounts during litigation. If the account had been deleted, that could affect results, but the scenario states the account still exists. Suspension alone does not prevent Vault from finding the user's mail.

The former employee's account was moved to a different organizational unit that is not covered by the Vault matter's search scope.

Why it fails: Vault matters are not scoped by organizational unit membership at search time. A matter can search across all users regardless of their current organizational unit, provided the user still exists in the directory and Vault retention is enabled for the applicable service. Moving a user between OUs does not remove them from Vault search results, so this would not explain the empty results.

Google Vault was enabled after the messages were sent, so only messages sent after Vault was turned on are indexed and searchable.

Why it fails: Vault retains and indexes existing mailbox content once Vault is turned on for the organizational unit, including historical messages that were already in the mailbox. Vault does not only capture new messages going forward; it processes existing data as well. Therefore enabling Vault after the messages were sent would not by itself cause searches for that user's mail to return nothing.

The users are not assigned a Google Workspace license that includes Drive, so they cannot use external sharing features.

Why it fails: If the users lacked a Drive license, they would not be able to access Drive at all, including internal sharing. The scenario states internal sharing works fine, which confirms the users have the necessary licenses and Drive access. License issues would typically produce a different error, such as 'You do not have permission to access this service,' and would affect all Drive functionality, not just external sharing.

The domain-wide setting for external sharing in the Google Admin console under Apps > Google Workspace > Drive and Docs > Sharing settings is set to 'Off' for the top-level organizational unit, and the child OU inherits that restriction.

Why it fails: If the top-level OU had external sharing off and the child OU inherited it, the admin would see that setting reflected when checking the child OU's effective policy. The admin already confirmed the child OU is set to 'On' for external sharing, so inheritance from a parent OU is not the issue. Additionally, in Google Workspace, a child OU's explicit setting overrides a parent's setting, so even if the parent were off, the child would still allow sharing.

The external partners are using a different Google Workspace domain, and cross-domain sharing is blocked by a default security setting that requires domain verification.

Why it fails: Google Workspace does not block cross-domain sharing by default; external sharing is controlled by the sharing settings in the Admin console. While domain verification can be used for trusted domains, it is not a requirement for sharing. The error described indicates a policy restriction, not a verification issue. The admin already confirmed the OU's sharing setting is 'On,' so a hidden default block is unlikely.

The partner domain is on the blocked senders list, preventing Drive shares from that domain.

Why it fails: Blocked senders lists in Gmail affect email delivery, not Drive sharing permissions. A blocked sender entry would stop Gmail messages from that domain but would not cause a Drive file shared with the user to appear yet be unopenable. The symptom described is a Drive access-control behaviour, not an email filtering behaviour.

The Drive sharing setting for the organizational unit is set to 'Off', blocking all external sharing.

Why it fails: If Drive sharing were turned off entirely for the organizational unit, users would not see the partner's files listed under 'Shared with me' at all, and they could not have received the share notification. The scenario shows the files are visible, so the block is more specific than a blanket sharing restriction and must target external content.

The user's Google Workspace license does not include Drive, so external files cannot be opened.

Why it fails: A license without Drive would prevent the user from using Drive at all, including seeing the 'Shared with me' list. Since the user can browse Drive and see shared files, the license clearly includes Drive. The failure occurs only when opening content owned by an external domain, pointing to a sharing policy rather than a licensing gap.

Check the user's Google Workspace Calendar sharing settings to ensure external sharing is allowed.

Why it fails: External sharing settings control whether calendars can be shared outside the organization, not whether internal shared calendars sync to a mobile device. The scenario involves shared calendars, but they are likely internal. External sharing is not relevant to sync issues for internal calendars.

Verify that the user's Google Workspace account has Google Calendar enabled as a service.

Why it fails: If Google Calendar were disabled for the user's organizational unit, the user would not have access to Calendar at all, not just missing events on mobile. The scenario implies the user has Calendar access. This is a basic service check that is unlikely to be the issue when only some events are missing.

Confirm that the user's mobile device has a stable internet connection and is not in battery saver mode.

Why it fails: While connectivity and battery saver can affect sync, the scenario specifically mentions missing events from shared calendars. If other calendars sync, connectivity is likely fine. Battery saver might delay sync, but it would not selectively omit specific calendars. This is a general troubleshooting step, but not the most targeted for this issue.

The user has exceeded the maximum number of devices allowed for their account.

Why it fails: Google Workspace does not impose a limit on the number of devices a user can sign in from by default. Mobile device management policies may control access, but a simple device count limit is not a standard restriction. This is unlikely to be the cause unless a specific policy is in place.

The user's Google Workspace password has expired and must be changed.

Why it fails: If the password had expired, the user would be unable to sign in from any device, including the laptop. Since they can sign in on the laptop, the password is valid. Password expiration is not the cause of this mobile-specific issue.

The user's account requires a security key for two-step verification, and the mobile device does not support it.

Why it fails: If the user's account requires a security key, they would also need it on their laptop. Since they can sign in on the laptop, this is not the cause. The issue is specific to the mobile device, so security key requirements are not the likely culprit.

The user's password has expired and they need to reset it.

Why it fails: If the password expired, the user would not be able to sign in to send email either. Since they can send email, authentication is working. Password expiration would affect both sending and receiving. This is not a plausible cause for the described symptoms.

The user's Gmail storage is full.

Why it fails: If storage is full, the user typically cannot send or receive new email, but they can still receive some messages if there is space. However, the user can send email, which suggests storage is not completely full. Also, storage full usually results in a specific error message. This is less likely than a mail routing issue.

The user has a Gmail filter that is archiving all incoming messages.

Why it fails: A filter could archive messages, but the user would still see them in All Mail. If the user checks All Mail and sees nothing, a filter is not the cause. Also, filters are user-specific and would not affect internal delivery unless set up that way. This is possible but not the most likely cause.

The user's account is not verified, so they cannot access external files.

Why it fails: Account verification is not a standard Google Workspace requirement for accessing external files. Users can access shared files as long as their account is active and policies allow. Verification typically relates to domain ownership or billing, not file access. This is an unlikely cause.

The file is in a shared drive that the user is not a member of, and the shared drive restricts access to members only.

Why it fails: If the file is in a shared drive with restrictions, the user would need to be a member. However, the scenario states the file is shared with the user's email address, which typically grants access if the user is not a member, unless the shared drive has specific restrictions. But the more likely cause is cross-domain policy, as shared drive membership issues would be indicated by a different error.

The user's Google Drive storage is full, preventing them from opening shared files.

Why it fails: A full Google Drive affects uploading and creating files, not opening shared files. Shared files do not count against the recipient's storage quota. The error would be about storage, not access. This is a common misconception about how Drive storage works.

Disable the 'Automatically add invitations to my calendar' setting for all users.

Why it fails: That setting governs whether invitations are added to the recipient's calendar automatically, not whether the invitation email is classified as spam by the receiving system. Turning it off would change user-facing behaviour within Workspace but would not alter the authentication or reputation signals that cause an external system to mark the message as junk.

Publish a DMARC record with a p=reject policy to force recipients to trust the domain.

Why it fails: A stricter DMARC policy does not fix calendar invitation deliverability and can worsen it if the calendar sending path does not align with the domain. DMARC p=reject tells receivers to reject unaligned mail, so if calendar messages are sent via a Google path that does not align, they would be rejected rather than merely marked as spam. The scenario already states DMARC is published and passing.

Add the recipient domain to the Workspace email allowlist so invitations are delivered.

Why it fails: An allowlist entry in Workspace controls inbound mail filtering for the administrator's own domain, not how external receivers treat outbound calendar invitations. The recipient's spam decision is made by the recipient's mail system based on authentication and reputation, so changing the sender's inbound allowlist has no effect on the reported problem and misdirects troubleshooting.

The domain's SPF record for Google Meet.

Why it fails: SPF records are used for email authentication and have no role in Google Meet video calls. Meet uses WebRTC and other protocols for real-time communication, not email. The error occurs when joining a call, not when sending or receiving email. Checking SPF records would not address the Meet join failure and is not a relevant troubleshooting step.

The user's Google Calendar sharing permissions.

Why it fails: Calendar sharing permissions control access to calendar events, not the ability to join a Meet call. Even if the user cannot see the event on their calendar, they can still join a Meet call via a direct link if external sharing is allowed. The error occurs when clicking the link, indicating a Meet access issue rather than a calendar visibility problem. Checking calendar sharing would not resolve the Meet join failure.

The user's Gmail delegation settings.

Why it fails: Gmail delegation allows another user to access a mailbox, but it has no impact on Google Meet participation. Delegates can send and read email on behalf of the user, but they do not affect video call access. The error is specific to joining a Meet call, not email access. Checking delegation settings would not resolve the issue and is irrelevant to the scenario.