Core Workspace Services practice questions

Apps > Google Workspace > Calendar > Settings

Why it fails: Meet link insertion is controlled under Apps > Google Workspace > Calendar > Sharing settings, not the general Calendar settings page. It tempts because that page holds calendar-level defaults, but the automatic video conferencing toggle sits in sharing settings.

Security > Calendar > Video call settings

Why it fails: This path is incorrect.

Apps > Google Workspace > Calendar > Sharing options

Why it fails: Sharing options control resource availability, not Meet links.

Modify the OU policy in Apps > Google Workspace > Meet

Why it fails: The Apps > Google Workspace > Meet route hosts recording, streaming and dial-in settings, not participant caps; the participant limit sits under Google Meet > Meet video settings within the OU. It is tempting because it is the OU-level Meet policy location, but it governs the wrong settings family.

Use a group policy for Meet access

Why it fails: Group policies govern service access and feature availability for members, not per-meeting participant counts, and groups do not map to organisational units. It is tempting because groups commonly restrict who may use Meet, but that scenario concerns enabling or disabling access rather than capping session size.

Set 'Participant limit' in the Meet settings

Why it fails: No standalone 'Participant limit' control exists in Meet settings; the cap is configured through the Meetings and recordings maximum participant count within the OU's Meet video settings. It is tempting because it names the desired outcome directly, but the setting as described is not a real admin console field.

7 days

Why it fails: Seven days is the standard trash retention for Drive, but administrators can restore files for up to 25 days after a user empties trash, so 7 days understates the maximum. It tempts because it matches the default user-visible trash window, not the admin recovery limit.

30 days

Why it fails: Thirty days exceeds the actual admin recovery window; Google Workspace administrators can restore deleted Drive files for up to 25 days after the user empties trash, not 30. It tempts because 30 days is a familiar retention figure, but the documented maximum is 25 days.

Unlimited

Why it fails: Restoration is time-limited.

Security > Authentication > Email verification

Why it fails: This path does not exist.

Account > Settings > Domain verification

Why it fails: Domain verification is for proving ownership, not configuring email security protocols.

Security > Data protection > Gmail

Why it fails: This section handles Data Loss Prevention (DLP) rules, not authentication.

Google Cloud Storage Transfer Service

Why it fails: Cloud Storage Transfer Service moves objects between buckets and file systems, not Gmail messages or Calendar events. It is tempting because it is Google's general-purpose data migration tool, and would be correct for migrating Drive or Cloud Storage content between accounts.

GAM (Google Apps Manager)

Why it fails: While possible, it is a third-party command-line tool, not the official service.

Vault

Why it fails: Vault retains and searches data for eDiscovery and legal holds; it does not transfer mailbox or calendar content into another user's account. It is tempting because departed-employee data lives there, and Vault would be correct for searching or exporting that data for litigation.

Apps > Google Workspace > Directory > Calendar

Why it fails: Directory > Calendar holds calendar sharing and external sharing settings, not resource inventory. It is tempting because Directory is where many Workspace-wide defaults live. Building resources are created under Apps > Google Workspace > Calendar > Resources, which this path omits.

Apps > Google Workspace > Calendar > Resources

Why it fails: Resources are managed under the Directory section, not directly in Calendar settings.

Organization > Settings > Resources

Why it fails: Organization > Settings > Resources does not exist as a resource-creation path in the Admin console; organisation-level settings cover policies, not calendar inventory. It is tempting as a central admin location. Calendar resources are added under Apps > Google Workspace > Calendar > Resources.

Security > Authentication > SPF

Why it fails: SPF records authenticate outbound sending domains; they do not block mail to a recipient domain or control routing. It is tempting because SPF failures do cause delivery rejections, and it would be correct when diagnosing why your own domain's messages fail authentication checks at the receiving end.

Apps > Google Workspace > Gmail > Compliance

Why it fails: Compliance settings govern content rules such as attachment and objectionable-content filtering, not outbound routing or domain blocklists. It is tempting because it is the Gmail area covering message restrictions, and would be correct when configuring content compliance rules that quarantine or reject messages matching specified expressions.

Security > Gmail > Routing

Why it fails: Routing settings control inbound and outbound delivery paths, including whether messages to a domain are rejected or rerouted. It is tempting because routing rules can block a domain, but the question asks where blocklists and routing issues are checked, which is the Blocked senders and Routing tabs under Apps > Gmail > Spam, not Security.

Apps > Google Workspace > Marketplace > Settings

Why it fails: This manages general Marketplace access, not specific API scopes.

Security > App access control

Why it fails: While related, the specific API controls for Drive scopes are found within API controls.

Apps > Google Workspace > Drive > API settings

Why it fails: This path does not exist.

Configure 'External participation' in Meet settings

