Azure Architecture Interview Questions for .NET Architects

Q1 A client needs a new .NET platform on Azure and hasn't picked a compute model yet. Walk through how you decide between App Service, Container Apps, AKS and Azure Functions.#

Short answer: Start from the workload's shape — a request/response web app, a bursty event-driven workload, or a system that genuinely needs orchestration primitives like custom schedulers or a service mesh — and let that, plus the team's operational maturity, pick the platform; App Service and Functions cover most line-of-business and event workloads with the least operational burden, Azure Container Apps is the sweet spot for microservices that want Kubernetes-style scaling without owning a cluster, and AKS is justified only when you need control the other three genuinely can't give you.

In practice I run every candidate workload through the same four questions: does it need to scale to zero, does it need custom networking or a service mesh, does the team already run Kubernetes elsewhere, and does compliance require workload isolation the platform enforces for you. A stateless ASP.NET Core API with predictable traffic almost always lands on App Service — it is the least to operate, has built-in deployment slots and easy custom domains, and nobody on the team needs to learn Kubernetes to keep it alive at 2 a.m. An event-driven workload (queue processing, webhooks, scheduled jobs) points at Azure Functions, especially now that the Flex Consumption plan closes most of the classic Consumption plan's cold-start and networking gaps. Container Apps earns its place when you have several services that need independent scaling and simple service discovery but not the full Kubernetes API surface — it gives you KEDA-based scaling and Dapr building blocks without a control plane to patch. AKS is the right answer when the team needs custom admission controllers, a service mesh, GPU node pools, or already has platform engineers running Kubernetes for other workloads, so the marginal cost of one more cluster is low.

What changes my answer mid-project is almost always discovering a constraint that wasn't visible at design time: a workload that turns out to need a custom NetworkPolicy or a sidecar the platform doesn't support, or the opposite — a team that adopted Running .NET on Kubernetes for one service and is now paying the operational tax of a cluster for workloads that never needed it. Reversing a compute decision is expensive, so I treat it as a last resort driven by a concrete, named constraint, never by fashion or a conference talk.

What interviewers look for: a decision framework driven by workload shape and team capability, not a list of services with adjectives attached, plus honesty about the real cost of running Kubernetes badly.

Common mistakes: defaulting to AKS because it is the most flexible option without weighing the ongoing patching, upgrade and on-call cost against a team that has never run a cluster before.

Q2 Explain the five pillars of the Azure Well-Architected Framework and how you actually use them in a design review, not just recite them.#

Short answer: The pillars are Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency, and the framework is only useful as a set of trade-off lenses applied to one workload at a time — every real design improves some pillars at the expense of others, and the interviewer wants to see you name the trade-off explicitly rather than claim you optimized all five simultaneously.

In a design review I use the pillars as a checklist of questions, not a scorecard: for reliability, what is the single point of failure and what is its blast radius; for security, what is the smallest set of identities and network paths that make this work; for cost optimization, what is the cost of the reliability and performance choices we just made, and is the business actually willing to pay it; for operational excellence, can the on-call engineer diagnose a failure at 3 a.m. from the telemetry we ship by default; for performance efficiency, does the design scale linearly with load or does it hit a wall at some multiple of today's traffic. A concrete conflict I see constantly: a stakeholder wants active-active multi-region for reliability, which roughly doubles run cost and adds real complexity to data consistency — resolving that isn't "add more pillars," it's going back to the business impact analysis, translating the requested RTO/RPO into dollars of downtime avoided, and either justifying the spend or choosing a cheaper pattern like an active-passive design with automated, tested failover that meets the same numeric target at lower cost.

What interviewers look for: a working example of two pillars in tension and how you resolved it with a business-driven decision, not a textbook definition of all five pillars.

Follow-up questions:

• Which pillar do you find teams neglect most often, and why?
• How do you turn a Well-Architected Framework review into prioritized backlog items instead of a report nobody acts on?

