Azure Network Security Review

A secure Azure network is not simply one with NSGs attached. It is one where traffic flows, trust boundaries, public exposure, private connectivity, routing, and monitoring are intentionally designed and regularly reviewed.

Welcome to the Azure Network Security Review Runbook.

This runbook builds on the practical skills from:

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

The objective is to move from:

I know how Azure networking works.

to:

I can systematically review Azure network architecture, identify risky traffic paths and public exposure, produce defensible findings, and recommend practical remediation.

This runbook is directly relevant to roles such as:

Azure Security Engineer
Cloud Security Engineer
Network Security Engineer
Cloud Security Consultant
Azure Solutions Architect
Cloud Security Architect

🎯 Runbook Information

Item	Details
Runbook	Azure Network Security Review
Difficulty	Intermediate → Advanced
Estimated Time	3–6 hours depending on environment
Primary Focus	Network Architecture, Exposure & Segmentation
Target Roles	Azure Security Engineer, Cloud Security Engineer, Network Security Engineer
Certification Alignment	AZ-104, AZ-500, AZ-305, SC-100
Output	Network Findings, Risk Ratings, Exposure Matrix, Remediation Roadmap

🏢 Scenario

You have been asked to perform a security review of an Azure network environment.

The organization operates:

multiple Azure VNets
frontend workloads
application services
databases
shared services
public IP addresses
Private Endpoints
Azure Firewall
VNet peerings
hybrid connectivity

Security leadership is concerned that:

some systems may be unnecessarily exposed to the internet
NSGs may contain overly broad rules
application tiers may not be properly segmented
unrestricted outbound access may exist
route tables may bypass central controls
VNet peerings may create excessive trust
sensitive PaaS resources may use public network paths
network telemetry may be incomplete

Your job is to answer:

Which systems can communicate, through which path, under which controls, and whether that connectivity is actually required?

🎯 Review Objectives

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

understand Azure network architecture
inventory VNets and subnets
identify public exposure
review Network Security Groups
evaluate rule priorities
review outbound access
assess route tables and UDRs
review Azure Firewall
assess hub-and-spoke architecture
review VNet peering
evaluate Private Endpoints
assess private DNS
review hybrid connectivity
assess administrative access
review network telemetry
identify segmentation weaknesses
create network-security findings
prioritize remediation
validate network changes

⚠️ Scope and Authorization

Before beginning, confirm:

subscriptions in scope
resource groups in scope
VNets in scope
Regions in scope
production vs non-production
hybrid connectivity in scope
Azure Firewall in scope
Private Endpoints in scope
whether changes are permitted
whether testing is read-only

Do not alter:

NSGs
routes
peerings
firewall rules
production connectivity

unless explicitly authorized.

🧭 Network Security Review Workflow

Use:

Scope
  ↓
Understand Architecture
  ↓
VNet Inventory
  ↓
Subnet Review
  ↓
Public Exposure
  ↓
NSG Review
  ↓
Routing
  ↓
Central Firewall
  ↓
Inter-VNet Connectivity
  ↓
Private Connectivity
  ↓
Hybrid Connectivity
  ↓
Egress
  ↓
Telemetry
  ↓
Findings
  ↓
Remediation
  ↓
Validation

01 — Understand the Network Architecture

Before reviewing individual firewall rules, understand the overall architecture.

Identify:

how many VNets exist
which subscriptions contain them
which workloads they support
which VNets are production
which VNets provide shared services
which VNets connect to on-premises infrastructure

Create:

VNet	Subscription	Region	CIDR	Environment	Purpose

🧠 First Question

Ask:

Why does this VNet exist?

If there is no clear answer, ownership and governance may already be weak.

02 — Review VNet Address Spaces

For each VNet document:

IPv4 address space
additional CIDRs
overlapping ranges
address-space utilization

🚨 Review For

overlapping address ranges
unnecessarily large address spaces
inconsistent network planning
connectivity limitations caused by overlap

03 — Review Subnet Architecture

