Microsoft Azure Fundamentals AZ-900: General Security and Network Security Features

Introduction: Mind the (Security) Gap

Let me take you back to one of my earliest gigs as a junior sysadmin, back when “migrating to the cloud” sounded like science fiction. Some colleagues and I were asked to spin up virtual servers in this new thing called the cloud. “It’s all managed by Microsoft,” someone said. “Hey, Microsoft’s got it all covered—no more security headaches, right?” If I had a dollar for every time someone said that, I’d probably have my own datacenter by now. Honestly, I have to bite my tongue every time—I just want to facepalm right there. Honestly, this is hands-down the biggest myth I hear from folks just getting started with the cloud. And trust me, believing it? That’s a shortcut straight to trouble—you really don’t want to learn that the hard way.

The reality? So, you’re about to take your first real plunge into the cloud—pretty exciting, isn’t it? Maybe a bit nerve-wracking too, but that’s totally normal. To be honest, jumping into the cloud reminds me of swapping your cozy little starter apartment for the keys to a super-slick penthouse way up in a skyscraper. Suddenly, the whole world looks different! Don’t get me wrong—it’s seriously cool up there, and the ‘view’ (aka, the possibilities) is just unreal! But let’s be real here—it can totally leave you spinning at first. You’re basically standing in the hallway thinking, ‘Wait, where’s the light switch? How do I unlock the door?’ What does this button do?!’ You spend a while just trying not to set off the alarm by accident. Picture this for a sec: you’re living in this skyscraper, and Microsoft’s the landlord—they’ve loaded the whole place with top-notch security gadgets, alarms, cameras, the works. You name it, it’s there. We’re talking security cams everywhere, alarms that’ll go off if someone sneezes the wrong way, guards doing their rounds… it’s locked up tight with all the high-end tech you could ask for. But guess what? Locking your own apartment door and making sure you don’t leave your spare keys under the mat? That’s still on you. Whether you’re knee-deep in AZ-900 study guides, thinking about making a career move, or totally new to this whole Azure thing, let me tell you—learning how Azure security works goes way beyond just ticking a box for the exam. It’s the building block for actually trusting the cloud with your stuff, day to day. Let’s actually roll up our sleeves and make sense of Azure’s security and networking tools, swap a few stories from real-world chaos, and pack your toolkit so you’re ready to crush the AZ-900 and keep your cloud setup safe.

Making Sense of Azure’s Shared Responsibility Model

The shared responsibility model is the bedrock of cloud security. Many newcomers—and even experienced pros—stumble here. In Azure, security is shared between Microsoft and the customer. It’s not “hands off” for you, nor is it a case of “you’re on your own.”

Analogy: Think of renting an apartment. Your landlord—let’s say that’s Microsoft in our story—takes care of putting sturdy locks on the main doors, setting up all the fire alarms, installing cameras, and making sure the building itself doesn’t collapse on your head. But you’re the one who’s gotta actually close and lock your own apartment door, stash your valuables somewhere safe, and make the call on who gets a copy of your key. In Azure, Microsoft handles physical datacenter security, underlying infrastructure, and network hardware. You’re responsible for your data, identities, access controls, and configurations.

Responsibility by Service Model:

Gray Areas: For services like managed databases (PaaS), you don’t patch the OS, but you must secure access, configure firewalls, and manage encryption keys. Always check service documentation for compliance responsibilities.

War Story: A client left their VM’s RDP port (3389) open to the internet, believing Azure would protect them by default. Long story short, within just a week, that VM got hit and compromised. Sure, Microsoft handled the guts of the infrastructure, but it was up to the client to actually lock things down on their end. Take it from me: you really want to know what’s on your plate before trouble finds you. Don’t wait to learn the hard way!

Zero Trust Security in Azure

Modern cloud security is built on the Zero Trust principle: never trust, always verify. Honestly, you’ve got to get in the mindset of, ‘Anything weird could go down at any time—better stay alert!’ Give folks just what they absolutely need—no more, no less—and always, always take a second look before letting anyone in. Seriously, don’t cut corners.

• Verify explicitly: Always authenticate and validate user and device identity (use MFA, Conditional Access).
• Least privilege: Grant only the minimum access users/resources need.
• Assume breach: Monitor continuously, segment networks, and be ready to respond.

