- Sie untersuchen regelmäßig Alerts, wissen aber nicht immer, welche Signale wirklich zusammengehören.
- Sie arbeiten mit Microsoft Defender XDR, Microsoft Sentinel oder Entra ID und möchten Vorfälle systematischer triagieren.
- Sie wollen vom allgemeinen IT- oder Security-Betrieb näher an SOC-Arbeit, Threat Hunting oder Incident Response heranrücken.
- Sie suchen eine Zertifizierung, die operative Sicherheitsarbeit sichtbarer macht, statt nur allgemeines Sicherheitswissen zu bestätigen.
SC-200 ist die Prüfung für die Zertifizierung Microsoft Certified: Security Operations Analyst Associate und bestätigt praxisnahe Fähigkeiten zur Erkennung, Untersuchung und Reaktion auf Bedrohungen in Microsoft-zentrierten Umgebungen. Sie ist besonders relevant, wenn der Arbeitsalltag aus Alert-Triage, KQL-Abfragen, Incident-Dokumentation, Microsoft Sentinel, Microsoft Defender XDR und Abstimmung mit IT-Ops besteht.
Stand: 2026. Microsoft verwendet heute Entra ID statt Azure AD; ältere Dokumentationen, Tickets und Runbooks enthalten jedoch oft noch den früheren Namen. Wer sich auf SC-200 vorbereitet, sollte deshalb nicht nur die aktuellen Produktnamen kennen, sondern auch verstehen, wie ältere Begriffe in bestehende Betriebsprozesse übersetzt werden.
Warum SC-200 für Security Operations relevant ist
Security Operations ist eine operative Disziplin. Der Wert einer Analystenrolle entsteht nicht dadurch, dass jeder Alert geöffnet wird, sondern dadurch, dass Muster erkannt, Zusammenhänge hergestellt und sinnvolle nächste Schritte eingeleitet werden. Genau an dieser Stelle passt SC-200 gut: Die Zertifizierung prüft Fähigkeiten rund um Erkennung, Untersuchung und Reaktion mit Microsoft-Sicherheitsdiensten.
Microsoft Learn beschreibt die Prüfung SC-200 rollenbasiert und ordnet sie dem Security Operations Analyst zu. Im Kern geht es um Microsoft Sentinel als SIEM- und SOAR-Plattform, Microsoft Defender XDR für Untersuchungen über Endpunkte, Identitäten, E-Mail und Cloud-Apps hinweg sowie um KQL als Abfragesprache für Analyse und Hunting. Das macht die Zertifizierung praxisnah, wenn eine Organisation bereits stark auf Microsoft 365, Azure und Defender-Technologien setzt.
Die Zertifizierung ersetzt keine SOC-Erfahrung. Sie kann aber eine gemeinsame Sprache schaffen: Was ist ein Incident, wann wird ein Alert eskaliert, welche Evidenz gehört in ein Postmortem, und wie wird eine KQL-Hypothese sauber belegt? In Teams mit unterschiedlichen Erfahrungsständen ist diese gemeinsame Arbeitsweise oft wichtiger als das reine Bestehen der Prüfung.
Welche Fähigkeiten SC-200 sichtbar macht
Ein guter Security Operations Analyst arbeitet nicht nur mit Tools, sondern mit Hypothesen. Ein ungewöhnlicher Login ist zunächst ein Signal, kein fertiger Vorfall. Erst wenn Benutzerkontext, Gerät, IP-Adresse, Geografie, MFA-Status, Endpoint-Telemetrie und betroffene Ressourcen zusammenpassen, entsteht eine belastbare Einschätzung.
SC-200 unterstützt genau diese Denkweise. Kandidaten beschäftigen sich mit Sentinel-Workspaces, Datenkonnektoren, Analyseregeln, Workbooks, Incidents, Hunting Queries und Automatisierung. In Microsoft Defender XDR geht es darum, Alerts über Domänen hinweg zu korrelieren und Angriffe nicht isoliert als E-Mail-, Endpoint- oder Identitätsproblem zu betrachten.
Eine praktische Triage-Heuristik hilft im Alltag: Priorität ergibt sich nicht allein aus dem Schweregrad eines Alerts. Wichtiger ist der Auswirkungsradius. Ein einzelner fehlgeschlagener Login eines normalen Benutzerkontos hat ein anderes Gewicht als ein erfolgreicher Login eines privilegierten Kontos von einem unbekannten Standort, gefolgt von verdächtigen Endpoint-Aktivitäten und Zugriffen auf sensible Daten.
Hier zeigt sich auch, warum KQL für SC-200 so zentral ist. Wer nur vordefinierte Dashboards liest, erkennt viele Ereignisse erst dann, wenn ein System sie bereits modelliert hat. Wer eigene Abfragen schreiben kann, prüft Hypothesen schneller und kann neue Angriffsmuster untersuchen, bevor daraus standardisierte Regeln werden.
Die folgende vereinfachte Abfrage eignet sich für ein Übungslab, wenn erfolgreiche Anmeldungen privilegierter Konten mit Alerts aus Microsoft Defender XDR oder Sentinel abgeglichen werden sollen. Sie ist kein fertiger Produktionsdetektor, zeigt aber die Denkweise hinter einer ersten Korrelation.
Example — KQL-Korrelation von Benutzer- und Alert-Signalen
let lookback = 24h;
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| where UserPrincipalName has_any ("admin", "privileged")
| project SigninTime = TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName
| join kind=inner (
SecurityAlert
| where TimeGenerated > ago(lookback)
| project AlertTime = TimeGenerated, Entities, AlertName, Severity
) on $left.UserPrincipalName == $right.Entities
| project SigninTime, AlertTime, UserPrincipalName, IPAddress, AppDisplayName, AlertName, Severity
| order by AlertTime desc
Der Lerneffekt liegt weniger in der konkreten Syntax als im Vorgehen: Ein Identitätssignal wird mit einem Sicherheitssignal verbunden, anschließend wird nach Kontext priorisiert. In einem realen Workspace müsste die Abfrage an Datenmodell, Entity-Mapping und Normalisierung angepasst werden.
Ein kleines SOC-Lab für die Vorbereitung
Lesen allein reicht für SC-200 selten aus, weil viele Prüfungsfragen operative Entscheidungen abbilden. Wer Sentinel nur aus Screenshots kennt, versteht zwar Begriffe, hat aber kaum Gefühl für Datenquellen, Latenz, Regelrauschen und Kostensteuerung. Ein kleines Lab ist deshalb oft der Unterschied zwischen oberflächlicher Prüfungsvorbereitung und belastbarem Können.
Ein sinnvolles Übungslab besteht aus einem Microsoft Sentinel-Workspace, angebundenen Signalen aus Entra ID, Microsoft 365 und Microsoft Defender XDR sowie einigen bewusst einfachen Analyseregeln. Fortgeschrittene Lernende können einen zweiten Workspace hinzufügen, um Mandanten-, Regionen- oder Kostenfragen zu simulieren. Wichtig ist nicht die Größe des Labs, sondern dass Daten wirklich fließen und Incidents entstehen, die untersucht werden können.
Eine häufige Implementierungsfalle liegt in der Datenaufnahme. Viele Teams aktivieren zu viele Datenquellen, bevor klar ist, welche Use Cases sie abdecken sollen. Das erzeugt Kosten, erhöht das Rauschen und erschwert Tuning. Besser ist ein schrittweiser Ansatz: zuerst relevante Identity-, Endpoint- und E-Mail-Signale, anschließend gezielte Erweiterung um weitere Logs, wenn ein Detection Use Case sie tatsächlich benötigt.
Auch Log-Normalisierung wird in Übungen oft unterschätzt. Unterschiedliche Quellen beschreiben Benutzer, Hosts und IP-Adressen nicht immer identisch. Wenn Entity-Mapping nicht sauber gepflegt ist, wirken Incidents fragmentiert, obwohl sie zum selben Angriff gehören. Analysten sollten deshalb früh prüfen, ob Regeln, Workbooks und Hunting Queries dieselben Entitäten konsistent verwenden.
Für SOAR eignet sich als einfache Übung ein Logic Apps-Playbook, das bei einem hoch priorisierten Incident zunächst Informationen sammelt, einen Teams- oder E-Mail-Hinweis an das SOC sendet und eine Genehmigung anfordert, bevor ein Gerät über Defender isoliert wird. Gerade diese Genehmigungsstufe ist lehrreich: Automatisierung soll beschleunigen, aber riskante Eindämmungsmaßnahmen brauchen klare Grenzen, Rollen und Protokollierung.
Wer strukturierte Praxis sucht, kann ein geführtes Microsoft-Sicherheitstraining nutzen, solange der Schwerpunkt auf realistischen Laboren und nicht auf Folienwiederholung liegt. Entscheidend ist, dass Lernende Analyseregeln bauen, False Positives reduzieren, Incidents dokumentieren und Playbooks testen.
SC-200, AZ-500 oder SC-100: die richtige Zertifizierung nach Aufgabe wählen
Die Verwechslung zwischen Microsoft-Sicherheitszertifizierungen ist nachvollziehbar, weil sich Produkte und Themen überschneiden. Eine einfache Entscheidungslogik hilft: SC-200 gehört in den Betrieb, AZ-500 in die technische Absicherung von Azure-Umgebungen, SC-100 in die Sicherheitsarchitektur über Domänen hinweg.
Wenn der Arbeitstag aus Alert-Triage, Incident Investigation, Threat Hunting, Sentinel-Regeln und Defender-Untersuchungen besteht, passt SC-200 am besten. Wenn die Hauptaufgaben in Netzwerksegmentierung, Key Vault, Azure Policy, Identitäts- und Plattformhärtung liegen, ist AZ-500 näher am Alltag. Wenn es um Zielarchitekturen, Sicherheitsstrategie, Zero-Trust-Design, Governance und Abstimmung mit Geschäftsrisiken geht, ist SC-100 der passendere nächste Schritt.
Diese Trennung ist auch für Karriereplanung nützlich. Ein SOC-Analyst kann mit SC-200-Grundlagen beginnen und später je nach Richtung vertiefen: mehr Engineering mit AZ-500, mehr Architektur mit SC-100 oder mehr herstellerneutrale Governance mit Zertifizierungen wie CISSP oder CISM. Die Reihenfolge sollte aus den tatsächlichen Aufgaben entstehen, nicht aus einer allgemeinen Rangfolge von Zertifikaten.
Wie SC-200 im Lebenslauf wirkt
Eine Zertifizierung ist für Arbeitgeber ein Signal, aber selten der alleinige Beleg für Einsatzfähigkeit. Im SOC zählen nachvollziehbare Arbeitsproben: eine gut erklärte Hunting Query, eine getunte Analyseregel, ein dokumentiertes Incident-Postmortem oder ein Playbook, das sauber zwischen automatischer Informationssammlung und genehmigungspflichtiger Eindämmung unterscheidet.
In technischen Interviews wird häufig nicht nur nach Definitionen gefragt. Kandidaten müssen erklären, wie sie einen Alert priorisieren, welche Daten sie als Nächstes prüfen und wann sie eskalieren würden. KQL-Aufgaben am Whiteboard oder in einer geteilten Umgebung sind dabei besonders aufschlussreich, weil sie Denkweise und Datenverständnis sichtbar machen.
Ein kleines Portfolio kann deshalb stärker wirken als ein Badge ohne Kontext. Sinnvoll sind anonymisierte Beispiele: eine KQL-Abfrage mit kurzer Hypothese, ein Diagramm im eigenen Notizsystem zur Incident-Timeline, eine Beschreibung der False-Positive-Reduktion einer Regel und ein kurzer Lessons-Learned-Abschnitt. Vertrauliche Informationen aus Arbeitgeberumgebungen gehören selbstverständlich nicht hinein.
Für Teamleads ist SC-200 ebenfalls nützlich, weil es Skill-Gaps konkreter macht. Fehlen KQL-Kenntnisse, Sentinel-Administration, Defender-XDR-Untersuchungen oder SOAR-Verständnis? Eine Zertifizierung kann diese Bereiche strukturieren, ersetzt aber nicht Rollenklärung, Zugriffskonzepte und abgestimmte Runbooks.
Vorbereitung ohne Prüfungsblindheit
Die SC-200-Vorbereitung sollte mit den offiziellen Microsoft-Learn-Prüfungszielen abgeglichen werden, aber sie sollte nicht dort enden. Prüfungsziele zeigen, welche Fähigkeiten gemessen werden; operative Reife entsteht durch Wiederholung, Fehleranalyse und den Umgang mit unvollständigen Informationen.
Ein tragfähiger Lernplan kombiniert Dokumentation, Labs und Nachbereitung. Nach jeder Übung sollte klar sein, welche Datenquelle verwendet wurde, welche Annahme geprüft wurde, welche Regel zu viel Rauschen erzeugte und welche Eskalation sinnvoll gewesen wäre. Diese Reflexion bereitet besser auf szenariobasierte Fragen vor als das Auswendiglernen einzelner Menüpfade.
Zusätzliche Orientierung bieten praxisnahe Fallbeispiele zur Microsoft Certified Security Operations Analyst Zertifizierung und ein fokussierter Leitfaden zur Vorbereitung auf SC-200. Beide Arten von Material sind am wertvollsten, wenn sie parallel zu einem eigenen Lab genutzt werden.
Ein häufiger Lernfehler besteht darin, Sentinel als reine Prüfungsoberfläche zu behandeln. In der Praxis hängen Ergebnisse stark von Datenqualität, Rollenmodellen und Betriebsprozessen ab. Wer nie RBAC, Datenkonnektoren, Regelaktivierung, Incident-Owner und Playbook-Berechtigungen getestet hat, kennt zwar die Theorie, wird aber bei der Umsetzung langsam.
Organisatorische Umsetzung im SOC
Security Operations funktioniert nur, wenn technische Fähigkeiten in klare Abläufe eingebettet sind. RBAC entscheidet, wer Incidents lesen, Regeln ändern, Playbooks ausführen oder Datenquellen anbinden darf. Zu großzügige Rechte erhöhen Risiko; zu enge Rechte verlangsamen Untersuchungen. Gute Teams trennen deshalb Untersuchungsrechte, Administrationsrechte und Freigaben für Eindämmungsmaßnahmen.
Runbooks sind ebenso wichtig. Ein Tier-1-Analyst braucht klare Kriterien, wann ein Alert geschlossen, angereichert oder eskaliert wird. Tier 2 benötigt ausreichend Kontext, damit nicht jede Untersuchung von vorn beginnt. Incident Responder brauchen belastbare Evidenz, um Systeme zu isolieren, Konten zu sperren oder Wiederherstellungsmaßnahmen mit IT-Ops zu koordinieren.
Eine kurze Fallvignette zeigt den Unterschied. Ein Alert meldet eine verdächtige Anmeldung eines privilegierten Kontos. Ein unerfahrener Analyst priorisiert nur nach Severity. Ein reiferer Prozess prüft zusätzlich, ob das Konto auf kritische Ressourcen zugriff, ob Defender Endpoint-Aktivitäten auf demselben Gerät meldet, ob die IP-Adresse bereits in anderen Incidents auftaucht und ob Änderungen an Postfachregeln oder OAuth-App-Berechtigungen erfolgt sind. Erst danach wird entschieden, ob Beobachtung, Eskalation oder Eindämmung angemessen ist.
Die Zusammenarbeit mit IT-Ops ist dabei kein Nebenthema. Geräteisolation, Passwortzurücksetzung, Netzwerkänderungen oder App-Blockaden haben betriebliche Folgen. SOAR-Playbooks sollten deshalb nicht nur technische Aktionen ausführen, sondern Benachrichtigung, Genehmigung, Ticketbezug und Dokumentation einschließen.
Wohin sich die Rolle entwickelt
KI-gestützte Funktionen verändern die SOC-Arbeit, aber sie nehmen Analysten nicht die Verantwortung für Kontext ab. Modelle können Ereignisse zusammenfassen, Muster vorschlagen und Routineaufgaben beschleunigen. Die entscheidenden Fragen bleiben menschlich geprägt: Ist die vorgeschlagene Eindämmung verhältnismäßig, welche Systeme sind kritisch, welche Geschäftsprozesse wären betroffen, und welche Evidenz reicht für eine Eskalation?
Dadurch verschiebt sich der Schwerpunkt der Rolle. Analysten werden stärker zu Gestaltern von Detection Logic, Automationsgrenzen und Incident-Prozessen. Wer KQL versteht, Regeln tunen kann und Playbooks kritisch prüft, bleibt auch dann relevant, wenn Tools mehr Vorarbeit leisten.
Cloud-Sicherheit verstärkt diese Entwicklung. Identitäten, SaaS-Anwendungen, Endpunkte und Cloud-Ressourcen erzeugen Signale, die nur im Zusammenhang aussagekräftig sind. Ein zusätzlicher Blick auf Cloud-Sicherheitskompetenzen kann deshalb sinnvoll sein, wenn SOC-Arbeit zunehmend hybride oder cloudnative Umgebungen umfasst.
Der nächste sinnvolle Schritt
SC-200 ist besonders stark, wenn sie als Nachweis operativer Arbeitsfähigkeit verstanden wird. Die Zertifizierung passt zu Fachkräften, die Alerts nicht nur bearbeiten, sondern Ursachen, Angriffspfade und angemessene Reaktionen erklären wollen. Ihr Nutzen wächst, wenn Vorbereitung, Lab-Arbeit und dokumentierte Praxisartefakte zusammenkommen.
Ein sinnvoller nächster Schritt ist, die eigenen Tagesaufgaben ehrlich mit der Zertifizierung abzugleichen: Wer untersucht und reagiert, sollte SC-200 priorisieren; wer Plattformen absichert, prüft eher AZ-500; wer Sicherheitsarchitektur verantwortet, schaut in Richtung SC-100. Readynez kann dabei als strukturierter Lernpartner dienen, wenn eine Organisation SC-200 nicht isoliert, sondern als Teil eines belastbaren Security-Operations-Skillplans aufbauen möchte.
