5.1 Entra Connect Sync vs Cloud Sync

Why hybrid identity still matters on SC-300

Most enterprises do not start life as cloud-only Microsoft Entra tenants. They already run Active Directory Domain Services (AD DS) for Windows logon, Group Policy, file shares, and line-of-business Kerberos apps. Hybrid identity bridges on-premises AD and Microsoft Entra ID so the same users (and often groups) exist in both places and can authenticate to Microsoft 365, Azure, and SaaS apps.

SC-300 Domain 1 expects you to plan and implement hybrid identity, not merely memorize product logos. Exam stems describe mergers, branch offices with limited servers, multi-forest acquisitions, and “we need a second server ready if the primary dies.” Your job is to pick Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync, scope the right objects, and operate safely with staging mode and agent high availability.

Microsoft Entra Connect Sync architecture

Microsoft Entra Connect Sync (often still called Azure AD Connect in older materials) is the full hybrid identity sync stack installed on one or more Windows servers in your environment.

Core components and concepts:

• Synchronization service — imports from AD (and optionally other directories), applies rules, and exports to Microsoft Entra ID.
• Connector space / metaverse — intermediate representations of objects used by the rules engine (exam depth is conceptual: objects are projected, joined, and transformed).
• Sync rules — built-in and custom rules that map attributes, filter objects, and control join behavior.
• Optional features — password hash synchronization, pass-through authentication, seamless SSO, Exchange hybrid writeback, device writeback, group writeback, password writeback, and more depending on version and configuration.
• SQL Express or full SQL — state store for the sync engine (larger directories often use full SQL Server).

Typical single-server topology:

1. Domain-joined Windows Server meets sizing and prerequisites.
2. Install Microsoft Entra Connect with express or customized settings.
3. Connect to Microsoft Entra ID with a Hybrid Identity Administrator (or Global Administrator) cloud identity.
4. Connect to one or more AD forests with an enterprise admin or appropriately delegated AD account for the installation phase.
5. Configure sign-in method (PHS, PTA, federation—covered in section 5.2).
6. Select OUs/domains and optional filtering; complete installation; initial sync runs.

Connect Sync is configuration-heavy on-premises. Wizard choices, Synchronization Service Manager (for advanced operators), PowerShell modules, and scheduled sync cycles all live around that server. That power is why Connect Sync still wins for complex custom rules, certain writeback scenarios, and topologies that Cloud Sync does not fully replace.

Microsoft Entra Cloud Sync architecture

Microsoft Entra Cloud Sync is the cloud-managed provisioning approach for hybrid identity. Instead of a full metaverse-style sync server owning the configuration, you:

1. Install one or more Microsoft Entra provisioning agents on domain-joined Windows servers.
2. Register agents with your tenant.
3. Create cloud sync configurations (provisioning jobs) in the Microsoft Entra admin center that define source AD, target Entra tenant, scoping, and attribute mappings.
4. Let agents pull configuration and synchronize objects outbound to Microsoft Entra ID.

Architecture differences that matter on the exam:

Cloud Sync shines when the organization wants less server footprint, easier multi-geo agent placement, and cloud-first operations. Connect Sync remains the answer when the scenario needs features or complexity only Connect Sync provides (for example, certain advanced writeback or custom rule requirements called out in the stem).

When to choose each (decision heuristics)

Use this exam decision tree:

Prefer Microsoft Entra Cloud Sync when:

• Single forest or straightforward multi-forest identity with agent-per-forest designs.
• Goal is modernization with minimal on-premises infrastructure.
• You need multiple lightweight agents for resiliency rather than a full second Connect server topology.
• Scoping needs are OU/group-based filters within Cloud Sync’s capabilities.
• Organization wants configuration managed primarily from the Entra admin center.

Prefer Microsoft Entra Connect Sync when:

• Scenario requires advanced sync rules, complex transformations, or documented Connect-only features.
• Heavy use of hybrid writeback features that the question ties to Connect Sync.
• Large, long-standing deployment already centered on Connect with customizations that would be costly to abandon mid-migration.
• Topology complexity exceeds what the exam describes as supported for Cloud Sync.

