This is a classic OpenShift case because egress controls can be namespace-scoped, so one project can reach the internet while another cannot even though both are on the same cluster. In OpenShift with OVN-Kubernetes, the main things to check are Kubernetes NetworkPolicy egress rules, OpenShift EgressFirewall objects, and sometimes EgressIP if the namespace is supposed to leave the cluster from a specific source IP.
OpenShift documents EgressFirewall as a namespace-level object, and Kubernetes documents that once a pod is selected by an egress policy, only the explicitly allowed outbound traffic is permitted. (Red Hat Documentation)
Scenario
Pods in namespace team-a can reach external sites, but pods in team-b cannot.
Examples:
oc exec -n team-a deploy/app -- curl https://example.com # works
That pattern strongly suggests the problem is policy attached to the namespace, not a cluster-wide outage. OpenShift’s EgressFirewall is evaluated per namespace, and if there is no matching rule then traffic is allowed by default unless something else, like a NetworkPolicy, restricts it. (Red Hat Documentation)
Diagram
Namespace team-a Namespace team-b
+---------------------+ +---------------------+
| pod -> external IP | | pod -> external IP |
+----------+----------+ +----------+----------+
| |
v v
[no blocking policy] [NetworkPolicy and/or
| EgressFirewall applies]
v |
traffic allo v
traffic denied or limited
Where namespace-specific egress can break:
1) Egress NetworkPolicy in that namespace
2) EgressFirewall object in that namespace
3) EgressIP expected for that namespace but misconfigured
4) DNS works, but external traffic is filtered after resolution
How to debug it
1. Prove it is really namespace-specific
Run the same test from a working namespace and a failing one:
If DNS works but outbound HTTP to external IPs fails, that points more toward egress filtering than DNS. This is an inference from Kubernetes DNS and policy behavior together. (Kubernetes)
2. Check NetworkPolicy in the failing namespace
This is the first thing I’d inspect:
oc get networkpolicy -n team-b
oc get networkpolicy -n team-b -o yaml
Kubernetes says that if a pod is selected by a policy with policyTypes: [Egress], the allowed outbound traffic is restricted to what the policy permits. A “default deny all ingress and all egress” policy is a standard pattern. (Kubernetes)
Typical bad case:
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: internal-only
That would allow only a narrow set of destinations and block internet egress.
3. Check for an OpenShift EgressFirewall
OpenShift provides EgressFirewall as a namespace object for controlling traffic from pods to destinations outside the cluster. It is specific to OVN-Kubernetes. (Red Hat Documentation)
Commands:
oc get egressfirewall -n team-b
oc get egressfirewall -n team-b -o yaml
OpenShift documents that traffic to an IP outside the cluster is checked against the namespace’s EgressFirewall rules in order. If a rule matches, that action applies; if no rule matches, traffic is allowed by default. (Red Hat Documentation)
A realistic blocking example is a namespace with rules allowing only a few CIDRs or DNS names and denying everything else.
4. Check whether the namespace is supposed to use EgressIP
If the application depends on a fixed source IP for outbound allowlisting, verify whether EgressIP is configured and healthy. OpenShift documents that an egress IP can be assigned to a namespace and is distinct from an egress router. (Red Hat Documentation)
Check:
oc get egressip
oc describe egressip <name>
If team-b is expected to leave via a specific egress IP and that configuration is broken, outbound access to third-party systems may fail even though generic internet access from other namespaces works. That last part is an inference from how vendor allowlists usually interact with source IP–based egress. (Red Hat Documentation)
5. Verify DNS separately
Sometimes people say “egress is broken” when the real failure is DNS.
nslookup fails, IP curl fails: maybe DNS or broader networking
nslookup works, IP curl fails: likely egress filtering
nslookup fails, IP curl works: DNS-only issue
That distinction follows from Kubernetes DNS behavior plus the documented policy mechanisms above. (Kubernetes)
6. Compare with a working namespace
This is one of the fastest ways to spot the difference:
oc get networkpolicy -n team-a -o yaml
oc get networkpolicy -n team-b -o yaml
oc get egressfirewall -n team-a -o yaml
oc get egressfirewall -n team-b -o yaml
When only one namespace is failing, the delta between those objects often explains it immediately.
7. Check whether the block is by destination type
OpenShift supports EgressFirewall rules for external destinations, and OpenShift also documents audit logging for egress firewall and network policy, which can help when you need proof of what is being denied. (Red Hat Documentation)
Ask:
does external IP fail?
does internal service traffic still work?
does only one external domain fail?
That helps separate “internet blocked” from “specific destinations blocked.”
What this usually turns out to be
Most common causes:
Default deny egress NetworkPolicy in the failing namespace. Kubernetes explicitly documents this pattern. (Kubernetes)
Namespace EgressFirewall allowing only selected external destinations. OpenShift documents EgressFirewall as namespace-scoped and processed rule by rule for external IP traffic. (Red Hat Documentation)
Broken or missing EgressIP where the app depends on outbound source-IP allowlists. OpenShift documents namespace egress IP configuration separately from egress routers. (Red Hat Documentation)
Misdiagnosed DNS problem, where name resolution fails and looks like internet egress failure. (Red Hat Documentation)
Because if it were a true cluster-wide OVN failure, you would usually see the problem across many namespaces, not just one. That last point is an operational inference, but it is a very useful one. (Red Hat Documentation)
When moving from on-premise to a Managed Service like ROSA (Red Hat OpenShift on AWS) or ARO (Azure Red Hat OpenShift), the interview shifts. The technical “heavy lifting” of managing master nodes and etcd is now handled by Red Hat and AWS/Microsoft (the SRE team).
Your role as an administrator moves from “Keeping the lights on” to “Governance, Cost Optimization, and Integration.”
1. The Shared Responsibility Model
This is the #1 question for managed services.
Q: Who is responsible for what in a ROSA/ARO environment?
The Provider (Red Hat/Cloud Provider): Manages the Control Plane (Masters), etcd health, patching of the underlying OS, and the core OpenShift Operators.
The Customer (You): Manages Worker nodes (scaling), Application lifecycle, RBAC, Network Policies, and Quotas.
Interview Tip: Mention that you no longer have cluster-admin in the traditional sense on ARO; you have a customer-admin role. You cannot SSH into master nodes or modify the etcd configuration directly.
2. Day 1: Provisioning & Connectivity
Q1: How does networking differ in ROSA/ARO compared to on-prem?
Answer: In a managed service, OpenShift is integrated into the Cloud’s Virtual Private Cloud (VPC/VNet).
Private vs. Public Clusters: You must decide if the API and Ingress are “Public” (accessible over the internet) or “Private” (only accessible via VPN/DirectConnect/ExpressRoute).
VPC Peering/Transit Gateway: You are responsible for connecting the OpenShift VPC to the rest of your cloud infrastructure (e.g., to reach a managed RDS database or Azure SQL).
Q2: What is the “Assisted Installer” vs. “Cloud CLI”?
Answer: For ROSA, you use the rosa CLI. For ARO, you use the az aro command. These tools abstract the CloudFormation or ARM templates required to spin up the infrastructure.
3. Day 2: Managed Operations
Q3: How do you handle cluster upgrades in ROSA/ARO?
Answer: You don’t just “hit update” and pray.
In ROSA, you can schedule upgrade windows via the OpenShift Cluster Manager (OCM).
The Red Hat SRE team monitors the upgrade. If it fails, they are the ones paged, not you. However, you must ensure your applications have correct Pod Disruption Budgets (PDBs) so the rolling update doesn’t take down your service.
Q4: How do you scale the cluster in the cloud?
Answer: You use MachineAutoscalers.
Unlike on-prem, where you are limited by physical hardware, in ROSA/ARO you define a MachineAutoscaler that monitors the cluster’s resource requests. If a pod can’t be scheduled due to lack of CPU, the autoscaler automatically provisions a new EC2/Azure VM and joins it to the cluster.
4. Cost & Security
Q5: How do you control costs in a managed OpenShift environment?
Answer: Since you pay for every worker node, I implement:
Cluster Autoscaling: Scaling down to minimum nodes at night.
Resource Quotas: Preventing developers from requesting 16GB of RAM for a “Hello World” app.
Spot Instances: Using AWS Spot or Azure Priority instances for non-production workloads to save up to 70% on compute costs.
Q6: How do you handle Authentication?
Answer: You typically don’t use local users. You integrate OpenShift with Azure AD (Entra ID) or AWS IAM/OIDC.
Question: “How do pods access cloud resources (like S3 or Azure Vault)?”
Answer:STS (Security Token Service) or Managed Identities. This allows pods to assume a cloud role without needing to store static “Access Keys” inside a Secret.
5. Summary Comparison: On-Prem vs. Managed
Feature
On-Prem (Bare Metal/VMware)
Managed (ROSA/ARO)
Control Plane
You manage (3 VMs/Servers)
Managed by SRE (Hidden/Bundled)
Updates
Manual / High Risk
Scheduled / Automated
Load Balancer
MetalLB / F5 / HAProxy
AWS NLB/ALB or Azure LB
Storage
ODF / vSphere CSI
EBS/EFS or Azure Disk/Files
Failure Response
You get paged at 3 AM
Red Hat/Cloud SRE handles infra
The “Pro” Managed Question:
“If the cluster is managed by Red Hat, why do they still need an Administrator like you?”
Winning Answer: “Because while Red Hat manages the platform, I manage the consumption. I ensure the networking between our VPCs is secure, I manage the RBAC and onboarding for our developers, I optimize costs so we aren’t over-provisioning cloud resources, and I implement the CI/CD patterns that allow our apps to run reliably on that platform.”
Azure Network Watcher is Azure’s built-in network monitoring and diagnostics service for IaaS resources. It helps you monitor, troubleshoot, and visualize networking for things like VMs, VNets, load balancers, application gateways, and traffic paths in Azure. It is not meant for PaaS monitoring or web/mobile analytics. (Microsoft Learn)
For interviews, the clean way to explain it is:
“Network Watcher is the tool I use when I need to see how traffic is flowing in Azure, why connectivity is failing, or what route/security rule is affecting a VM. It gives me diagnostics like topology, next hop, IP flow verify, connection troubleshooting, packet capture, and flow logs.” (Microsoft Learn)
The most important features to remember are:
Topology: visual map of network resources and relationships. (Microsoft Learn)
IP flow verify: checks whether a packet to/from a VM would be allowed or denied by NSG rules. (Microsoft Learn)
Next hop: tells you where traffic to a destination IP will go, such as Internet, Virtual Appliance, VNet peering, gateway, or None. Very useful for UDR and routing issues. (Microsoft Learn)
Connection troubleshoot / Connection Monitor: tests reachability and latency between endpoints and shows path health over time. (Microsoft Learn)
Packet capture: captures packets on a VM or VM scale set for deep troubleshooting. (Microsoft Learn)
Flow logs / traffic analytics: records IP traffic flow data and helps analyze traffic patterns. (Microsoft Learn)
A strong interview answer for when to use it:
“I use Network Watcher when a VM cannot reach a private endpoint, an app cannot talk to another subnet, routing seems wrong, NSGs may be blocking traffic, or I need packet-level proof. I usually check NSG/IP Flow Verify first, then Next Hop, then Connection Troubleshoot, and if needed packet capture and flow logs.” That workflow maps directly to the capabilities Microsoft documents. (Microsoft Learn)
A simple example: If a VM cannot reach a private endpoint, I would check:
DNS resolution for the private endpoint name.
IP flow verify for NSG allow/deny.
Next hop to confirm the route is correct.
Connection troubleshoot / Connection Monitor for end-to-end reachability and latency.
Packet capture if I need proof of SYN drops, resets, or missing responses. (Microsoft Learn)
One interview caution: Network Watcher is mainly for Azure IaaS network diagnosis, not your general observability platform for app performance. Azure Monitor is broader, and Network Watcher plugs into that platform for network health and diagnostics. (Microsoft Learn)
Here are clean, interview-ready answers you can memorize and adapt depending on how deep the interviewer goes 👇
30-Second Answer
“Azure Network Watcher is a network diagnostics and monitoring service for Azure IaaS. I use it to troubleshoot connectivity issues between resources like VMs, VNets, and private endpoints. Key tools I rely on are IP Flow Verify to check NSG rules, Next Hop for routing issues, and Connection Troubleshoot for end-to-end connectivity. If needed, I go deeper with packet capture and flow logs.”
1–2 Minute Answer (More Detailed, Still Smooth)
“Azure Network Watcher is a native Azure service that helps monitor, diagnose, and troubleshoot network issues in IaaS environments. It’s especially useful when dealing with VMs, VNets, NSGs, and routing.
For example, if a VM cannot connect to another resource, I follow a structured approach:
First, I use IP Flow Verify to confirm whether NSG rules are allowing or denying traffic
Then I check Next Hop to validate routing and identify if traffic is going to a firewall, gateway, or nowhere
I use Connection Troubleshoot or Connection Monitor to test actual connectivity and latency
If the issue is still unclear, I use packet capture to inspect traffic at the packet level
And for ongoing visibility, I enable NSG flow logs and traffic analytics
So overall, Network Watcher gives me both real-time troubleshooting and historical visibility into network traffic and behavior.”
Scenario Answer
Scenario: VM cannot connect to a Private Endpoint
“If a VM cannot connect to a private endpoint, I’d troubleshoot using Network Watcher step-by-step:
DNS first – confirm the private endpoint resolves to a private IP
Use IP Flow Verify to check if NSG rules allow traffic
Use Next Hop to confirm routing isn’t misconfigured (like a bad UDR sending traffic to a firewall)
Run Connection Troubleshoot to validate end-to-end connectivity
If needed, run packet capture to see if packets are dropped or not returning
This structured approach helps isolate whether the issue is DNS, NSG, routing, or the application itself.”
Bonus: One-Liner
“Network Watcher is my go-to tool for debugging Azure networking — it helps me validate NSGs, routing, and connectivity quickly.”
This is one of those topics where interviewers are testing if you truly understand Azure networking flow, not just definitions. Let’s make this practical and interview-ready.
Private Endpoint vs Service Endpoint
Private Endpoint (Private Link)
Assigns a private IP inside your VNet
Traffic stays entirely on Microsoft backbone
Uses Private DNS
Most secure (no public exposure)
Service Endpoint
Extends your VNet identity to Azure services
Still uses the public endpoint
Secured by VNet-based access rules
No private IP assigned to the service
Key Differences
Feature
Private Endpoint
Service Endpoint
IP Address
Private IP in VNet
Public IP
Traffic Path
Fully private
Public endpoint (Azure backbone)
DNS Required
✅ Yes (critical)
❌ No
Security Level
Highest
Medium
Data Exfiltration Protection
Strong
Limited
Troubleshooting Approach (THIS is what matters)
Scenario 1: Private Endpoint NOT Working
This is where most candidates fail — DNS is the #1 issue.
Step-by-step:
1. DNS Resolution (MOST IMPORTANT)
Does the FQDN resolve to a private IP?
If not → DNS misconfiguration
Common issue:
Missing Private DNS Zone (e.g., privatelink.blob.core.windows.net)
VNet not linked to DNS zone
2. NSG Check
Use Network Watcher IP Flow Verify
Ensure traffic is allowed
3. Routing (UDR / Firewall)
Use Next Hop
Check if traffic is being forced through a firewall incorrectly
4. Private Endpoint State
Approved?
Connected?
5. Connection Troubleshoot
Validate actual reachability
Scenario 2: Service Endpoint NOT Working
Easier than Private Endpoint, but different failure points.
Step-by-step:
1. Subnet Configuration
Is Service Endpoint enabled on the subnet?
2. Resource Firewall
Example: Storage Account → “Selected networks”
Is your subnet allowed?
3. NSG Rules
Still applies → allow outbound
4. Route Table
If forced tunneling is enabled → traffic may NOT reach Azure service properly
5. Public Endpoint Access
Ensure the service allows public endpoint traffic (since Service Endpoint uses it)
Side-by-Side Troubleshooting Mindset
Problem Area
Private Endpoint
Service Endpoint
DNS
🔴 Critical
🟢 Not needed
Subnet config
🟡 Minimal
🔴 Must enable endpoint
Firewall rules (resource)
🟢 Private access
🔴 Must allow subnet
Routing issues
🔴 Common
🟡 Sometimes
Complexity
High
Medium
Interview Scenario Answer (Perfect Response)
“If a connection to an Azure service fails, I first determine whether it’s using Private Endpoint or Service Endpoint because the troubleshooting path differs.
For Private Endpoint, I start with DNS — ensuring the service resolves to a private IP via Private DNS. Then I check NSGs, routing using Next Hop, and validate connectivity using Network Watcher tools.
For Service Endpoint, I verify the subnet has the endpoint enabled, ensure the Azure resource firewall allows that subnet, and confirm routing isn’t forcing traffic through a path that breaks connectivity.
The key difference is that Private Endpoint issues are usually DNS-related, while Service Endpoint issues are typically configuration or access control related.”
Pro Tip
Say this line:
“Private Endpoint failures are usually DNS problems. Service Endpoint failures are usually access configuration problems.”
Here’s a clean mental model + diagram . This ties together DNS → Routing → NSG → Destination in the exact order Azure evaluates traffic.
The Core Flow
That’s your anchor. Every troubleshooting answer should follow this flow.
Visual Memorization Diagram
End-to-End Flow (Private Endpoint example)
Step-by-Step Mental Model
1. DNS (FIRST — always)
Question: “Where is this name resolving to?”
Private Endpoint → should resolve to private IP
Service Endpoint → resolves to public IP
If DNS is wrong → NOTHING else matters
2. Routing (Next Hop)
Question: “Where is the traffic going?”
Internet?
Virtual Appliance (Firewall)?
VNet Peering?
None (blackhole)?
Use:
Network Watcher → Next Hop
If routing is wrong → traffic never reaches destination
3. NSG (Security Filtering)
Question: “Is traffic allowed or denied?”
Check:
Source IP
Destination IP
Port
Protocol
Use:
Network Watcher → IP Flow Verify
If denied → traffic is dropped
4. Destination (Final Check)
Question: “Is the service itself allowing traffic?”
Private Endpoint → connection approved?
Service Endpoint → firewall allows subnet?
App listening on port?
The Interview Cheat Code
“When debugging Azure networking, I always follow a layered approach: first DNS resolution, then routing using Next Hop, then NSG validation with IP Flow Verify, and finally I check the destination service configuration.”
Example Walkthrough
VM cannot reach Storage Account (Private Endpoint)
You say:
DNS – does it resolve to private IP?
Routing – is traffic going to correct subnet or firewall?
NSG – is port 443 allowed outbound?
Destination – is private endpoint approved?
Ultra-Simple Memory Trick
Think of it like a package delivery 📦:
DNS = Address lookup (where am I going?)
Routing = Road path (how do I get there?)
NSG = Security gate (am I allowed through?)
Destination = Door (is it open?)
Bonus
“Azure evaluates routing before NSG for outbound traffic decisions, so even if NSG allows traffic, incorrect routing can still break connectivity.”
For a brand-new microservices project in 2026, security isn’t just a “layer” you add at the end—it’s baked into the infrastructure. AKS has introduced several “secure-by-default” features that simplify this.
Here are the essential security best practices for your new setup:
1. Identity over Secrets (Zero Trust)
In 2026, storing connection strings or client secrets in Kubernetes “Secrets” is considered an anti-pattern.
Best Practice: Use Microsoft Entra Workload ID.
Why: Instead of your app having a password to access a database, your Pod is assigned a “Managed Identity.” Azure confirms the Pod’s identity via a signed token, granting it access without any static secrets that could be leaked.
New in 2026: Enable Conditional Access for Workload Identities to ensure a microservice can only connect to your database if it’s running inside your specific VNet.
2. Harden the Host (Azure Linux 3.0)
The operating system running your nodes is part of your attack surface.
Best Practice: Standardize on Azure Linux 3.0 (CBL-Mariner).
Why: It is a “distroless-adjacent” host OS. It contains ~500 packages compared to the thousands in Ubuntu, drastically reducing the number of vulnerabilities (CVEs) you have to patch.
Advanced Isolation: For sensitive services (like payment processing), enable Pod Sandboxing. This uses Kata Containers to run the service in a dedicated hardware-isolated micro-VM, preventing “container breakout” attacks where a hacker could jump from your app to the node.
3. Network “Blast Radius” Control
If one microservice is compromised, you don’t want the attacker to move laterally through your entire cluster.
Best Practice: Use Cilium for Network Policy.
Why: As of 2026, Cilium is the gold standard for AKS networking. It uses eBPF technology to filter traffic at the kernel level.
Strategy: Implement a Default Deny policy. By default, no service should be able to talk to any other service unless you explicitly write a rule allowing it.
4. API Server Protection
The Kubernetes API server is the “front door” to your cluster. If someone gets in here, they own everything.
Best Practice: Use API Server VNet Integration (Private Clusters).
Why: This ensures your cluster’s management endpoint is not reachable from the public internet. It exists only inside your private network.
Access Control: Use Microsoft Entra RBAC (Role-Based Access Control). Never use the “cluster-admin” local account. Link permissions to your team’s Entra ID groups so that when an employee leaves the company, their cluster access is revoked instantly.
5. Continuous Supply Chain Security
Security starts before the code even reaches AKS.
Best Practice: Enable Defender for Cloud and Binary Authorization.
Why: Defender for Cloud scans your images in the Azure Container Registry (ACR) for malware and secrets.
Enforcement: Use Azure Policy for Kubernetes to block any deployment that hasn’t been scanned or isn’t coming from your trusted registry.
Summary Security Checklist
Area
2026 Standard
Identity
Microsoft Entra Workload ID (No Secrets)
OS
Azure Linux 3.0 with OS Guard
Network
Cilium with mTLS (Service Mesh)
Access
Private Cluster + Entra RBAC
Governance
Azure Policy “Restricted” Baseline
Pro-Tip: Check your Secure Score in Microsoft Defender for Cloud weekly. It will give you a prioritized list of “quick fixes” for your specific AKS cluster based on real-time threats.
With a Service Mesh (specifically the Istio-based add-on for AKS), you are moving toward a “Zero Trust” network architecture. In this setup, the network is no longer trusted by default; every connection must be verified and encrypted.
Here is the 2026 security blueprint for running microservices with Istio on AKS.
1. Automated mTLS (Encryption in Transit)
By default, traffic between Kubernetes Pods is unencrypted. With Istio, you can enforce Strict Mutual TLS (mTLS) without changing a single line of application code.
The Best Practice: Apply a PeerAuthentication policy at the namespace level set to STRICT.
The Result: Any service that tries to connect via plain text will be instantly rejected by the sidecar proxy. This ensures that even if an attacker gains access to your internal network, they cannot “sniff” sensitive data (like headers or tokens) passing between services.
2. Identity-Based Authorization
IP addresses are ephemeral in Kubernetes and shouldn’t be used for security. Istio uses SPIFFE identities based on the service’s Kubernetes Service Account.
The Best Practice: Use AuthorizationPolicy to define “Who can talk to Whom.”
Example: You can create a rule that says the Email Service can only receive requests from the Orders Service, and only if the request is a POST to the /send-receipt endpoint. Everything else is blocked at the source.
3. Secure the “Front Door” (Ingress Gateway)
In 2026, the Kubernetes Gateway API has reached full GA (General Availability) for the AKS Istio add-on.
The Best Practice: Use the Gateway and HTTPRoute resources instead of the older Ingress objects.
Security Benefit: It allows for better separation of concerns. Your platform team can manage the physical load balancer (the Gateway), while your developers manage the routing rules (HTTPRoute) for their specific microservices.
4. Dapr + Istio: The “Power Couple”
Since you are building microservices, you might also use Dapr for state and messaging. In 2026, these two work together seamlessly but require one key configuration:
The Best Practice: If both are present, let Istio handle the mTLS and Observability, and disable mTLS in Dapr.
Why: Having two layers of encryption (“double wrapping” packets) adds significant latency and makes debugging network issues a nightmare.
5. Visualizing the “Blast Radius”
The biggest security risk in microservices is lateral movement.
The Best Practice: Use the Kiali dashboard (integrated with AKS) to view your service graph in real-time.
The Security Win: If you see a weird line of communication between your Public Web Frontend and your Internal Payment Database that shouldn’t exist, you’ve found a security hole or a misconfiguration before it becomes a breach.
Summary Security Checklist for Istio on AKS
Task
2026 Recommended Tool
Transport Security
PeerAuthentication (mode: STRICT)
Service Permissions
Istio AuthorizationPolicy
External Traffic
Kubernetes Gateway API (Managed Istio Ingress)
Egress (Outgoing)
Service Entry (Block all traffic to external sites except specific approved domains)
Auditing
Azure Monitor for Containers + Istio Access Logs
Warning for 2026: Ensure your worker nodes have enough “headroom.” Istio sidecars (Envoy proxies) consume roughly 0.5 to 1.0 vCPU and several hundred MBs of RAM per Pod. For a project with many small microservices, this “sidecar tax” can add up quickly.
At its core, Azure Kubernetes Service (AKS) is Microsoft’s managed version of Kubernetes. It’s designed to take the “scary” parts of managing a container orchestration system—like setting up the brain of the cluster, patching servers, and handling scaling— and offload them to Azure so you can focus on your code.
Think of it as Kubernetes with a personal assistant.
1. How it Works (The Architecture)
AKS splits a cluster into two distinct parts:
The Control Plane (Managed by Azure): This is the “brain.” It manages the API server, the scheduler, and the cluster’s state. In AKS, Microsoft manages this for you for free (or for a small fee if you want a guaranteed Uptime SLA). You don’t have to worry about its health or security patching.
The Data Plane (Managed by You): These are the “worker nodes” (Virtual Machines) where your applications actually run. While you pay for these VMs, AKS makes it easy to add, remove, or update them with a single click or command.
2. Key Features (2026 Standards)
As of 2026, AKS has evolved into an “AI-ready” platform. Here are the standout features:
AKS Automatic: A newer “Zero-Ops” tier where Azure handles almost everything—node configuration, security hardening, and even choosing the right VM sizes based on your app’s needs.
Smart Scaling: It uses the Horizontal Pod Autoscaler (HPA) and Cluster Autoscaler to grow or shrink your infrastructure based on real-time traffic, saving you money during quiet hours.
AI & GPU Support: Native integration with the latest NVIDIA GPUs (like the NCv6 series) makes it a go-to for training LLMs or running AI inference.
Enterprise Security: It integrates directly with Microsoft Entra ID (formerly Azure AD), so you can control who accesses your cluster using the same identity they use for email.
3. Why Use It?
Benefit
What it means for you
Reduced Overhead
You don’t have to be a Kubernetes expert to keep the cluster running.
Cost Efficiency
You only pay for the worker nodes you use. Features like Spot VMs can cut costs by up to 80% for non-critical tasks.
Fast Updates
Upgrading to a new Kubernetes version is a “push-button” experience rather than a manual nightmare.
Deep Integration
It plays perfectly with Azure Monitor, Azure Storage, and GitHub Actions for a smooth “code-to-cloud” pipeline.
4. Common Use Cases
Microservices: Breaking down a giant app into smaller, independent pieces.
AI/ML Workflows: Running data-heavy training jobs and deploying models.
DevOps Pipelines: Using containers to ensure that “it works on my machine” also means “it works in production.”
Pro Tip: If you’re just starting out in 2026, look into Azure Linux 3.0 as your node operating system. It’s a lightweight, secure OS built by Microsoft specifically for AKS that boots faster and has a smaller attack surface than traditional Linux distros.
Starting a brand-new project in 2026 is an exciting time for AKS because the platform has moved from “manual infrastructure” to “intelligent automation.”
Here is the recommended blueprint for launching a fresh project today.
1. The Big Choice: Automatic vs. Standard
The first decision you’ll face in the Azure Portal is which “tier” to use.
Feature
AKS Automatic (Recommended)
AKS Standard
Philosophy
“Just run my code.”
“Give me all the knobs.”
Management
Azure manages nodes, scaling, and security.
You manage node pools and VM sizes.
Best For
New startups, rapid dev, and “Zero-Ops” teams.
Large enterprises with strict custom networking.
Security
Hardened by default (Azure Policy, Cilium).
Configurable (you must set the guardrails).
Advice: For a brand-new project, start with AKS Automatic. It enforces modern best practices (like the Cilium network data plane) out of the box, saving you from “Day 2” configuration headaches.
Automatic Kubernetes Cluster manages these elements for you:
Networking and Security Azure CNI Overlay powered by Azure Cilium
Resource provisioning Automated node provisioning and scaling
On-demand scaling Optimal scaling tools like KEDA, HPA, and VPA
Kubernetes version upgrade Automatic updates for enhanced stability
2. Setting Up Your Foundation (The 2026 Stack)
When configuring your new cluster, stick to these current standards:
The OS: Choose Azure Linux 3.0. It’s Microsoft’s own cloud-optimized distro. It’s faster and more secure than Ubuntu because it contains only the bare essentials needed to run containers.
Networking: Use Azure CNI Overlay. It allows you to scale to thousands of Pods without burning through your private IP address space—a common pitfall in older projects.
Identity: Enable Microsoft Entra Workload ID. Never use “Service Principals” or hardcoded secrets to let your app talk to a database. Workload ID gives your Pod its own managed identity.
3. Integrating AI (KAITO)
If your new project involves AI (and most do in 2026), you’ll want to enable the Kubernetes AI Toolchain Operator (KAITO).
What it does: It simplifies running Large Language Models (LLMs) like Phi-4 or Falcon on your cluster.
Why use it: Instead of manually figuring out which GPU driver matches which model, KAITO automates the provisioning of GPU nodes and sets up the inference endpoint for you.
4. Cost Control for New Projects
Don’t let a “Hello World” app cost you hundreds.
Use the “Dev/Test” Preset: This scales down redundancy to save money while you’re still building.
Spot Instances: For background tasks or non-critical processing, use Spot node pools to get up to 80-90% off standard VM pricing.
Vertical Pod Autoscaler (VPA): In 2026, the VPA is much smarter. It can watch your app and suggest (or automatically apply) the exact amount of CPU and RAM needed, so you aren’t paying for “idle” capacity.
5. Your First Steps
To get moving, I recommend the following workflow:
Install the Azure CLI (ensure it’s version 2.82+ for 2026 features).
Create an ACR (Azure Container Registry): This is where you’ll store your app images.
Deploy via “Automated Deployments”: Use the “Automated Deployments” tab in the AKS portal. You point it at your GitHub repo, and it will generate the GitHub Actions and Kubernetes YAML files for you.
Building a microservices architecture on AKS is a “textbook” use case, but in 2026, the strategy has shifted from just “managing containers” to “managing a distributed system.”
Since each service in your project will have its own lifecycle, database, and scaling needs, here is how you should structure your new AKS environment.
1. The Connectivity Layer: Service Mesh
In a microservices setup, the network becomes your biggest challenge. You shouldn’t have your services talking to each other using hardcoded internal URLs.
The 2026 Choice:Istio-based Service Mesh add-on for AKS.
Why: It provides “Mutual TLS” (mTLS) by default, meaning all communication between your microservices is encrypted automatically. It also gives you a “Service Graph,” allowing you to visualize exactly how traffic flows from Service A to Service B.
2. Global Traffic Routing (Ingress)
You need a “front door” to route external users to the correct microservice (e.g., api.myapp.com/orders goes to the Order Service).
Application Gateway for Containers (ALB): This is the modern evolution of the standard Ingress Controller. It’s a managed service that sits outside your cluster, handling SSL termination and Web Application Firewall (WAF) duties so your worker nodes don’t have to waste CPU on security overhead.
3. Data Persistence & State
The golden rule of microservices is one database per service.
Don’t run DBs inside AKS: While you can run SQL or MongoDB as a container, it’s a headache to manage.
The 2026 Way: Use Azure Cosmos DB or Azure SQL and connect them to your microservices using Service Connector. Service Connector handles the networking and authentication (via Workload ID) automatically, so your code doesn’t need to store connection strings or passwords.
4. Microservices Design Pattern (Dapr)
For a brand-new project, I highly recommend using Dapr (Distributed Application Runtime), which is an integrated extension in AKS.
Dapr provides “building blocks” as sidecars to your code:
Pub/Sub: Easily send messages between services (e.g., the “Order” service tells the “Email” service to send a receipt).
State Management: A simple API to save data without writing complex database drivers.
Resiliency: Automatically handles retries if one microservice is temporarily down.
5. Observability (The “Where is the Bug?” Problem)
With 10+ microservices, finding an error is like finding a needle in a haystack. You need a unified view.
Managed Prometheus & Grafana: AKS has a “one-click” onboarding for these. Prometheus collects metrics (CPU/RAM/Request counts), and Grafana gives you the dashboard.
Application Insights: Use this for “Distributed Tracing.” It allows you to follow a single user’s request as it travels through five different microservices, showing you exactly where it slowed down or failed.
Summary Checklist for Your New Project
Cluster: Create an AKS Automatic cluster with the Azure Linux 3.0 OS.
Identity: Use Workload ID instead of secrets.
Communication: Enable the Istio add-on and Dapr extension.
Database: Use Cosmos DB for high-scale microservices.
CI/CD: Use GitHub Actions with the “Draft” tool to generate your Dockerfiles and manifests automatically.
Azure Storage is a highly durable, scalable, and secure cloud storage solution. In 2026, it has evolved significantly into an AI-ready foundational layer, optimized not just for simple files, but for the massive datasets required for training AI models and serving AI agents.
The platform is divided into several specialized “data services” depending on the type of data you are storing.
1. The Core Data Services
Service
Data Type
Best For
Blob Storage
Unstructured (Objects)
Images, videos, backups, and AI training data lakes.
Azure Files
File Shares (SMB/NFS)
Replacing on-premise file servers; “Lift and Shift” for legacy apps.
Azure Disks
Block Storage
Persistent storage for Virtual Machines (OS and data disks).
Azure Tables
NoSQL Key-Value
Large scale, schema-less structured data (e.g., user profiles).
Azure Queues
Messaging
Reliable messaging between different parts of an application.
2. Modern Tiers (Cost vs. Speed)
You don’t pay the same price for data you use every second versus data you keep for 10 years. You choose an Access Tier to optimize your bill:
Premium: SSD-backed. Ultra-low latency for high-performance apps and AI inference.
Hot: For data you access frequently. Lower access cost, higher storage cost.
Cool (30 days): For data like short-term backups. Lower storage cost, higher access cost.
Cold (90 days): New in the 2020s—optimized for “infrequent” but immediate access.
Archive (180 days): Lowest cost, but data is “offline.” Rehydrating it takes hours.
3. Redundancy: Protecting Your Data
Azure keeps multiple copies of your data to protect against hardware failure or entire data center disasters.
LRS (Locally Redundant): 3 copies in a single data center. Protects against disk failure.
ZRS (Zone-Redundant): 3 copies across 3 different data centers in one region. Protects against a data center fire/outage.
GRS (Geo-Redundant): Copies data to a secondary region hundreds of miles away. Protects against a major regional disaster.
What’s New in 2026?
Agentic Scale: Blob storage can now handle millions of small objects per second to support AI Agents that need to “remember” long-term context or retrieve data from RAG (Retrieval-Augmented Generation) stores.
Elastic SAN: A fully managed Storage Area Network (SAN) service that lets you pool block storage for different workloads, making it easier to migrate heavy SQL or Oracle databases to the cloud.
AI Integration: Native “hooks” for frameworks like LangChain and Microsoft Foundry, allowing AI models to read directly from your storage with minimal setup.
Choosing the right storage in 2026 depends on two main factors: the structure of your data and how your application (or AI agent) needs to access it.
Here is the 2026 decision framework to help you choose the right tool for the job.
The “Quick Decision” Tree
If your project needs to…
The Winner is…
Store millions of files for AI training or Data Lakes.
Blob Storage (Data Lake Gen2)
Replace an on-premise file server (SMB/NFS).
Azure Files
Provide high-speed block storage for Virtual Machines.
Managed Disks
Pool storage across many VMs/Containers like a Cloud SAN.
Elastic SAN
Send messages between different microservices.
Queue Storage
Store simple Key-Value data (User profiles, logs).
Table Storage
1. Blob Storage: The AI & Big Data King
In 2026, Blob storage is no longer just for “backups.” It is the central engine for Agentic Scale—supporting AI agents that need to read massive amounts of context quickly.
Best For: Unstructured data (PDFs, Images, Parquet files).
Key Feature:Data Lake Storage Gen2. This adds a “Hierarchical Namespace” (real folders) to your blobs, which makes big data analytics and AI processing 10x faster.
2026 Strategy: Use Cold Tier for data you only touch once a quarter but need available instantly for AI “Reasoning” tasks.
2. Azure Files: The “Lift-and-Shift” Hero
If you have an existing application that expects a “Drive Letter” (like Z:\), use Azure Files.
Best For: Shared folders across multiple VMs or local office computers.
New in 2026:Elastic ZRS (Zone Redundant Storage). This provides ultra-high availability for mission-critical file shares without the complexity of managing your own cluster.
Performance: Use Premium Files if you are running active databases or high-transaction apps; use Standard for simple office document sharing.
3. Managed Disks vs. Elastic SAN
This is the “local” vs “network” storage debate for your servers.
Managed Disks (The Individual): Use Premium SSD v2. It’s the modern standard because it allows you to scale IOPS and Throughput separately, so you don’t have to buy a “huge disk” just to get “high speed.”
Elastic SAN (The Pool): If you are migrating a massive environment from an on-premise SAN (like Dell EMC or NetApp), Elastic SAN lets you buy one large “pool” of performance and share it across all your VMs and Kubernetes clusters.
4. Specialized: Tables & Queues
These are “developer” storage types.
Azure Tables: Use this if Cosmos DB is too expensive for your needs. It’s a “no-frills” NoSQL database for billions of small, structured rows.
Azure Queues: Use this to decouple your app. If a user uploads a photo, put a message in the Queue. A “Worker” then sees that message and processes the photo. This prevents your app from crashing under heavy load.
Pro-Tip for 2026: The “Cost First” Choice
If you are still unsure, start with Blob Storage. It is the most flexible, has the best API support for modern AI frameworks (like LangChain), and offers the most aggressive cost-saving tiers (Cool, Cold, and Archive).
What is the “main action” your application will take? (e.g., “Scanning documents for AI,” “Hosting a website,” or “Running a heavy SQL database?”) I can give you the specific configuration for that.
Cost optimization in Azure is no longer just about “turning things off.” In 2026, it is a continuous lifecycle known as FinOps, focusing on three distinct phases: Inform (Visibility), Optimize (Rightsizing & Rates), and Operate (Governance).
Here is the strategic blueprint for optimizing your Azure spend today.
1. Inform: Get Full Visibility
You cannot optimize what you cannot see.
Tagging Enforcement: Use Azure Policy to require tags like Environment, Owner, and CostCenter. This allows you to group costs by department or project in Azure Cost Management.
Budget Alerts: Set thresholds at 50%, 80%, and 100% of your predicted monthly spend.
Azure Advisor Score: Check your “Cost Score” in Azure Advisor. It provides a “to-do list” of unused resources, such as unattached Managed Disks or idle ExpressRoute circuits.
2. Optimize: The Two-Pronged Approach
Optimization is divided into Usage (buying less) and Rate (paying less for what you use).
A. Usage Optimization (Rightsizing)
Shut Down Idle Resources: Azure Advisor flags VMs with <3% CPU usage. For Dev/Test environments, use Auto-shutdown or Azure Automation to turn VMs off at 7:00 PM and on at 7:00 AM.
Storage Tiering: Move data that hasn’t been touched in 30 days to the Cool tier, and data older than 180 days to the Archive tier. This can save up to 90% on storage costs.
B-Series VMs: For workloads with low average CPU but occasional spikes (like small web servers), use the B-Series (Burstable) instances to save significantly.
B. Rate Optimization (Commitment Discounts)
In 2026, you choose your discount based on how much flexibility you need.
Discount Type
Savings
Best For…
Reserved Instances (RI)
Up to 72%
Static workloads. You commit to a specific VM type in a specific region for 1 or 3 years.
Savings Plan for Compute
Up to 65%
Dynamic workloads. A flexible $ /hour commitment that applies across VM families and regions.
Azure Hybrid Benefit
Up to 85%
Using your existing Windows/SQL licenses in the cloud so you don’t pay for them twice.
Spot Instances
Up to 90%
Interruptible workloads like batch processing or AI model training.
3. Operate: Modern 2026 Strategies
AI Cost Governance: With the rise of Generative AI, monitor your Azure OpenAI and AI Agent token usage. Use Rate Limiting on your APIs to prevent a runaway AI bot from draining your budget in a single night.
FinOps Automation: Use Azure Resource Graph to find “orphaned” resources (like Public IPs not attached to anything) and delete them automatically via Logic Apps.
Sustainability & Carbon Optimization: Use the Azure Carbon Optimization tool. Often, the most “green” resource (lowest carbon footprint) is also the most cost-efficient one.
The “Quick Wins” Checklist
[ ] Delete Unattached Disks: When you delete a VM, the disk often stays behind and keeps billing you.
[ ] Switch to Savings Plans: If your RIs are expiring, move to a Savings Plan for easier management.
[ ] Check for “Zombies”: Idle Load Balancers, VPN Gateways, and App Service Plans with zero apps.
[ ] Rightsize your SQL: Switch from “DTU” to the vCore model for more granular scaling and Hybrid Benefit savings.
Pro Tip: Never buy a Reserved Instance (RI) for a server that hasn’t been rightsized first. If you buy a 3-year reservation for an oversized 16-core VM, you are “locking in” waste for 36 months!
To find the “low-hanging fruit” in your Azure environment, you can use Azure Resource Graph Explorer and Log Analytics.
Here are the specific KQL (Kusto Query Language) scripts to identify common waste areas.
1. Identify Orphaned Resources (Quickest Savings)
These resources are costing you money every hour but aren’t attached to anything. Run these in the Azure Resource Graph Explorer.
Instead of running these manually, use Azure Workbooks.
Search for “Workbooks” in the Azure Portal.
Click Add > New.
Add a “Query” cell and paste any of the KQL scripts above.
Save the Workbook as “Monthly Cost Cleanup.”
Now, you can open this dashboard once a month and see exactly what needs to be deleted!
Setting up an automated alert for “Unattached Disks” is a brilliant move for cost governance. In Azure, this is handled by monitoring the Activity Log for a specific event: the “Delete Virtual Machine” action (which leaves the disk behind) or the “Detach Disk” action.
Here is the 2026 step-by-step guide to setting this up.
Step 1: Create an Action Group (The “Who” to notify)
Before you create the alert, you need to tell Azure how to contact you.
Enter your email address and name the notification EmailDevOps.
Click Review + create.
Step 2: Create the Activity Log Alert (The “When”)
Now, we create the trigger that watches for disks being left alone.
In Monitor, click Alerts > + Create > Alert rule.
Scope: Select your Subscription.
Condition: This is the most important part. Click + Add condition and search for:
Signal Name:Detach Disk (Microsoft.Compute/disks)
Alternative: You can also alert on Delete Virtual Machine, but “Detach Disk” is more accurate for catching orphaned resources.
Refine the Logic: Under “Event initiated by,” you can leave it as “Any” or specify a specific automation service principal if you only want to catch manual detaches.
Step 3: Connect and Save
Actions: Click Select action groups and choose the CostAlertTeam group you created in Step 1.
Details: Name the rule Alert-Disk-Unattached.
Severity: Set it to Informational (Sev 4) or Warning (Sev 3).
Click Review + create.
The “Pro” Way (2026 Strategy): Use Log Analytics
The method above tells you when a disk is detached, but it won’t tell you about disks that are already unattached. To catch those, use a Log Search Alert with a KQL query.
The KQL Query:
Code snippet
// Run this every 24 hours to find any disk with a "ManagedBy" state of NULL
| where managedBy == "" and diskState == "Unattached"
| project name, resourceGroup, subscriptionId
Why this is better:
Activity Log Alerts are “reactive” (they fire only at the moment of the event).
Log Search Alerts are “proactive” (they scan your environment every morning and email you a list of every unattached disk, even if it was detached months ago).
Summary of the Workflow
Detach/Delete Event happens in the VNet.
Activity Log captures the event.
Azure Monitor sees the event matches your rule.
Action Group sends you an email immediately.
While an immediate alert is great for a “fire-drill” response, a Weekly Summary Report is the gold standard for long-term cost governance. It keeps your inbox clean and ensures your team stays accountable for “disk hygiene.”
In 2026, the best way to do this without writing custom code is using Azure Logic Apps.
The Architecture: “The Monday Morning Cleanup”
We will build a simple 3-step workflow that runs every Monday at 9:00 AM, queries for unattached disks, and sends you a formatted HTML table.
Step 1: Create the Logic App (Recurrence)
Search for Logic Apps and create a new one (select Consumption plan for lowest cost).
Open the Logic App Designer and select the Recurrence trigger.
Set it to:
Interval: 1
Frequency: Week
On these days: Monday
At these hours: 9
Step 2: Run the KQL Query
Add a new step and search for the Azure Monitor Logs connector.
Select the action: Run query and visualize results.
Configure the connection:
Subscription/Resource Group: Select your primary management group.
Resource Type: Log Analytics Workspace.
The Query: Paste the “Orphaned Disk” query from earlier:Code snippetResources | where type has "microsoft.compute/disks" | extend diskState = tostring(properties.diskState) | where managedBy == "" and diskState == "Unattached" | project DiskName = name, ResourceGroup = resourceGroup, SizeGB = properties.diskSizeGB, Location = location
Chart Type: Select HTML Table.
Step 3: Send the Email
Add a final step: Office 365 Outlook – Send an email (V2).
To: Your team’s email.
Subject:⚠️ Weekly Action: Unattached Azure Disks found
Body:
Type some text like: “The following disks are currently unattached and costing money. Please delete them if they are no longer needed.”
From the Dynamic Content list, select Attachment Content (this is the HTML table from Step 2).
Why this is the “Pro” Move
Zero Maintenance: Once it’s running, you never have to check the portal manually.
Low Cost: A Logic App running once a week costs roughly $0.02 per month.
Formatted for Humans: Instead of a raw JSON blob, you get a clean table that you can forward to project owners.
Bonus: Add a “Delete” Link
If you want to be a 2026 power user, you can modify the KQL to include a “Deep Link” directly to each disk in the Azure Portal:
Now, you can click the link in your email and delete the disk in seconds.
Combining the different “zombie” resources into one report is the most efficient way to manage your Azure hygiene.
By using the union operator in KQL, we can create a single list of various resource types that are currently costing you money without providing value.
1. The “Ultimate Zombie” KQL Query
Copy and paste this query into your Logic App or Azure Resource Graph Explorer. It looks for unattached disks, unassociated IPs, and empty App Service Plans all at once.
| where managedBy == "" and diskState == "Unattached"
| project Name = name, Type = "Orphaned Disk", Detail = strcat(properties.diskSizeGB, " GB"), ResourceGroup, SubscriptionId
| union (
// Query for Unassociated Public IPs
Resources
| where type == "microsoft.network/publicipaddresses"
| where properties.ipConfiguration == "" and properties.natGateway == ""
| project Name = name, Type = "Unattached IP", Detail = tostring(properties.ipAddress), ResourceGroup, SubscriptionId
)
| union (
// Query for Empty App Service Plans (Costly!)
resources
| where type =~ "microsoft.web/serverfarms"
| where properties.numberOfSites == 0
| project Name = name, Type = "Empty App Service Plan", Detail = strcat(sku.tier, " - ", sku.name), ResourceGroup, SubscriptionId
)
| union (
// Query for Idle Load Balancers (No Backend Pool members)
resources
| where type == "microsoft.network/loadbalancers"
| where array_length(properties.backendAddressPools) == 0
| project Name = name, Type = "Idle Load Balancer", Detail = "No Backend Pools", ResourceGroup, SubscriptionId
)
| order by Type asc
2. Updating Your Logic App Report
To make this work in your weekly email:
Open your Logic App and update the “Run query” step with the new combined KQL above.
Update the HTML Table: Since the new query uses consistent column names (Name, Type, Detail), your HTML table will now neatly list the different types of waste side-by-side.
3. Advanced 2026 Tip: Add “Potential Savings”
If you want to get your manager’s attention, you can add a “Estimated Monthly Waste” column. While KQL doesn’t know your exact billing, you can hardcode estimates:
Code snippet
| extend MonthlyWaste = case(
Type == "Orphaned Disk", 5.00, // Estimate $5 per month
Type == "Unattached IP", 4.00, // Estimate $4 per month
Type == "Empty App Service Plan", 50.00, // Estimate $50+ for Standard+
0.00)
Your “Monday Morning” Checklist
When you receive this email every Monday, follow this triage:
Disks: Delete immediately unless you specifically kept it as a “manual backup” (though you should use Azure Backup for that).
Public IPs: Delete. Unused Public IPs are charged by the hour in Azure.
App Service Plans: If you aren’t using them, scale them to the Free (F1) tier or delete them. These are often the biggest hidden costs.
To turn this report into a powerful leadership tool, we need to calculate the “Total Potential Monthly Savings.” This changes the conversation from “We have a few loose disks” to “We can save $800/month by clicking these buttons.”
Here is how to update your Logic App and KQL to include a summary total.
<strong>💡 Quick Win Tip:</strong> Deleting these resources today
will save your department approx <strong>$@{outputs('Total_Waste_Sum')}</strong> per month.
</div>
3. Why This Works in 2026
The “Nudge” Effect: By showing the total dollar amount at the bottom, you create a psychological incentive for resource owners to clean up.
Customizable Pricing: You can adjust the MonthlyWaste numbers in the KQL to match your specific Enterprise Agreement (EA) pricing.
Single Pane of Glass: You now have one query that covers Compute, Network, and Web services.
Final Triage Steps
Review: If you see a “TOTAL POTENTIAL SAVINGS” of $0.00, congratulations! Your environment is clean.
Action: For the “Empty App Service Plans,” check if they are in a Free (F1) or Shared (D1) tier first—those don’t cost money, but they will still show up as “Empty.”
Users / Internet
|
Azure Front Door + WAF
|
===================================
| |
Region A Region B
Primary Secondary
| |
App Gateway/WAF App Gateway/WAF
| |
------------------------- ----------------------
| Spoke: App | | Spoke: App |
| Web / API / AKS | | Web / API / AKS |
| Managed Identity | | Managed Identity |
------------------------- ----------------------
| |
------------------------- ---------------------
| Spoke: Data | | Spoke: Data |
| SQL / Storage / KV | | SQL / Storage / KV |
| Private Endpoints | | Private Endpoints |
------------------------- ---------------------
\_________________ Hub VNet ______________/
Firewall | Bastion | Private DNS | Resolver
Monitoring | Shared Services | Connectivity
On-prem / Branches
|
ExpressRoute / VPN
|
Global connectivity to hubs / spokes
What makes this an Azure Landing Zone design
Azure landing zones are the platform foundation for subscriptions, identity, networking, governance, security, and platform automation. Microsoft’s landing zone guidance explicitly frames these as design areas, not just one network diagram. (Microsoft Learn)
So in an interview, say this first:
“This isn’t just a 3-tier app. I’m placing the app inside an enterprise landing zone, where networking, identity, governance, and shared services are standardized at the platform layer.” (Microsoft Learn)
How to explain the architecture
Traffic enters through Azure Front Door with WAF, which is the global entry point and can distribute requests across multiple regional deployments for higher availability. Microsoft’s guidance calls out Front Door as the global load balancer in multiregion designs. (Microsoft Learn)
Each region has its own application stamp in a spoke VNet. The app tier runs in the spoke, stays mostly stateless, and uses Managed Identity to access downstream services securely without storing secrets. The data tier sits behind Private Endpoints, so services like Key Vault, SQL, and Storage are not exposed publicly. A private endpoint gives the service a private IP from the VNet. (Microsoft Learn)
Shared controls live in the hub VNet: Azure Firewall, Bastion, DNS, monitoring, and sometimes DNS Private Resolver for hybrid name resolution. Hub-and-spoke is the standard pattern for centralizing shared network services while isolating workloads in spokes. (Microsoft Learn)
The key enterprise networking points
Use hub-and-spoke so shared controls are centralized and workloads are isolated. Microsoft’s hub-spoke guidance specifically notes shared DNS and cross-premises routing as common hub responsibilities. (Microsoft Learn)
For Private Endpoint DNS, use centralized private DNS zones and link them to every VNet that needs to resolve those names. This is one of the most important details interviewers look for, because private endpoint failures are often DNS failures. (Microsoft Learn)
For multi-region, either peer regional hubs or use Azure Virtual WAN when the estate is large and needs simpler any-to-any connectivity across regions and on-premises. (Microsoft Learn)
“Only the front door is public.”
“App and data tiers stay private.”
“Private Endpoints are used for PaaS services.”
“Managed Identity removes stored credentials.”
“Policies and guardrails are applied at the landing zone level.”
“Shared inspection and egress control sit in the hub.”
That lines up with landing zone governance, security, and platform automation guidance. (Microsoft Learn)
2-minute interview answer
“I’d place the 3-tier application inside an Azure landing zone using a hub-and-spoke, multi-region design. Azure Front Door with WAF would be the global ingress layer and route traffic to regional application stacks. In each region, the web and app tiers would live in a spoke VNet, while shared services like Firewall, Bastion, private DNS, and monitoring would live in the hub. The data tier would use services like Azure SQL, Storage, and Key Vault behind Private Endpoints, with centralized private DNS linked to all VNets that need resolution. The application would use Managed Identity for secure access without secrets. For resilience, I’d deploy a secondary region and let Front Door handle failover. For larger estates or more complex connectivity, I’d consider Virtual WAN to simplify cross-region and hybrid networking.” (Microsoft Learn)
Memory trick
Remember it as:
Global edge → Regional spokes → Private data → Shared hub controls
Or even shorter:
Front Door, Spokes, Private Link, Hub
Perfect—here’s a one-page Azure interview cheat sheet you can quickly revise before interviews 👇
Azure Architecture Cheat Sheet (Landing Zone + Networking + Identity)
1. Core Architecture
– Hub-and-spoke, multi-region, with centralized security and private backend services in Microsoft Azure.
2. Mental Diagram
Internet
|
Front Door (WAF)
|
Region A / Region B
|
Spoke VNet (App)
|
Private Endpoint
|
Data (SQL / Storage / Key Vault)
+ Hub VNet
Firewall | DNS | Bastion
3. Security Principles
“Only ingress is public”
“Everything else is private”
“Use Private Endpoints for PaaS”
“Use Managed Identity—no secrets”
“Enforce with policies and RBAC via Microsoft Entra ID”
4. Identity (VERY IMPORTANT)
Most secure → Managed Identity
Types:
User
Service Principal
Managed Identity
Rule:
Inside Azure → Managed Identity
Outside Azure → Federated Identity / Service Principal
5. Networking (What to Remember)
Private Endpoint
Uses private IP
Needs Private DNS
❗ Most common issue = DNS
Public Endpoint
Needs:
NAT Gateway or Public IP
Route to internet
Rule:
Private = DNS problem
Public = Routing problem
6. Troubleshooting Framework
Always say:
“What → When → Who → Why → Fix”
Step
Tool
What
Cost Mgmt / Metrics
When
Logs (Azure Monitor)
Who
Activity Log
Why
Correlation
Fix
Scale / Secure / Block
7. Defender Alert Triage
“100 alerts = 1 root cause”
Steps:
Go to Microsoft Defender for Cloud (not emails)
Group by resource/type
Find pattern (VM? same alert?)
Check:
NSG (open ports?)
Identity (who triggered?)
Contain + prevent
8. Cost Spike Debug
Cost Management → find resource
Metrics → confirm usage
Activity Log → who created/changed
Check:
Autoscale
CI/CD
Compromise
9. Resource Graph (Quick Wins)
Use Azure Resource Graph for:
Orphaned disks
Unused IPs
Recent resources
10. 3-Tier Design (Quick Version)
WAF → Web → App → Data
↓
Private Endpoints
11. Power Phrases
Say these to stand out:
“Zero trust architecture”
“Least privilege access”
“Identity-first security”
“Private over public endpoints”
“Centralized governance via landing zone”
“Eliminate secrets using Managed Identity”
Final Memory Trick
“Front Door → Spoke → Private Link → Hub → Identity”
30-Second Killer Answer
I design Azure environments using a landing zone with hub-and-spoke networking and multi-region resilience. Traffic enters through Front Door with WAF, workloads run in spoke VNets, and backend services are secured using private endpoints. I use managed identities for authentication to eliminate secrets, and enforce governance through policies and RBAC. This ensures a secure, scalable, and enterprise-ready architecture.
That matches Azure’s n-tier guidance, where logical layers are separated and can be deployed to distinct tiers for security, scale, and manageability. (Microsoft Learn)
Simple Azure design
Users
|
Azure Front Door / WAF
|
Web Tier
(App Service or VMSS)
|
App Tier
(App Service / AKS / VMSS)
|
Data Tier
(Azure SQL / Storage / Cache)
Better interview-ready version
Internet
|
Front Door + WAF
|
Application Gateway
|
---------------- Web Subnet ----------------
Web Tier
(App Service or VM Scale Set)
|
----------- App / API Private Subnet -------
App Tier
(App Service with VNet Integration / AKS / VMSS)
|
----------- Data Private Subnet ------------
Azure SQL / Storage / Redis / Key Vault
(Private Endpoints)
What I’d choose in Azure
For a modern Azure-native design, I’d usually use:
Front Door + WAF for global entry and protection
App Service for the web tier
App Service or AKS for the app/API tier
Azure SQL for the database
Key Vault for secrets
Private Endpoints for Key Vault and database access
VNet integration so the app tier can reach private resources inside the virtual network. Azure App Service supports VNet integration for reaching resources in or through a VNet, and Azure supports private endpoints for services like Key Vault. (Microsoft Learn)
Security design
A strong answer should include:
Put the web tier behind WAF
Keep the app tier private
Put the data tier behind Private Endpoints
Use Managed Identity from app tier to Key Vault and database where supported
Use NSGs and subnet separation
Disable public access on back-end services when possible. Azure’s secure n-tier App Service guidance specifically uses VNet integration and private endpoints to isolate traffic within the virtual network. (Microsoft Learn)
High availability and scaling
For resilience, I’d make the web and app tiers stateless, enable autoscaling, and run across multiple availability zones or multiple instances. Azure’s web app and Well-Architected guidance emphasizes designing for reliability, scalability, and secure operation. (Microsoft Learn)
2-minute interview answer
“I’d design the 3-tier app with a web tier, app tier, and data tier. User traffic would enter through Azure Front Door with WAF, then go to the web tier, typically App Service or VM Scale Sets. The web tier would call a private app tier that hosts the business logic. The app tier would connect to the data tier, such as Azure SQL, Storage, Redis, and Key Vault. I’d use VNet integration and private endpoints so the back-end services are not publicly exposed. For security, I’d separate tiers into subnets, apply NSGs, use Managed Identity for secret and database access, and store secrets in Key Vault. For reliability, I’d keep the web and app tiers stateless and scale them horizontally.” (Microsoft Learn)
Easy memory trick
Remember it as:
Ingress → Web → Logic → Data and Public only in front, private everywhere else
🧠 🧱 3-Tier Azure Diagram
✍️ Draw This on a Whiteboard
🌍 Internet
|
Azure Front Door / WAF
|
Application Gateway
|
--------------------------------
| Web Tier (Public) |
| App Service / VM Scale Set |
--------------------------------
|
--------------------------------
| App Tier (Private) |
| API / Backend / AKS |
--------------------------------
|
--------------------------------
| Data Tier (Private) |
| Azure SQL / Storage |
| + Key Vault |
--------------------------------
(Private Endpoints + VNet Integration)
🎤 What to Say While Drawing
🟢 Step 1 — Entry Point
“This is a 3-tier architecture in Microsoft Azure. Traffic enters through Front Door with WAF for global routing and security.”
🟢 Step 2 — Web Tier
“The web tier handles user requests. It’s the only layer exposed publicly and is typically built using App Service or VM Scale Sets.”
🟢 Step 3 — App Tier
“The app tier contains business logic and APIs. It’s private and only accessible from the web tier.”
🟢 Step 4 — Data Tier
“The data tier includes services like Azure SQL, Storage, and Key Vault, all accessed via Private Endpoints so they are not exposed to the internet.”
🟢 Step 5 — Security
I use VNet integration and Private Endpoints so all backend communication stays inside Azure. I also use Managed Identity for secure access to Key Vault and databases, eliminating secrets.
🔐 Add These Details
Mention these to stand out:
NSGs between tiers
Private DNS for Private Endpoints
No public access on DB / Key Vault
Use Azure Key Vault for secrets
Identity via Microsoft Entra ID
⚡ Ultra-Simple Memory Trick
👉 Draw 3 boxes vertically:
Web (Public)
App (Private)
Data (Private)
Then add:
WAF on top
Private Endpoints at bottom
💬 30-Second Version
“I’d design a 3-tier app with a web tier, app tier, and data tier. Traffic enters through Front Door with WAF, hits the web tier, then flows to a private app tier and finally to a private data tier. I’d secure backend services using Private Endpoints and use Managed Identity for authentication, ensuring no secrets are stored and no backend services are publicly exposed.”
Azure Front Door is a global, scalable entry point for your web applications. Think of it as a smart traffic cop sitting at the edge of Microsoft’s global network that routes users to the fastest, most available backend.
Key capabilities:
Global load balancing — distributes traffic across regions, routing users to the nearest or healthiest backend
SSL/TLS termination — handles HTTPS offloading at the edge, reducing backend load
URL-based routing — routes /api/* to one backend and /images/* to another
Caching — caches static content at edge locations (POPs) to reduce latency
Health probes — automatically detects unhealthy backends and reroutes traffic
Session affinity — sticky sessions to keep a user on the same backend
Front Door operates at Layer 7 (HTTP/HTTPS) and uses Microsoft’s global private WAN backbone, so traffic travels faster than the public internet.
Azure WAF (Web Application Firewall)
Azure WAF is a security layer that inspects and filters HTTP/S traffic to protect web apps from common exploits and vulnerabilities.
What it protects against:
SQL injection
Cross-site scripting (XSS)
OWASP Top 10 threats
Bot attacks and scraping
Rate limiting / DDoS at Layer 7
Custom rule-based threats (e.g. block specific IPs, countries, headers)
Two modes:
Detection mode — logs threats but doesn’t block (good for tuning)
WAF is a feature/policy that runs on top of Front Door (and also on Application Gateway). You attach a WAF policy to your Front Door profile, and it inspects all incoming traffic before it reaches your backends.
User Request
│
▼
┌─────────────────────────────┐
│ Azure Front Door │ ← Global routing, caching, SSL termination
| where type == "microsoft.network/publicipaddresses"
| where isnull(properties.ipConfiguration)
| project name, resourceGroup, location, sku
👉 These are exposed but unused → security + cost risk
3. Unattached Network Interfaces (NICs)
Resources
| where type == "microsoft.network/networkinterfaces"
| where isnull(properties.virtualMachine)
| project name, resourceGroup, location
4. Unused Network Security Groups (NSGs)
Resources
| where type == "microsoft.network/networksecuritygroups"
| where isnull(properties.networkInterfaces)
and isnull(properties.subnets)
| project name, resourceGroup, location
5. Empty Resource Groups (Bonus)
ResourceContainers
| where type == "microsoft.resources/subscriptions/resourcegroups"
| join kind=leftouter (
Resources
| summarize count() by resourceGroup
) on resourceGroup
| where count_ == 0 or isnull(count_)
| project resourceGroup
How to Run These Queries
You can run them in:
Azure Portal → Resource Graph Explorer
CLI:az graph query -q "<query>"
PowerShell:Search-AzGraph -Query "<query>"
Pro Tip (Senior-Level Insight)
👉 Don’t just find orphaned resources—automate cleanup
Schedule queries using:
Azure Automation
Logic Apps
Trigger:
Alerts
Cleanup workflows
Interview Answer
I use Azure Resource Graph with KQL queries to identify orphaned resources at scale across subscriptions. For example, I can query for unmanaged disks where the disk state is unattached, or public IPs without an associated configuration. Similarly, I check for NICs not linked to VMs and NSGs not applied to subnets or interfaces.
Beyond detection, I typically integrate these queries into automated governance workflows—using alerts or scheduled jobs to either notify teams or trigger cleanup—so we continuously reduce cost and improve security posture.
Here’s a solid production-ready pattern, plus a script approach you can talk through in an interview.
Production cleanup strategy
Use Azure Resource Graph for detection, then use Azure Automation with Managed Identity for controlled remediation. Resource Graph is built for cross-subscription inventory queries at scale, and its query language is based on KQL. You can run the same queries in the portal, Azure CLI with az graph query, or PowerShell with Search-AzGraph. (Microsoft Learn)
Safe workflow
Phase 1: Detect Run queries for likely orphaned resources such as unattached disks, unused public IPs, unattached NICs, and unused NSGs. Azure documents advanced query samples and the CLI quickstart for running them. (Microsoft Learn)
Phase 2: Classify Do not delete immediately. First separate findings into:
definitely orphaned
likely orphaned
needs human review
A good rule is to require at least one of these before cleanup:
older than X days
no keep tag
no recent change window
not in protected subscriptions or resource groups
You can also use Resource Graph change history to review whether a resource was recently modified before acting. (Microsoft Learn)
Phase 3: Notify Send a report to the owning team or central platform team. Include:
resource ID
resource group
subscription
resource age or last change
proposed action
deadline for objection
Phase 4: Quarantine before delete For risky resource types, first tag them with something like:
cleanupCandidate=true
cleanupMarkedDate=2026-04-13
cleanupOwner=platform
Then wait 7 to 30 days depending on the environment.
Phase 5: Delete with guardrails Only auto-delete low-risk items such as clearly unattached disks or unused public IPs after the waiting window. Keep production subscriptions on approval-based cleanup unless the criteria are extremely strict.
Good governance rules
A mature setup usually includes:
exclusion tags like doNotDelete=true
separate policy for prod vs non-prod
allowlist of critical subscriptions
dry-run mode by default
centralized logs of all cleanup actions
approval gate for medium-risk deletions
This aligns well with Azure’s broader security and operations guidance, and Azure Automation supports managed identities so runbooks can access Azure without stored secrets. (Microsoft Learn)
Example architecture
Azure Resource Graph
|
v
Scheduled Automation Runbook
(with Managed Identity)
|
+--> Query orphaned resources
+--> Filter by tags / age / subscription
+--> Write report to Storage / Log Analytics
+--> Notify owners
+--> Optional approval step
+--> Delete approved resources
Example: Azure CLI script
This is a simple version for unattached managed disks. Start in report-only mode.
Search-AzGraph is the PowerShell command for Resource Graph, and Azure Automation supports system-assigned or user-assigned managed identities for authenticating runbooks securely. (Microsoft Learn)
What to say in an interview
A strong answer would sound like this:
I’d use Azure Resource Graph to detect orphaned resources across subscriptions, then feed those results into an Azure Automation runbook running under Managed Identity. I would never delete immediately. Instead, I’d apply filters like age, tags, subscription scope, and recent change history, then notify owners or mark resources for cleanup first. For low-risk resources in non-production, I might automate deletion after a quarantine period. For production, I’d usually keep an approval gate. That gives you cost control without creating operational risk. (Microsoft Learn)
Best resource types to target first
Start with the safest, highest-confidence cleanup candidates:
