SC-500 study materials
SC-500 study resources

SC-500 common mistakes

SC-500 · Understand the traps and how to avoid them.

Mistake 1

Treating authentication and authorization as interchangeable when answering questions about Zero Trust or access control, so the candidate picks 'authorization' where the scenario describes verifying identity.

The two terms appear together in nearly every identity scenario and the exam deliberately builds distractors around them; candidates who learned them as a single concept skim past the verb in the stem.

What to do instead

Before answering, underline the verb in the scenario: 'prove who you are' maps to authentication; 'what you are allowed to do' maps to authorization. Practice sorting a list of 20 short scenario sentences into the two buckets until it is automatic.

Mistake 2

Confusing the roles of Microsoft Entra ID and on-premises Active Directory, choosing Entra ID for a capability that actually belongs to domain controllers such as Group Policy or Kerberos delegation.

Many candidates come from an on-premises background and mentally map 'directory service' onto the product they know, so they attribute legacy AD DS features to the cloud service.

What to do instead

Build a two-column comparison of Entra ID versus AD DS covering protocol, management tool, join type, and policy mechanism, and memorize the boundary: cloud identity, conditional access, and SSO on one side; Group Policy, OU structure, and Kerberos on the other.

Mistake 3

Selecting Microsoft Defender for Cloud where the scenario is about endpoint threat protection, or vice versa, because both products carry the Defender name.

The shared branding creates a false family resemblance, and candidates answer from name recognition rather than from the workload each product actually protects.

What to do instead

Memorize a one-line scope statement for each Defender workload (Cloud = posture and server/container protection in Azure and multicloud; Endpoint = device detection and response; Identity = directory-based detection; Office = email and collaboration). Recite the scope line before evaluating any option.

Mistake 4

Mixing up the Microsoft Purview solutions, for example choosing Data Loss Prevention when the scenario describes classifying and labeling content, or choosing sensitivity labels when the requirement is to block sharing.

Purview is a suite of adjacent capabilities that all touch the same content, and candidates learn the names as a list without mapping each to its distinct job.

What to do instead

Create a decision table with rows for classification, labeling, blocking, retention, and insider risk, and one column per Purview solution. Answer every practice scenario by first naming the job the scenario demands, then reading across the row.

Mistake 5

Answering Conditional Access questions by choosing a session control or a standalone policy feature when the requirement is an access control evaluated at sign-in, such as requiring MFA or a compliant device.

Conditional Access is described in marketing material as a broad 'policy engine', so candidates over-extend it to any policy-like requirement in the stem.

What to do instead

Anchor on the if-then structure: Conditional Access evaluates signals at sign-in and grants or blocks. If the scenario mentions an already-signed-in session, look outside Conditional Access. Write the if-then for each practice scenario before looking at the options.

Mistake 6

Assuming the highest-privilege role is the correct answer for a least-privilege scenario, picking Global Administrator where a scoped role such as User Administrator or a custom role is required.

Candidates remember Global Administrator as the role that 'can do everything' and default to it under time pressure, ignoring the least-privilege phrasing in the stem.

What to do instead

Treat words like 'least privilege', 'only', and 'specific department' as hard constraints. For each practice question, name the narrowest built-in role that satisfies the stated task before reading the answer choices.

Mistake 7

Confusing the shared responsibility model boundary, attributing a control such as physical datacenter security or hypervisor patching to the customer in a cloud scenario.

The model shifts by service type (IaaS, PaaS, SaaS), and candidates memorize a single diagram instead of the per-service split, so they apply the IaaS boundary to every question.

What to do instead

Draw the model three times, once each for IaaS, PaaS, and SaaS, and mark where the line falls in each. When a scenario appears, first classify the service model, then apply the matching boundary.

Mistake 8

Treating compliance score, compliance manager assessments, and regulatory compliance offerings as interchangeable, choosing an assessment template when the question asks what proves a control is met.

The compliance tooling uses overlapping vocabulary (assessment, score, control, improvement action) and candidates never separate the artifact from the measurement.

What to do instead

Define each term in one sentence on a flashcard: assessment template, assessment, control, improvement action, and compliance score. For each practice item, identify which of the five the question is actually asking about before evaluating options.

Mistake 9

Choosing a threat-protection feature for a posture-management requirement, for example selecting a detection alert when the scenario asks for a secure score recommendation or a regulatory benchmark view.

Posture and protection are presented together in product documentation, and candidates conflate 'know my risk' with 'detect an attack'.

What to do instead

Use the question 'is something happening now, or is this about how I am configured?' Detection answers the first; posture and benchmarks answer the second. Tag every practice scenario with one of those two labels before answering.

Mistake 10

Ignoring the identity governance family (access reviews, entitlement management, lifecycle workflows) and answering governance scenarios with authentication features such as MFA or password protection.

Governance is the least familiar area for candidates focused on sign-in security, so they pattern-match 'access' to authentication controls.

What to do instead

Learn governance as the answer to 'who should have access over time and who approves it'. Map access reviews to periodic recertification, entitlement management to request-and-approval packages, and lifecycle workflows to joiner/mover/leaver automation, then drill scenarios that use those exact phrases.