Q3 What is an Azure landing zone, and how do platform landing zones differ from application landing zones?#

Short answer: A landing zone is a pre-provisioned, policy-governed Azure environment that a workload team deploys into rather than a raw subscription; platform landing zones provide the shared, centrally owned foundation — connectivity, identity and management — while application landing zones are the subscriptions where individual workload teams actually deploy resources, each inheriting the platform's guardrails through Azure Policy rather than through manual review.

The standard shape, drawn from the enterprise-scale landing zone pattern, is a management group hierarchy under a root: a Platform group split into Connectivity (hub VNets, ExpressRoute/VPN gateways, Azure Firewall), Identity (domain controllers or identity-adjacent infrastructure) and Management (Log Analytics, Azure Monitor, Automation) subscriptions; a Landing Zones group typically split into Corp (workloads that need connectivity back to on-premises) and Online (internet-facing workloads that don't); and separate Sandbox and Decommissioned groups so experimentation and retired subscriptions never inherit production policy by accident. Azure Policy is assigned at the management group level and flows down automatically, which is what makes the model scale — a new application team doesn't get a security review meeting, it gets a subscription that already has diagnostic settings, network restrictions and tagging requirements enforced before the first resource is deployed. The practical architect skill being tested here is "subscription vending": can you describe how a new workload team goes from a request to a compliant, connected subscription in hours instead of weeks, because that turnaround time is usually the actual business metric a platform team is measured on.

What interviewers look for: the platform-versus-application split stated precisely, plus an understanding that governance is enforced through policy inheritance, not through people reviewing every deployment.

Common mistakes: describing a landing zone as "just a subscription with some rules" without the management group hierarchy that makes policy inheritance and subscription vending actually work at scale.

Q4 Design the network topology for a multi-region .NET platform on Azure. When do you reach for a hub-spoke topology, and when does it stop being the right answer?#

Short answer: Hub-spoke — a central hub VNet holding shared services (Azure Firewall, VPN/ExpressRoute gateway, DNS resolver) peered to per-workload spoke VNets that route through it — is the right default up to roughly a handful of regions and a few dozen spokes; beyond that, the operational cost of managing peerings and route tables by hand outweighs the benefit, and Azure Virtual WAN's managed any-to-any hub becomes the better answer.

The core trade-off is who owns the routing complexity. In hub-spoke, you own it: VNet peering is not transitive, so spoke-to-spoke traffic has to be explicitly routed through the hub via user-defined routes, and every new region means standing up another hub and deciding whether to mesh the hubs together or accept that cross-region traffic hairpins through a gateway. Virtual WAN replaces that hand-built mesh with a Microsoft-managed backbone: spokes connect to a regional virtual hub, and any-to-any connectivity between hubs, branches and spokes is handled for you, which is exactly the complexity that becomes unmanageable manually once you are past a handful of regions or a couple of dozen VNets. For a typical enterprise .NET platform, I default to hub-spoke inside a single region or two, keep the hub thin (firewall, gateway, private DNS resolver — nothing workload-specific), and only escalate to Virtual WAN when the topology itself, not the traffic volume, becomes the bottleneck.

resource spokePeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  name: '${spokeVnet.name}/spoke-to-hub'
  properties: {
    remoteVirtualNetwork: { id: hubVnetId }
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: true
  }
}

What interviewers look for: an explicit trigger for switching topologies (peering-mesh and route-table burden, not raw traffic) rather than treating hub-spoke as a permanent default.

Follow-up questions:

• How do you handle DNS resolution for private endpoints across peered spokes?
• What changes about this design if two regions need active-active traffic, not just disaster recovery?

Q5 When do you use a private endpoint versus a service endpoint versus routing through Azure Firewall, and how would you lock down an AKS cluster's access to Azure SQL and Storage?#