Why it fails: The External participation setting controls whether external attendees may join at all, not whether a PIN is demanded of them. It is tempting because it governs external access, which sounds adjacent to the requirement. Enforcing a password/PIN for external participants requires the Meet safety settings that mandate host or meeting codes for external joiners.

Require 'Admin approval' for all meetings

Why it fails: Admin approval governs who may create or join meetings under moderated access policies; it does not attach a password or PIN to each session. It is tempting because approval gates external access, appearing to secure meetings. Requiring a PIN for external participants is enforced through the Meet safety settings that mandate meeting codes.

Enable 'Meet Entry PIN' in Meet settings

Why it fails: Meet Entry PIN applies only to dial-in phone participants, not external video joiners, so it cannot enforce a PIN for them. It is tempting because it genuinely gates meeting entry, but only for PSTN callers — the correct control is host management requiring external participants to ask to join.

Security > Meet > Calendar sync

Why it fails: This path does not exist.

Apps > Google Workspace > Calendar

Why it fails: Calendar settings don't handle Meet link auto-generation.

Apps > Google Workspace > Directory

Why it fails: This manages contacts, not Meet settings.

Reports > Audit > Drive

Why it fails: Reports > Audit > Drive only shows historical activity events such as who moved or deleted a drive; it cannot restore anything. It is tempting because the audit log identifies the culprit and timestamp, but recovery requires the Shared drives management view under Drive and Docs, not the reporting section.

Directory > Groups > Shared Drives

Why it fails: Groups holds membership and permission settings, not trashed shared drives, so no restore control exists there. It is tempting because shared drive administration lives under Directory, yet restoration sits in the separate Shared drives view reached from Drive and Docs, where deleted drives are listed and recoverable.

Security > Data > Restore

Why it fails: Security > Data covers alert centre, classification and data protection controls, not Drive trash recovery, so no shared drive restore exists there. It is tempting because Security sounds like the admin recovery area, yet trashed shared drives are restored from the Drive and Docs > Shared drives view instead.

Apps > Google Workspace > Settings

Why it fails: Apps > Google Workspace > Settings governs service availability and per-app features, not account addition on managed devices. It is tempting as the central Workspace policy console, but blocking personal accounts requires the device-level setting under Directory > Devices > Mobile & endpoints, not app configuration.

Directory > Users > Device settings

Why it fails: Directory > Users > Device settings configures per-user device policies such as screen lock and wipe, not whether personal Google accounts may be added. It is tempting because it is user-scoped device management, but the personal-account restriction lives under Directory > Devices > Mobile & endpoints.

Security > Account > Personal account restriction

Why it fails: Security > Account > Personal account restriction does not exist as a Google Admin console path; personal account blocking is configured under Directory > Devices > Mobile & endpoints. It is tempting because the name matches the requirement exactly, but no such Security menu location exists.

Recordings are deleted automatically after 7 days

Why it fails: They are kept until deleted or archived.

All participants receive a copy in their Drive

Why it fails: Only the organizer's Drive receives the file.

Recordings are stored in a global Meet storage bucket

Why it fails: This is not how Google Workspace storage works.

Automate password changes for migrated accounts

Why it fails: The Data Migration Service transfers mail, calendar and Drive data; it does not set or change user passwords, which remain managed in the Admin Console or via the directory. Password automation belongs to provisioning or identity sync tooling, not migration.

Migrate Drive files to a specific shared drive

Why it fails: The Data Migration Service migrates Drive content only into a user's My Drive; it cannot target a specific shared drive, which requires Drive-level migration tooling or manual transfer. It is tempting because Drive migration is supported, but the destination scope is the limiting factor.

Sync browser bookmarks for migrated users

Why it fails: The Data Migration Service handles mail, calendar, contacts and Drive files; browser bookmarks are not a supported data type and are instead synced through Chrome user profiles. Bookmark sync is tempting because it is user data, but it sits outside the migration service's scope.

Force user to use specific email client

Why it fails: Gmail security settings govern transport, authentication, and content handling; client choice is a user preference, not an enforceable Admin Console security control. It is tempting because client restrictions exist for other services, but Gmail permits IMAP, POP, and web access configuration rather than forcing a specific client.

Automatic email deletion after 30 days

Why it fails: Retention governs how long messages are kept, not a security control; Admin Console retention rules set periods up to custom limits rather than a fixed 30-day automatic deletion. It is tempting as a data-hygiene measure, but it would be correct under compliance retention policy configuration.

Export all of the CEO's mail to a drive and store it for 7 years.

Why it fails: Exporting is a manual process and does not automatically retain future messages. It also does not prevent deletion from the mailbox. A retention rule is the automated way to ensure ongoing retention for the specified period.

Create a matter and add the CEO as a custodian, then set a hold on all their mail.

