Azure Incident Investigation

A strong Azure incident investigation is not just about closing an alert. It is about determining what happened, how far the activity spread, what evidence supports the conclusion, how to contain the threat safely, and how to prevent recurrence.

Welcome to the Azure Incident Investigation Runbook.

This runbook brings together the practical skills from:

• Microsoft Sentinel Lab
• Microsoft Defender for Cloud Lab
• Microsoft Entra ID Security Lab
• Azure Network Security Lab
• Azure Security Assessment Runbook
• Microsoft Entra ID Security Review Runbook
• Azure Network Security Review Runbook

The objective is to move from:

I can investigate an individual Azure alert.

to:

I can perform a structured cloud incident investigation from initial detection through containment, recovery, and post-incident reporting.

This runbook is relevant to roles such as:

• Security Operations Analyst
• Cloud Security Analyst
• Azure Security Engineer
• Incident Responder
• Microsoft Sentinel Analyst
• Cloud Security Consultant
• Security Engineer
• Cloud Security Architect

🎯 Runbook Information

Item	Details
Runbook	Azure Incident Investigation
Difficulty	Intermediate → Advanced
Estimated Time	Depends on incident scope
Primary Focus	Detection, Investigation, Containment & Recovery
Target Roles	SOC Analyst, Azure Security Engineer, Incident Responder
Certification Alignment	SC-200, AZ-500, SC-300, SC-100
Output	Incident Timeline, Evidence Register, Scope Assessment, Root Cause, Incident Report

🏢 Scenario

You are part of the security team responsible for an Azure environment.

Microsoft Sentinel reports suspicious activity involving a privileged identity.

Shortly afterward:

• an NSG is modified
• a new application credential appears
• Defender for Cloud reports suspicious activity on a VM
• unusual outbound network traffic is observed

Management asks:

“Has the Azure environment been compromised, what has been affected, and what should we do now?”

Your job is to determine:

• whether the alert is legitimate
• how the activity began
• which identities are affected
• which resources were changed
• whether persistence exists
• whether data or workloads were accessed
• how far the attacker may have moved
• how to contain the incident
• how to restore secure operations

🎯 Investigation Objectives

By the end of this runbook, you should be able to:

• open and classify an incident
• validate Sentinel alerts
• investigate Microsoft Entra sign-ins
• review Entra audit activity
• investigate Azure Activity Logs
• correlate Defender for Cloud findings
• investigate suspicious RBAC changes
• investigate compromised identities
• investigate application identities
• investigate compromised VMs
• review network evidence
• build an incident timeline
• determine incident scope
• identify persistence
• preserve evidence
• contain affected identities and workloads
• support eradication and recovery
• determine root cause
• document lessons learned

⚠️ Authorization and Response Authority

Before performing incident-response actions, confirm:

• tenant and subscriptions in scope
• incident-response authority
• whether accounts may be disabled
• whether sessions may be revoked
• whether resources may be isolated
• whether VMs may be stopped
• whether snapshots may be collected
• whether network controls may be modified
• evidence-retention requirements
• legal/compliance escalation requirements

🧠 Important Principle

Do not jump immediately from:

Alert

to:

Delete everything.

Containment should reduce risk while preserving your ability to understand what happened.

🧭 Incident Investigation Workflow

Use:

Prepare
  ↓
Detect
  ↓
Validate
  ↓
Classify
  ↓
Scope
  ↓
Contain
  ↓
Preserve Evidence
  ↓
Investigate
  ↓
Eradicate
  ↓
Recover
  ↓
Root Cause
  ↓
Lessons Learned

01 — Open an Incident Record

Assign a unique incident ID.

Example:

AZ-IR-2026-001

Record:

Field	Details
Incident ID
Detection Time
Detection Source
Initial Severity
Tenant
Subscription
Incident Owner
Status

02 — Capture the Original Alert

Record the original detection exactly as received.

Possible sources:

• Microsoft Sentinel

• Microsoft Defender for Cloud

• Microsoft Defender

• Microsoft Entra ID

• Azure Monitor

• user report

• external intelligence

Create:

Alert Source:

Alert Name:

Severity:

Affected Identity:

Affected Resource:

Time:

Description:

Evidence:

03 — Validate the Detection

Do not assume an alert means confirmed compromise.

Determine whether the activity is:

False Positive
Benign Positive
Suspicious
Confirmed Malicious

🧠 Validation Questions

Ask:

Was the user expected to perform this activity?

Was there an approved change?

Is the location unusual because of VPN or travel?

