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

Introduction

Azure security gets confusing fast because several services sound related while solving very different problems. For AZ-900, you’re not trying to memorize every last configuration detail or deployment step. What really matters is getting a feel for what each service actually does, when you'd reach for it, and how to tell apart the ones people mix up all the time, like Microsoft Entra ID vs Azure RBAC, NSG vs Azure Firewall, WAF vs DDoS Protection, and Defender for Cloud vs Microsoft Sentinel.

Honestly, the easiest way I’ve found to think about Azure security is as a stack of layers: identity, permissions, network controls, application protection, data protection, monitoring, and governance. Azure security is also strongly identity-driven. In modern cloud design, identity is a major control plane, but it does not replace network, data, and monitoring controls. It works alongside them.

One terminology note before we start: Microsoft Entra ID is the current name for Azure AD. You will still hear “Azure AD” in older documentation and conversations, but for current Microsoft terminology and exam readiness, recognize Microsoft Entra ID as Microsoft’s cloud-based identity and access management service used across Azure, Microsoft 365, and many other applications.

Security Foundations You Need for AZ-900

Shared responsibility model is foundational. Microsoft takes care of the cloud infrastructure itself, and customers are responsible for what they build, deploy, and configure inside that cloud. That responsibility split shifts a bit depending on whether you’re using IaaS, PaaS, or SaaS.

A move to Azure does not remove security responsibility. If you're running virtual machines in Azure, you're still responsible for patching the guest operating system, setting up access the right way, protecting data, and avoiding public exposure unless there's a real business reason for it. PaaS definitely takes a lot of the day-to-day operational work off your plate, but you still have to look after identities, secrets, data, and secure configuration on your side.

CIA triad remains a useful lens:

• Confidentiality – keep data private through encryption, access control, and secret protection.
• Integrity – prevent unauthorized change through permissions, logging, and secure configuration.
• Availability – keep systems reachable through resilient design and protections such as DDoS mitigation.

Defense in depth means using multiple layers. A very practical Azure setup might look like this: Entra ID handles the sign-in side, MFA adds an extra check, RBAC controls who can do what, NSGs help filter traffic at the subnet level, WAF protects the public web app, Key Vault keeps secrets locked down, and Sentinel gives you visibility into what’s happening. And that layering is the whole idea, honestly. If one control misses something, another one’s there to catch it. If one control fails, others still help.

Least privilege means granting only the access required. In Azure, that might mean giving someone Reader instead of Contributor if they only need to view things, scoping access to a resource group instead of the whole subscription, and not leaving broad admin rights in place any longer than you have to.

Zero Trust is a strategy, not a single product. The mindset is actually pretty simple: verify everything you reasonably can, keep access tight, and assume something might already be compromised somewhere in the environment. In Azure, that usually shows up as MFA, Conditional Access, private connectivity, segmented networks, and good logging so you can actually see what’s going on.

Authentication, Authorization, and Governance Compared

This is one of the most important AZ-900 areas because many questions are really asking you to identify which control plane the problem belongs to.

Identity and Access Security in Azure

Microsoft Entra ID is Microsoft’s cloud identity and access management service. It handles users, groups, application identities, authentication, and access to cloud apps. For Azure, it is the identity platform most commonly tied to sign-in and access decisions.

At a fundamentals level, know these identity types:

• Users – human identities.
• Groups – collections used to simplify access assignment.
• Service principals – identities used by applications or automation.
• Managed identities – Azure-managed identities for resources, often used so apps can authenticate to services like Key Vault without stored credentials.

Authentication proves identity. Authorization determines what that identity can do. A simple way to picture the Azure flow is this: someone signs in through Entra ID, Conditional Access checks the context, MFA might get triggered, and then Azure RBAC determines what that person or identity can actually do at the subscription, resource group, or resource level.

Single sign-on lets users sign in once and access multiple applications. Multi-Factor Authentication adds another verification factor, which is one of the most effective protections against compromised passwords.

