Design a Secure Azure Web Workload

Design and threat-review an Azure web workload with Zero Trust controls.

Introduction

30 Second Summary

When people trust a web app with their data, they expect strangers to stay out. They also expect the service to stay available when they need it.

In this project, you will transform a deliberately weak public Azure web workload into a secure architecture built around Zero Trust. The result is an exported PNG backed by a six-point threat review against the Azure Well-Architected Framework.

What You'll Build

Your finished draw.io diagram gives you a clear visual you can present while tracing how approved web traffic reaches a protected Azure workload.

By the end of this project, you'll have:

A secure ingress path that you can trace from a user through Azure Application Gateway plus Azure Web Application Firewall to Azure App Service.
A private access map that shows Azure App Service using private connectivity to reach Azure SQL Database plus Azure Key Vault.
A six-point threat review that connects each red risk to identity, segmentation, secrets protection, monitoring, or incident response.
Secret Mission: Model an unauthorized Azure Key Vault attempt with visible containment, detection, and response paths.

Are there any prerequisites?

You'll need a Windows device with internet access plus a Microsoft account. You do not need an Azure subscription because this project deploys no cloud resources.

Before We Start

This is your moment to define the public web workload you are designing before any hands-on work begins. Consider why its users would care if their data were exposed or changed without permission. Consider what would happen if the workload became unavailable.

Set Up Your Free Design Workspace

Your workload brief gives you a security problem to design around. Now you need a place to turn that problem into architecture.

A browser-only workspace keeps this project free. It keeps your attention on architecture decisions instead of cloud account setup.

You will use Microsoft Edge for the Microsoft Learn references. A blank draw.io canvas stores the design locally on your device.

In this step, get ready to:

Make Microsoft Edge available on your device.
Open the two official Microsoft Learn references in separate tabs.
Start a local draw.io diagram with Azure Networking shapes enabled.

Launch Microsoft Edge

Microsoft Edge becomes the home for your reference material and diagram. First, confirm that the browser is available on your device.

Press the Windows key to open the Windows search bar.
Type Microsoft Edge into the search bar.
Press Enter to launch the browser.

Tab 1

Complete any first-run prompts using your preferred browser settings.

That browser check is complete. Microsoft Edge is ready to hold your design workspace.

Tab 2

Microsoft provides an official Windows installer for Microsoft Edge. You can use any available browser to reach the download page.

Visit the official Download Microsoft Edge page.
Download the Windows version from the page.
Run the downloaded Microsoft Edge installer.
Follow the on-screen prompts to finish the installation.
Press the Windows key to reopen the Windows search bar.
Type Microsoft Edge into the search bar.
Press Enter to launch the installed browser.

Microsoft Edge should now open on your device. Your browser workspace is ready for the project.

Microsoft Edge Still Won't Open?

Confirm your internet connection by loading the official download page again.
Download a fresh installer from the official page.

Still stuck? Help me troubleshoot why Microsoft Edge will not install or open on Windows.

Open the official security references

The Azure Well-Architected Framework gives you a structured security checklist. The baseline Azure App Service architecture gives you a secure reference pattern.

Open the official baseline App Service architecture in a separate Microsoft Edge tab.
Open the official Azure Well-Architected Security checklist in another Microsoft Edge tab.
Leave both reference tabs open for the later design steps.

You should now see the baseline App Service architecture in one tab. You should see the security checklist in another tab.

Why Use This Baseline?

A landing-zone design emphasizes platform governance. This App Service baseline keeps your threat review centered on one public web workload.

The pattern brings ingress, private connectivity, workload identity, secret storage, and monitoring into one design. Each control has a visible place on the finished diagram.

Prepare the blank Azure canvas

Draw.io can store the editable diagram directly on your device. You do not need an additional account.

The Azure shape library adds recognizable service symbols to the left panel. These shapes make the later architecture easier to trace.

Open the draw.io online editor in another Microsoft Edge tab.
Choose the storage option that keeps the diagram on your device.
Start a new blank diagram.
Select More Shapes in the shapes panel.
Find Networking in the shapes dialog.
Enable Azure.
Select Apply.

Before you check the result, predict whether the left panel now contains Azure shapes.

Check the left panel for Azure shapes.
Confirm that an empty editing canvas is visible in the center.

You should see a blank editing canvas. Azure shapes should appear in the left panel.

Don't See Azure Shapes?