Azure actually bakes Zero Trust right in with stuff like Conditional Access in Microsoft Entra ID, separate Virtual Networks, Just-in-Time access for VMs, and always-on monitoring thanks to Defender for Cloud.

Core Azure Security Features

Let’s Talk: Identity & Who Gets the Keys

Microsoft Entra ID (formerly Azure Active Directory): Think of Entra ID as the security guard at your cloud’s front door. It’s sort of like rolling up to the coolest club in town—there’s a tough bouncer out front who checks your ID to make sure you’re really on the list (that’s authentication). And once you’re in, what you get to see or do depends on the kind of wristband you’re given—maybe it’s access all-areas, maybe it’s just the basic crowd. Here’s how I usually break it down: after you’ve made it past the club’s burly bouncer (that’s the authentication part), the wristband you get slapped on—that's your authorization. It’s what tells you which areas you can actually get into, or if we’re talking Azure, which bits of your cloud you’re allowed to poke at and mess around with.

• Single sign-on (SSO): Users log in once and access multiple apps (Microsoft 365, Azure, third-party SaaS).
• Integration: Connects with on-premises Active Directory, third-party identity providers, and supports B2B/B2C scenarios.

Authentication vs. Authorization: Authentication is checking your ID at the club entrance. Authorization is the wristband showing which areas you’re allowed in.

Multi-Factor Authentication (MFA): MFA requires a second verification step (like a phone app code). It prevents 99% of identity attacks. Seriously, if you take nothing else away—always, always turn on MFA for everyone, but especially for your admins.

Conditional Access: The modern, recommended way to enforce MFA and other security controls in Microsoft Entra ID. You can even get fancy with it: set conditions so maybe MFA only pops up if someone’s logging in from a suspicious spot, block entire countries, or only let folks in if they’re on a company device.

Alright, let’s really get into it and go step by step on how to set up a Conditional Access policy—no need to panic or second-guess yourself, I’ll show you exactly where to click.

1. In the Azure portal, go to Microsoft Entra ID > Protection > Conditional Access.
2. Click + New policy.
3. Give your policy a clear name so you don’t confuse yourself later, like 'Require MFA for Admins.'
4. Set Assignments: Users/Groups (e.g., “Directory roles: Global Admin”).
5. Cloud apps: Select “All cloud apps” or specific ones.
6. Conditions: Add sign-in risk or locations if desired.
7. Access controls: Grant access Require multi-factor authentication.
8. Enable the policy and click Create.

Exam Tip: Per-user MFA (the old method) is still available but Microsoft recommends Conditional Access for flexibility and auditing.

Troubleshooting: If users are unexpectedly blocked, check Conditional Access logs under “Sign-ins” for reasons and remediation steps.

Managed Identities for Azure Resources: Managed identities (system-assigned or user-assigned) allow Azure resources (VMs, Functions, Logic Apps) to securely access services like Key Vault or Azure SQL—without storing secrets in code or config files.

Let’s jump into a quick hands-on: setting up a managed identity for a VM so it can pull secrets from Key Vault—no secret squirrel business required.

1. Enable managed identity in VM’s “Identity” pane.
2. Go to Key Vault’s Access control (IAM), add a role assignment (e.g., Secret Reader) for the VM’s managed identity.
3. Now, once those permissions are set, your app (or even you, while testing) can just jump right in from that VM using the Azure CLI—or whatever tool you fancy—and pull secrets directly out of Key Vault. No extra hoops to jump through. No clunky hacks, no extra steps—just works straight out of the gate. Goodbye to sticky notes full of passwords or copying secrets all over creation—this way, everything stays neat, tidy, and super secure from the get-go. No more sketchy hardcoded passwords lurking in your scripts!

az keyvault secret show --vault-name MyKeyVault --name "DbPassword" (Yup, that simple—no password juggling involved!)

RBAC: Give People (and Apps) Just Enough Access

RBAC’s your tool for handing out permissions—think of it as choosing who gets which keys and what rooms they unlock. You can set these at a big-picture level (whole subscription), just a department (resource group), or even on a single, special-resource 'room.'

• Owner: Full control, including access management.
• Contributor: Create/edit resources, but can’t grant access.
• Reader: View only, no changes.

My Go-To RBAC Tips:

• Grant the least privilege needed.
• Stick with the built-in roles most of the time—they’re solid—but if you need something super specific, go ahead and whip up a custom role.
• Regularly audit role assignments—review the “Access control (IAM)” blade and use “Access reviews” in Microsoft Entra ID.

