MS-102 Study Guide: Implementing and Managing Identity and Access in Microsoft Entra ID

March 30, 2026 TechieGeek

Identity is the control plane of Microsoft 365. Every sign‑in, every Conditional Access decision, every admin action flows through Entra ID. If you get identity wrong, no amount of hardening on top will save the tenant.

For MS‑102, “Implement and manage Microsoft Entra identity and access” is 25–30% of the exam and maps to three big areas:

Implement and manage identity synchronization
Implement and manage authentication
Implement and manage secure access

This post walks those three areas in depth, from how they work to how you should think about them for both the exam and real-world design.

1. Identity Synchronization: Bringing Identities to the Cloud

Most organizations start with identities in on‑premises Active Directory. Microsoft 365 services live in Entra ID. Identity synchronization is how you bridge those two worlds.

1.1 Cleaning up your directory first

If you sync a messy AD, you get a messy Entra tenant. Before any sync agent runs, do a hygiene pass:

Fix duplicate UPNs and proxy addresses.
Remove invalid characters in userPrincipalName and mail attributes.
Standardize UPN suffixes (for example, align them to your primary email domain).
Check for stale objects (disabled accounts, old service accounts).

Doing this early avoids hard‑to‑debug sync failures and mismatched identities later.

1.2 Entra Connect Sync vs Entra Cloud Sync

You have two main tools for directory sync:

Entra Connect Sync (classic sync server):

Installed on a Windows Server in your datacenter.
Supports:
- Multiple forests
- Complex OU and attribute filtering
- Full writeback (passwords, groups, devices in some scenarios)
Best when:
- You have a complex AD topology.
- You already run AD FS or other on‑prem identity infra.
- You need granular control and legacy features.

Entra Cloud Sync (lightweight agent):

Uses a small provisioning agent installed on‑prem.
Orchestration is cloud‑based, with less configuration on the server itself.
Handles multiple forests without heavy configuration.
Best when:
- You want simple, low‑maintenance sync.
- You’re modernizing and don’t need everything Connect Sync can do.
- You have multiple small forests and want to avoid heavy infrastructure.

A simple rule: if you’re green‑field or relatively simple, start with Cloud Sync; if you have a big, old, and complicated AD, you’ll likely still use Connect Sync for now.

1.3 How password hash synchronization actually works (without marketing fluff)

Password Hash Sync often raises security questions. At a high level:

AD stores an MD4 hash of the user’s password.
The sync agent reads that hash, applies additional cryptographic processing (salt + PBKDF2 / SHA‑256), and produces a new hash.
That second‑stage hash is what gets stored in Entra ID, never the actual password or the raw AD hash.
The result is:
- The cloud hash can’t be reversed to the plain password.
- It can’t be used in a classic pass‑the‑hash attack back on‑prem.
- Authentication in the cloud uses that hardened hash.

For the exam, what matters is the idea: with PHS, password validation happens in Entra, but no plaintext or AD‑style hashes are exposed.

1.4 Monitoring and troubleshooting sync

Once sync is running, you need to keep it healthy:

Watch for:
- High numbers of sync errors.
- Disabled sync agents.
- Credential or permission issues.
Typical troubleshooting flow:
- Check the sync health dashboard.
- Look at recent sync runs and error statistics.
- Drill down into specific object errors (often attribute conflicts, invalid values, or scoping issues).
- Fix in AD, then force a delta sync.

In MS‑102 questions, if you see anything like “users aren’t syncing”, think: health dashboard, last sync time, and configuration changes first.

2. Authentication: How Users Prove Who They Are

Once identities are in Entra ID, you decide how users authenticate. The exam expects you to know the differences and trade‑offs, not just definitions.

Password Hash Synchronization (PHS)

Hash of the password hash stored in Entra.
Sign‑in happens in the cloud.
Works when on‑prem AD is offline.
Recommended default for most organizations.

Pass‑Through Authentication (PTA)

Password checked against an on‑prem domain controller in real time.
No password hash stored in the cloud.
Requires PTA agents on‑prem; sign‑in fails if agents or DCs are unavailable.
Useful for strict compliance environments or where password residency is tightly controlled.

Federation (AD FS and others)

Entra redirects sign‑in to on‑prem federation (for example, AD FS).
Allows advanced claims rules and third‑party integrations.
High complexity, extra servers, and more moving parts.
Legacy pattern; most migrations move away from this toward PHS or PTA.

For MS‑102 thinking:

PHS: pick this unless there’s a very good reason not to.
PTA: pick when security/compliance mandates no password hash in the cloud.
Federation: pick only when the scenario explicitly requires AD FS–type capabilities.

2.2 Self‑Service Password Reset (SSPR)

SSPR is simple but high impact:

Users register one or more authentication methods.
If they forget their password or get locked out, they reset it themselves.
You define:
- Who can use SSPR (scoped or all users).
- Which methods are allowed (app, phone, email, etc.).
- How many methods are required for reset.

For design and exam questions:

SSPR reduces helpdesk calls.
Combine SSPR with strong registration (for example, require two methods).
Make sure change flows back to AD if your users are synced.

2.3 Password protection and banned passwords

Passwords are still a weak point. Entra Password Protection helps by:

Blocking a global list of known bad passwords (like “Password123” patterns).
Letting you add custom banned words:
- Company name.
- City names.
- Team names.
- Product names.

You can enforce this in:

Cloud only (for cloud accounts).
On‑prem AD as well using a domain controller agent and proxy service.

Design tip: start in audit mode on‑prem to see how many password changes would have been rejected, then move to enforce once you’re comfortable.

2.4 Strong and modern authentication methods

You should be familiar with a few key methods:

Authenticator app (push notifications) — common, good baseline MFA.
FIDO2 security keys / passkeys — phishing‑resistant, hardware‑backed authentication.
Temporary Access Pass (TAP) — short‑lived, one‑time credential used when:
- A user has lost their phone.
- A new user hasn’t registered MFA yet.
- You want to bootstrap passwordless sign‑in.

Exam questions often test you on when to use TAP (onboarding/recovery) and when to recommend FIDO2 (highest security scenarios).

3. Secure Access: Conditional Access and Risk‑Based Controls

Once users can sign in, the job is to make sure access is appropriate every time. That’s where Conditional Access and risk-based policies come in.

3.1 Conditional Access basics

A Conditional Access policy is essentially:

If a user with these characteristics tries to access this resource under these conditions, then apply these controls.

Every policy has two halves:

Assignments:
- Users or roles (who).
- Cloud apps or actions (what).
- Conditions:
  - Location (named locations, countries, IP ranges).
  - Device platform.
  - Client app (browser, mobile, legacy protocols).
  - Sign‑in risk.
  - Device state (hybrid joined, compliant, etc.).
Access controls:
- Grant access:
  - Require MFA.
  - Require compliant device.
  - Require password change.
- Block access.

Some common patterns:

Require MFA for administrators across all cloud apps.
Require a compliant device for Exchange Online and SharePoint.
Block access from non‑trusted countries or from Tor/anonymous IPs.
Restrict legacy authentication entirely.

From an exam point of view, you should be able to translate a business requirement into assignments + access controls in your head.

3.2 Building safe policies (and not locking yourself out)

A few design principles you should remember:

Start new policies in report‑only mode.
- You see what would have happened without impact.
- Review sign‑in logs and policy evaluation results.
Always have a break‑glass account:
- Cloud‑only.
- No Conditional Access applied.
- Strong, unique password, and ideally stored offline.
Use Include and Exclude scopes thoughtfully:
- Include all users, then exclude break‑glass and emergency accounts.
- Include all apps, then exclude known exceptions only when necessary.

These patterns show up in scenario questions where the tenant gets locked out or admin access is unintentionally blocked.

Risk-based access adds an intelligent layer on top of CA:

Sign‑in risk:
- Evaluates each sign‑in.
- Looks at factors like atypical location, impossible travel, suspicious IPs, malware-associated IPs, and more.
- Levels: Low, Medium, High.
User risk:
- Evaluates the account over time.
- Indicates likelihood the identity is compromised (for example, leaked credentials, repeated suspicious sign‑ins).
- Also Low, Medium, High.

You then build policies around those:

If sign‑in risk is Medium or High, require MFA.
If user risk is High, force a password change at next sign‑in.

The important thing is the difference:

Sign‑in risk answers “Is this sign‑in suspicious?”
User risk answers “Is this account likely compromised overall?”

3.4 Tying it all together: example policies

Here are a few realistic, exam‑relevant policies:

Admin MFA policy
- Users: directory roles such as Global Administrator, Security Administrator, Exchange Administrator.
- Apps: all cloud apps.
- Controls: require MFA.
- Purpose: ensure all privileged roles are protected by MFA.
Trusted location bypass
- Users: all users.
- Apps: all cloud apps.
- Conditions:
  - Location: exclude named locations representing office IP ranges.
