Hybrid Identity and Global Secure Access (15 questions)
Go deeper on this topic in Hybrid Identity and Global Secure Access Field Guide.
Both the Microsoft traffic profile and the Internet Access profile are enabled and assigned to users running the Global Secure Access client. An administrator opens Microsoft traffic policies and changes the Action for the SharePoint Online policy group (*.sharepoint.com) from Forward to Bypass. What happens to SharePoint Online traffic on those clients?
Correct answer: D. It egresses direct-and-local from the client and is not acquired by the Internet Access profile.
Traffic that is available for acquisition in the Microsoft traffic profile can only be acquired in that profile. Setting a rule to Bypass tells Global Secure Access to skip acquisition entirely, so the client uses its normal network routing path to egress directly; the Internet Access profile never inherits that traffic.
Why the other options are wrong:
- A. The Internet Access profile never acquires traffic that is eligible for the Microsoft profile, even when that traffic is bypassed.
- B. Bypass means the traffic egresses directly to the internet, not that it is blocked.
- C. Private Access carries defined private application segments, not Microsoft 365 SaaS traffic.
Memory hook: Bypass = direct-and-local; the Internet profile never inherits Microsoft traffic.
Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/how-to-manage-microsoft-profile
In Microsoft Entra Internet Access, an administrator builds a custom security profile at priority 100 for the Sales group and also configures the Baseline profile with organization-wide category blocks. A colleague assumes that when the Sales profile matches, the Baseline profile is skipped. Which statement about the Baseline security profile is correct?
Correct answer: C. The Baseline profile is a catch-all at the lowest priority (65,000) that applies to all Internet Access traffic and always executes, even when a higher-priority profile matches
The Baseline security profile is special: it applies to all Internet Access traffic routed through Global Secure Access without needing a Conditional Access link, sits at the lowest priority (65,000), and always executes as a catch-all even when a Conditional Access policy matches another security profile. Priority ordering follows traditional firewall logic, where 100 is highest and 65,000 is lowest, so higher-priority custom profiles are evaluated first and can create exceptions, but the Baseline still runs. This lets you set org-wide protections in Baseline while allowing higher-priority profiles to override specific rules.
Why the other options are wrong:
- A. The Baseline profile is the lowest priority (65,000), not the highest. Priority 100 is the highest and is used by targeted custom profiles that take precedence over Baseline for conflicting rules.
- B. The Baseline profile is the one profile that does not require a Conditional Access link; it applies to all Internet Access traffic by default.
- D. The Baseline profile applies to all traffic routed through Global Secure Access, including both client-based and remote network traffic, not just remote networks.
Memory hook: Baseline profile = catch-all at priority 65,000, no Conditional Access needed, ALWAYS runs even when a custom profile matches. 100 = highest, 65,000 = lowest.
Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/concept-internet-access
Quick Access is configured with the wildcard application segment *.contoso.local. An administrator then creates a Global Secure Access enterprise application with an application segment for hr.contoso.local on port 443/TCP and assigns it only to the HR group. A user who is assigned to Quick Access but not to the HR application tries to reach hr.contoso.local. What happens, and why?
Correct answer: D. Access is denied, because the enterprise application segment takes precedence over the overlapping Quick Access segment and the user isn't assigned to that application.
When an enterprise application's network segment overlaps a Quick Access segment, the enterprise application takes precedence for that resource. This enforces explicit per-app assignment, so a user who is not assigned to the HR application is blocked from reaching it even though it falls within the Quick Access wildcard.
Why the other options are wrong:
- A. Quick Access does not win overlaps; the enterprise application segment takes precedence.
- B. Overlap does not cancel access; HR users assigned to the application still connect normally.
- C. The specific enterprise application segment overrides the Quick Access wildcard, not the reverse.
Memory hook: The named app beats the catch-all: explicit assignment wins the overlap.
Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/tutorial-private-access-app-segmentation
A company currently uses AD FS with password hash synchronization (PHS) configured through Microsoft Entra Connect. The security team wants to move away from AD FS and adopt pass-through authentication (PTA) instead. Which statement correctly describes a key operational difference between PHS and PTA that the team must plan for?
Correct answer: B. PTA validates user credentials against on-premises Active Directory in real time, while PHS synchronizes a hash of the password to Microsoft Entra ID
With pass-through authentication, user credentials are validated directly against on-premises Active Directory Domain Services in real time via lightweight on-premises agents. No password hash or password is stored in Microsoft Entra ID. With password hash synchronization, a hash of the on-premises password is synchronized to Microsoft Entra ID, allowing authentication to occur in the cloud without any dependency on on-premises infrastructure at sign-in time. This is a critical planning difference: PTA requires on-premises PTA agents to be available for authentication to succeed.
Why the other options are wrong:
- A. PTA does require on-premises agents to handle real-time credential validation. It does not store credentials in Microsoft Entra ID. Only PHS can authenticate solely from the cloud after initial synchronization.
- C. PTA does not require AD FS. PTA uses its own lightweight agent installed on-premises, separate from AD FS infrastructure. Removing AD FS is actually a common reason for migrating from federation to PTA or PHS.
- D. This option swaps the two methods. PTA is the one that validates credentials through real-time on-premises agents; PHS is the one that stores a hash in the cloud.
Memory hook: PTA = Phone a friend on-premises every time. PHS = Hash stored in the cloud, no call needed.
Microsoft Learn: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-azure-ad-connect
After enabling the Microsoft traffic profile, an analyst notices Microsoft Entra sign-in logs now show the security service edge proxy's egress IP instead of each user's real public IP, which breaks IP-based Conditional Access. Which Global Secure Access feature restores the user's actual public egress IP to the sign-in and audit logs?
Correct answer: C. Source IP restoration
Source IP restoration, part of the Adaptive Access feature, detects and securely communicates the user's original public egress IP to Microsoft Entra ID and Microsoft Graph, so IP-based location policies, Identity Protection risk detections, and sign-in/audit logs reflect the real client IP. It requires the Microsoft traffic profile to be enabled.
Why the other options are wrong:
- A. The compliant network check verifies the user is on Global Secure Access; it does not surface the client IP.
- B. Source IP anchoring makes a downstream SaaS app see your controlled egress IP; it does not restore the client IP in Entra logs.
- D. Universal tenant restrictions block sign-ins to external tenants; they do not reveal the client's source IP.
Memory hook: Restoration = give Entra back the real client IP.
Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/how-to-source-ip-restoration
A company wants remote employees to reach an internal server over RDP (3389/TCP) and SSH (22/TCP) with Zero Trust controls and no legacy VPN. They already use Microsoft Entra application proxy to publish a couple of internal web portals. Which approach fits the RDP/SSH requirement?
Correct answer: C. Publish the server via Microsoft Entra Private Access as an enterprise application with application segments for the required ports; application proxy publishes HTTP/HTTPS web apps only.
Microsoft Entra application proxy publishes HTTP/HTTPS web applications. Arbitrary TCP/UDP protocols such as RDP and SSH are delivered by Microsoft Entra Private Access using application segments (destination, port, and protocol). Both services share the same Microsoft Entra private network connector.
Why the other options are wrong:
- A. Private Access delivers RDP and SSH with Zero Trust controls and no VPN required.
- B. Changing pre-authentication to Passthrough does not turn application proxy into a general TCP tunnel.
- D. Application proxy publishes HTTP/HTTPS web apps only; it cannot expose raw RDP or SSH via external URLs.
Memory hook: App Proxy = web only; Private Access = any port (RDP, SSH, SMB).
Microsoft Learn: https://learn.microsoft.com/entra/identity/app-proxy/overview-what-is-app-proxy
A hybrid organization has Microsoft Entra hybrid joined Windows 11 devices and on-premises Active Directory. They want to deploy Windows Hello for Business so users get single sign-on to on-premises file shares, using the simplest deployment with no requirement to deploy or modify a public key infrastructure (PKI). Which trust type should they choose?
Correct answer: A. Cloud Kerberos trust
Windows Hello for Business cloud Kerberos trust is the recommended hybrid deployment model. It is the only hybrid option that requires no certificate/PKI deployment; users get a partial TGT from Microsoft Entra ID via Microsoft Entra Kerberos, and on-premises domain controllers still issue Kerberos service tickets for resource access.
Why the other options are wrong:
- B. Key trust still depends on a PKI (domain controller certificates), so it is more complex than cloud Kerberos trust.
- C. Certificate trust requires an enterprise PKI plus a certificate registration authority (AD FS) to issue user authentication certificates - the most infrastructure.
- D. 'Federated trust' is not a Windows Hello for Business trust type; the three trust types are cloud Kerberos, key, and certificate.
Memory hook: Cloud Kerberos = no PKI, uses Entra Kerberos - the easy hybrid button.
Microsoft Learn: https://learn.microsoft.com/windows/security/identity-protection/hello-for-business/deploy/
An administrator enabled Microsoft Entra seamless SSO with password hash synchronization. On corporate, domain-joined Windows devices, users are still prompted for their password in the browser instead of being signed in silently. Sync is healthy and the users are in the correct groups. Which configuration is most likely missing?
Correct answer: C. The URL https://autologon.microsoftazuread-sso.com must be added to the users' browser Intranet zone, typically via Group Policy.
Browsers only send Kerberos tickets to endpoints they trust as intranet sites. Seamless SSO works by having the browser answer the Microsoft Entra sign-in service's HTTP 401 challenge with a Kerberos ticket for the AZUREADSSOACC account, so https://autologon.microsoftazuread-sso.com must be in the users' Local intranet zone, normally delivered via Group Policy. Without that zone entry, silent sign-in fails and the browser falls back to a password prompt. Placing the URL in the Trusted Sites zone instead actually blocks sign-in.
Why the other options are wrong:
- A. Modern authentication is required for seamless SSO to work with current clients, not disabled. Turning it off would break the modern sign-in flow rather than fix silent sign-in.
- B. The AZUREADSSOACC account is a computer object whose Kerberos decryption key is shared with Entra ID. It must not be made a Domain Admin, and doing so would not resolve the browser-zone issue.
- D. Kerberos requires the device clock to be within five minutes of the domain controller. Deliberately skewing it by ten minutes would break ticket issuance, not enable SSO.
Memory hook: Silent SSO needs autologon.microsoftazuread-sso.com in the INTRANET zone. Not there = password prompt; Trusted Sites = hard block.
Microsoft Learn: https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-sso-quick-start
Cloud-only users reset their passwords with SSPR successfully, but users synchronized from on-premises AD DS get an error and their on-premises passwords never change. Password hash sync is healthy and all users are licensed for Microsoft Entra ID P1. What must be enabled so the synced users can reset their passwords?
Correct answer: D. Password writeback in Microsoft Entra Connect (or Entra Connect cloud sync)
Password writeback is the feature that writes cloud password changes back to on-premises AD DS in real time, using either Microsoft Entra Connect or Entra Connect cloud sync. Without it, a synchronized user's SSPR cannot commit the new password to AD DS, so the reset fails. Writeback is supported with password hash sync, pass-through authentication, and AD FS.
Why the other options are wrong:
- A. The custom banned password list blocks weak passwords during change or reset; it does not enable writing the new password back to on-premises AD DS.
- B. Seamless SSO silently signs users in on corporate devices; it has nothing to do with writing a reset password back to on-premises AD DS.
- C. Pass-through authentication is an authentication method (and its agents do not run on domain controllers). Password writeback, not PTA, commits the SSPR change to AD DS, and writeback works with PHS, PTA, or AD FS.
Memory hook: Synced-user SSPR needs Password Writeback - the cloud change must be written back to AD DS.
Microsoft Learn: https://learn.microsoft.com/entra/identity/authentication/concept-sspr-writeback
Contoso wants a lightweight hybrid identity option: a cloud-managed, lightweight agent (supporting multiple active agents for automatic failover) that can synchronize users from a disconnected, newly acquired forest, configured entirely from the Microsoft Entra admin center. Which solution best fits?
Correct answer: C. Microsoft Entra Cloud Sync
Cloud Sync uses lightweight provisioning agents (supporting multiple active agents for automatic failover), is configured and managed in the cloud from the Microsoft Entra admin center, and supports disconnected forests, making it ideal for merger/acquisition scenarios.
Why the other options are wrong:
- A. Wrong: Connect Sync is a heavier server-installed engine configured on-premises, and its multiple instances aren't active/active; it isn't the cloud-managed lightweight-agent option described.
- B. Wrong: AD FS is a federation/authentication service, not a directory synchronization engine.
- D. Wrong: Connect Health is a monitoring service for hybrid components, not a sync engine.
Memory hook: Cloud Sync = lightweight cloud-managed agents; great for M&A / disconnected forests.
Microsoft Learn: https://learn.microsoft.com/entra/identity/hybrid/cloud-sync/connect-to-cloud-sync-decision-guide
A network engineer configured a Global Secure Access remote network (a site-to-site IPsec tunnel from the branch's customer premises equipment) so that branch users can reach an internal line-of-business app published through Microsoft Entra Private Access, without installing any client. Users at the branch cannot reach the private app. What is the reason?
Correct answer: C. The Private Access traffic forwarding profile is not supported over remote network connectivity; it requires the Global Secure Access client on end-user devices.
Global Secure Access remote networks support the Microsoft traffic and Internet Access traffic forwarding profiles, but the Private Access profile is not supported over remote network connectivity. Private Access traffic can only be acquired by the Global Secure Access client installed on end-user devices. To give branch users access to a Private Access-published application, deploy the GSA client to those devices rather than relying on the clientless remote-network (IPsec) path.
Why the other options are wrong:
- A. There is no dedicated second-tunnel requirement for DNS. Private Access simply is not available over remote network connectivity and needs the client.
- B. Remote networks are not limited to a single port. The failure is that the Private Access profile is not carried over remote networks at all, regardless of the app's port.
- D. The Microsoft Entra traffic profile is always-on and system-managed; disabling it is neither possible nor related to Private Access over remote networks.
Memory hook: Private Access = client only. Remote-network IPsec carries Microsoft and Internet Access profiles, never Private Access.
Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/concept-remote-network-connectivity
A company is planning a forest consolidation over the next year and will move user accounts between Active Directory domains and forests. They are installing Microsoft Entra Connect now and want the link between each on-premises user and its Microsoft Entra ID object to survive the cross-forest moves. Which attribute should be configured as the source anchor?
Correct answer: D. ms-DS-ConsistencyGuid, because its value can be carried forward when an object moves between domains or forests, preserving the link to the cloud object
Microsoft recommends ms-DS-ConsistencyGuid as the source anchor whenever objects may move between domains or forests, which is common in consolidations, mergers, and acquisitions. objectGUID is system-assigned and regenerated when an object is recreated in a new domain or forest, which breaks the link to the existing cloud object. Because ms-DS-ConsistencyGuid is a writable attribute, migration tooling can copy the value forward to the target forest so Microsoft Entra ID still hard-matches the moved object to its existing cloud identity. Microsoft's operations guidance is explicit: if you are currently using objectGUID and have cross-forest movement, switch to ms-DS-ConsistencyGuid.
Why the other options are wrong:
- A. userPrincipalName is disqualified as a source anchor: it can change (rename, marriage, department move) and it contains an @ character, which the wizard blocks. A source anchor must be immutable.
- B. objectGUID is stable only as long as the object stays in the same directory. When an account is recreated in a different domain or forest, AD assigns a new objectGUID, breaking the source anchor link. That is precisely the scenario ms-DS-ConsistencyGuid was designed to solve.
- C. objectSID also changes when an account is migrated to a new domain (the account receives a new SID, with the old one retained only as SID history). It is not a supported source anchor attribute.
Memory hook: Cross-forest moves coming? Use ms-DS-ConsistencyGuid - you can carry it forward. objectGUID is reborn in the new forest and breaks the link.
Microsoft Learn: https://learn.microsoft.com/entra/identity/hybrid/connect/plan-connect-design-concepts
An organization with a federated domain wants to pilot cloud authentication (PHS) for one department before converting the whole domain from federated to managed. It needs those pilot users to authenticate directly to Microsoft Entra ID while everyone else in the same domain continues to use AD FS. Which feature accomplishes this?
Correct answer: C. Staged rollout, which overrides authentication on a per-user (security group) basis so pilot users use cloud authentication while the domain stays federated.
Staged rollout is a temporary migration mechanism for federated organizations. Adding users to a staged rollout security group makes Microsoft Entra ID stop redirecting those specific users to the federation server and instead authenticate them directly with cloud authentication (PHS, PTA, or certificate-based authentication) plus optional seamless SSO, while the domain itself remains federated for everyone else. This narrows the blast radius of migration testing: you validate cloud authentication, MFA, and Conditional Access behavior with a pilot group before performing the full domain cutover from federated to managed. Staged rollout is explicitly not intended as a permanent state.
Why the other options are wrong:
- A. Cross-tenant synchronization provisions B2B users between separate tenants. It does not change how existing users in one federated domain authenticate.
- B. Conditional Access controls access after authentication routing is decided. It cannot redirect a federated user to cloud authentication, which is what staged rollout does at the tenant sign-in layer.
- D. Converting the domain to managed switches all users at once, which is exactly the large blast radius staged rollout is designed to avoid. Re-federating individuals is not how the feature works.
Memory hook: Staged rollout = move a pilot GROUP off federation to cloud auth while the domain stays federated. Temporary, per-user, pre-cutover.
Microsoft Learn: https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-staged-rollout
An administrator enabled Microsoft Entra Private Access and wants to begin per-app segmentation. They browse to Global Secure Access, then Applications, then Application Discovery, but the discovery table is empty. What is the most likely reason?
Correct answer: A. No users have accessed private resources through Quick Access, so there is no traffic to analyze.
Application Discovery relies on traffic flowing through Quick Access. If Quick Access is not configured, or no users have accessed applications through it, the discovery page shows an expected empty state rather than a product error.
Why the other options are wrong:
- B. Discovery feeds the creation of enterprise applications; it does not depend on one already existing.
- C. Application Discovery is a Private Access feature driven by Quick Access traffic, not the Internet Access profile.
- D. The Global Secure Access client must be installed and running to generate the traffic that discovery analyzes.
Memory hook: No Quick Access traffic, no discovery data.
Microsoft Learn: https://learn.microsoft.com/entra/global-secure-access/how-to-application-discovery
An organization deploys Microsoft Entra Private Access as part of Global Secure Access to replace its legacy VPN for remote users. Which statement accurately describes what Microsoft Entra Private Access provides that a traditional VPN does not?
Correct answer: C. Private Access provides per-app Zero Trust Network Access using Conditional Access policies for each private resource
Microsoft Entra Private Access provides Zero Trust Network Access (ZTNA) at a per-application level, allowing granular Conditional Access policies to be applied to each private resource or app individually. Traditional VPNs grant access to an entire network segment once a user authenticates, which can allow lateral movement. Private Access supports per-app access for TCP and UDP applications, Quick Access for IP and FQDN ranges, and integrates deeply with Conditional Access for more granular security than a VPN provides.
Why the other options are wrong:
- A. Private Access does not mandate FIDO2 keys. It enforces Conditional Access policies, which can require various authentication strengths, but it does not itself require FIDO2 specifically.
- B. Universal Tenant Restrictions is a feature of Microsoft Entra Internet Access for Microsoft services, which prevents users from authenticating to unauthorized external tenants. It is not a Private Access feature.
- D. Tunneling internet traffic to block malicious sites is the function of Microsoft Entra Internet Access (the Secure Web Gateway component), not Private Access. Private Access focuses on private, internal corporate resources.
Memory hook: VPN = opens the whole castle. Private Access = opens one specific room at a time, only if your Conditional Access badge allows it.
Microsoft Learn: https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access