Instiq
Chapter 2 · Managing core services·v1.0.0·Updated 6/15/2026·~13 min

What's changed: Created Associate Google Workspace Administrator Chapter 2 (Domain 2 "Core services": configuring Gmail/Drive/Calendar/Meet = routing/sharing scope/resources/recording-participant control; service on/off and additional apps = on/off per OU/group, allow/block Marketplace/connected apps, API access management).

2.2Service on/off and managing additional apps

Key points

Understand turning core/additional Google services on/off per OU or group, controlling access for Marketplace and third-party apps (API access, allow/block connected apps), and governing external sharing and integrations per organizational policy.

Organizations do not use every service uniformly. Administrators govern which services, for whom, and how far to enable. This directly balances convenience and security.

2.2.1Turning services on/off

Core and additional Google services can be turned on/off per OU or group (e.g., disable YouTube only for a department, enable a new service only for a pilot group). You can also manage how new services default (auto-on or manual). Map "vary service availability per department/group = on/off per OU/group."

2.2.2Controlling additional apps and API access

You can allow/block the Marketplace apps and third-party connected apps users use. With API access management (app access control), limit access to Workspace data to trusted apps only and block unverified ones. Map "control external apps accessing data = app access control" and "govern Marketplace app adoption = allowlist/block."

Exam point

Common: requirement → means. E.g., "disable a service only for a department" = on/off per OU; "enable only for a pilot group" = on/off per group; "stop unverified external apps from accessing data" = API access management/app access control; "allow only specific Marketplace apps" = allowlist.

Warning

Watch the mix-ups: (1) Service availability is differentiated per OU/group. (2) App access control is about whether external apps may access data—a different layer from service on/off. (3) Auto-on defaults for new services can expose them unintentionally—set a policy.

Diagram of toggling services per OU/group, allow/block Marketplace/connected apps, and limiting external apps data access via API access management.
Govern availability

2.2.3Section summary

  • Services on/off per OU/group (also manage new-service defaults)
  • Govern Marketplace/connected apps via allow/block
  • Limit external apps data access via API access management (app access control)

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. To disable a Google service only for a specific department, which best fits?

Q2. To stop unverified third-party apps from accessing Workspace data, what do you use?

Q3. To pilot a new service by enabling it for one group only, which best fits?

Q4. To allow only specific Marketplace apps for the organization, which is most appropriate?

Q5. Which correctly describes service on/off vs app access control?

Q6. Which is a correct risk of new Google services defaulting to auto-on?

Check your understandingPractice questions for Chapter 2: Managing core services