Let me show you the lowdown on assigning a built-in role in Azure—it’s actually way easier than people think:

1. First, find whatever resource you want to manage (could be storage, a VM, whatever), click on it so you’re on its overview screen, ready to make changes.
2. Click Access control (IAM) > Add > Add role assignment.
3. Select a role (e.g., “Storage Blob Data Contributor”), then the user/group/managed identity.
4. Click Save.

Lab: Create a Custom Role

1. In the Azure portal, go to Subscriptions > Access control (IAM) > Roles > + Add > Add custom role.
2. This is where you really get to put on your architect’s hat—if you’re the kind of person who likes to fine-tune exactly what everyone is allowed (or not allowed) to do, this is your jam! Make those permissions as tight or as loose as the situation calls for. If you want to let somebody just start or stop VMs—and nothing else—spell that out clearly in your custom role. Better too strict than too loose, honestly. You can totally do that here.
3. Assign custom role as above.

Data Protection

Your data in Azure is precious—protect it at all times:

• Encryption at rest: Storage Service Encryption is on by default for managed disks, blobs, and files. For some services, verify encryption is enabled.
• Encryption in transit: Azure uses TLS (Transport Layer Security) for secure connections between clients and Azure services.
• Customer-managed keys (CMK): For extra control, you can provide your own keys via Key Vault, instead of relying solely on Microsoft-managed keys.
• Double encryption: Some services allow multiple encryption layers (e.g., Azure SQL DB with Transparent Data Encryption + disk encryption).

Azure Key Vault: Securely store secrets, certificates, and encryption keys. Whether you’re cool just letting Microsoft look after everything for you, or you want to dial it up and use hardware security modules like a real secret agent, Key Vault has your back—no headaches, no drama. Quick tip: these days, you really should use RBAC for access control with Key Vault (it’s way smoother than the old legacy access policies).

Lab: Store and Retrieve a Secret with Key Vault (Portal & CLI)

1. Go to Create a resource > Security > Key Vault.
2. Configure access with RBAC: assign “Key Vault Secrets User” to users or managed identities.
3. Store a secret via the portal or CLI:

az keyvault secret set --vault-name MyKeyVault --name "DbPassword" --value "SuperSecret123!" (yup, that’s all it takes—your secret’s now locked away!) (And boom—your secret’s stashed away safe and sound!) (And there you go—your secret’s stored tight, no drama!)

To read the secret (from a VM with managed identity):

az keyvault secret show --vault-name MyKeyVault --name "DbPassword" (Yup, that simple—no password juggling involved!)

• Soft-delete and purge protection: Enable these to recover deleted secrets and prevent permanent loss.
• Secret rotation: Automate regular key and secret rotation for improved security.

Best Practice: Never store passwords or connection strings in code—use Key Vault and managed identities.

Let’s be real for a sec—let’s talk about the things that really make you lose sleep: those ever-present security threats. Here’s the deal—hackers never clock out, and your systems can’t afford to either. Your security needs to keep hustling day and night, even when you’re grabbing a nap.

These attackers never run out of new angles—you’ve got to keep your security radar tuned and never get so comfortable you miss their latest move. Seriously, there’s always something new bubbling up. Microsoft Defender for Cloud is your security control center—offering continuous assessment, recommendations, and threat detection across all your Azure resources (and even multi-cloud environments).

• Defender for Cloud Tiers:
• Free: Security recommendations and Secure Score.
• Standard: Advanced threat protection (Defender plans for VMs, Storage, SQL, Kubernetes, etc.), Just-in-Time VM access, adaptive application controls, regulatory compliance dashboard.
• Defender for Cloud Plans: Enable/disable per resource type (e.g., Defender for Servers, Storage, SQL).
• Integration: Connects with SIEM tools like Azure Sentinel for deeper analytics and investigation.
• Just-in-Time (JIT) VM Access: Temporarily opens management ports on VMs for approved users only, minimizing attack surface.

Lab: Enable Defender for Cloud Standard (Portal)

1. Go to Microsoft Defender for Cloud > Environment settings.
2. Select your subscription, enable required Defender plans (e.g., Defender for Servers).
3. Review recommendations in the Recommendations blade.

Case Study: A student flagged a “High” severity alert for an open management port. Using JIT in Defender for Cloud, they locked down the port and reduced their exposure in minutes. Continuous monitoring and fast response are critical!

