SC-900 Domains Decoded: What a Data Analyst Already Knows (And What's New)

This is the in-depth I wanted when I started — the one that would've told me, honestly, which parts of SC-900 my background already covered and which parts were genuinely new ground.

Nine years in atmospheric science and data analytics turns out to be worth more on this exam than I expected, but not everywhere. So let me walk through all four domains and mark, domain by domain, what a data person already knows and what they have to build from scratch.

I'll do it with my real numbers on the table: I went from 40% cold on my first practice assessment to 62% a few days later, with Microsoft Compliance as my stubborn gap the whole way. This isn't a victory-lap post. It's a map drawn mid-climb, about a week out from the exam.

If you're coming to SC-900 from data, analytics, IT, or any adjacent field without a Microsoft security background, this is your terrain guide.

First, what SC-900 actually is

SC-900 is Microsoft's Security, Compliance, and Identity Fundamentals certification. It's vendor-specific — it wants to know whether you understand Microsoft's security tools and how they fit together — but it's built on vendor-neutral security concepts underneath. That split is the whole story of this post: the concepts, a data analyst largely already owns. The branded tools are the new part.

The exam is organized into four skill areas. I'll take them in order, easiest-to-hardest for someone with my background — which is not the same order they're hardest for everyone.

Domain 1 — Security, Compliance & Identity Concepts

What I already knew: more than I gave myself credit for.

This domain is the vocabulary layer — the shared-responsibility model, defense in depth, the CIA triad, Zero Trust, encryption and hashing, the difference between authentication and authorization. Here's the thing: a data analyst has been living most of this without the security labels on it.

Shared responsibility? That's just knowing which layer of a system is yours to secure versus the platform's — the same reasoning I used when deciding what my problem was versus the cloud provider's on any data pipeline. Encryption at rest versus in transit? I'd handled that by protecting data. Zero Trust — "never trust, always verify" — is honestly just good analytical hygiene: don't assume the input is clean because of where it came from; verify it.

What was new: mostly the precise Microsoft-flavored definitions and the exact vocabulary the exam wants. Knowing a concept and knowing its tested name are different things, and this domain is where I had to tighten loose intuition into exam-precise terms.

Verdict

Strongest domain for a data background. This is where you bank points.

Domain 2 — Microsoft Entra (Identity & Access)

What I already knew: the logic of access control.

I'd drilled DAC, MAC, and RBAC hard for my ISC2 CC, so when SC-900 got to identity and access, the underlying model wasn't new — role-based access is role-based access. The idea that identity is the new security perimeter, that authentication proves who you are, and authorization decides what you can touch — that carried straight over.

What was new: the branded layer, and this is where SC-900 starts testing you on Microsoft's specific product names. Microsoft Entra ID (what used to be Azure AD), Conditional Access, Multi-Factor Authentication, Single Sign-On, the identity types — and the confusable pairs that live here. This is where the exam gets sneaky:

• Conditional Access vs. Identity Protection — one enforces access policies based on signals; the other detects and flags identity risk. Adjacent, not identical.

• Privileged Identity Management (PIM) vs. Entitlement Management — both sound like "managing who gets what," but one is about just-in-time elevation of privileged roles and the other is about managing access packages at scale.

• 
  

My whole study method became one question for pairs like these: which branded tool owns this exact verb? Not "what does it roughly do" — what's the precise action that distinguishes it from the tool next to it.

Verdict

The concepts transfer; the product names don't. Budget real time for the vocabulary.

Domain 3 — Microsoft Security Solutions (Defender & Sentinel)

What I already knew: the instinct, which is honestly the heart of my whole storm-to-SOC throughline.

This domain covers Microsoft's threat-protection stack — Microsoft Defender in its various forms, and Microsoft Sentinel, the SIEM. A SIEM is, at its core, a data-analysis engine pointed at security logs: ingest signals, correlate them, surface the anomaly. That's the exact shape of the anomaly-detection work I did in atmospheric science — pull in noisy data, find the pattern that doesn't belong. Sentinel is that instinct wearing an enterprise-security badge.

What was new: the product taxonomy. Defender for Endpoint versus Defender for Cloud versus Defender for Office 365 versus Defender for Identity — Microsoft has a Defender for nearly every surface, and the exam wants you to know which Defender guards which door. That's memorization, not intuition.

Verdict

The "what a SIEM is for" part is intuitive if you come from data; the "which product covers which surface" part is flashcards.

Domain 4 — Microsoft Compliance (Purview)

What I already knew: the least. This is my gap, and I'm not going to pretend otherwise.

Every practice assessment, from the 40% cold baseline to the 62%, has flagged the same cluster: Compliance. It's the domain furthest from a data-analytics background, because it's less about analyzing data and more about governing it — retention, classification, data lifecycle, insider risk, compliance posture — through a specific stack of Microsoft Purview tools.

Why it's hard: it's a wall of branded tools that do adjacent-sounding things, with almost no intuitive hook to hang them on. The confusable questions here are brutal:

• Which tool owns data retention?

• Which one classifies and labels sensitive data?

• Which one scores your compliance posture — and is that Compliance Manager, or something else?

• Where does Data Loss Prevention sit versus Information Protection?

  
  

There's no "I've basically done this before" shortcut. This domain is pure build-from-scratch, and it's where my final week is going — daily, not every-other-day, drilling Purview and Compliance Manager side by side until the verbs stop blurring.

Verdict

Hardest domain for a data background, and the one that separates a pass from a fail if you neglect it.

The honest map, in one view

If you're coming from data or analytics, here's the terrain:

• Domain 1 (Concepts): you mostly know this. Tighten the vocabulary.

  
  

• Domain 2 (Entra): you know the access logic. Learn the product names.

  
  

• Domain 3 (Defender/Sentinel): you know what a SIEM is for. Memorize which product covers which surface.

  
  

• Domain 4 (Compliance/Purview): new ground. Give it the most time, not the least.

  
  

The pattern is consistent across all four: the security concepts transfer; the Microsoft branding doesn't. Your background is a real head start on why each control exists. The exam's difficulty lives in which branded tool owns which specific job — and that's true whether you're a data analyst, a helpdesk tech, or a total beginner. Nobody intuits that Purview owns retention. You learn it.

Where I am, a week out

40% → 62% → the final push. My concepts and access domains are solid, my Sentinel instinct is doing real work, and Compliance is the wall I'm still climbing. That's not exam-ready yet — it's honestly mid-climb, and I'd rather show you that than a tidy fiction.

The plan for the last stretch is exactly what the map says: stop spending time on the domains that already transfer, and pour it into the one that doesn't. Read where the misses concentrate, commit the hours there, leave the green domains alone.

How I'd explain this in a SOC interview

Ask me how I get up to speed on an unfamiliar tool stack fast, and this is the answer: I don't treat a new platform as a blank slate — I separate what's genuinely new from what's just a rebrand of a fundamental I already hold, so I can spend my limited learning time on the actual gap instead of re-learning concepts I own under different names. Then I baseline honestly, find where my knowledge is thinnest, and load my effort there rather than spreading it evenly. That's how you onboard onto a SOC's specific tooling — Sentinel, whatever Defender products, whatever ticketing and EDR they run — without drowning: map the new vendor's names onto the security concepts that don't change, and drill the true unknowns. The tool changes. The question underneath doesn't.

A week out. The map is drawn. Now I climb the last of it.

Storm to SOC — read the map, then move. 💜