- Controls: require MFA for other locations.
- Purpose: reduce MFA fatigue for on‑site users while still protecting remote access.
High‑risk user lock‑down
- Users: all users.
- Condition: user risk = High.
- Controls: require password change.
- Purpose: automatically remediate compromised accounts.
Medium+ sign‑in risk protection
- Users: all users.
- Condition: sign‑in risk = Medium or High.
- Controls: require MFA.
- Purpose: step up verification when sign‑ins look suspicious.

4. How to Think About This for MS‑102

Instead of memorizing features, focus on cause and effect:

If you see existing AD + Microsoft 365, think:
- Directory cleanup → choose sync method → configure password hash sync.
If you see helpdesk drowning in password resets, think:
- SSPR and password protection.
If you see “require MFA sometimes but not always”, think:
- Conditional Access with location, device, or risk conditions.
If you see “compromised account”, think:
- User risk and sign‑in risk policies, plus forced password change.

The exam doesn’t just want button clicks; it wants to see that you understand why a particular Entra capability is the right tool for a given job.

Identity Synchronization (Q1–Q6)

1. Your company has a single on‑premises AD forest with ~5000 users and plans to move to Microsoft 365. They require group writeback and have some complex OU filtering needs. Which synchronization approach is most appropriate?

A. Entra Cloud Sync
B. Entra Connect Sync
C. Manual CSV imports to Entra ID
D. Federation with AD FS only

Correct answer: B
Explanation: Entra Connect Sync supports complex OU filtering and writeback scenarios and is better suited to larger, complex AD environments.learn.microsoft

2. You’ve installed a sync tool, but several user accounts are failing to sync due to invalid characters in userPrincipalName. What should you have done before enabling the first sync?

A. Enabled Password Hash Sync
B. Run Entra Password Protection on-prem
C. Run a directory cleanup tool against on‑prem AD
D. Configured Conditional Access policies

Correct answer: C
Explanation: A cleanup tool should be used before initial sync to find and fix invalid attributes and duplicates in AD.linkedin

3. Your organization has three untrusted AD forests and wants to minimize on‑prem infrastructure. Which sync model is generally the best fit?

A. Entra Connect Sync with AD FS
B. Entra Cloud Sync using multiple agents
C. Manual user creation in Entra ID
D. Password writeback only

Correct answer: B
Explanation: Entra Cloud Sync is designed for multi‑forest scenarios with lightweight agents and less infrastructure.linkedin

4. A user’s account exists in Entra ID but is missing several group memberships that exist on-prem. Sync is otherwise successful. Where is the most appropriate place to start troubleshooting?

A. Check Conditional Access policy assignments
B. Check sync rules and group scoping in the sync tool
C. Check sign‑in logs
D. Recreate the user in Entra ID

Correct answer: B
Explanation: Group membership sync issues usually relate to sync rules, OU filters, or attribute scoping in the sync configuration.learn.microsoft

5. Your security team is worried that password hashes will be stored in the cloud if you enable Password Hash Sync. How should you describe what is stored in Entra ID?

A. The plain text password
B. The same hash that AD stores on-prem
C. A second‑stage hash derived from the AD hash and additional processing
D. No password data at all

Correct answer: C
Explanation: PHS stores a hardened, second‑stage hash derived from the AD password hash, not the original hash or plain text password.ssw+1

6. During a review, you notice the last successful sync run was over 24 hours ago. What is the first place you should look to diagnose this?

A. Edit Conditional Access policies
B. Check the sync health and agent status
C. Reset all user passwords
D. Reinstall the sync tool

Correct answer: B
Explanation: You should first review sync health and agent status to see if the scheduler or agent has failed.learn.microsoft

Authentication (Q7–Q11)

7. Your organization wants users to still be able to sign in to Microsoft 365 even if on‑prem domain controllers are offline. Which sign‑in method best supports this?

A. Pass‑Through Authentication
B. Federation with AD FS
C. Password Hash Synchronization
D. Cloud‑only accounts only

Correct answer: C
Explanation: With PHS, authentication happens in Entra ID and does not depend on on‑prem domain controllers.ssw+1

8. A compliance officer insists no password hashes may be stored in the cloud. The organization still wants centralized sign‑in for Microsoft 365 with existing AD passwords. Which sign‑in method is most appropriate?

A. Password Hash Synchronization
B. Pass‑Through Authentication
C. Federation with AD FS
D. Self‑Service Password Reset

Correct answer: B
Explanation: PTA validates credentials against on‑prem DCs in real time and does not store password hashes in Entra ID.learn.microsoft