Monitoring & Governance

Azure Monitor provides real-time collection and analysis of metrics and logs across your Azure estate. You can totally get Azure Monitor to send you an alert if anything funky happens, or just use it to see which of your systems are running smooth and which ones are crying out for a little TLC.

• Log Analytics: Centralizes logs for querying and dashboarding.
• Diagnostic Settings: Enable on resources to route logs to Log Analytics, Storage, or Event Hub.
• Activity Logs: Track who did what, when, and where in your environment.

Lab: Set Up an Alert Rule

1. Go to Azure Monitor > Alerts > + New alert rule.
2. Pick whatever resource you want to babysit for a while—maybe it’s a VM you’re worried about, a storage account that’s extra important… honestly, anything that makes your spidey senses tingle or just needs some backup.
3. Define a condition (e.g., “Administrative operation” or CPU spike).
4. Set an action group for notifications (email, SMS, Logic App).

Azure Policy enforces organizational requirements automatically.

• Effects include: Deny (block non-compliant deployments), Audit (log but allow), Append (add properties), DeployIfNotExists (remediate).
• Initiatives bundle related policies for easier management (e.g., a security baseline).

Lab: Create a Custom Azure Policy

1. Go to Azure Policy > Definitions > + Policy definition.
2. Use built-in policy templates or define JSON for custom rules.
3. Assign at subscription or resource group level.
4. Keep tabs on your compliance progress in the Policy dashboard, and if you spot anything off, fix it up right there.

Resource Locks: Prevent accidental deletion or modification of critical resources using CanNotDelete and ReadOnly locks.

• Set via the Locks blade on the resource.
• Audited in Activity Logs.

Azure Network Security Features

Splitting Up Your Network for Safety (a.k.a. Segmentation & Isolation)

Virtual Networks (VNets): VNets are your isolated Azure network segments, comparable to office suites in a skyscraper. Within that VNet floor, you carve out subnets—they’re like separate offices or rooms for your different teams or workloads. They’re perfect for splitting up your web servers, app servers, and databases so nothing steps on each other’s toes.

Application Security Groups (ASGs): ASGs group VM NICs by application, simplifying NSG rules: allow traffic between “Web” and “DB” groups instead of managing per-IP rules.

Lab: Use ASGs in NSG Rules

1. Create ASGs (e.g., “WebServers”, “DbServers”).
2. Assign VMs to ASGs via their NIC settings.
3. In NSG, create rules that allow traffic from “WebServers” ASG to “DbServers” ASG on port 1433 (SQL).

Access Control

Network Security Groups (NSGs): NSGs filter traffic at L3/L4 (IP, port, protocol) and are always stateful: if inbound traffic is allowed, response traffic is automatically allowed out.

• You can stick NSGs on entire subnets or get granular and put them right on a specific network interface (NIC)—it just depends where you want to draw your traffic lines.
• If you’re worried about rules overlapping, here’s the trick: the lower the priority number, the sooner it gets checked—so be careful to set those priorities right or you might block something you meant to allow.
• Out of the box, NSGs slam the door on all inbound traffic but let everything out. Need to reel in those outbound flows? You can totally lock things down even more if your scenario calls for it.

Sample NSG Rule Table:

Lab: Create and Test NSG Rules (CLI & Portal)

az network nsg create --resource-group MyResourceGroup --name MyNSG (Super quick way to spin one up from the CLI!) az network nsg rule create --resource-group MyResourceGroup --nsg-name MyNSG --name AllowHTTP --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-range 80 --source-address-prefix * (One-liner to let HTTP through—easy peasy!)

Troubleshooting: If you lose access to a VM, use the Azure Serial Console or Network Watcher’s “Connection Troubleshoot” tool to diagnose NSG/firewall issues.

Guarding the Gates: Firewalls, WAFs, and DDoS Defenders

Azure Firewall: A fully-managed, stateful L3-L7 firewall for centralized control, logging, and application/network rules. This thing is perfect for putting the brakes on traffic at the edges of your network, or between different parts inside (what folks call east-west traffic).

Application Gateway + Web Application Firewall (WAF): Application Gateway is a layer 7 load balancer for HTTP(S) traffic; WAF adds protection against web attacks like SQL injection and XSS.

Feature Comparison Table:

Lab: Deploy Azure Firewall (Portal)