Reopen More Shapes.
Locate Azure under Networking.
Enable Azure.
Select Apply.

Still missing the library? Help me enable the Azure shapes in draw.io.

That is your free design workspace ready. Your editable diagram remains local on your device.

Your browser workspace now has the references and drawing tools you need. Next, you will draw the deliberately risky first version of the web workload.

Draw the Risky First Draft

Your draw.io workspace is ready. Now you can turn your workload brief into a visible architecture.

A deliberately exposed first draft makes the workload's weak paths easy to see. This gives you a concrete baseline for the threat review.

In this step, get ready to:

Build the three-component workload row.
Connect the request path to the database path.
Label the direct access risk and the credential risk.

Add the workload components

Your first row uses a user plus Azure App Service plus Azure SQL Database. Their left-to-right order makes the workload path easy to trace.

In the draw.io tab from earlier, drag a person shape from the left shape panel to the left side of the canvas.
Double-click the person shape to replace its label with User.

You should see a single shape labeled User on the left side of the canvas.

Drag an Azure App Service shape from the left Azure library to the center of the canvas.
Double-click the app shape to replace its label with Azure App Service.

You should see Azure App Service positioned to the right of User.

Drag an Azure SQL Database shape from the left Azure library to the right side of the canvas.
Double-click the database shape to replace its label with Azure SQL Database.

You should now see three labeled components arranged from left to right. The row should begin with User.

Connect the direct access path

Connectors make the workload path readable. One connector represents the web request while the other represents the database call.

Hover over User until the four connection arrows appear.
Drag one connection arrow from User onto Azure App Service.

You should see a connector pointing from User to Azure App Service.

Hover over Azure App Service until the four connection arrows appear.
Drag one connection arrow from Azure App Service onto Azure SQL Database.

You should see a second connector pointing from Azure App Service to Azure SQL Database.

Connector Pointing the Wrong Way?

Delete the connector that points toward the wrong source.
Recreate the connector from the source shape toward the destination shape.

Still stuck? Help me correct the connector directions in draw.io.

Label the risky assumptions

Labels make the unsafe network and credential assumptions explicit.

Double-click the connector between User and Azure App Service to edit its label.
Enter Direct access.

The first connector should now display Direct access.

Double-click the connector between Azure App Service and Azure SQL Database to edit its label.
Enter Direct access.

Both connector labels should now show Direct access.

Double-click an empty area beside Azure App Service to create a text note.
Enter Application stores database credential.

You should see the credential note beside Azure App Service.

Labels Missing or Detached?

Select any label that moved away from its connector.
Drag the selected label back onto the middle of its connector.
Compare all three text values with the target text above.

Need a hand? Help me fix the labels in my risky architecture draft.

Before you trace the finished draft, how many security or monitoring components do you expect the workload path to cross?

Read the diagram from left to right.

You should see User pointing directly to Azure App Service. The next arrow should point directly to Azure SQL Database.

Both arrows should say Direct access. No security or monitoring component should sit between the three shapes.

That exposed result is intentional. Your weak baseline now makes direct access and stored credentials visible.

Your risky baseline is complete. Next, you will map six red findings to the architecture through a structured security review.

Threat-Review the Draft

Your risky first draft now makes the workload's path visible in draw.io. The arrows show where traffic moves without judging whether the design meets security guidance.

A threat review maps visible weaknesses to specific security guidance. The Azure Well-Architected Framework gives you a structured way to do that through its security checklist.

In this step, get ready to:

Compare the risky draft with six security checklist recommendations.
Map six unresolved risks onto the diagram with red callouts.
Finish a locally saved threat review with a risk legend.

Compare the draft with the security checklist

The checklist turns broad security concerns into recommendations you can test against the diagram. Your direct paths provide the evidence for this review.

Before you compare them, predict whether the three-component draft satisfies Microsoft's security recommendations.

Switch back to the Microsoft Learn security checklist tab from earlier.
Locate recommendations SE:04, SE:05, SE:06, SE:09, SE:10, plus SE:12.
Compare those six recommendations with the draft's shapes, arrows, plus credential note.

The draft falls short in six places. That result is intentional because each gap now has a name you can track.

What Do the Six Findings Reveal?

SE:04 No segmentation records the absence of boundaries around the workload layers.
SE:05 No identity boundary shows no visible authorization control before Azure App Service.
SE:06 Uncontrolled network paths applies to direct traffic entering the app. The path to Azure SQL Database has the same gap.
SE:09 Credential stored with the app maps directly to the credential note beside the app.
SE:10 No monitoring records the absence of a monitoring path.
SE:12 No incident response owner records the absence of a named response owner.