9. You want to let users reset their own passwords after verifying their identity, without contacting the helpdesk. Which feature should you configure?

A. Conditional Access
B. Self‑Service Password Reset
C. Entra Identity Protection
D. Entra Password Protection

Correct answer: B
Explanation: SSPR allows end users to reset or unlock their own accounts after verifying via registered methods.linkedin

10. Your password policy must prevent users from including the company name and city in their password. Which capability meets this requirement?

A. Increasing password length to 16 characters
B. Entra Password Protection with a custom banned password list
C. Enforcing password change every 30 days
D. Blocking legacy authentication protocols

Correct answer: B
Explanation: Entra Password Protection allows custom banned words and patterns to be blocked in passwords.linkedin

11. A new employee is starting and has not yet registered any MFA methods. You want them to sign in securely on day one without using a temporary password printed on paper. Which approach is most appropriate?

A. Enable SMS‑based MFA only
B. Issue a Temporary Access Pass and require registration at first sign‑in
C. Grant Global Administrator role temporarily
D. Disable Conditional Access

Correct answer: B
Explanation: A Temporary Access Pass provides time‑limited, passwordless sign‑in to bootstrap registration of stronger methods.techcommunity.microsoft

Conditional Access and Risk (Q12–Q18)

12. You’re asked to “require MFA for all admins in all cloud apps.” Which is the most appropriate assignment in Conditional Access?

A. Users: All users; Apps: All cloud apps
B. Users: Directory roles (admin roles); Apps: All cloud apps
C. Users: Specific admin group; Apps: Single app only
D. Users: Guests only; Apps: All cloud apps

Correct answer: B
Explanation: Target directory roles so all admins are covered across all apps without affecting standard users unnecessarily.youtube

13. You created a new CA policy. It’s set to Report‑only. What will happen to user sign‑ins?

A. Users will be blocked if they don’t meet the policy
B. Users will be required to use MFA immediately
C. Nothing is enforced; the policy only logs what would have happened
D. Users will be forced to change passwords

Correct answer: C
Explanation: Report‑only mode evaluates sign‑ins and logs results without enforcing controls, allowing safe testing.learn.microsoft

14. You need to reduce MFA prompts for users in your head office while still requiring MFA for remote users. Which Conditional Access configuration is the best approach?

A. Disable MFA globally
B. Create a named location for office IP ranges and exclude it from an MFA policy
C. Turn off Conditional Access and use Security Defaults only
D. Require MFA only for mobile devices

Correct answer: B
Explanation: Defining the office IPs as a trusted named location and excluding them from an MFA policy reduces prompts for on‑site users while keeping MFA for others.youtube

15. A user signs in from a location they’ve never used before, from a device they’ve never used, and from an IP associated with previous attacks. Which risk signal is most relevant?

A. User risk
B. Sign‑in risk
C. Device compliance status
D. Authentication strength

Correct answer: B
Explanation: These conditions describe an anomalous sign‑in; sign‑in risk evaluates the likelihood that a specific sign‑in is suspicious.techdocweb+1

16. Your security policy states: “If an account is likely compromised, require the user to change their password at next sign‑in.” Which risk‑based policy best fits this requirement?

A. Sign‑in risk policy enforcing MFA
B. User risk policy requiring password change
C. Session control policy to limit access
D. Device compliance policy

Correct answer: B
Explanation: User risk policies act on accounts deemed compromised and typically require a secure password change.learn.microsoft

17. You want to automatically require MFA when a sign‑in appears suspicious, but otherwise allow sign‑ins without MFA where other policies permit it. How should you configure this?

A. User risk policy → High risk → Block access
B. Sign‑in risk policy → Medium and above → Require MFA
C. Conditional Access policy → All users → Block access
D. Security defaults only

Correct answer: B
Explanation: A sign‑in risk policy targeting Medium‑and‑above risk sign‑ins and requiring MFA is the standard pattern for risky sign‑ins.techdocweb+1

18. Your organization wants to protect privileged accounts even more aggressively than standard users. Which approach aligns with recommended best practice?

A. Apply the same risk policies to all users, including admins
B. Exclude admins from all risk policies
C. For admins, block access entirely when user risk is high, while requiring only password change for standard users
D. Force admins to use only SMS MFA

Correct answer: C
Explanation: It’s recommended to treat high‑risk admin accounts more strictly, often blocking access instead of only requiring password change.techdocweb

X Facebook LinkedIn Copy Email Pinterest Reddit Telegram ChatGPT SMS

Admin365.Blog