1. Go to Create a resource > Networking > Azure Firewall.
2. Just hook your firewall up to the right VNet and subnet, and you’re ready to start defining how traffic moves.
3. Write up rules for what’s okay and what’s not—for example, maybe you want to allow web traffic out (ports 80 and 443) but block everything else.

DDoS Protection: All Azure public IPs are protected by basic DDoS defense. For workloads at risk, enable DDoS Protection Standard for detailed telemetry, adaptive tuning, and attack mitigation SLAs.

• Enable via the DDoS Protection Plan and associate with a VNet.
• Keep an eye on Azure Monitor for live alerts—if anything sketchy pops up, you’ll know right away.

Security Note: DDoS Standard is recommended for e-commerce, online services, or any public endpoint with business impact.

Private Connectivity and Secure Access

VPN Gateway: Establishes site-to-site or point-to-site encrypted tunnels between on-premises and Azure VNets over the internet. It’s super fast to get going and works great for small businesses or remote branches that need a trustworthy connection into Azure.

ExpressRoute: A private, dedicated connection from on-premises to Azure via a connectivity provider. Offers predictable latency and reliability, but does not automatically encrypt traffic. For sensitive data, add encryption at the application or network layer.

Azure Bastion: Provides secure, browser-based RDP/SSH to VMs without exposing public IPs. No VPN or NSG rule changes needed.

Lab: Connect to a VM with Azure Bastion

1. Deploy Azure Bastion in your VNet.
2. In the VM blade, click Connect > Bastion and log in securely via the portal.

Service Endpoints vs. Private Endpoints:

• Service Endpoints: Extend Azure service (e.g., Storage, SQL) IP addresses into your VNet. Traffic remains on the Microsoft backbone. Secure PaaS access to only your network.
• Private Endpoints (Private Link): Assign a private IP to Azure services in your VNet, fully isolating traffic from public internet. Strongest option for data privacy.

Lab: Secure a Storage Account with Private Endpoint

1. In the Storage Account pane, select Networking > Private endpoint connections.
2. Create a new private endpoint in your VNet/subnet.
3. Update NSG rules to allow access only from private IPs.

Troubleshooting and Diagnostics

Even with best practices, misconfigurations happen. Here’s how to diagnose and resolve common Azure security/networking issues:

• NSG Rule Lockout: Lost access to a VM? Use Azure Serial Console or Network Watcher > Connection Troubleshoot to test connectivity and identify blocking rules. Temporarily relax NSG for recovery, then re-tighten with caution.
• MFA/Conditional Access Lockout: If an admin is locked out due to Conditional Access, use an emergency access (break-glass) account excluded from policies. Audit and rotate credentials regularly.
• RBAC Misassignment: If a user can’t access a resource, check role assignments at all scopes (resource, group, subscription). Use Access control (IAM) > Check access to trace permissions.
• Key Vault Access Denied: Confirm that the user or managed identity has the correct RBAC role on the Key Vault.
• Network Connectivity: Use Network Watcher to run packet captures, check effective security rules, and monitor network topology.

Pro Tip: Enable diagnostic logs on NSGs, Firewall, and Key Vault, then stream to Log Analytics for centralized troubleshooting.

Security Best Practices in Azure

Avoid common pitfalls with these proven Azure security best practices:

• Identity: Always enable MFA (preferably via Conditional Access). Use strong password policies and monitor risky sign-ins. Assign least privilege—never grant “Owner” unless absolutely necessary.
• Network: Segment workloads (VNets/subnets/ASGs), restrict inbound ports, and use NSGs. Employ Azure Firewall for centralized enforcement. Double-check rules before deployment.
• Encryption: Ensure all data (storage, databases, backups) is encrypted at rest and in transit. Use Key Vault with managed identities for secret management. Enable soft-delete and purge protection.
• Monitoring: Set up Azure Monitor alerts, review logs weekly, and use Defender for Cloud’s Secure Score and recommendations.
• Policy and Governance: Enforce tags, resource locks, and compliance policies. Audit and remediate non-compliant resources regularly.
• Automation: Use Azure Blueprints to deploy security baselines, and automate compliance with Policy Initiatives.

Common Pitfalls: Forgetting shared responsibility, skipping MFA, creating overly permissive NSG/firewall rules, not monitoring logs, or failing to review access regularly.

Practical Scenarios and Labs

Lab 1: Creating/Configuring an NSG (Portal & CLI)

Portal Steps:

1. Go to Network Security Groups in the portal.
2. Click Create, enter name/location/resource group.
3. Add inbound rule:

• Name: Allow-HTTP
• Priority: 100
• Port: 80
• Source: Any
• Action: Allow

1. Associate NSG with your subnet or VM NIC.

CLI Steps:az network nsg create --resource-group MyResourceGroup --name MyNSG (Super quick way to spin one up from the CLI!) az network nsg rule create --resource-group MyResourceGroup --nsg-name MyNSG --name AllowHTTP --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-range 80 --source-address-prefix * (One-liner to let HTTP through—easy peasy!) Troubleshooting Tip: Lost connectivity? Use Network Watcher or Serial Console. Always keep an emergency access strategy.

Lab 2: Enabling MFA with Conditional Access

1. Go to Microsoft Entra ID > Protection > Conditional Access.
2. Create a new policy (“Require MFA for all users” or specific group).
3. Set grant control to Require multi-factor authentication.
4. Test policy with a non-admin user first to avoid lockouts.

Tip: Prepare a help article for users setting up the Microsoft Authenticator app.

Lab 3: Assigning RBAC Roles and Auditing Access

1. Go to any Azure resource’s Access control (IAM) blade.
2. Click Add > Add role assignment.
3. Choose a built-in or custom role and assign it to a user/group/managed identity.
4. Use Check Access to audit assigned permissions and troubleshoot issues.

Exam Tip: Know which roles are needed for each action. “Reader” sees, “Contributor” changes, “Owner” manages access.

Lab 4: Reviewing Security Recommendations in Defender for Cloud

1. Go to Microsoft Defender for Cloud.
2. Review Secure Score and top recommendations.
3. Remediate issues (e.g., open ports, missing encryption) directly from the portal.

Knowledge Check: Is the recommendation about platform (Microsoft) or customer responsibility? This is crucial for the exam!

Lab 5: Using Managed Identity to Access Key Vault Secret from a VM

1. Enable system-assigned managed identity on a VM.
2. Grant the VM’s identity “Key Vault Secrets User” role on the Key Vault.
3. Log in to the VM and retrieve a secret:  az keyvault secret show --vault-name MyKeyVault --name "DbPassword" (Yup, that simple—no password juggling involved!)

Lab 6: Secure VM Access with Azure Bastion

1. Deploy Azure Bastion in the desired VNet.
2. Remove public IP from VM.
3. Use Bastion’s browser-based RDP/SSH to connect securely, no public exposure.

Scenario 1: Securing a Two-Tier Web App

Textual Description of Network Layout: Imagine a VNet with two subnets: “Web” (web server VM) and “DB” (database VM). The web subnet allows HTTP/S from the internet through Azure Firewall. The DB subnet allows SQL traffic from the web subnet only, enforced with NSG and ASG rules. Both subnets deny all other inbound traffic. Azure Firewall inspects inbound and outbound traffic, with logging enabled.

• Create VNets/subnets and deploy VMs.
• Apply NSGs and ASGs for least privilege rules.
• Deploy Azure Firewall; set rules for inbound web traffic only.
• Enable diagnostics/logging for monitoring and compliance.

Case Study: A retail client accidentally exposed their database VM to the internet. Tightening NSG and ASG rules, auditing access, and enabling Firewall logging quickly closed the gap and passed their security audit.

Scenario 2: Hybrid Cloud with Secure VPN and ExpressRoute

Textual Description of Network Layout: An on-premises datacenter connects to Azure VNet via site-to-site VPN. An ExpressRoute circuit is added for mission-critical apps. Sensitive workloads use Private Endpoints to restrict access to SQL and Storage accounts. Azure Bastion provides secure admin access to VMs—no public IPs. Azure Monitor and Sentinel collect logs from all endpoints.

• Establish VPN Gateway for initial connectivity.
• Deploy ExpressRoute for high-throughput, private connection (with app-level encryption).
• Configure Private Endpoints for PaaS resources; restrict NSG rules to on-prem IPs only.
• Set up Azure Bastion for secure admin access.
• Monitor and alert on suspicious activity using Sentinel.

Best Practice: Always encrypt sensitive data, even over ExpressRoute or VPN, and use Private Endpoints for maximum isolation.

Scenario 3: Securing a Serverless API with Private Link