Why it fails: A hold preserves data indefinitely until the hold is removed, but it does not set a specific retention period of 7 years. Holds are typically used for legal cases, not for fixed retention periods. The requirement is for a 7-year retention, which is better met with a retention rule.

Set up a Gmail compliance rule to blind carbon copy all CEO emails to a dedicated account.

Why it fails: A compliance rule can route copies, but it does not guarantee retention for 7 years and may be bypassed. It also does not integrate with Vault's retention framework. The correct approach is a Vault retention rule.

SPF (Sender Policy Framework)

Why it fails: SPF alone only specifies which servers are authorized to send email for your domain. It does not encrypt email in transit, nor does it provide a mechanism for recipients to verify the sender's identity beyond IP authorization. While SPF helps prevent spoofing, it does not meet the requirement for encryption or reporting, which are key features of a more comprehensive standard.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Why it fails: DMARC builds on SPF and DKIM to provide a policy for handling emails that fail authentication and enables reporting. However, DMARC itself does not encrypt email in transit; it relies on SPF and DKIM for authentication. Without additional configuration such as TLS, encryption is not guaranteed. Thus, DMARC alone does not meet the encryption requirement.

DKIM (DomainKeys Identified Mail)

Why it fails: DKIM adds a digital signature to outgoing emails, allowing recipients to verify that the message was sent by your domain and was not altered in transit. However, DKIM alone does not encrypt email in transit, nor does it provide a reporting mechanism for authentication failures. It is often used with SPF and DMARC but does not fulfill all the stated requirements.

Set up a data transfer rule in the Admin console under Directory > Data Transfer.

Why it fails: Data transfer in the Admin console allows an administrator to manually transfer data from one user to another, but it does not automatically trigger upon account deletion. It requires the administrator to initiate the transfer each time, which does not meet the requirement for automatic, hands-off operation for all future departures.

Configure a Google Vault retention rule that moves files to the manager when the account is deleted.

Why it fails: Google Vault retention rules are designed to preserve or delete data for eDiscovery and compliance, not to transfer ownership. Vault can hold data for a set period, but it cannot automatically reassign Drive files to another user. This option misinterprets Vault's purpose as a data migration tool.

Use the Google Workspace Admin SDK to write a script that transfers files upon account deletion.

Why it fails: While the Admin SDK can be used to programmatically transfer files, it requires custom development and does not natively trigger on account deletion. This approach adds complexity and maintenance overhead, and does not provide a built-in automatic solution. The native transfer ownership feature is simpler and directly addresses the requirement without scripting.

In the Google Admin console under Apps > Google Workspace > Gmail > Compliance, create a content compliance rule that requires secure transport.

Why it fails: Content compliance rules inspect message content and attachments against expressions, not transport encryption capabilities. They can trigger actions like quarantine or modify delivery, but they do not enforce TLS on the SMTP connection itself. This rule type cannot reject messages solely because the receiving server lacks TLS support, so it fails to meet the security team's requirement.

In the Google Admin console under Apps > Google Workspace > Gmail > Hosts, add the recipient domains and enable the 'Require TLS delivery' option for each host.

Why it fails: The Hosts setting is used to route messages to specific inbound or outbound gateways, not to enforce TLS per recipient domain. While you can specify a host and enable TLS, this approach requires you to enumerate every external domain, which is impractical and does not apply to arbitrary recipients. It also does not reject messages when TLS is unavailable; it only attempts TLS to the configured host.

In the Google Admin console under Security > Authentication > SMTP relay service, configure the allowed senders and require authentication.

Why it fails: The SMTP relay service setting controls which devices or applications can send mail through Google's servers, and it enforces authentication for relay. It does not enforce TLS encryption for outbound messages to external recipients. Configuring allowed senders here affects relay permissions, not transport security, so it cannot reject messages to non-TLS recipients.

A Google Group used as a collaborative inbox

Why it fails: A Google Group with a collaborative inbox allows members to assign and track conversations, but it is designed around group membership and does not give users the ability to send and reply as the group address in the same way a shared mailbox does. It is better suited for team workflows than for a single shared support address with full send-as capability.

Delegated access in Gmail

Why it fails: Delegated access lets a user open another mailbox from their own Gmail interface, but the delegate must still be granted access by the mailbox owner and typically uses their own credentials. It does not provide a shared identity where replies come from the shared address without the delegate's own address appearing. It is not the intended feature for a support queue shared by multiple people.

A Gmail delegated mailbox configured in the Admin console

Why it fails: Delegation is configured by the mailbox owner in Gmail settings, not centrally in the Admin console, and it still requires the delegate to use their own sign-in. It also does not provide a unified send-as identity for a team. This makes it unsuitable for a shared support mailbox that multiple users must operate without sharing a password.