Is automation responsible?

Does another telemetry source confirm suspicious behavior?

04 — Assign Initial Severity

Use a consistent model.

🔴 Critical

Examples:

• confirmed Global Administrator compromise

• broad tenant takeover

• major sensitive-data exposure

• multiple subscriptions affected

🟠 High

Examples:

• privileged account compromise

• production workload compromise

• unauthorized security-control changes

🟡 Medium

Examples:

• suspicious activity with limited scope

• lower-privilege compromised identity

🔵 Low

Examples:

• minor suspicious activity

• likely benign event requiring confirmation

05 — Establish the Investigation Time Window

Start with:

First Known Suspicious Event
        ↓
Look Backward
        ↓
Look Forward

Search backward for:

• initial access

• credential compromise

• suspicious authentication

• reconnaissance

Search forward for:

• privilege escalation

• resource changes

• persistence

• lateral movement

• data access

06 — Identify the Primary Identity

Determine whether the activity involves:

• Entra user

• privileged administrator

• guest

• service principal

• managed identity

• automation identity

Record:

Identity	Type	Privileged?	Expected Activity?

🧠 Key Question

Ask:

Which identity actually performed the action?

Do not assume the visible human account was the only identity involved.

07 — Review Microsoft Entra Sign-In Logs

For the affected user review:

• timestamp

• source IP

• location

• application

• authentication result

• MFA

• device

• Conditional Access result

Create:

Time	IP	Location	Application	Result	MFA	Risk

🧠 Sign-In Principle

A successful sign-in proves:

authentication succeeded.

It does not prove:

the user was legitimate.

08 — Investigate Suspicious Authentication Patterns

Look for:

• unusual geography

• unfamiliar IP

• unfamiliar device

• repeated failures followed by success

• unexpected privileged-account use

• unusual applications

🚨 Example Sequence

20 Failed Sign-Ins
      ↓
Successful Authentication
      ↓
Privileged Azure Change

This should receive immediate attention.

09 — Review Conditional Access Results

Determine:

• which policies applied

• whether MFA was required

• whether policies were bypassed

• whether the identity was excluded

🚨 Important

An unexplained Conditional Access exclusion may itself be part of the incident.

10 — Review Entra Audit Logs

Search for high-impact identity events.

Examples:

• role assignments

• group membership changes

• application registration changes

• credential creation

• Conditional Access changes

• guest creation

🧠 Identity Attack Pattern

Suspicious Sign-In
      ↓
Privilege Change
      ↓
Persistence

11 — Investigate Privileged Role Changes

If a user suddenly receives a privileged role:

ask:

• who assigned it?

• when?

• was PIM involved?

• was the change approved?

• what happened afterward?

📋 Privilege Timeline

Time	Actor	Target	Role	Legitimate?

12 — Review PIM Activity

Where PIM is used, investigate:

• role activation

• approver

• justification

• activation duration

• MFA

• unusual timing

🧠 Important

A legitimate PIM activation has a very different context from an unauthorized permanent role assignment.

13 — Review Application Registrations

Look for suspicious changes to:

• app registrations

• service principals

• permissions

• client secrets

• certificates

🚨 Persistence Pattern

Compromised Administrator
        ↓
Creates App Credential
        ↓
Service Principal
        ↓
Persistent Access

This can remain even after the original user credential is reset.

14 — Search for New Client Secrets

Review:

• application

• credential creation time

• actor

• expiry

• permissions

🚨 High-Risk Question

Ask:

Did the attacker create another way back into the environment?

15 — Search for New or Modified Service Principals

Investigate:

• unexpected application identities

• new admin consent

• permission increases

• new credentials

• ownership changes

16 — Review Admin Consent Activity

If broad application permissions were granted:

determine:

• who approved the consent

• which application

• which permissions

• whether business justification exists

17 — Review Azure RBAC Changes

Investigate changes involving:

• Owner

• Contributor

• User Access Administrator

• custom roles

• role assignments

🧠 Cloud Persistence

An attacker may move from:

Entra Privilege
      ↓
Azure RBAC
      ↓
Subscription Access

18 — Review Azure Activity Logs

Azure Activity helps answer:

Who changed Azure resources?

Search for:

• VM operations

• NSG changes

• route-table changes

• public IP creation

• resource deployment

• Key Vault changes

• storage changes

• RBAC changes

📋 Azure Activity Timeline

Time	Identity	Operation	Resource	Result

19 — Investigate Network Security Changes

Look for changes involving:

• NSGs

• route tables

• firewall rules

• public IPs

• peerings

🚨 Attack Pattern

Compromised Identity
      ↓
NSG Changed
      ↓
Public Port Opened
      ↓
Workload Accessed

20 — Review Defender for Cloud Alerts

For related alerts document:

• affected resource

• severity

• time

• alert type

• evidence

• recommended response

🧠 Correlation Principle

Defender tells you:

suspicious workload behavior may exist.

Azure Activity may tell you:

who changed the workload.

Entra may tell you:

how that identity authenticated.

Combine them.

21 — Review Microsoft Sentinel Incident

Open the Sentinel incident.

Review:

• alert sources

• entities

• timeline

• related incidents

• severity

• owner

22 — Review Incident Entities

Possible entities:

• account

• IP

• host

• Azure resource

• URL

• file

Create an entity map.

User A
  ↓
IP X
  ↓
Azure VM
  ↓
NSG Change
  ↓
External IP Z

23 — Build the Master Incident Timeline

Create one chronological timeline combining:

• Entra sign-ins

• Entra audit

• PIM

• Azure Activity

• Defender alerts

• Sentinel incidents

• network telemetry

📋 Master Timeline

Time	Event	Source	Identity/Resource	Significance

🧠 Timeline Goal

The incident should eventually become a story you can explain clearly.

24 — Investigate a Suspected Compromised VM

Record:

• VM name

• subscription

• resource group

• public IP

• private IP

• subnet

• NSG

• managed identity

• disks

• Defender status

25 — Review VM Network Exposure

Ask:

• does it have a public IP?

• are SSH/RDP ports exposed?

• which NSGs apply?

• was exposure recently changed?

26 — Review VM Identity

Determine whether the VM uses:

• system-assigned managed identity

• user-assigned managed identity

• service principal credentials

🧠 Key Question

Could the compromised workload access Azure resources through its identity?

27 — Review Managed Identity Activity

Search Azure activity and relevant logs for actions performed using the workload identity.

Determine:

• resources accessed

• permissions

• timing

• unusual operations

28 — Review Network Telemetry

Use available telemetry such as:

• Azure Firewall

• NSG-related flow information where available

• Sentinel network logs

• Defender context

Investigate:

• source

• destination

• port

• protocol

• time

• volume

🧠 Network Evidence Question

Ask:

Where did this workload communicate before and after the alert?

29 — Investigate Suspicious Outbound Traffic

Example:

Azure VM
   ↓
Unexpected External IP
   ↓
Repeated Outbound Connections

Ask:

• legitimate destination?

• application dependency?

• threat intelligence?

• other compromised workloads?

30 — Investigate East-West Movement

Review communication between:

• VM to VM

• frontend to application

• application to database

• development to production

• spoke to spoke

🧠 Lateral Movement in Azure

May occur through:

Network Connectivity
        +
Azure RBAC
        +
Managed Identity
        +
Application Permissions

Do not investigate only IP traffic.

31 — Review Storage Access

If storage is involved, review:

• network configuration

• role assignments

• access mechanisms

• recent configuration changes

• data access evidence where available

🧠 Data Incident Question

Ask:

Was sensitive data accessed, modified, deleted, or exposed?

32 — Review Key Vault Activity

Investigate:

• secret access

• key access

• permission changes

• public access changes

• credential updates

🚨 Persistence / Credential Risk

An attacker may retrieve:

• application secrets

• certificates

• keys

which could expand the incident.

33 — Determine Initial Access

Possible initial-access paths may include:

• stolen password

• stolen session

• weak MFA

• exposed application secret

• compromised VM

• exposed administrative port

• over-trusted application

🧠 Important

Do not write:

Sentinel alert

as the root cause.

Sentinel detected the behavior.

34 — Search for Privilege Escalation

Look for:

• Entra role assignment

• Azure RBAC escalation

• PIM misuse

• group membership changes

• application permissions

35 — Search for Persistence

Look for:

• new users

• new service principals

• new app secrets

• new certificates

• new privileged group memberships

• new RBAC assignments

• automation resources

🧠 Persistence Question

Ask:

If the original identity is disabled, can the attacker still return?

36 — Search for Defense Evasion

Review whether the attacker changed:

• Conditional Access

• logging

• Sentinel configuration

• Defender settings

• NSGs

• diagnostic settings

🚨 High-Risk Finding

Security-control modification can indicate deliberate defense evasion.

37 — Search Across Subscriptions

Do not assume the incident is limited to one subscription.