Deploy an Azure Function App with Private Endpoint in a VNet. Only an internal web app in the same VNet can connect; all public traffic is blocked. Storage and Key Vault dependencies are also accessed via Private Endpoints. Defender for Cloud monitors function activity; Sentinel correlates suspicious events.

• Deploy Function App with networking set to private.
• Configure Private Endpoints for all backend services.
• Set NSG rules for east-west traffic only.
• Monitor with Defender for Cloud and Sentinel.

Security Note: Use managed identities for secure access to secrets from the function code.

Advanced Security Monitoring: Azure Sentinel

Azure Sentinel is Microsoft’s cloud-native SIEM (Security Information and Event Management) solution. It aggregates logs, detects threats, and automates response.

• Ingest data from Azure resources, on-prem systems, and other clouds.
• Use built-in analytics to detect suspicious activity (e.g., failed logins, unusual traffic).
• Automate investigation and remediation with playbooks (Logic Apps).

Lab: Enable Azure Sentinel

1. In the portal, go to Azure Sentinel and create a new workspace.
2. Connect sources (Azure AD, VMs, Firewall, etc.).
3. Run queries and set up alert rules for threats.

Common Attack Vectors and Azure Mitigations

Security for Serverless and Containers

• Azure Functions: Secure with Private Endpoints, managed identities, and Defender for Cloud monitoring.
• Azure Kubernetes Service (AKS): Use RBAC, network policies, container image scanning, and enable Defender for Kubernetes for threat detection.

Exam Preparation: Summary, Tips, and Sample Questions

AZ-900 Security and Networking Objectives Quick Reference:

Memory Aids:

• Shared Responsibility: “You secure what you control.”
• RBAC Rule: “Least privilege, right role, right scope.”
• Network Controls: “NSG for subnets/NICs, Firewall at perimeter, WAF for web apps.”

Sample Multiple-Choice Questions:

1. Who is responsible for securing data stored in Azure Storage Accounts?
   A) Microsoft
   B) Customer
   C) Microsoft and Customer
   Answer: B) Customer
2. Which Azure feature enables a VM to securely access Key Vault without credentials?
   A) Service Principal
   B) Managed Identity
   C) User Account
   Answer: B) Managed Identity
3. To restrict web traffic to a subnet, which feature should you use?
   A) Azure Monitor
   B) Network Security Group (NSG)
   C) Azure Policy
   Answer: B) Network Security Group (NSG)

Common Exam Pitfalls:

• Forgetting shared responsibility splits (especially for PaaS vs. IaaS)
• Mixing up NSG, Firewall, and WAF scopes
• Confusing “Reader” and “Contributor” RBAC roles
• Assuming ExpressRoute always encrypts data (it does not!)

Study Recommendations:

• Spend time in the Azure portal—try out labs, apply policies, and break/fix things safely.
• Microsoft's official documentation provides detailed guidance on AZ-900 exam objectives and hands-on labs.
• Review Secure Score and recommendations in Defender for Cloud.
• Keep updated with new Azure features and naming (e.g., Microsoft Entra ID).

Key Terms Glossary:

• RBAC – Role-Based Access Control
• NSG – Network Security Group
• MFA – Multi-Factor Authentication
• Conditional Access – Policy engine for access controls
• Managed Identity – Identity for Azure resources
• Private Endpoint – Assigns private IP to Azure PaaS resource
• Defender for Cloud – Unified cloud security posture management
• Sentinel – Cloud-native SIEM
• Zero Trust – Security model: never trust, always verify

References & Further Reading

• Microsoft's official documentation provides a comprehensive skills outline for the AZ-900 Exam.
• Azure Security Best Practices Overview offers guidance on securing your cloud environment.
• Microsoft Entra ID (Azure AD) Documentation explains identity and access management in detail.
• Microsoft Defender for Cloud documentation covers unified security management and threat protection.
• Azure Monitor Overview describes monitoring solutions for infrastructure and applications.
• Azure Sentinel Overview introduces cloud-native SIEM capabilities.
• Azure Key Vault Documentation details secure storage of keys and secrets.
• Azure Identity Management resources outline best practices for managing identities.
• Azure Networking Documentation explains network architecture and security features.

Experiment in a free Azure subscription—try the labs, configure policies, and investigate logs. Curiosity and hands-on practice are your best assets for both the exam and real-world cloud security!