Short answer: A private endpoint gives a specific PaaS resource instance a private IP inside your VNet via Azure Private Link, so traffic never touches the public internet and can be reached from on-premises over ExpressRoute or VPN; a service endpoint only optimizes the route to the resource's public IP over the Microsoft backbone and restricts access by VNet identity on the resource's own firewall, which is weaker and increasingly considered legacy for anything handling sensitive data; Azure Firewall or an NVA sits in the hub to filter and log north-south and east-west traffic, and is a complement to private endpoints, not a substitute for them.

For locking down an AKS cluster's access to Azure SQL and Storage, the design is: disable public network access on both resources, create private endpoints for each in a dedicated subnet, and link a private DNS zone (privatelink.database.windows.net, privatelink.blob.core.windows.net) to every VNet that needs to resolve them, including the hub if DNS resolution is centralized. Pods reach the database and storage account over the cluster's VNet-native networking without ever routing to a public endpoint, which closes off both accidental public exposure and the data-exfiltration risk a service endpoint doesn't fully address — because a service endpoint still permits traffic to any instance of that Azure service unless additional resource-level firewall rules are layered on. Azure Firewall still matters here for the traffic private endpoints don't cover: outbound calls the cluster makes to the internet (package registries, external APIs), which should go through the firewall's FQDN filtering rather than a default-allow NAT gateway.

resource pe 'Microsoft.Network/privateEndpoints@2023-09-01' = {
  name: 'pe-sql-orders-prod'
  location: location
  properties: {
    subnet: { id: privateEndpointSubnetId }
    privateLinkServiceConnections: [
      {
        name: 'sql-connection'
        properties: {
          privateLinkServiceId: sqlServerId
          groupIds: [ 'sqlServer' ]
        }
      }
    ]
  }
}

What interviewers look for: the specific mechanism difference (private IP via Private Link versus route optimization plus firewall rules), applied to a concrete AKS scenario rather than stated in the abstract.

Common mistakes: treating service endpoints and private endpoints as interchangeable, or forgetting that private endpoints need private DNS zone links in every VNet that resolves them, which is the single most common source of "it works from the hub but not from the spoke" tickets.

Q6 Design the identity model for a .NET platform that spans multiple environments and needs to call other Azure resources, third-party APIs and its own CI/CD pipeline securely.#

Short answer: Use a managed identity for anything Azure-to-Azure (an App Service or AKS pod reading from Key Vault or Storage), reserve Entra ID app registrations for identities that need to be called by external parties or need delegated user permissions, and use workload identity federation — not stored client secrets — for both AKS pods and CI/CD pipelines, so no long-lived credential exists anywhere in the system for an attacker to steal.

The distinctions matter because each solves a different problem: a system-assigned managed identity is tied to one resource's lifecycle and is the simplest option for a single App Service calling Key Vault; a user-assigned managed identity is a standalone resource you can attach to several compute resources and reuse, which is the right choice when five Container Apps revisions all need the same downstream permissions. App registrations exist for the cases managed identity can't cover — a multi-tenant SaaS API that needs its own client ID and secret rotation story, or an application acting on behalf of a signed-in user via delegated permissions. For AKS specifically, Microsoft Entra Workload ID replaced the older AAD Pod Identity approach: pods present a Kubernetes service account token that's federated with an Entra app registration via OIDC trust, so the pod gets a short-lived Entra token with no secret ever stored in the cluster. The same federated-credential pattern applies to identity architecture for CI/CD: GitHub Actions or Azure DevOps pipelines authenticate to Azure via OIDC federation instead of a stored service principal secret, which removes the single most common secret-leak vector in pipeline configuration.

// Works unchanged locally (developer credential), in a pipeline (OIDC federation)
// and in Azure (managed identity) — no secret is ever stored in configuration.
var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri(keyVaultUri), credential);
KeyVaultSecret secret = await client.GetSecretAsync("orders-db-connection");

What interviewers look for: a clear mapping from identity type to problem (Azure-to-Azure, external caller, pipeline) and specific knowledge that AKS and CI/CD both have a federated, secretless option, since "we still use a stored service principal secret" is a common real-world gap.