Review cross-subscription access where the identity has permissions.

38 — Search Across the Tenant

For privileged Entra compromise, review:

• applications

• directory roles

• guest access

• service principals

• security-policy changes

39 — Build an Affected Asset Matrix

Category	Affected?	Evidence
Entra Users
Privileged Roles
Service Principals
Azure RBAC
VMs
Storage
Key Vault
Networking
Subscriptions

40 — Determine Blast Radius

Use:

Identity Permissions
       +
Network Reachability
       +
Application Permissions
       +
Data Access
       =
Potential Blast Radius

41 — Preserve Evidence

Depending on authorization and investigation needs, preserve:

• Sentinel incident data

• Entra sign-in logs

• Entra audit logs

• Azure Activity

• Defender alerts

• network telemetry

• relevant VM/disk evidence

🧠 Evidence Principle

Capture important evidence before actions that may change or destroy it.

42 — Maintain an Evidence Register

Create:

Evidence ID	Source	Time Collected	Description	Owner

43 — Preserve VM Evidence

Where required and authorized, consider appropriate Azure disk/snapshot evidence methods before destructive remediation.

Document:

• resource

• time

• snapshot/reference

• investigator

44 — Contain a Compromised User

Depending on incident severity and authority, containment may include:

• disable user

• revoke sessions

• reset credentials

• remove privileged roles

• remove suspicious group membership

⚠️ Important

Before disabling a critical service identity or administrator:

understand business impact.

45 — Contain a Compromised Service Principal

Potential actions may include:

• remove suspicious secret/certificate

• disable or restrict the application identity

• reduce permissions

• revoke unnecessary consent

46 — Contain a Compromised VM

Possible actions may include:

• isolate with controlled NSG

• remove public exposure

• restrict outbound traffic

• preserve required forensic access

Conceptually:

Compromised VM
      ↓
Quarantine Network Control
      ↓
Restricted Communication

47 — Contain Suspicious Network Paths

Potentially restrict:

• public administrative access

• malicious destination IPs

• compromised workload communication

• unnecessary peer routes

Only where authorized.

🧠 Containment Principle

Contain enough to stop further damage.

Do not destroy evidence unnecessarily.

48 — Remove Unauthorized Privilege

After evidence is preserved and unauthorized access is confirmed:

remove:

• malicious directory roles

• suspicious Azure RBAC assignments

• malicious group memberships

• unauthorized PIM assignments

49 — Remove Persistence

Remove verified malicious:

• application credentials

• service principals

• users

• role assignments

• automation resources

⚠️ Ownership Validation

Do not delete unfamiliar objects simply because you do not recognize them.

Validate business ownership first.

50 — Rotate Credentials

Depending on scope, rotate:

• user credentials

• application secrets

• certificates

• Key Vault secrets

• workload credentials

51 — Rebuild Compromised Workloads

For a confirmed VM compromise, determine whether:

• patching

• cleaning

• rebuilding

provides sufficient assurance.

Often a rebuild from a known-good image may be preferable to trusting a heavily compromised system.

52 — Restore Security Controls

Ensure that attackers did not leave weakened controls such as:

• open NSGs

• broad RBAC

• Conditional Access exclusions

• disabled logging

• public endpoints

53 — Recover Business Services

Recovery should include:

• restoring required application functionality

• validating identity

• validating networking

• validating access

• validating logging

• validating Defender/Sentinel

54 — Monitor for Recurrence

During the agreed observation period, monitor:

• affected users

• application identities

• IP addresses

• Azure resources

• security alerts

• network activity

55 — Determine Root Cause

Document:

Root Cause:

Initial Access:

Contributing Factors:

Control Failure:

Detection Source:

🧠 Example

Do not write:

Root Cause: Microsoft Sentinel alert.

Write:

Root Cause: A long-lived application credential was exposed and used to obtain unauthorized access.

56 — Identify Contributing Factors

Examples:

• excessive privilege

• missing MFA

• Conditional Access exception

• public RDP

• over-privileged service principal

• incomplete logging

• weak segmentation

57 — Assess Business Impact

Consider:

• confidentiality

• integrity

• availability

• regulatory impact

• operational impact

• customer impact

🧠 Translate Technical Evidence

Instead of:

Microsoft.Authorization/roleAssignments/write occurred.

Explain:

An unauthorized identity granted additional privileged access within the Azure subscription, increasing the attacker’s control over cloud resources.

58 — Build the Final Incident Timeline

Use:

Initial Access
      ↓
Authentication
      ↓
Privilege Escalation
      ↓
Persistence
      ↓
Resource Changes
      ↓
Detection
      ↓
Containment
      ↓
Eradication
      ↓
Recovery

59 — Create Corrective Actions

Create:

Control Gap	Corrective Action	Owner	Priority

Examples:

• weak privileged authentication

• long-lived secrets

• excessive Owner access

• missing Sentinel detection

• public management access

60 — Conduct Lessons Learned

Ask:

Prevention

What could have prevented the incident?

Detection

Why was it detected when it was?

Response

What slowed containment?

Evidence

Was telemetry sufficient?

Recovery

What made restoration difficult?

61 — Update Security Controls

Potential improvements may include:

• stronger Conditional Access

• PIM

• managed identities

• reduced Azure RBAC

• Private Endpoints

• centralized network controls

• Defender for Cloud

• Sentinel detections

62 — Update Detection Rules

Convert lessons learned into new or improved detection.

Example:

Incident Pattern
      ↓
KQL Hunt
      ↓
Detection Logic
      ↓
Analytics Rule

63 — Review Automation Opportunities

Potential low-risk automation:

• assign incident

• tag incident

• enrich IP

• notify SOC

• collect evidence

Higher-risk automation may include:

• disable account

• isolate workload

and should be carefully governed.

64 — Create the Incident Report

Recommended structure:

1. Executive Summary
2. Incident Overview
3. Severity
4. Detection
5. Scope
6. Timeline
7. Evidence
8. Identity Investigation
9. Azure Resource Investigation
10. Network Investigation
11. Containment
12. Root Cause
13. Business Impact
14. Eradication
15. Recovery
16. Corrective Actions
17. Lessons Learned

📄 Example Executive Summary

Incident ID:
AZ-IR-001

Severity:
High

Summary:
Suspicious authentication involving a privileged Microsoft Entra identity was followed by unauthorized Azure network and application-identity changes.

Affected Areas:
Microsoft Entra ID, Azure RBAC, network controls, and application identities.

Detection:
Microsoft Sentinel and Microsoft Defender for Cloud.

Containment:
The affected identity was restricted, suspicious privilege was removed, and impacted resources were isolated.

Root Cause:
Compromise of a privileged credential combined with excessive standing access.

Corrective Actions:
Strengthen privileged authentication, reduce standing access through PIM, improve application-identity governance, and expand Sentinel detection coverage.

65 — Create an Incident Findings Register

ID	Finding	Severity	Corrective Action
IR-001
IR-002

66 — Example Finding — Excessive Standing Privilege

Finding ID:
IR-001

Title:
Compromised Identity Held Permanent Privileged Access

Severity:
High

Observation:
The compromised human identity permanently held a high-impact administrative role.

Risk:
Credential compromise provided immediate privileged capability without additional elevation controls.

Recommendation:
Reduce standing privilege and implement controlled temporary privileged access through PIM where appropriate.

67 — Example Finding — Missing Detection

Finding ID:
IR-002

Title:
Application Credential Creation Was Not Detected

Severity:
High

Observation:
A new privileged application credential was created during the incident without generating a dedicated SOC alert.

Risk:
Attackers may establish persistent non-human access without timely detection.

Recommendation:
Implement dedicated Sentinel analytics for high-risk application-identity changes.

🎤 Azure Incident Investigation Interview Questions

Practise without notes.

Incident Process

1. How would you investigate an Azure security incident?

2. What do you do first after receiving an alert?

3. What is the difference between validation and containment?

4. Why preserve evidence?

Identity

5. How would you investigate a suspicious Entra sign-in?

6. Which identity changes would concern you?

7. How would you detect persistence through service principals?

8. Why are app secrets important during an incident?

Azure Activity

9. What does Azure Activity Log tell you?

10. How would you investigate an unexpected NSG change?

11. How would you identify who changed Azure RBAC?

Sentinel

12. How does Sentinel support Azure incident response?

13. How would you build an incident timeline?

14. What are entities?

Defender

15. How would you use Defender for Cloud during an investigation?

16. How would you correlate Defender with identity activity?

VM Investigation

17. How would you investigate a potentially compromised Azure VM?

18. How would you isolate a VM?

19. Why investigate managed identity activity?

Network

20. What network evidence would you review?

21. How would you investigate suspicious outbound traffic?

🚨 Scenario Interview Question 1

A Global Administrator signs in from an unusual location and creates a new client secret.

Use:

Validate Sign-In
      ↓