Conditional Access is not general-purpose authorization for Azure resource actions. It evaluates signals during authentication and token issuance to supported resources, then enforces controls such as require MFA, block access, require password change, or require a compliant device. Common signals include user or group, application, device state, location, and sometimes risk. Risk-based scenarios depend on the relevant Entra ID Protection capabilities and licensing, so not every tenant has the same feature set.

Common Conditional Access examples:

• Require MFA for privileged administrators.
• Block legacy authentication.
• Require a compliant device for access to sensitive apps.
• Restrict access from specific locations.

Azure RBAC controls permissions to Azure resources. You can assign roles to security principals, which is just Microsoft’s way of saying identities like users, groups, service principals, and managed identities. Scope matters, and permissions inherit downward through the Azure hierarchy:

• Management groups
• Subscriptions
• Resource groups
• Resources

Common built-in roles to recognize:

A practical example: assigning Reader at subscription scope lets someone view everything in that subscription. Assigning Contributor only on one resource group limits their management rights to that workload. That is a classic least-privilege design.

Azure Policy is different from RBAC. RBAC answers, “Who can do this action?” Policy answers, “Is this deployment or configuration allowed?” If a user can sign in and has Contributor rights but deployment is still blocked, Policy may be the reason.

Network Security Features in Azure

Virtual Networks are private network boundaries in Azure. Subnets divide a VNet into smaller segments so you can separate workloads and apply controls more precisely. A simple three-tier setup might use a web subnet, an app subnet, and a data subnet. That kind of segmentation cuts down on unnecessary east-west traffic, and it usually makes the security rules much easier to understand and maintain.

Network Security Groups are stateful packet-filtering rules applied to subnets or network interfaces. They let you allow or block traffic based on things like source, destination, port, and protocol, so they’re really handy for basic network control. Because they’re stateful, return traffic for an allowed session gets handled automatically. They are not a full replacement for a centralized firewall service.

A few NSG points are really worth keeping in mind for AZ-900:

• They can be associated to a subnet or a NIC.
• They evaluate inbound and outbound rules.
• Rules have priorities; lower numbers are evaluated first.
• Azure includes default rules, so troubleshooting often starts with checking custom and default rule interaction.

A practical NSG example would be allowing HTTPS inbound to a web subnet while blocking direct RDP or SSH from the internet.

Azure Firewall is a managed, stateful network security service usually deployed in a VNet and commonly used in centralized or hub-and-spoke architectures. It supports centralized policy enforcement, network rules, application rules, and DNAT. It’s a lot more than just a simple subnet filter. In real environments, it’s often used for controlled egress, traffic inspection, and keeping rule management consistent across multiple networks.

Web Application Firewall protects web applications from common HTTP/S attacks such as SQL injection and cross-site scripting. In Azure, WAF is delivered through supported services such as Azure Application Gateway WAF and Azure Front Door WAF, rather than as a generic standalone firewall product. Application Gateway WAF is often a good fit when you’re delivering an app in a specific region, while Front Door WAF is usually the better choice when you want a global entry point or edge-based delivery.

Azure DDoS Protection helps protect Azure resources from DDoS attacks, especially volumetric and protocol attacks that threaten availability. Azure already includes basic platform-level DDoS infrastructure protection by default, so you’re not starting from zero. DDoS Network Protection adds enhanced protection for virtual networks and internet-facing workloads with more visibility and tuning. For AZ-900, the big thing to remember is that DDoS Protection helps keep public-facing services available during flood-style attacks. It doesn’t inspect web payloads or filter out things like SQL injection.

Azure Bastion provides secure RDP and SSH connectivity to VMs through the Azure portal or client experience without assigning public IP addresses to the target VMs. It reduces exposure of management ports, but it doesn’t replace broader admin security practices like RBAC, NSGs, and just-in-time access where that applies.