Inventory subnets.

Create:

Subnet	VNet	CIDR	Purpose	Public Workloads?

Classify subnets such as:

frontend
application
database
management
shared services
firewall
Private Endpoint

🧠 Security Question

Ask:

Does subnet design reflect workload trust boundaries?

A three-tier application may conceptually use:

Frontend
   ↓
Application
   ↓
Data

rather than placing everything in one subnet.

04 — Review Network Segmentation

Document the intended communication.

Example:

Internet
   ↓
Frontend
   ↓
Application
   ↓
Database

Then identify prohibited paths.

Internet ─X→ Application

Internet ─X→ Database

Frontend ─X→ Database Admin Interface

🚨 Finding Pattern

A flat architecture where application tiers can communicate broadly may increase lateral-movement risk.

05 — Inventory Public IP Addresses

Identify all public IP resources.

Create:

Public IP	Associated Resource	Purpose	Required?	Risk

Review:

VMs
load balancers
Application Gateways
firewalls
other public resources

🧠 Exposure Question

Ask:

Does this resource genuinely require direct public network reachability?

06 — Identify Internet-Facing Workloads

Create an exposure matrix.

Resource	Public?	Service/Port	Business Need	Risk

Pay special attention to:

SSH
RDP
database ports
application admin interfaces
custom management ports

🚨 High-Risk Examples

TCP 22
Source: Internet

TCP 3389
Source: Internet

These should receive immediate review.

07 — Review Network Security Groups

For important NSGs document:

associated subnet/NIC
inbound rules
outbound rules
priorities
source
destination
protocol
port

Create:

NSG	Direction	Source	Destination	Port	Action	Purpose

08 — Review Rule Priority

Remember:

Lower numerical priority is evaluated first.

When rules appear contradictory, inspect:

rule priority
source
destination
protocol

🧠 Troubleshooting Principle

Do not evaluate a rule independently.

Evaluate the effective traffic decision.

09 — Review Broad Sources

Look for:

Any
Internet
very large CIDR ranges
broad VNet access

Then ask:

Is this source really required?

🧠 Context Matters

Public HTTPS on an internet-facing application may be expected.

Public database access usually requires much stronger justification.

10 — Review Administrative Ports

Specifically assess:

TCP 22
TCP 3389
database administration
management consoles

🚨 Example Finding

Finding ID:
AZNET-001

Title:
Internet-Exposed Administrative Access

Severity:
High

Observation:
A production virtual machine allows RDP from an unrestricted internet source.

Risk:
The workload is directly exposed to internet-based authentication and exploitation attempts.

Recommendation:
Remove unrestricted public administrative access and use an approved private or controlled management path.

11 — Review Outbound Rules

Do not focus only on ingress.

Inspect whether workloads can send:

Any
→ Internet
→ Any Port

🧠 Egress Security Questions

Ask:

Does the workload require unrestricted outbound internet connectivity?

Which destinations are actually needed?

🚨 Why Egress Matters

Compromised workloads may use outbound access for:

command and control
malicious downloads
data exfiltration

12 — Create an Egress Matrix

Source Workload	Destination	Port	Purpose	Required?

13 — Review Effective Security Rules

Where applicable, inspect effective security rules on network interfaces.

This helps identify combined effects of:

subnet NSG
NIC NSG

🧠 Important

Do not assume a visible rule on one NSG equals the final traffic decision.

14 — Review Route Tables

Inventory User Defined Routes.

Create:

Route Table	Subnet	Destination	Next Hop	Purpose

Look for:

default routes
virtual appliances
firewall routes
gateway routes

15 — Review User-Defined Routes

Understand whether sensitive traffic is forced through:

Azure Firewall
network virtual appliance
central inspection

Example:

Application Subnet
       ↓
UDR
       ↓
Azure Firewall
       ↓
Destination

🚨 Routing Risk

A route change can unintentionally bypass:

inspection
centralized egress
expected trust boundaries

16 — Review Next-Hop Behavior