Red will mark findings that remain unresolved in the current draft.

Return to draw.io from earlier.
Create a small red callout labeled SE:04 No segmentation on the canvas.
Create a small red callout labeled SE:05 No identity boundary on the canvas.

You should now see two red findings on the canvas.

Create a small red callout labeled SE:06 Uncontrolled network paths on the canvas.
Create a small red callout labeled SE:09 Credential stored with the app on the canvas.

You should now see four red findings on the canvas.

Create a small red callout labeled SE:10 No monitoring on the canvas.
Create a small red callout labeled SE:12 No incident response owner on the canvas.

The six security gaps are now visible as red callouts.

Map each finding on the canvas

A finding becomes useful when its position makes the affected path obvious. The legend keeps the color meaning clear.

Positioning six findings on a small canvas can feel fiddly. Clear spacing keeps every label readable.

Add a small legend reading Red = unresolved risk in an open corner of the canvas.
Move SE:04 No segmentation beside the area spanning Azure App Service plus Azure SQL Database.

The legend now defines the review color. The segmentation finding points to the missing workload boundaries.

Move SE:05 No identity boundary beside the arrow from User to Azure App Service.
Move SE:06 Uncontrolled network paths between the two Direct access arrows.

The inbound path now shows its missing identity boundary. Both direct paths now point to the network-control gap.

Move SE:09 Credential stored with the app beside the Application stores database credential note.
Move SE:10 No monitoring below the workload path.

The credential finding now maps to its risky assumption. The monitoring finding highlights the missing visibility around the workload.

Move SE:12 No incident response owner beside the full workload diagram.

Every finding now points to the part of the draft that provides its evidence.

Save and verify the threat review

Saving locally preserves the editable draft for the secure redesign. The risky paths must remain visible so you can resolve each finding later.

Save the editable diagram back to your device.
Trace the original route from User through Azure App Service to Azure SQL Database.
Confirm both arrows still carry the label Direct access.
Confirm the note Application stores database credential remains beside Azure App Service.

You should still see the unchanged risky route beneath the new threat-review layer.

Before you count, predict whether every checklist recommendation appears exactly once on the canvas.

Count the red callouts on the canvas.

What Should I See?

The three original components remain visible. Both arrows still read Direct access.

The note Application stores database credential remains beside Azure App Service.

A red callout reads SE:04 No segmentation.
A red callout reads SE:05 No identity boundary.
A red callout reads SE:06 Uncontrolled network paths.
A red callout reads SE:09 Credential stored with the app.
A red callout reads SE:10 No monitoring.
A red callout reads SE:12 No incident response owner.
The legend reads Red = unresolved risk.

Strong work. Your diagram now connects six checklist recommendations to visible workload risks.

Your threat review now explains exactly where the draft falls short. Next, you will replace the direct entry path with an inspected one. You will add private network boundaries.

Add Secure Ingress and Segmentation

Your threat review made the risky paths visible. A user can still reach Azure App Service directly while Azure SQL Database sits on an uncontrolled application path.

This step replaces those exposed routes with an inspected entry point. It also introduces network boundaries that contain private application traffic.

In this step, get ready to:

Divide the workload into three network areas with separate responsibilities.
Route approved inbound traffic through an inspected gateway.
Replace direct dependency routes with private service paths.

Create the network boundary

An Azure Virtual Network gives the workload one visible security boundary. Network segmentation divides that boundary into areas with separate jobs.

Switch back to the draw.io tab from earlier.
Drag a large rectangle from the shapes panel onto the canvas.
Label the rectangle Azure Virtual Network.

You should see one large boundary that has enough space for the gateway path plus the application network paths.

Why This Network Pattern?

The baseline architecture separates gateway traffic from application integration. It also reserves a dedicated area for private service endpoints.

These boundaries make traffic paths easier to control. Containment reduces how far a breach can spread.

Add three smaller rectangular areas inside the Azure Virtual Network boundary.
Label the first area GatewaySubnet.

The first subnet now has a defined purpose for the inspected entry point.

Label the second area AppServiceSubnet.
Label the third area PrivateEndpointsSubnet.

You should now see three named areas inside the virtual network boundary. Each area represents a distinct network responsibility.

Having Trouble With the Boundary?

