You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Network Security Groups (NSGs) act as a virtual firewall that filters traffic for Azure resources using a set of security rules. Each rule uses a five-tuple system—source, source port, destination, destination port, and protocol (TCP or UDP)—to decide whether to allow or deny traffic. Because NSGs are stateful, when a rule permits traffic in one direction, the return traffic is automatically allowed without needing a separate rule.
You can associate an NSG at the subnet level, the network interface (NIC) level, or both, creating layers of security. For inbound traffic, Azure evaluates the subnet NSG first and then the NIC NSG; both must allow the traffic for it to reach the resource. For outbound traffic, the order is reversed: the NIC NSG is processed before the subnet NSG. If a resource has no NSG associated with its subnet or NIC, all traffic is blocked by default when the resource has a public IP.
Every rule has a priority number ranging from 100 to 4096, where lower numbers have higher priority and are processed first. Once traffic matches a rule, Azure stops evaluating any further rules, making priority critical for resolving conflicts. Azure includes several default rules to ensure basic connectivity, including AllowVNetInBound for traffic within the same virtual network, AllowAzureLoadBalancerInBound for health probes, and DenyAllInBound to block other traffic not explicitly allowed.
To manage complex environments, you can use Application Security Groups (ASGs) and Service Tags to reduce the number of rules. ASGs let you group virtual machines by function (for example, "WebServers") so you apply rules to logical groups instead of individual IP addresses. Service Tags represent groups of IP addresses for specific Azure services, such as Storage.EastUS, and update dynamically as the service's IP ranges change.
For centralized management, Security Admin Rules from Azure Virtual Network Manager provide a higher level of control that sits above standard NSG rules. These rules are evaluated before any NSG rules and can be set to "Always Allow" or "Deny" to enforce company-wide policies. This creates a defense-in-depth strategy where central administrators set the baseline security, while individual teams manage application-specific needs through their own NSGs.
Application Security Groups (ASGs) allow you to logically group virtual machines by application workload, enabling application-centric network segmentation. Instead of creating individual NSG rules for each VM or managing lists of IP addresses, you define ASGs that represent roles or tiers—such as web servers, business logic, or databases. This approach simplifies network security policy management and aligns it closely with your application architecture.
You create an ASG using the Azure Portal, PowerShell, or CLI, specifying the resource group and region. After creation, you associate the network interfaces of your VMs with the appropriate ASG. A single network interface can belong to multiple ASGs, allowing flexible grouping based on workload requirements. All network interfaces in an ASG must reside in the same virtual network, ensuring consistent policy enforcement within that boundary.
NSGs act as the enforcement mechanism by filtering inbound and outbound traffic using rules that reference ASGs as the source or destination. For example, you can allow HTTP traffic from the Internet to all VMs in the "asg-web" group, or restrict database access so only VMs in the "asg-logic" group can connect to those in "asg-db". NSG rules are processed in order of priority, and when multiple rules apply, the one with the highest priority (lowest number) takes precedence.
Network Security Groups (NSGs) are essential for controlling inbound and outbound traffic to Azure resources. They act as a basic, stateful, packet-filtering firewall, allowing you to manage access based on IP address and TCP or UDP protocols. NSGs help ensure that only legitimate traffic is allowed to and from your virtual machines and services.
NSGs include several features that simplify management and reduce configuration errors. Augmented security rules simplify rule definitions, allowing complex rules without needing multiple simple rules. Service tags are Microsoft-created labels representing groups of IP addresses that update dynamically, such as Storage.EastUS for all Azure storage in the East US region. Application security groups allow you to group resources and create rules based on these groups, such as allowing traffic to all systems in the "Webservers" application group.
To configure NSG rules, you must understand priority and default rules. NSG rules are evaluated based on their priority, with lower numbers having higher precedence. Each rule specifies a priority, action (allow or deny), direction (inbound or outbound), protocol (TCP, UDP, or any), and source and destination (IP addresses or service tags). You apply NSGs to subnets or network interfaces; when applied to a subnet, the rules affect all resources within that subnet, and when applied to a network interface, the rules only affect the specific resource connected to that interface.
Network Security Groups (NSGs) filter network traffic using security rules that either allow or deny communication. Each rule has a Priority number ranging from 100 to 4096, where lower numbers indicate higher precedence. When traffic enters or leaves a resource, Azure evaluates rules in order and stops processing as soon as it finds a matching rule, meaning a rule with priority 100 always overrides a conflicting rule with priority 200.
The interaction between different NSGs depends on the direction of traffic. For Inbound Traffic, Azure evaluates rules at the subnet level first, then at the Network Interface (NIC) level. For Outbound Traffic, the order reverses: NIC rules are processed before subnet rules. Traffic must be explicitly allowed at both levels to successfully reach its destination or exit the network.
Every NSG includes Default Security Rules that provide basic connectivity, such as allowing internal virtual network traffic and outbound internet access. These default rules have the lowest possible priority to ensure any custom rules you create will take precedence. To simplify management, you can use Augmented Security Rules to group multiple IP addresses and ports into a single rule, Service Tags to represent groups of Azure service IP prefixes, and Application Security Groups (ASGs) to filter traffic based on application structure.
For global governance, Security Admin Rules created in Azure Virtual Network Manager (AVNM) take precedence over standard NSG rules and are evaluated first in the hierarchy. If a security admin rule is set to "Deny" or "Always Allow," Azure terminates further evaluation, meaning local NSG rules will not be checked. This ensures high-level security policies cannot be accidentally bypassed by local administrators.
To understand the cumulative impact of multiple NSGs and admin rules, administrators should examine the Effective Security Rules for a specific NIC, which provides a consolidated list of all rules currently applied to the resource. Additionally, IP Flow Verify within Azure Network Watcher can test if a specific packet is allowed or denied, making it essential for troubleshooting complex reachability issues.
NSGs manage and secure network traffic by containing security rules that control both inbound and outbound communication to and from Azure resources. To create an inbound security rule, navigate to your NSG in the Azure portal and select Inbound security rules, then click + Add to enter the details. Key settings include Source (typically set to Any), Source port ranges (typically * for any), Destination (select IP Addresses), Destination IP addresses/CIDR ranges (specify your virtual network subnet range), Service (select Custom), Destination port ranges (enter 22, 3389 for SSH and RDP access), Protocol (select Any), Action (select Allow), Priority (enter 1000 to ensure the rule is processed before Deny rules), and Name.
After creating the inbound security rule, associate the NSG with the virtual network subnet to apply the traffic rules. This involves selecting Subnets in your NSG, clicking + Associate, choosing your virtual network and subnet, and confirming the association. Outbound security rules control traffic leaving your Azure resources and can be configured to allow or deny traffic based on specific criteria, including Destination (specify target IP addresses or CIDR ranges), Destination port ranges, Protocol (TCP, UDP, or Any), Action (Allow or Deny), and Priority.
NSG diagnostics within Azure Network Watcher helps administrators understand how traffic moves through a virtual network. A key feature is IP flow verify, which checks if a specific packet is allowed or denied based on security and admin rules. By using a 5-tuple approach—source and destination IP, ports, and protocol—it identifies the exact rule responsible for the traffic decision, making it essential for quickly diagnosing connectivity issues.
To properly evaluate the impact of security configurations, administrators must examine effective security rules, which represent the aggregation of all NSG settings applied at both the subnet and network interface levels. Because rules are processed by priority (lowest number first), understanding this combined list is vital for resolving conflicts. Azure provides a clear view of these rules, allowing you to see which custom or default rules are currently active on a running virtual machine.
NSG flow logs provide visibility by recording all IP traffic flowing through an NSG at Layer 4 of the OSI model. These logs capture the traffic decision (allow or deny) and throughput information when using version 2, with data stored in Azure Storage for auditing, compliance, or security analysis. When troubleshooting, remember that NSGs act as a stateful firewall, though some non-default inbound TCP rules may behave in a stateless manner. To ensure accurate logging, enable NSG flow logs on all critical subnets and verify that the Microsoft.Insights resource provider is registered.
For more intuitive understanding of network data, Traffic Analytics visualizes flow logs within a Log Analytics workspace, helping identify security "hot spots" and misconfigurations. However, NSG flow logs are scheduled for retirement in 2027, so Microsoft recommends migrating to virtual network flow logs to overcome current limitations and ensure long-term support for network monitoring.
Azure Bastion is a fully managed platform-as-a-service that provides secure RDP and SSH access to virtual machines directly through the Azure portal. This setup ensures that your target virtual machines do not need public IP addresses, which protects them from internet-based attacks. To begin, you must deploy the service within a virtual network that contains a dedicated subnet named AzureBastionSubnet, which must use a prefix size of at least /26 to ensure there are enough IP addresses to support the host and any future scaling.
Deploying the Bastion host involves a clear sequence of operations to establish a secure boundary. First, you configure the target virtual network with its standard subnets and the specialized Bastion subnet. Next, you must provision a public IP address using the Standard SKU, which the Bastion host uses to receive incoming management traffic on port 443. Finally, you associate the public IP address and the designated subnet when creating the Bastion host resource.
To control traffic moving in and out of the Bastion subnet, you must attach a specialized Network Security Group (NSG). The inbound rules must allow HTTPS traffic over port 443 from the public internet to enable administrator connections. Meanwhile, the outbound rules must permit traffic to reach your target virtual machines on ports 3389 for RDP and 22 for SSH, restricting these outbound rules to the private IP addresses of your target virtual machines to prevent unauthorized network traversal.
When connection errors occur, administrators should use the Connection Troubleshoot tool within Network Watcher. This utility tests the direct TCP connection between the Bastion host and the target virtual machine to pinpoint where the traffic is being blocked. For example, if a user experiences a black screen upon connecting, the root cause is often client-side firewalls blocking WebSockets or a missing NSG rule. Additionally, virtual machines that rely on Just-In-Time (JIT) VM access require specific role assignments so that the Bastion service can successfully request temporary network openings.
Maintaining reliable access requires strict adherence to NSG rule configurations on the Bastion subnet. For inbound traffic, the NSG must allow port 443 from the GatewayManager service tag and ports 8080 and 5701 for internal data plane communication between host instances. For outbound traffic, the NSG must allow communication to the target VMs on ports 3389 and 22, as well as port 443 to the AzureCloud service tag to send diagnostic logs.
To support high-traffic environments, you can scale the Bastion deployment to handle more concurrent sessions. Utilizing the Standard SKU or higher allows you to configure host scaling, which increases the number of instances up to a maximum of 50. A single instance typically supports up to 20 concurrent RDP sessions or 40 SSH sessions. To leverage this capability, the initial subnet must be sized at /26 or larger.
Authentication issues are often caused by using incorrect formatting or unsupported security keys. When connecting to domain-joined Windows virtual machines, users must input their credentials using the User Principal Name format, such as username@domain.com. For Linux connections, the private SSH keys must use RSA, DSA, or OPENSSH formats. Monitoring who is accessing your workloads is critical by enabling BastionAuditLogs, which records every administrative session. For environments with strict compliance regulations, the Premium SKU offers session recording, which captures all graphical activity during RDP and SSH connections and stores it in an Azure storage account.
Azure Bastion operates as a fully managed service that protects your workloads by keeping virtual machines entirely isolated from the public internet. By forcing all management traffic through TLS-encrypted sessions, you eliminate the risk of port scanning on your private servers. To further strengthen this boundary, you can integrate Azure Firewall into your virtual network topology to inspect and filter traffic before it reaches Bastion. The NSG on the Bastion subnet must also allow outbound traffic over port 80 to the internet for certificate validation and session management.
Securing access to the Bastion host itself depends on a combination of Microsoft Entra ID and Azure RBAC. Users who need to connect to target virtual machines must be assigned the Reader role on the virtual machine, the network interface card, the virtual network, and the Bastion resource itself. To enforce the principle of least privilege, you can implement Privileged Identity Management (PIM) to grant these administrative roles on a temporary, just-in-time basis. Additionally, SSH keys should be managed securely within Azure Key Vault with access permissions restricted to simple retrieval operations.
To optimize costs and streamline operations in large environments, you can deploy a single Bastion host in a hub virtual network and connect to virtual machines residing in peered spoke virtual networks. For environments demanding maximum isolation, the Premium SKU supports a private-only deployment that completely eliminates the public IP address, allowing secure connections exclusively through private endpoints. To guarantee high availability, you can deploy Bastion across multiple availability zones.
Continuous monitoring ensures that your remote access methods remain compliant with corporate security policies. You should enable NSG flow logs along with Azure Monitor, Traffic Analytics, and Microsoft Defender for Cloud to detect anomalous traffic patterns and security threats. Session recordings generated by Premium SKU deployments must be stored in secure Azure storage accounts governed by strict retention and access lifecycle policies.
Virtual Network service endpoints provide a secure way for resources in your virtual network to connect directly to Azure platform services. When you enable a service endpoint for a subnet, traffic from that subnet to the supported Azure service flows over the Microsoft Azure backbone network, keeping the traffic off the public internet and enhancing security. A key benefit is that enabling a service endpoint extends your virtual network's identity to the Azure service, allowing you to configure the service to only accept traffic from your specific subnets, effectively removing its public internet exposure.
Service endpoints are widely available for many core Azure services including Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Key Vault, Azure Service Bus, and Azure App Service. While Azure Private Link is recommended for the most private access, service endpoints are a simpler, no-cost option to secure service access at the network level.
When you enable a service endpoint for a subnet, the fundamental routing for traffic to that Azure service changes, shifting from going over the public internet to traveling exclusively over the Azure backbone. A critical operational effect is that the source IP address seen by the Azure service changes from a public IP address to the private IP address of the virtual machine or instance inside your virtual network. This private IP sourcing is what allows you to create virtual network firewall rules on the service itself.
You configure service endpoints at the subnet level, not on individual virtual machines. Once enabled for a subnet, all resources in that subnet can use the endpoint to reach the service. It's important to understand that DNS resolution for the service still returns its public IP address; the routing change happens at the network layer. To control this traffic, you use Network Security Groups (NSGs) on the subnet, and you can simplify NSG rule creation by using Service Tags which represent the IP address groups for entire Azure services.
Service endpoints are enabled by registering specific Resource Providers for your subscription. Major supported services include Azure Storage (via Microsoft.Storage), Azure SQL Database (Microsoft.Sql), Azure Key Vault (Microsoft.KeyVault), and Azure Cosmos DB (Microsoft.AzureCosmosDB). A key benefit is optimal routing, which prevents service traffic from being forced through an on-premises network (forced tunneling), thus improving performance. However, for Azure SQL, the virtual network and the database must be in the same region, and service endpoints do not natively provide private connectivity from on-premises networks without additional firewall configuration.
Azure Service Endpoints and Azure Private Endpoints solve similar problems but in fundamentally different ways. A service endpoint secures access at the service level (e.g., all Azure Storage accounts), routing traffic from your subnet over the Azure backbone but the service retains its public endpoint. A private endpoint, powered by Azure Private Link, provides connectivity at the individual resource level (e.g., one specific storage account), creating a network interface with a private IP address inside your virtual network that maps directly to that single resource instance.
A comparison matrix contrasting Azure Service Endpoints and Private Endpoints across scope, connectivity, on-premises access, data exfiltration protection, and cost.
This difference in scope leads to major security implications. With service endpoints, you can restrict a service to only accept traffic from your virtual networks, but a user or application within your network could still potentially access any instance of that service that you have permissions for, posing a data exfiltration risk. Private endpoints provide built-in protection against this: the private endpoint only connects to the one mapped resource, blocking access to all other resources within the same service.
Their support for different access patterns is another key distinction. Service endpoints only provide private routing for traffic originating within Azure virtual networks and do not support direct private access from on-premises networks. Private endpoints, however, do support private connectivity from on-premises networks when connected via VPN or ExpressRoute private peering. From a management and cost perspective, service endpoints are simple to set up, have no additional cost, and are managed at the subnet level, while private endpoints incur extra charges per endpoint and for processed data, and require more management including DNS configuration.
Private Endpoints provide a way to connect to Azure services using a private IP address from your own virtual network. This process, called Azure Private Link, ensures that traffic stays on the Microsoft backbone and never touches the public internet. By using a private endpoint, you can secure access to specific instances of a service, such as a single database, rather than the entire service, which significantly reduces the attack surface of your cloud resources.
To manage traffic flow, you use Network Security Groups (NSGs) and Application Security Groups (ASGs) to create rules for your endpoints. These tools filter inbound and outbound traffic based on organizational security policies. You must enable network policies on the subnet for these rules to work, and ASGs help you group resources logically without needing complex IP lists. For advanced security, you can send traffic through a Network Virtual Appliance (NVA) or firewall by creating a User-Defined Route (UDR) on the source subnet that points to the private endpoint's IP address, ensuring that all data is inspected for threats before it reaches the target Azure service.
Proper DNS resolution is critical when setting up private endpoints. Because the service still uses its original web address, your network must resolve that address to the new private IP. You achieve this by using Azure Private DNS zones, which automatically manage these records for your virtual network. Compared to service endpoints, private endpoints offer better protection against data exfiltration and allow secure access from on-premises networks using a VPN or ExpressRoute, making them more flexible and secure for complex hybrid cloud environments.
Private endpoint DNS configuration enables secure, private connectivity to Azure PaaS services from within virtual networks. Proper DNS resolution ensures that client requests to a service's fully qualified domain name (FQDN) resolve to the private IP address of the private endpoint rather than the public IP, maintaining network isolation and security. For virtual network workloads without a custom DNS server, Azure-provided DNS (168.63.129.16) is used, which automatically resolves queries for private DNS zones linked to the virtual network.
In peered virtual network scenarios, the same private DNS zone must be linked to all peered virtual networks to ensure consistent resolution. A hub-and-spoke topology is common, where a single private DNS zone in the hub network is shared across all spokes. For on-premises workloads to resolve private endpoints, a DNS forwarder must be deployed within an Azure virtual network linked to the private DNS zone, and the on-premises DNS server must be configured with a conditional forwarder for the Azure private DNS zone.
Azure DNS Private Resolver provides a fully managed solution for hybrid DNS resolution. This service uses inbound endpoints to receive DNS queries from on-premises networks and outbound endpoints with DNS forwarding rulesets to direct queries to appropriate DNS servers. Use the recommended private DNS zone names for each Azure service to ensure automatic record management, and Private DNS zone groups automate the creation and maintenance of DNS records when a private endpoint is updated.
Private Endpoints in Azure allow you to securely connect to Azure PaaS services from within your virtual network, ensuring that traffic between your virtual network and the Azure service remains on the Microsoft Azure backbone network. Azure Private Link provides improved security by securing Azure service resources to your virtual network and removing public internet access, allowing traffic only from the private endpoint within your virtual network. You can access Azure services from on-premises networks over ExpressRoute private peering, VPN tunnels, and peered virtual networks without traversing the internet.
Private Endpoints are network interfaces that connect you privately and securely to a service powered by Azure Private Link, using a private IP address from your virtual network. Service Endpoints provide secure and direct connectivity to Azure services over an optimized route on the Azure backbone network, allowing private IP addresses in the virtual network to reach the endpoint of an Azure service without needing a public IP address. Private endpoints and service endpoints differ in several important ways: private endpoints apply to individual instances of a service, while service endpoints apply to the entire service; private endpoints offer built-in protection against data exfiltration, which service endpoints do not; and private endpoints allow private access from on-premises networks, whereas service endpoints do not.
When implementing private endpoints, disable public network access for the resources you want to secure. Use Network Security Groups to control traffic flow to and from the private endpoints, and use Azure Monitor and other auditing tools to keep track of data flow and ensure compliance with security policies.
Prepare and test your skills
Prepare and test your skills
Azure Service Endpoints secure access at the entire service level by routing traffic over the Azure backbone while retaining a public endpoint, whereas Azure Private Endpoints map a private IP address in your virtual network directly to an individual resource instance. Unlike service endpoints, private endpoints provide built-in protection against data exfiltration and support secure access from on-premises networks via VPN or ExpressRoute. Additionally, service endpoints are available at no extra cost and configured at the subnet level, whereas private endpoints incur charges per endpoint and for processed data.
For inbound traffic, Azure evaluates the subnet-level Network Security Group first and then the network interface (NIC) level, requiring both levels to permit the traffic. For outbound traffic, the evaluation order is reversed, with NIC rules processed before subnet rules. Within each level, rules are processed sequentially based on priority from 100 to 4096, terminating evaluation as soon as a matching rule is found.
Azure Bastion requires a dedicated subnet named AzureBastionSubnet with a prefix size of at least /26 and a public IP address using the Standard SKU. Its associated Network Security Group must permit inbound traffic on port 443 from the internet and the GatewayManager service tag, as well as ports 8080 and 5701 for host communication. Outbound rules must permit connections to target virtual machines on ports 3389 and 22, port 443 to the AzureCloud service tag, and port 80 to the internet for certificate validation.
Security Admin Rules from Azure Virtual Network Manager are evaluated before standard Network Security Group rules in the network evaluation hierarchy. If a security admin rule matches with an action of Always Allow or Deny, Azure terminates further evaluation immediately. This ensures that centralized baseline security policies cannot be bypassed or overridden by local NSG rules.
StudyCerts
StudyCerts