Private Link is the underlying capability for private access to supported services. A Private Endpoint is the network interface with a private IP in your VNet that privately maps to a supported PaaS resource. This is a key distinction. If the requirement says private access to a supported Azure service without public exposure, Private Endpoint is the exam-friendly answer. Private endpoints often require correct private DNS configuration so name resolution points to the private IP.

Service Endpoints vs Private Endpoints is another useful distinction. Service endpoints extend VNet identity to an Azure service over the Azure backbone, but the service still uses its public endpoint. Private endpoints give the service a private presence in your VNet through a private IP. If the wording emphasizes no public exposure, choose Private Endpoint.

VPN Gateway provides encrypted connectivity over the internet. It supports site-to-site connections between on-premises and Azure, point-to-site connections for individual client devices, and VNet-to-VNet connections between Azure networks.

ExpressRoute provides private connectivity to Azure through a connectivity provider and does not use the public internet for the data path. It is often chosen for more predictable enterprise connectivity. One important nuance here: ExpressRoute is private, but that doesn’t automatically mean the traffic is encrypted. If encryption is required, you may need to add that separately.

Data Protection and Secrets Management

Data protection in Azure usually starts with encryption at rest and encryption in transit. At rest means data is protected while stored. In transit means data is protected while moving across networks, usually with TLS.

Many Azure services provide platform-managed encryption by default. Azure Storage uses Storage Service Encryption, and managed disks support encryption options as well. Some workloads support customer-managed keys if an organization needs more control over key ownership and lifecycle. For AZ-900, the big idea is pretty simple: Azure often gives you built-in encryption capabilities, but customers still manage access and can choose how keys are controlled depending on their requirements.

Azure Key Vault securely stores and manages sensitive material:

• Secrets – passwords, connection strings, tokens
• Keys – cryptographic keys
• Certificates – X.509 certificates and related lifecycle use cases

A strong pattern is using a managed identity for an Azure application so it can retrieve a secret from Key Vault without storing credentials in code or configuration files. That’s a whole lot safer than hardcoding a database password in an app settings file.. Key Vault also supports rotation and centralized control, which helps cut down on secret sprawl.

Threat protection, monitoring, and visibility

Microsoft Defender for Cloud helps improve cloud security posture and provides cloud workload protection capabilities. You should associate it with recommendations, secure score, and posture improvement across Azure resources. Current Microsoft positioning also includes broader CNAPP-related capabilities, but for AZ-900 the core idea is posture management plus workload protection.

Secure Score is a guidance-oriented indicator, not a guarantee of security or compliance. It helps teams prioritize improvements such as enabling MFA, reducing public exposure, or turning on recommended protections.

Microsoft Sentinel is a cloud-native SIEM and SOAR service. It ingests logs from Azure, Microsoft 365, on-premises systems, and third-party sources. Think of Sentinel as the analytics and response layer: data connectors bring in logs, analytics rules generate detections, incidents are created for investigation, and playbooks can automate response actions.

A good mental model is this workflow: Defender for Cloud identifies weak posture and workload issues, logs flow into monitoring systems, Sentinel correlates activity into incidents, and analysts investigate or automate response.

Visibility also depends on core logging services. At a high level, know these sources:

• Azure Activity Log – subscription-level control plane events
• Resource logs/diagnostic logs – service-specific operational and security events
• Sign-in logs – authentication activity in Entra ID
• Log Analytics/Azure Monitor – collection, querying, alerting, and analysis

Defender for Cloud vs Microsoft Defender XDR can confuse beginners. Defender for Cloud focuses on cloud posture and workload protection. Defender XDR is part of the broader Microsoft Defender family for cross-domain detection and response across identities, endpoints, email, and more. For AZ-900, if the question says secure score or posture recommendations, think Defender for Cloud.

Governance, Compliance, and Policy Enforcement

Governance and security overlap heavily in Azure. Many real-world security problems are really configuration and standardization problems.