Resize the large rectangle if any subnet sits outside its edge.
Move the large rectangle behind the subnet shapes if it covers their labels.

Still stuck? Help me arrange the virtual network boundary and three subnet areas in draw.io.

Place the gateway and private endpoints

Azure Application Gateway becomes the controlled entry point. Azure Web Application Firewall inspects requests before App Service receives them.

Private endpoints keep Azure platform services reachable through private addresses. Azure Key Vault joins SQL Database as a private dependency.

Drag an Azure Application Gateway shape into GatewaySubnet.
Label the shape Azure Application Gateway + Azure Web Application Firewall.

The diagram now has a single component responsible for receiving inspected web traffic.

Position the existing Azure App Service shape beside AppServiceSubnet.
Draw an integration connector from Azure App Service into AppServiceSubnet.

The connector now shows that App Service uses the application subnet for private outbound communication.

Drag an Azure Key Vault shape beside the existing Azure SQL Database shape.
Add three private endpoint markers inside PrivateEndpointsSubnet.

The private endpoint area now has one marker for each service that needs private access.

Position the first marker in line with Azure App Service.
Position the second marker in line with Azure SQL Database.

The application endpoint plus the database endpoint now have clear positions inside the private endpoint subnet.

Position the third marker in line with Azure Key Vault.

You should see private endpoint markers for App Service, SQL Database, and Key Vault inside PrivateEndpointsSubnet.

Why Does App Service Use Two Network Paths?

The application subnet represents App Service integration with the virtual network. This path supports private communication from the app to its dependencies.

The App Service private endpoint supports inbound private access from the gateway. The two paths serve different traffic directions.

Replace the direct paths

Private Link carries application traffic to SQL Database plus Key Vault through their private endpoints. The public access labels make the intended boundary explicit.

Delete the existing User-to-App Service arrow labeled Direct access.
Delete the existing App Service-to-SQL Database arrow labeled Direct access.

The two uncontrolled routes are now gone from the canvas.

Draw a connector from User to Azure Application Gateway + Azure Web Application Firewall.
Draw a connector from the gateway to the App Service private endpoint.

The public portion of the inbound path now stops at the inspected gateway before continuing to a private endpoint.

Draw a connector from the App Service private endpoint to Azure App Service.
Label the complete inbound flow Inspected HTTPS request.

You should now see one approved route from User through the gateway to App Service.

Draw a connector from Azure App Service to the SQL Database private endpoint.
Continue the path from the SQL Database private endpoint to Azure SQL Database.

The database path now crosses its private endpoint instead of using the old direct route.

Label the SQL Database path Private Link.
Draw a connector from Azure App Service to the Key Vault private endpoint.

The app now has a second private path leading toward Key Vault.

Continue the path from the Key Vault private endpoint to Azure Key Vault.
Label the Key Vault path Private Link.

Both application dependencies now use paths that pass through PrivateEndpointsSubnet.

Add Public network access disabled below Azure SQL Database.
Add Public network access disabled below Azure Key Vault.

The diagram now states that the database plus the vault reject public network routes.

Add Addressed to the SE:04 No segmentation callout.
Add Addressed to the SE:06 Uncontrolled network paths callout.

The SE:05 No identity boundary, SE:09 Credential stored with the app, SE:10 No monitoring, and SE:12 No incident response owner findings remain visible. The legend still states Red = unresolved risk.

Save the updated editable diagram to the same local file.

Before you trace the finished design, do you expect any user route to reach the app, database, or vault without passing through a security boundary?

Trace the inbound route from User to Azure App Service.
Trace the application route from Azure App Service to Azure SQL Database.
Trace the application route from Azure App Service to Azure Key Vault.
Check every connector leaving User for a direct route to the app, database, or vault.

You should see the user route pass through Azure Application Gateway plus Azure Web Application Firewall before reaching App Service. No user arrow should point directly to the app, database, or vault.

The SQL Database path plus the Key Vault path should each pass through a private endpoint. Both destination services should show Public network access disabled.

Does a Path Still Bypass a Control?

Remove any remaining arrow labeled Direct access.
Check that the inbound path crosses the App Service private endpoint.
Check that each dependency path crosses its matching private endpoint.

Need another pair of eyes? Help me find any uncontrolled path in my secure Azure web workload diagram.

That is a major security shift: your workload now has one inspected entry point plus private dependency paths.

Your network controls now resolve SE:04 plus SE:06. Next, you will complete identity protection plus operational detection and response.