Common mistakes: issuing an app registration with a client secret for a purely Azure-to-Azure call that a managed identity would have handled with zero credential to rotate or leak.

Q7 How do you design for high availability and disaster recovery in Azure, and how do you decide the RTO and RPO targets that drive the architecture?#

Short answer: RTO and RPO are business decisions, not architecture decisions — they come out of a business impact analysis that prices downtime and data loss per minute for a given workload — and the architecture then implements the cheapest pattern that meets those numbers: availability zones for intra-region failures with near-zero RPO, and cross-region replication with an explicit, usually non-zero RPO for a regional disaster, choosing between active-passive and active-active based on how much extra cost and complexity the RTO target actually justifies.

Availability zones are physically separate datacenters within a region, each with independent power, cooling and networking, close enough together for synchronous replication — Azure SQL zone-redundant configuration and zone-redundant Storage are built on this, and they protect against a datacenter-level failure with effectively no data loss and minimal application change. Cross-region protection is a different tier of problem: not every Azure region has a designated paired region anymore — newer regions increasingly rely on availability zones instead — so the DR design has to be explicit about which secondary region it targets and why, rather than assuming a pairing exists. Active-passive (a warm or pilot-light secondary that's promoted on failover) is the default because it is dramatically cheaper than active-active and the RTO of "a few minutes to fail over a pre-provisioned secondary" satisfies most business requirements; active-active is reserved for the rare workload where even single-digit minutes of downtime has a quantifiable, large cost, and it comes with a real tax — the application has to handle multi-region write conflicts or be partitioned so each region owns a distinct slice of data, which is a substantial engineering investment most workloads don't need.

What interviewers look for: RTO/RPO framed as a cost-benefit decision handed down from the business, not a number the architect picked, plus accurate knowledge that region pairing isn't universal across Azure regions anymore.

Follow-up questions:

• How would you design data partitioning to make active-active safe for an orders system?
• What's the difference between the RPO you design for and the RPO you actually test?

Q8 Walk through what happens when an entire Azure region goes down for a typical three-tier .NET application — App Service or AKS in front of Azure SQL and Storage.#

Short answer: Traffic Manager or Front Door detects failed health probes and stops routing to the primary region within its probe interval, the application tier in the secondary region has to already be running or come up from a pre-baked image or deployment (a cold secondary adds its own startup time to your effective RTO), Azure SQL fails over through a pre-configured auto-failover group rather than anything automatic by default, and Storage account failover is customer-initiated or runbook-triggered, not instantaneous — which means the true RTO is the slowest of these four steps, not the fastest, and the true RPO is whatever the database and storage replication lag was at the moment of the outage.

The part candidates usually get wrong is assuming failover is a single event; it's actually a chain, and each link has to have been provisioned and tested beforehand or it doesn't work under pressure. Azure SQL failover groups give you a stable read-write listener endpoint that repoints automatically once failover completes, but the failover itself — automatic or manual, depending on how the group is configured — still has a replication lag measured in seconds to low minutes under normal conditions that can grow under heavy write load right before the outage, which is the real-world reason RPO for geo-replicated SQL is described as "typically low, not zero." Storage account geo-failover for GRS/RA-GRS accounts is a separate decision entirely — it has to be triggered, and any writes not yet replicated at the moment of the regional outage are lost, so anything the application treats as durable the instant it's written needs its own reconciliation story for the window right before a failover. The single biggest cause of a DR plan failing in production isn't the data layer at all — it's DNS TTLs that are too long, certificates that were only ever issued for the primary region's hostname, or configuration that hard-codes a region-specific endpoint, all of which only surface the first time you actually run the failover, which is why untested DR plans should be assumed broken until proven otherwise with a real game day.

What interviewers look for: the ordered, step-by-step failure chain with realistic RPO caveats at each layer, and a strong opinion that DR is only real once it's been tested end to end, not just designed on paper.

Q9 How do you keep Azure spend under control at scale without turning every engineering decision into a cost-approval meeting?#

Short answer: Combine structural cost controls that don't require per-decision oversight — reservations or savings plans for steady-state baseline compute, autoscaling so you only pay peak price during peak load, mandatory tagging enforced by policy for chargeback, and budgets with automated alerts — with a lightweight review cadence driven by Azure Advisor's cost recommendations, so the platform catches waste continuously instead of relying on an engineer to remember to check.

Reservations and savings plans are the highest-leverage lever for predictable workloads, but only after you have a real usage baseline — committing to a one- or three-year reservation before you understand steady-state consumption locks in waste instead of removing it, so I sequence this after at least a month or two of stable production traffic, not on day one. Autoscaling (App Service autoscale rules, AKS cluster autoscaler plus HPA, Container Apps' built-in KEDA scaling) handles the workloads that genuinely vary; the mistake is applying it to workloads that don't actually vary and then paying for the scaling infrastructure's overhead without the benefit. Tagging is the least glamorous and most load-bearing piece: without a cost-center or owner tag enforced by an Azure Policy deny or append effect at the management group level, cost data can be seen in Azure architecture dashboards but never attributed to a team, which means nobody feels the cost and nothing changes. Budgets with action-group-triggered alerts turn a monthly bill surprise into a same-day Slack notification, which is a far cheaper way to catch a runaway resource than a retrospective.

az consumption budget create \
  --budget-name platform-monthly \
  --amount 50000 \
  --category cost \
  --time-grain monthly \
  --start-date 2026-10-01 \
  --end-date 2027-09-30

What interviewers look for: structural, low-friction controls (tagging, budgets, autoscaling) over manual gatekeeping, plus the specific insight that reservations bought before a usage baseline exists often waste money instead of saving it.

Common mistakes: treating Azure Advisor recommendations as optional noise instead of a continuous, low-cost source of right-sizing and idle-resource findings.

Q10 You inherit an Azure environment with no landing zone, no tagging strategy and a cost trend that's climbing faster than the business. What's your first 90 days?#

Short answer: Spend the first month purely on discovery and low-risk, high-confidence wins — inventory what exists, tag it, kill obviously idle resources — before touching anything structural, then use months two and three to introduce governance in audit mode first and enforcement second, because a big-bang policy rollout in deny mode on an ungoverned environment breaks things and burns the trust you need for the harder changes later.

Days 0–30 are discovery: run Azure Resource Graph queries across every subscription to inventory what actually exists versus what anyone remembers deploying, turn on Cost Management analysis by subscription and resource group to find the concentration of spend, and roll out an Azure Policy tagging requirement in audit (not deny) mode so you can see compliance gaps without breaking anyone's deployment pipeline on day one. Days 30–60 are quick, reversible wins: deallocate or resize instances Advisor flags as idle, delete unattached managed disks and orphaned public IPs, and apply auto-shutdown schedules to non-production resources — these typically recover a meaningful fraction of spend within weeks and buy political capital for the structural work ahead. Days 60–90 are the structural fix: stand up a real management group hierarchy and a minimal landing zone (connectivity, identity, management), move policy from audit to enforced for new resources first and existing resources second, and only now — with a real usage baseline in hand — start buying reservations or savings plans for the workloads that have proven stable. Sequencing matters as much as the individual actions: governance introduced as "here's what's already broken" instead of "here's a new gate you have to pass" gets far less pushback from the teams whose workloads you're now constraining.

What interviewers look for: a sequenced, low-risk-first plan that separates discovery from enforcement, and an explicit acknowledgment that governance rolled out as deny-mode policy on day one on an ungoverned estate causes outages and erodes trust.

Common mistakes: jumping straight to buying reservations or enforcing deny-mode policies before establishing a usage baseline or getting buy-in, which turns a cost-control initiative into an incident.