For suspicious or unclear network paths, determine the actual next hop.

Ask:

Is the traffic going where the architecture says it should?

17 — Review Azure Firewall

If Azure Firewall exists, review:

firewall policy
network rules
application rules
DNAT rules
logging
egress controls
threat intelligence settings where applicable

🧠 Firewall Security Question

Ask:

Which traffic flows must pass through the firewall?

Then verify that routing enforces that architecture.

18 — Review Firewall Rule Scope

Look for:

broad source ranges
broad destination ranges
Any ports
rules with unclear business purpose
stale temporary rules

19 — Review Centralized Egress

Determine whether internet-bound traffic from private workloads is centralized.

Concept:

Spoke Workloads
      ↓
UDR
      ↓
Azure Firewall
      ↓
Internet

🧠 Security Benefit

Centralized egress can improve:

visibility
policy enforcement
threat detection
governance

But it can also introduce:

cost
complexity
availability dependencies

20 — Review Hub-and-Spoke Architecture

Where applicable, map:

               Hub VNet
      ┌──────────┼──────────┐
      ↓          ↓          ↓
    Prod        Dev       Shared
    Spoke       Spoke     Services

The hub may contain:

Azure Firewall
DNS
VPN/ExpressRoute
shared services

21 — Review Hub Security

Assess:

route propagation
firewall enforcement
shared-service access
administrative access
segmentation between spokes

🚨 High-Risk Question

Ask:

Can every spoke communicate with every other spoke?

They should not necessarily be able to.

22 — Review VNet Peering

Inventory peerings.

Create:

Source VNet	Destination VNet	Subscription	Purpose	Required?

🧠 Peering Security Question

Ask:

What new trust path does this peering create?

23 — Review Peering Configuration

Assess relevant settings such as:

virtual-network access
forwarded traffic
gateway transit
remote gateways

depending on architecture.

🚨 Common Risk

A development VNet should not automatically have unrestricted access to production simply because both connect to a shared topology.

24 — Review Network Trust Matrix

Create:

Source	Destination	Allowed?	Required?	Control
Dev	Prod DB	No	No	NSG/Firewall
Frontend	App	Yes	Yes	NSG
App	DB	Yes	Yes	NSG

This is valuable professional documentation.

25 — Review Private Endpoints

Inventory Private Endpoints.

Create:

Endpoint	Service	VNet/Subnet	Resource	Public Access Disabled?

🧠 Private Endpoint Principle

Private Endpoints can reduce public network exposure by providing private IP-based connectivity.

But they do not replace:

authentication
authorization
RBAC
data access controls

26 — Review Sensitive PaaS Resources

Look for services such as:

Storage
Key Vault
SQL/database services
other sensitive PaaS resources

Ask:

Does this service need a public network path?

🚨 Example Finding

Finding ID:
AZNET-002

Title:
Sensitive PaaS Resource Uses Unnecessary Public Network Access

Severity:
Medium / High

Observation:
An internal application accesses a sensitive Azure service through a public endpoint although private connectivity is available.

Risk:
The design expands network exposure and increases attack surface.

Recommendation:
Evaluate Private Endpoint-based connectivity and restrict unnecessary public access after validating application dependencies.

27 — Review Private DNS

For Private Endpoints, verify that name resolution maps services to private addresses as intended.

🧠 Why DNS Matters

A Private Endpoint can exist while an application still resolves the public endpoint if DNS is misconfigured.

28 — Review Private DNS Zones

Document:

private DNS zones
VNet links
ownership
forwarders/resolvers where applicable

🚨 Troubleshooting Pattern

Private Endpoint Exists
        +
DNS Resolves Public Address
        =
Traffic May Still Use Public Path

29 — Review Hybrid Connectivity

Identify:

Site-to-Site VPN
Point-to-Site VPN where applicable
ExpressRoute
gateway infrastructure

Create:

Connection	Source	Destination	Purpose	Criticality

30 — Review VPN Connectivity

Assess:

business purpose
routing
tunnel redundancy
monitored status
permitted networks

🧠 Security Question

Ask:

Which on-premises networks can reach Azure production workloads?

31 — Review ExpressRoute Architecture

Understand:

connectivity purpose
routing
redundancy
security requirements

🧠 Important

Dedicated connectivity does not automatically replace all other security requirements.

Still consider:

segmentation
authentication
encryption requirements
monitoring

32 — Review Hybrid Trust Boundaries

Map:

On-Premises
     ↓
VPN / ExpressRoute
     ↓
Hub
     ↓
Azure Workloads

Then document which network segments should communicate.

33 — Review Administrative Access Architecture

Determine how administrators access workloads.

Possible methods:

public SSH/RDP
Azure Bastion
VPN/private management subnet
just-in-time controls
managed administration services

🧠 Preferred Security Properties

Administrative access should be:

authenticated
least privileged
limited
monitored
preferably not broadly public

34 — Review Azure Bastion Usage

If Azure Bastion is used, assess:

target resources
deployment architecture
public exposure reduction
ownership
logging where appropriate

Do not assume Bastion automatically solves all administrative security issues.

Identity and VM access controls still matter.

35 — Review Public Load Balancers

For internet-facing load balancers, assess:

frontend IP
listeners
backend pools
NSGs
health probes
intended workload

36 — Review Application Gateway

Where Application Gateway exists, review:

frontend configuration
listeners
backend pools
TLS
Web Application Firewall if used
logging

🧠 Web Security Connection

For public web applications, architecture may include:

Internet
   ↓
Application Gateway / WAF
   ↓
Application Tier
   ↓
Private Data Tier

37 — Review Database Network Exposure

For important databases assess:

public endpoint
Private Endpoint
firewall/network restrictions
application source networks
administrative access

🚨 High-Risk Pattern

Internet
   ↓
Database Port

should receive immediate attention.

38 — Review Storage Network Exposure

Assess important storage accounts for:

public network access
network rules
Private Endpoints
trusted-service exceptions

39 — Review Key Vault Network Exposure

Assess:

public network access
firewall settings
Private Endpoint
application dependencies

40 — Review Kubernetes / AKS Networking Where Applicable

If AKS exists, assess high-level areas such as:

API-server exposure
network architecture
ingress
private-cluster design
workload segmentation

Do not treat AKS as only another VM network.

It introduces additional layers of networking.

41 — Review Network Telemetry

Determine whether sufficient network evidence exists.

Possible sources may include:

Azure Firewall logs
NSG-related telemetry where supported
Application Gateway logs
load-balancer diagnostics
Azure Monitor
Microsoft Sentinel

🧠 Visibility Question

Ask:

If suspicious network traffic occurred yesterday, could the security team reconstruct the path today?

42 — Review Diagnostic Settings

For important network/security resources, assess whether diagnostics are sent to appropriate destinations.

Review:

Log Analytics
storage
Event Hub where applicable

43 — Review Sentinel Network Coverage

Assess whether Microsoft Sentinel receives relevant network telemetry.

Create:

Network Source	Sentinel Connected?	Detection Use Case
Azure Firewall
Identity
Azure Activity
Application Gateway

44 — Review Network Security Alerts

Correlate available:

Defender for Cloud findings
Sentinel alerts
firewall telemetry
Azure Activity

🚨 Incident Pattern

Suspicious Sign-In
      ↓
NSG Rule Changed
      ↓
Public Port Opened
      ↓
Suspicious Traffic

This is a network + identity incident, not only a firewall event.

45 — Review Azure Activity for Network Changes

Look for changes involving:

NSGs
route tables
public IPs
VNet peerings
firewalls
network interfaces

🧠 Cloud Security Question

Ask:

Who changed the network control, and what happened afterward?

46 — Review Change Governance

Determine whether sensitive network changes require:

change approval
infrastructure as code
peer review
monitoring
rollback

🚨 Risk Pattern

Direct manual changes to critical production networking with no audit/change process increase operational and security risk.

47 — Review Infrastructure as Code

If networking is deployed through:

Terraform
Bicep
ARM templates

assess whether configuration changes can be:

reviewed
version controlled
validated
rolled back

48 — Review Environment Separation

Assess whether:

Production
Development
Test
Sandbox
Shared Services

have appropriate network boundaries.

🚨 Example

Development systems should not automatically reach production databases.

49 — Review Sensitive Workload Isolation

Identify high-value systems such as:

identity services
payment systems
regulated databases
security infrastructure

Ask whether stronger network isolation is appropriate.

50 — Build an Attack Surface Map

Create:

Internet
│
├── Application Gateway :443
├── VM :3389      ← Review
├── Database      ← High Risk
└── Public PaaS Endpoint

🧠 Ask

Which of these paths are intentionally public?

51 — Build an East-West Attack Map

Example:

Frontend
   ↓
Application
   ↓
Database

Dev ─X→ Production

This makes lateral-movement opportunities easier to explain.

52 — Build a Network Findings Register

Create:

ID	Finding	Severity	Affected Resource	Priority
AZNET-001
AZNET-002

53 — Standard Finding Format

Use:

Finding ID:

Title:

Severity:

Affected Resource:

Network Path:

Observation:

Evidence:

Risk:

Business Impact:

Recommendation:

Validation:

54 — Example Finding — Public RDP

Finding ID:
AZNET-003

Title:
Production Virtual Machine Exposes RDP to the Internet

Severity:
High

Observation:
TCP 3389 is permitted from an unrestricted internet source.

Risk:
The workload is directly reachable by internet-based attackers attempting credential compromise or exploitation.

Recommendation:
Remove unrestricted public administrative access and move administration to an approved private or controlled access path.

Validation:
Confirm RDP is no longer reachable from unapproved internet sources.

55 — Example Finding — Flat Network

Finding ID:
AZNET-004

Title:
Application Tiers Lack Effective Segmentation

Severity:
High

Observation:
Frontend, application, and database workloads can communicate broadly without documented least-privilege restrictions.

Risk:
Compromise of one application component may enable unnecessary lateral movement.

Recommendation:
Define approved traffic flows and enforce segmentation using NSGs and/or centralized network-security controls.

56 — Example Finding — Unrestricted Egress

Finding ID:
AZNET-005

Title:
Sensitive Workloads Have Unrestricted Internet Egress

Severity:
Medium / High

Observation:
Sensitive application workloads can initiate outbound connections to unrestricted internet destinations.

Risk:
Compromised resources may communicate with malicious infrastructure or exfiltrate data.

Recommendation:
Identify required outbound dependencies and implement appropriate egress controls and monitoring.

57 — Example Finding — Peering Trust

Finding ID:
AZNET-006

Title:
Development VNet Has Unnecessary Connectivity to Production

Severity:
High

Observation:
VNet peering and network controls permit development workloads to access sensitive production networks beyond documented requirements.

Risk:
Compromise of lower-trust development workloads may provide a path toward production systems.

Recommendation:
Restrict inter-VNet communication to explicitly required flows.

58 — Rate Network Risk

Use:

Reachability
+
Exposure
+
Trust
+
Asset Criticality
+
Exploitability
+
Business Impact
=
Risk

🔴 Critical

Examples:

internet-reachable sensitive database
exposed privileged administration surface with major impact

🟠 High

Examples:

unrestricted SSH/RDP
major production segmentation weakness
development-to-production trust

🟡 Medium

Examples:

unrestricted egress
unnecessary public PaaS access
incomplete telemetry

🔵 Low

Examples:

stale NSG
unused public IP
unclear documentation

59 — Prioritize Findings

Recommended order:

Critical Internet Exposure
        ↓
Administrative Exposure
        ↓
Sensitive Lateral Access
        ↓
Routing / Firewall Bypass
        ↓
Unrestricted Egress
        ↓
Telemetry Gaps
        ↓
Architecture Cleanup

60 — Build a Remediation Roadmap

Use:

Immediate
0–7 Days

Short Term
7–30 Days

Medium Term
30–90 Days

Strategic
90+ Days

Example:

Finding	Timeframe
Public database	Immediate
Public RDP	Immediate
Dev-to-prod access	Short Term
Unrestricted egress	Medium Term
Hub redesign	Strategic

61 — Validate Remediation

Network remediation must be tested carefully.

Validate:

Required Traffic
→ Works

Unauthorized Traffic
→ Fails

🧠 Important

Security improvements that cause unexpected outages are not successful changes.

Validate both:

security
application functionality

62 — Perform Connectivity Validation

For important flows document:

Source	Destination	Port	Expected
Frontend	Application	8080	Allow
Internet	Application	8080	Deny
Application	Database	DB Port	Allow

63 — Validate DNS

After Private Endpoint changes confirm:

service hostname
resolved IP
expected private path
application connectivity

64 — Validate Firewall Routing

Confirm:

expected traffic reaches firewall
required applications still work
bypass routes do not remain

65 — Prepare an Exposure Summary

Create:

Exposure Type	Count
Public VMs
Public Admin Ports
Public PaaS Endpoints
Public Databases
Broad Egress Paths

66 — Prepare a Network Trust Summary

Document:

trusted VNets
restricted VNets
hybrid networks
production access paths
administrative networks

67 — Create the Executive Summary

Example:

The Azure network security review identified excessive public exposure, weak segmentation between application tiers, and broad outbound connectivity.

The highest-priority issues include internet-facing administrative access and unnecessary connectivity between lower-trust and production networks.

Immediate remediation should focus on removing unnecessary public management paths and restricting high-risk lateral connectivity.

Longer-term improvements should strengthen private service connectivity, centralized egress controls, network telemetry, and enterprise network governance.

68 — Create the Technical Report

Recommended structure:

1. Executive Summary
2. Scope
3. Network Architecture
4. VNet & Subnet Inventory
5. Public Exposure
6. NSG Review
7. Routing Review
8. Azure Firewall
9. VNet Peering
10. Private Connectivity
11. Hybrid Connectivity
12. Administrative Access
13. Network Telemetry
14. Findings
15. Risk Summary
16. Remediation Roadmap
17. Positive Observations

🌟 Positive Observations

Include good controls such as:

no public administrative ports
strong subnet segmentation
centralized Azure Firewall
Private Endpoints for sensitive services
documented traffic flows
Sentinel network monitoring
controlled development-to-production trust

🎤 Azure Network Security Review Interview Questions

Practise without notes.

Assessment

1. How would you perform an Azure network-security review?

2. What information would you gather first?

3. How do you identify Azure internet exposure?

VNets and Segmentation

4. What is an Azure VNet?

5. Why use multiple subnets?

6. What is network segmentation?

7. How would you secure a three-tier application?

NSGs

8. What is an NSG?

9. How do NSG priorities work?

10. Why should outbound rules be reviewed?

11. How do you identify effective network access?

Routing

12. What is a route table?

13. What is a UDR?

14. How would you determine whether traffic bypasses Azure Firewall?

Firewall

15. NSG vs Azure Firewall?

16. Why centralize egress?

17. What risks exist with overly broad firewall rules?

Private Connectivity

18. What is a Private Endpoint?

19. Does a Private Endpoint replace RBAC?

20. Why is private DNS important?

Connectivity

21. What is VNet peering?

22. What security risks exist with peering?

23. What is hub-and-spoke?

24. VPN vs ExpressRoute?

Monitoring

25. What network telemetry would you send to a SIEM?

26. How would you investigate an unexpected NSG change?

🚨 Scenario Interview Question 1

A production VM allows RDP from the entire internet. What would you do?

A strong answer should include:

confirm business requirement
determine current exposure
review previous activity
move administration to a controlled private path
remove unrestricted RDP
validate required access
monitor for recurrence

🚨 Scenario Interview Question 2

An application needs access to Azure Storage, but policy prohibits public connectivity.