Complete the Identity and Operations Design

Your inspected ingress path and private service paths now reduce the workload's network exposure. This final design step closes the four red findings that remain.

Network isolation alone cannot protect application credentials. A managed identity moves secret access into an auditable identity boundary.

Network isolation also cannot reveal an attack. Monitoring makes suspicious activity visible. Clear incident response ownership puts that evidence in front of the right team.

In this step, get ready to:

Close the identity and secret-storage findings.
Close the monitoring and incident-response findings.
Export the completed design as an editable PNG.

Add identity and protect secrets

Microsoft Entra ID becomes the user identity boundary. The managed identity gives Azure App Service a workload identity for private secret retrieval from Azure Key Vault.

Before you change the design, predict whether the current network paths can prove which identity retrieved a secret.

Switch back to the draw.io tab from earlier.
Trace the current path from Azure App Service to Azure Key Vault.

You can see where the traffic travels. The remaining SE:05 and SE:09 callouts show that the design cannot identify the workload or remove the stored-credential assumption.

Add a Microsoft Entra ID shape beside the User shape from the Azure library in the left panel.
Set the new shape's label to Microsoft Entra ID.
Draw a connector from User to Microsoft Entra ID.
Draw a connector from Microsoft Entra ID to Azure App Service.
Add a managed identity shape beside Azure App Service.
Set the new shape's label to Managed identity.
Draw a connector from Managed identity to Azure Key Vault.
Replace the credential-storage note beside Azure App Service with Secret retrieved from Key Vault using managed identity.

How does the identity path help?

Microsoft Entra ID establishes the user identity boundary. The managed identity gives App Service its own workload identity.

Key Vault can authorize that workload identity for secret retrieval. The application no longer carries a database credential in the design.

Mark the SE:05 No identity boundary finding as Addressed.
Mark the SE:09 Credential stored with the app finding as Addressed.
Change both addressed callouts to green.

Before you check the result, predict which two visual paths now explain user identity and workload identity.

Trace the user identity path through Microsoft Entra ID.
Trace the workload identity path from Azure App Service to Azure Key Vault.

You should see separate paths for user identity and workload access. The new secret note should replace the risky credential assumption.

Identity paths look unclear?

Move Microsoft Entra ID closer to the User shape so its connector stays separate from the inspected HTTPS path.
Move Managed identity closer to Azure App Service so its Key Vault connector does not cross the Private Link path.

Still tangled? Help me arrange the identity paths in my secure Azure workload diagram.

Add monitoring and response ownership

Application Insights captures application telemetry from Azure App Service. Azure Monitor brings platform signals from Azure Application Gateway, Azure SQL Database, and Azure Key Vault into the operations view.

Telemetry becomes actionable when someone owns the response. The ownership note makes that responsibility visible in the architecture.

Add an Application Insights shape beside Azure App Service.
Set the new shape's label to Application Insights.
Add an Azure Monitor shape to the right of the workload.
Set the new shape's label to Azure Monitor.
Draw a monitoring connector from Azure App Service to Application Insights.
Draw a monitoring connector from Application Insights to Azure Monitor.
Draw a monitoring connector from Azure Application Gateway to Azure Monitor.

What do these monitoring paths show?

Application Insights represents application telemetry from App Service. Azure Monitor represents the wider platform view across the workload.

Together, these paths show where responders obtain evidence when availability or security changes.

Draw a monitoring connector from Azure SQL Database to Azure Monitor.
Draw a monitoring connector from Azure Key Vault to Azure Monitor.
Add the ownership note App team operates the workload; security team triages security alerts beside Azure Monitor.
Mark the SE:10 No monitoring finding as Addressed.
Mark the SE:12 No incident response owner finding as Addressed.
Change both addressed callouts to green.

Before you inspect the operations view, predict whether every monitored service now has a visible route to telemetry.

Trace the monitoring path from Azure Application Gateway.
Trace the monitoring path from Azure App Service.
Trace the monitoring path from Azure SQL Database.
Trace the monitoring path from Azure Key Vault.

You should see signals from all four services reach the monitoring layer. The ownership note should name the team that operates the workload and the team that triages security alerts.

Monitoring arrows hard to follow?

Place Azure Monitor outside the virtual network boundary so the monitoring arrows can converge without covering the private service paths.
Use one consistent connector colour for every monitoring path.