Authentication Context
      ↓
Audit Activity
      ↓
Application
      ↓
Permission
      ↓
Persistence
      ↓
Containment

🚨 Scenario Interview Question 2

Microsoft Defender reports suspicious activity on a production VM.

A strong answer should discuss:

• validate Defender finding

• identify VM

• review public exposure

• inspect identity

• correlate Sentinel

• review Azure Activity

• review network evidence

• isolate if required

• determine scope

🚨 Scenario Interview Question 3

A compromised user is disabled. Is the incident closed?

No.

Check whether the attacker created:

• service principals

• secrets

• roles

• group memberships

• Azure RBAC assignments

• resources

🚨 Scenario Interview Question 4

An NSG was modified to expose RDP to the internet.

Investigate:

• actor

• timestamp

• authentication context

• affected workloads

• subsequent connection attempts

• whether the change was authorized

🚨 Scenario Interview Question 5

The Sentinel incident only contains one alert. How do you determine whether the incident is larger?

Expand beyond the incident itself.

Use:

• Entra logs

• audit logs

• Azure Activity

• Defender

• network telemetry

• application identities

🧠 Incident Interview Framework

Use:

Detect
 ↓
Validate
 ↓
Scope
 ↓
Preserve
 ↓
Contain
 ↓
Investigate
 ↓
Eradicate
 ↓
Recover
 ↓
Improve

💬 Interview Tip

Avoid:

“I would disable the account and close the incident.”

A stronger answer is:

“I would validate the alert, identify the affected identity and resources, preserve relevant evidence, determine the scope through Entra, Azure Activity, Sentinel, Defender, and network telemetry, contain the immediate threat, search for persistence, remediate the root cause, recover securely, and document corrective actions.”

That sounds like a Cloud Incident Responder.

📁 Portfolio Deliverables

Create sanitized examples of:

• incident intake form

• Sentinel investigation

• identity timeline

• Azure Activity timeline

• affected-resource matrix

• evidence register

• incident attack-path diagram

• containment plan

• root-cause analysis

• executive incident report

📝 Resume Examples

Instead of:

Azure incident response experience.

Use:

Investigated simulated Azure security incidents by correlating Microsoft Entra sign-ins, Entra audit activity, Azure Activity Logs, Microsoft Sentinel, Defender for Cloud, and network telemetry.

Or:

Performed end-to-end Azure incident-response exercises covering validation, scope analysis, compromised identities, suspicious Azure resource changes, persistence, containment, root-cause analysis, and recovery.

⭐ Runbook Readiness Check

You should be able to:

• validate Azure security alerts

• investigate Entra sign-ins

• review audit activity

• investigate RBAC changes

• review Azure Activity Logs

• analyze Sentinel incidents

• correlate Defender findings

• investigate compromised VMs

• review managed-identity activity

• investigate network evidence

• identify persistence

• determine blast radius

• preserve evidence

• contain identities and workloads

• determine root cause

• create professional incident reports

The objective is not:

I closed the Sentinel incident.

The objective is:

I established what happened, which identities and resources were affected, how far the attacker may have moved, whether persistence exists, and what controls must change to prevent recurrence.

🏆 Runbook Complete

You now have a repeatable Azure incident-investigation methodology:

Incident Intake
      ↓
Alert Validation
      ↓
Identity Investigation
      ↓
Azure Resource Investigation
      ↓
Network Investigation
      ↓
Scope Analysis
      ↓
Containment
      ↓
Evidence Preservation
      ↓
Eradication
      ↓
Recovery
      ↓
Root Cause
      ↓
Lessons Learned

This directly supports roles such as:

• Security Operations Analyst

• Azure Security Engineer

• Cloud Incident Responder

• Cloud Security Engineer

• Microsoft Sentinel Analyst

• Security Consultant

🚀 What’s Next?

You have now completed the Azure security lab and runbook sequence:

Azure RBAC Lab
      ↓
Microsoft Entra ID Security Lab
      ↓
Azure Network Security Lab
      ↓
Microsoft Defender for Cloud Lab
      ↓
Microsoft Sentinel Lab
      ↓
Azure Security Assessment Runbook
      ↓
Microsoft Entra ID Security Review Runbook
      ↓
Azure Network Security Review Runbook
      ↓
Azure Incident Investigation Runbook

At this point, the Azure section forms the same complete career-readiness loop as AWS:

Certification knowledge → Labs → Professional runbooks → Job readiness → Interview readiness.

➡️ Next: Google Cloud Certification & Security Path