Discuss:

Private Endpoint
DNS
authorization
public network restrictions
application validation

🚨 Scenario Interview Question 3

Development workloads can reach production databases.

A strong answer should discuss:

business requirement
current network path
peering/routing
NSGs/firewall
least privilege
segmentation
monitoring

🚨 Scenario Interview Question 4

Traffic should pass through Azure Firewall but appears to bypass it.

Use:

Source
 ↓
Subnet
 ↓
Route Table
 ↓
Effective Route
 ↓
Firewall
 ↓
Destination

Review:

UDR association
route specificity
peering
gateway behavior

🚨 Scenario Interview Question 5

A Private Endpoint is deployed, but the application still connects to the service’s public IP.

Investigate:

DNS resolution
private DNS zone
VNet link
application DNS configuration
endpoint status

🧠 Network Interview Framework

Use:

Source
   ↓
Destination
   ↓
DNS
   ↓
Route
   ↓
NSG
   ↓
Firewall
   ↓
Service
   ↓
Return Path
   ↓
Telemetry

💬 Interview Tip

Avoid:

“I would check the NSG and firewall.”

A stronger answer is:

“I would first define the expected source, destination, port, and network path. Then I would validate DNS, effective routes, NSG rules, centralized firewall controls, the target service, return path, and telemetry to determine exactly where connectivity is permitted or blocked.”

That sounds like a Network Security Engineer.

📁 Portfolio Deliverables

Create sanitized examples of:

VNet architecture diagram
subnet inventory
public-exposure matrix
NSG review
route analysis
VNet peering matrix
Private Endpoint review
traffic matrix
network attack-path diagram
findings register
remediation roadmap

📝 Resume Examples

Instead of:

Azure network security experience.

Use:

Performed a structured Azure network-security review covering VNets, subnet segmentation, NSGs, route tables, VNet peering, public exposure, Private Endpoints, and centralized network controls.

Or:

Identified internet exposure, excessive lateral connectivity, and unrestricted outbound paths in an Azure lab environment and produced prioritized remediation with traffic-flow validation.

⭐ Runbook Readiness Check

You should be able to:

inventory VNets and subnets
identify public exposure
review NSGs
understand effective security rules
assess outbound access
review routing
assess Azure Firewall
understand hub-and-spoke
review VNet peering
assess Private Endpoints
troubleshoot private DNS
review hybrid connectivity
assess network telemetry
create defensible network findings
validate remediation

The objective is not:

I reviewed every NSG rule.

The objective is:

I understand which traffic paths exist, which trust relationships are necessary, which paths create unnecessary attack surface, and how to reduce risk without breaking required business communication.

🏆 Runbook Complete

You now have a repeatable methodology for:

Architecture Discovery
      ↓
Exposure Analysis
      ↓
Segmentation Review
      ↓
NSG Review
      ↓
Routing Analysis
      ↓
Central Firewall Review
      ↓
Private Connectivity
      ↓
Network Monitoring
      ↓
Risk Analysis
      ↓
Remediation
      ↓
Validation

This directly supports roles such as:

Azure Security Engineer
Cloud Security Engineer
Network Security Engineer
Cloud Security Consultant
Azure Solutions Architect
Cloud Security Architect

🚀 What’s Next?

You have now completed the broad Azure security assessment, identity review, and network review:

Azure Security Assessment
        ↓
Microsoft Entra ID Security Review
        ↓
Azure Network Security Review

The next runbook focuses on what happens when those preventive controls fail and suspicious activity must be investigated.

➡️ Next: Azure Incident Investigation Runbook

In the next runbook, you will systematically work through:

incident intake
alert validation
Microsoft Sentinel incidents
Microsoft Entra sign-in investigation
Azure Activity Logs
Defender for Cloud alerts
compromised identities
suspicious Azure resource changes
compromised VMs
network evidence
incident scoping
containment
evidence preservation
root-cause analysis
recovery
post-incident reporting
incident-response interview scenarios