Need another layout option? Help me simplify the monitoring paths in my Azure architecture diagram.

Export and verify the finished diagram

A PNG gives you a shareable snapshot of the completed architecture. Including a copy of the diagram keeps the exported image editable in draw.io.

Add Green = addressed risk to the existing legend.
Keep Red = unresolved risk visible in the legend.
Save the completed editable diagram to the same local file from earlier.

Before you export, predict whether a reviewer can connect every original finding to a visible control or owner.

Confirm that SE:04 and SE:06 remain marked Addressed.
Confirm that SE:05 and SE:09 now show Addressed.
Confirm that SE:10 and SE:12 now show Addressed.

You should count six addressed findings. The diagram now connects each security gap to a visible architecture decision.

Open the File menu in draw.io.
Point to Export as.
Select PNG.
Select Include a copy of my diagram in the export dialog.
Confirm the export to save the PNG locally.

Before you open the export, predict whether the security story remains readable outside the editor.

Open the exported PNG from the location you chose during export.

You should see Microsoft Entra ID plus the managed identity path to Key Vault. You should also see the complete monitoring layer.

All six findings should show Addressed. The ownership note and both legend entries should remain readable.

Export missing part of the diagram?

Return to draw.io from earlier.
Move any shapes that sit far outside the main diagram closer to the workload.
Repeat the PNG export with Include a copy of my diagram selected.

Still missing content? Help me fix an incomplete draw.io PNG export.

Strong finish. Your PNG now shows controlled identity, observable activity, and named response ownership.

Secret mission

Trace an Unauthorized Key Vault Access Attempt

The approved workload path is secure. A reviewer will still ask what happens when a compromised user reaches directly for Azure Key Vault. Show where the attempt is contained before tracing the denied event to its security response owner.

Clean Up Your Resources

No Azure resources were deployed, so this project has no ongoing cloud costs. Your only cleanup decision concerns the locally saved draw.io diagram and PNG export.

Resources you used:

Your locally saved editable draw.io diagram containing the complete secure design plus the bonus attack path.
Your locally saved PNG export showing the completed secure design before the bonus attack-path annotations.

Keep everything running

No action needed. Choose this if you want to reuse the architecture during interviews or future security reviews.

Keep the editable draw.io diagram as your source file for future architecture reviews.
Use the editable diagram when you want to revisit the attack-path annotations.
Keep the PNG export as the shareable image from the main project.

Pause - I'll come back to this later

No cloud service or local process continues running after this project. Your saved files remain available without creating any charges.

Close the draw.io tab in Microsoft Edge.
Close the two Microsoft Learn tabs in Microsoft Edge.
Leave the editable diagram plus PNG export in their current saved locations.

Delete - I don't want to use this again

Remove both local artifacts if you want to start fresh. This only affects the two files you identify below.

Press the Windows key to open device search.
Use device search to open your file manager.
Use the file manager's search field to locate the recently saved editable draw.io diagram.
Preview the matching file to identify the diagram containing the complete secure design plus the bonus attack path.
Delete that editable diagram.
Use the file manager's search field to locate the recently saved PNG export.
Preview the matching file to identify the architecture image without the bonus attack-path annotations.
Delete that PNG export.
Repeat both searches after deletion.

You should find no matching copies of the two project artifacts in their original saved locations. No Azure cleanup or account deletion is required.

Nice Work!

You did it! You designed a secure Azure web workload that you can defend in an architecture review. Your threat review turned six security gaps into visible controls based on the Azure Well-Architected Framework.

You've learned how to:

Built an intentionally exposed first draft. Used a structured threat review to map six security gaps to the Azure Well-Architected security checklist.
Applied Zero Trust to the workload's traffic paths. Built secure ingress through Azure Application Gateway with Azure Web Application Firewall before reaching Azure App Service. Protected Azure SQL Database through private connectivity. Applied the same private boundary to Azure Key Vault.
Set Microsoft Entra ID as the user identity boundary. Replaced stored credentials with a managed identity for Azure App Service. Sent application telemetry to Application Insights. Routed platform monitoring to Azure Monitor. Named the security team as the incident triage owner. Exported a portfolio-ready PNG from draw.io. Preserved an editable diagram copy inside the image.
Completed the Secret Mission by tracing an unauthorized attempt to reach Azure Key Vault. Your diagram shows two containment points. It routes the denied event to Azure Monitor. It ends with a named response owner plus a defined audit-log review.

Ready to quiz yourself?