Coexistence note: Many real environments run both products for different forests or during migration. SC-300 may describe a pilot forest on Cloud Sync while the primary forest remains on Connect Sync. Do not assume they are mutually exclusive in every case; choose based on the forest’s requirements.

Staging mode (Connect Sync)

Staging mode is a Connect Sync safety and high-availability concept:

• A server in staging mode imports from directories and runs synchronization (rules processing) but does not export to Microsoft Entra ID or connected directories.
• A production Connect server remains the only exporter.
• You can promote a staging server (disable staging mode) after validating configuration, completing upgrades, or recovering from primary failure—following Microsoft’s documented cutover steps (including ensuring only one exporter).

Exam uses of staging mode:

Trap: staging mode is not the same as installing Cloud Sync agents, and it is not password hash “staging” language from other products. It is specifically the Connect Sync export-disabled mode.

Object filtering and OU scoping

Both products must avoid synchronizing the entire directory blindly. Scoping controls which identities appear in Entra ID.

Common Connect Sync scoping techniques:

• Domain and OU filtering — select only OUs that hold identities you want in the cloud (for example, exclude service accounts OU, lab OUs, or terminated-users holding pens).
• Group-based filtering (where used) — synchronize users who are members of a designated group (pilot patterns).
• Attribute-based filtering / custom sync rules — advanced exclusion (for example, extensionAttribute flags).
• App-based filtering concepts in broader Entra provisioning — know that hybrid sync scoping is about which directory objects are in scope, separate from Conditional Access who can access an app.

Cloud Sync scoping is configured in the cloud sync job: select organizational units, group scope filters, and attribute mappings available in the Cloud Sync experience.

SC-300 scenario patterns:

• “Only users in the Cloud-Users OU should appear in Entra ID” → configure OU filtering/scoping, not Conditional Access.
• “Pilot 200 users first” → group or OU pilot scope, then expand.
• “Service accounts flooded the cloud directory” → tighten OU filter; disable unnecessary object types if the product option applies.

Filtering mistakes cause orphan cloud users, missing employees, or license waste. Always align UPN suffixes, proxy addresses, and source anchor planning before broad sync.

Multi-forest awareness (high level)

Enterprises often have:

• Account forest + resource forest.
• Multiple account forests after mergers.
• Different UPN namespaces per brand.

Connect Sync can connect to multiple AD forests in one deployment (subject to supported topologies: for example, users represented once, careful source anchor and matching). Multi-forest design must avoid duplicate identities and define which forest is authoritative for which attributes.

Cloud Sync commonly uses separate configurations and agents aligned to forests or domains, managed from the cloud. Exam stems that say “each forest has limited local servers and must sync independently” often point to Cloud Sync agents per forest rather than shipping all traffic through one giant Connect box—unless advanced Connect features are required.

Remember: multi-forest is about directory topology and object uniqueness, not about multi-tenant Entra by default. One Entra tenant can receive identities from multiple forests when designed correctly.

Cloud provisioning agents for Cloud Sync

The Microsoft Entra provisioning agent is the on-premises worker for Cloud Sync:

• Installed on domain-joined Windows Server that can reach domain controllers and outbound HTTPS to Microsoft endpoints.
• Registered to the tenant; appears in the Entra admin center under Cloud Sync / provisioning agents.
• Runs as a service; pulls job configuration; reads AD; provisions to Entra ID.
• High availability: install multiple agents so agent maintenance or host failure does not stop synchronization.
• Agents are outbound-connected—firewall design focuses on egress to Microsoft, not inbound holes to the agent.

Operational checklist for exams:

1. Right-size agent hosts and keep them patched.
2. Use at least two agents for production configurations.
3. Monitor agent health and provisioning logs in the portal.
4. Do not confuse the Cloud Sync agent with the PTA authentication agent (different feature, covered next) even though both are lightweight on-prem agents.

Putting Connect Sync vs Cloud Sync together

Hybrid identity is the bridge from AD DS to Microsoft Entra ID. Master which engine runs where, how you stay safe with staging and filters, and how Cloud Sync agents change the operations model. Authentication methods—PHS, PTA, seamless SSO, and federation—build on this foundation in the next section.