Management groups help organize multiple subscriptions so governance can be applied at scale. Policies and some access decisions can be applied high in the hierarchy and inherited downward. That matters in large environments where consistency across subscriptions is a major requirement.

Azure Policy uses definitions and assignments to enforce or audit standards. High-level effects worth recognizing include:

• Deny – block noncompliant deployments
• Audit – allow but flag noncompliance
• Modify/Append – add or alter properties such as tags in supported scenarios
• DeployIfNotExists – deploy related settings or resources when conditions are met

A classic example is assigning a policy at the production subscription level to deny public IP addresses, require tags like owner and environment, and audit resources missing required settings. That is governance, compliance support, and security control working together.

Troubleshooting Common Security Misconfigurations

Even in a fundamentals exam, troubleshooting logic helps you choose the right service.

• User signed in successfully but cannot manage a resource: check Azure RBAC role assignment and scope.
• User is blocked before or during sign-in: check Conditional Access, MFA requirements, device compliance, or sign-in restrictions.
• Deployment is denied even though the user has Contributor: check Azure Policy.
• Traffic between subnets is blocked: check NSG rules, priority order, and subnet/NIC associations.
• A VM is reachable only through insecure public RDP/SSH: consider Bastion and review public IP exposure.
• An app cannot reach Storage or SQL through a private endpoint: check whether the service supports Private Link and verify private DNS resolution.
• Web attacks still hit the app: verify the app is actually behind Application Gateway WAF or Front Door WAF and that policy is enabled.

Exam Scenarios and Rapid Review

Scenario 1: A company wants admins to access VMs without public IPs on those VMs. Answer: Azure Bastion.

Scenario 2: An auditor must view all resources in a subscription but not make changes. Answer: Azure RBAC with the Reader role.

Scenario 3: A company wants to require MFA for administrators signing in from outside trusted locations. Answer: Conditional Access.

Scenario 4: A public web app needs protection from SQL injection and XSS. Answer: WAF through Application Gateway or Front Door.

Scenario 5: A workload needs private access from a VNet to Azure Storage without public exposure. Answer: Private Endpoint.

Scenario 6: A branch office needs encrypted connectivity to Azure over the internet. Answer: VPN Gateway.

Scenario 7: An enterprise needs private dedicated connectivity to Azure. Answer: ExpressRoute.

Scenario 8: A company wants to stop creation of public IPs in production. Answer: Azure Policy.

Scenario 9: A team wants posture recommendations and secure score. Answer: Defender for Cloud.

Scenario 10: A SOC wants SIEM/SOAR capabilities and incident investigation. Answer: Microsoft Sentinel.

Rapid review keywords:

• Identity → Microsoft Entra ID
• Sign-in conditions → Conditional Access
• Permissions to Azure resources → Azure RBAC
• Allowed or denied configuration → Azure Policy
• Subnet or NIC filtering → NSG
• Centralized managed firewall → Azure Firewall
• HTTP/S web attacks → WAF
• Availability under flood attack → DDoS Protection
• Secure RDP/SSH without public VM IP → Bastion
• Private access to supported PaaS service → Private Endpoint
• Secrets, keys, certificates → Key Vault
• Recommendations and secure score → Defender for Cloud
• SIEM/SOAR → Sentinel

Conclusion

Azure security becomes much easier once you sort services by purpose. Entra ID handles identity. Conditional Access evaluates sign-in conditions. RBAC controls what authenticated identities can do. Policy governs what configurations are allowed. NSGs, Azure Firewall, WAF, DDoS Protection, Bastion, Private Endpoints, VPN Gateway, and ExpressRoute each solve different network security problems. Key Vault protects secrets and keys. Defender for Cloud improves posture, while Sentinel supports detection and response.

For AZ-900, focus on service recognition and common distinctions. If you can identify whether a question is about identity, permissions, sign-in conditions, network filtering, web protection, private connectivity, governance, or monitoring, you will answer most fundamentals questions correctly.