Microsoft azure Interview Questions

Note: Cloud interviews reward specifics about cost, security, and failure. Anyone can say they "deployed to Azure"; describing what it cost and how it recovered is what shows ownership.

Cover:

• What the workload was and where it came from. A lift-and-shift from on-premises virtual machines is a very different exercise from a greenfield deployment to App Service or AKS. Say which.
• The services you chose and why. Not a list — a justification. "We used App Service rather than AKS because we had three services and no Kubernetes experience on the team" is a real answer.
• The hard part. Strong candidates: networking and hybrid connectivity, an identity or RBAC model that grew complex, a database migration with minimal downtime, or a cost overrun you had to bring under control.
• The outcome — cost, availability, or deployment frequency before and after.

This is asked constantly, because uncontrolled cloud spend is a real and common failure.

Visibility first:

• Tag everything by environment, owner, and cost centre, and enforce tagging with Azure Policy. Without tags you cannot attribute a bill, and attribution is what changes behaviour.
• Cost Management budgets and alerts so overspend is caught in week one rather than on the invoice.
• Azure Advisor for concrete rightsizing recommendations.

Then the levers, roughly in order of payoff:

• Turn things off. Non-production environments running overnight and at weekends are the most common waste. Auto-shutdown schedules pay for themselves immediately.
• Rightsize. Instances are usually provisioned for a peak that never arrives.
• Reserved Instances or Savings Plans for predictable baseline workloads — substantial savings for a one or three year commitment.
• Storage lifecycle policies moving cold data to Cool and Archive tiers.
• Watch egress charges, which surprise people because ingress is free.

Note: Framing cost as an engineering responsibility rather than a finance problem is the answer interviewers want.

Give a timeline, and be honest about what you did not know at the time.

• Detection. What alerted you — an Azure Monitor alert, Application Insights failure rate, an availability test, or a customer. If it was a customer, that gap is itself a finding worth stating.
• Triage before diagnosis. Stopping the impact comes first: rolling back a deployment, failing over to a secondary region, scaling out, or disabling a feature flag. Interviewers want to see that you do not debug while users are down.
• Diagnosis. The evidence — Log Analytics queries, Application Insights end-to-end transaction views, Service Health to rule out an Azure-side issue, and activity logs to see what changed.
• The permanent fix. Usually something structural: a missing health probe, no retry with backoff on a transient fault, a single point of failure with no zone redundancy, or a secret that expired with no alert.

Note: Mentioning that you checked Azure Service Health early is a good practical detail — a meaningful share of incidents are platform-side, and confirming that changes the response entirely.

Lead with least privilege and work outwards.

• Identity is the perimeter. Everything authenticates through Microsoft Entra ID. Enforce multi-factor authentication, use Conditional Access policies, and disable legacy authentication protocols.
• RBAC with least privilege. Assign the narrowest built-in role that works, at the narrowest scope — a resource group rather than a subscription. Assign to groups, never to individuals, so access is managed by group membership.
• Privileged Identity Management for just-in-time elevation, so nobody holds standing Owner rights.
• Managed identities instead of secrets. This is the most important practical point: a managed identity lets a service authenticate to another Azure service with no credential stored anywhere. Where a secret is unavoidable, it belongs in Key Vault with rotation, never in configuration or code.
• Network controls — private endpoints so data services are not exposed publicly, network security groups, and a firewall or WAF at the edge.
• Azure Policy to enforce standards automatically, and Defender for Cloud for continuous posture assessment.

Note: Saying you would enforce rules with Policy rather than documentation is what distinguishes an engineer who has operated a real subscription.

How you keep up: the Azure updates feed and roadmap, the well-written official architecture centre, and hands-on work in a personal subscription. Certifications are useful for structure and for filling gaps you did not know you had, but say plainly that they are not a substitute for having run something.

How you evaluate a new service:

• Is it generally available in your region? Preview services have no SLA and can change or be withdrawn. This alone rules out most new things for production.
• Does it solve a problem you have, measured? Managed services trade cost and flexibility for reduced operational burden, which is often a good trade — but only if the burden was real.
• What is the exit cost? The more managed and proprietary the service, the harder it is to leave. That is acceptable for some workloads and not others; the point is to decide deliberately.
• Can your team operate it? Choosing AKS with nobody who knows Kubernetes creates a bigger problem than it solves.

Note: Naming a service you chose not to adopt, with the reasoning, is the strongest version of this answer.

This checks whether you can bring order to a shared cloud estate without slowing teams down. Tell it as problem, design, rollout, result.

• The problem: make it concrete — “five product teams in one subscription, everyone was Owner, nobody could say which resources belonged to whom, and the monthly bill had doubled.”
• The design you proposed:
  • A management group hierarchy — platform, production landing zones, non-production and sandbox — aligned with the Cloud Adoption Framework.
  • Subscriptions per workload or per environment, giving clear cost and access boundaries.
  • Azure Policy initiatives: allowed regions, required tags such as owner, costCentre and environment, no public IPs in production, diagnostic settings deployed automatically.
  • RBAC through Entra ID groups, with Contributor at resource-group level and Owner reserved for a small platform team via PIM.
  • Budgets and cost alerts per subscription.
• How you rolled it out: policies in Audit mode first to measure impact, a clean-up period with each team, then switching key policies to Deny. Governance defined in code so changes went through pull requests.
• Getting buy-in: you involved team leads early, explained what each rule protected against, and gave them a sandbox with looser rules so experimentation was not blocked.
• Result: numbers where possible — tag compliance going from 30% to over 95%, cost attributable per team, standing Owner assignments removed.

Include one conflict: a team blocked by a Deny policy during a release, and how you handled it — an exemption with an expiry date rather than weakening the policy for everyone.

Note: Interviewers look for a balance between control and developer freedom. Governance that nobody can work within ends up bypassed.

The interviewer wants evidence that you reduce toil and risk, and that you can bring others along. Structure it as before, what you built, adoption, measurable outcome.

• Before: describe the pain with specifics — environments built by hand from a Word document, staging that did not match production, a two-day wait for a new environment, and an outage caused by a manual setting missed on one App Service.
• What you built:
  • Bicep modules for the building blocks — App Service with slots, Azure SQL, Key Vault, private endpoints — with parameter files per environment.
  • A pipeline in Azure DevOps or GitHub Actions: lint and build, a what-if preview posted to the pull request, approval gates for production, then deployment.
  • Authentication through workload identity federation or a managed identity, so no client secrets were stored in the pipeline.
• How you approached it: started with one application, exported and cleaned up existing resources rather than rebuilding everything, and validated that the template reproduced the current state exactly before trusting it.
• Adoption: documentation, a walkthrough for the team, and gradually restricting portal write access in production once the pipeline was reliable.
• Outcome: environment creation time, deployment frequency, fewer configuration-related incidents, or audit findings closed.

Add a lesson learned: perhaps a deployment that removed something unexpectedly, which led you to adopt what-if review, deployment stacks with deny settings, or resource locks on critical resources.

Note: Quantify the time saved and tie it to reliability, not just convenience. “We stopped having configuration drift incidents” is a stronger result than “it was faster”.

This is a situational judgement question. The interviewer wants to see that you protect production and help solve the problem quickly — neither a flat “no” nor handing over the keys.

How to structure your answer:

1. Understand the need first. Ask what the issue is and what exactly they need to do — restart an app, read logs, change a configuration value, scale a database. Owner is almost never required; it includes the right to grant access to others.
2. Offer the least privilege that solves it. Reader plus Log Analytics access to investigate; Website Contributor on one App Service to restart or change settings; Contributor scoped to a single resource group if genuinely needed.
3. Make it time-bound. Use Privileged Identity Management to grant an eligible role with activation, justification, approval and an automatic expiry of a few hours, rather than a permanent assignment.
4. Keep it auditable. Activity Log and PIM records show exactly what was done. Ideally, pair on the fix or have the change go through the pipeline, even as an expedited release.
5. Have a break-glass path. If it is a genuine severity-one incident and the normal route is too slow, follow the documented emergency-access process rather than improvising.

Show follow-through: after the incident, review why the developer lacked the access they needed. Perhaps the team needs a standing, scoped operational role, better dashboards, or runbooks automated so fewer people need direct production access.

Tone matters: say that you would respond quickly and collaboratively — the developer is trying to fix production, not break it.

Note: Mentioning PIM, scope and expiry together shows you understand that security and speed can coexist when access is designed well.

Cloud roles involve decisions with cost and risk implications that business stakeholders must approve. The interviewer wants to see that you can translate technical options into business terms and help someone decide.

Structure the story:

• Situation: who the stakeholder was and what was being decided — for example, a finance head questioning why the proposed multi-region design for a customer portal cost nearly double the single-region option.
• How you framed it:
  • You translated technical terms into business outcomes: instead of “RTO and RPO”, you said “if the Central India region has a major outage, option A is back in about four hours and may lose the last hour of orders; option B recovers in minutes with almost no lost data.”
  • You put a rough cost on downtime — revenue per hour, penalties, reputational impact — so the extra spend could be compared with the risk it removes.
  • You presented two or three options with cost, risk and effort, including a middle ground such as zone-redundant deployment plus geo-redundant backups.
• Tools you used: a one-page summary, a simple diagram, and an analogy — for example, comparing zone redundancy to having two branches in the same city and multi-region to having a branch in another state.
• Outcome: the decision reached, and why it was right for the business — often the middle option, with the multi-region design documented for later.

What to emphasise: you listened to their concerns, avoided jargon, and made it their decision with your recommendation clearly stated, rather than trying to win an argument.

Note: Admit what you learned — perhaps that leading with the business impact, rather than the architecture diagram, got a faster decision.

This asks for a measurable improvement you drove. Interviewers want to see diagnosis based on data, sensible fixes, and a verified result. Use STAR with numbers.

• Situation: the application and the symptom — “an App Service API with p95 latency over three seconds at peak and several timeouts a day,” or “an AKS workload that restarted pods under load.”
• Diagnosis: this is the heart of the answer. Explain how you found the cause:
  • Application Insights dependency tracking showing most time spent in Azure SQL calls.
  • Query Performance Insight revealing a missing index, or the database hitting its DTU or vCore limit.
  • KQL queries in Log Analytics correlating errors with deployments or traffic peaks.
  • SNAT port exhaustion on outbound connections, a classic App Service issue fixed with connection reuse or a NAT gateway.
• Actions: the fixes, ideally layered — index and query changes, Azure Cache for Redis for hot reads, autoscale rules on the App Service plan, health checks so unhealthy instances leave rotation, retry policies with exponential backoff, and moving to zone-redundant tiers.
• Verification: load testing with Azure Load Testing or another tool before and after, and alerts on the metrics that mattered.
• Result: p95 latency down to a specific figure, error rate reduced, availability improved, and ideally cost unchanged or lower.

Finish with prevention: dashboards, SLO-based alerts, or a performance test added to the pipeline so the problem does not return unnoticed.

Note: Avoid answers where the only fix was “we scaled up”. Scaling can be part of the answer, but interviewers want to hear that you found and fixed the underlying cause.

The three models differ in how much you manage versus how much the provider manages — this is the "shared responsibility" spectrum.

• IaaS (Infrastructure as a Service) — you get virtual machines, storage, and networking; you manage the operating system, patching, runtime, and application. Azure examples: Virtual Machines, Virtual Networks, Managed Disks. Maximum control, maximum operational burden. Use it for lift-and-shift migrations and workloads needing specific OS-level configuration.
• PaaS (Platform as a Service) — the provider manages the operating system and runtime; you deploy code and configuration. Azure examples: App Service, Azure SQL Database, Azure Functions, Container Apps. Far less to operate, at the cost of some flexibility. This is where most new development should start.
• SaaS (Software as a Service) — you consume a finished application. Azure and Microsoft examples: Microsoft 365, Dynamics 365. You manage only your data and users.

The interview point: the trade is control against operational cost. Patching an IaaS VM is your job and a real ongoing expense; with PaaS it is not.

Note: Serverless — Functions and Logic Apps — is worth naming as a further step, where you do not manage instances at all and pay per execution.

The hierarchy:

• Region — a geographic area containing one or more datacentres, such as Central India or West Europe.
• Availability Zone — a physically separate datacentre within a region, with independent power, cooling, and networking. Zones protect against a datacentre failure.
• Region pair — each region is paired with another in the same geography, used for geo-redundant storage and coordinated platform updates.

Designing for availability, in increasing order of cost and protection:

• Multiple instances in one zone — protects against a single instance failing. This is the minimum; a single VM has a limited SLA.
• Zone-redundant deployment — instances spread across zones behind a load balancer, with zone-redundant storage and a zone-redundant database. Protects against losing a datacentre, usually at little or no extra cost. This is the sensible default.
• Multi-region — active-passive with failover, or active-active with Front Door or Traffic Manager routing. Protects against losing an entire region, but roughly doubles cost and introduces genuinely hard data replication and consistency problems.

Note: Tie the choice to RTO and RPO rather than picking a tier. And say that a disaster recovery plan you have never tested is not a plan — failover drills are what make it real.

Azure Storage account services:

• Blob Storage — unstructured objects: images, backups, logs, video, data lake files. Tiered as Hot, Cool, Cold, and Archive, with progressively lower storage cost and higher access cost. Lifecycle policies move data between tiers automatically.
• File Storage — fully managed SMB and NFS shares. Its main use is lift-and-shift, where an application expects a mounted network drive.
• Queue Storage — simple message queuing for decoupling components. Service Bus is the richer alternative when you need ordering, sessions, or topics.
• Table Storage — a basic key-value NoSQL store; Cosmos DB is the modern successor.

Managed Disks are separate — block storage attached to virtual machines, in Standard HDD, Standard SSD, Premium SSD, and Ultra Disk tiers.

Databases are a different question again: Azure SQL Database for relational, Cosmos DB for globally distributed NoSQL, and managed PostgreSQL or MySQL where you want the open-source engine.

Note: Redundancy options are a likely follow-up. LRS keeps three copies in one datacentre, ZRS spreads them across availability zones, GRS replicates to the paired region, and GZRS combines both. The cost rises with each step, so match it to how bad losing the data would actually be.

Microsoft Entra ID — formerly Azure Active Directory — is a cloud identity and access management service. It is the authentication and authorisation layer for Azure, Microsoft 365, and thousands of SaaS applications.

The differences from on-premises Active Directory are fundamental, not cosmetic:

• Protocols. On-premises AD uses Kerberos and LDAP. Entra ID uses OAuth 2.0, OpenID Connect, and SAML — internet protocols designed for applications outside your network.
• Structure. AD has organisational units, domains, forests, and Group Policy. Entra ID is flat, with users, groups, and tenants, and no Group Policy.
• What it manages. AD manages domain-joined Windows machines. Entra ID manages access to applications and cloud resources across any platform.

They are complementary rather than alternatives. Most organisations run both, synchronised with Entra Connect so users have one identity across on-premises and cloud — hybrid identity.

Key capabilities to name: single sign-on, multi-factor authentication, Conditional Access for policy-based access decisions, Privileged Identity Management for just-in-time elevation, and managed identities for services.

Note: Do not confuse Entra ID roles, which control access to identity objects, with Azure RBAC roles, which control access to Azure resources. They are separate systems and the distinction is a favourite interview probe.

Azure Resource Manager (ARM) is the deployment and management layer. Every request — from the portal, CLI, PowerShell, or an SDK — goes through ARM, which handles authentication, RBAC, tagging, and dependency ordering. That is why access control and tagging work consistently regardless of the tool used.

The hierarchy: management group → subscription → resource group → resource. A resource group is a lifecycle boundary — resources deployed and deleted together belong in one.

Infrastructure as code means declaring that infrastructure in version-controlled files rather than clicking through the portal.

• Bicep — the current Microsoft-recommended language. A concise domain-specific language that compiles to ARM JSON, with modules, type safety, and no state file to manage.
• ARM templates — the original JSON format. Verbose and hard to read, but still what everything compiles to.
• Terraform — multi-cloud, with a large ecosystem and its own state file. Often chosen where an organisation is not Azure-only.

Why it matters: environments are reproducible, changes go through code review, drift is detectable, and rebuilding after a disaster becomes a pipeline run rather than an archaeology project.

Note: Deployment modes are a good detail — Incremental adds and updates without removing anything, while Complete deletes resources in the group that are not in the template. Running Complete unexpectedly is a memorable way to lose things.

Four ways to run application code, differing in abstraction level and control.

• App Service — managed hosting for web applications and APIs. You deploy code or a container; Azure handles the OS, patching, scaling, and load balancing. Deployment slots give you staged releases and swap-based rollback. Use it for a standard web application or API — it is the right default and people over-engineer past it constantly.
• Azure Functions — event-driven serverless. Code runs in response to a trigger — HTTP, a queue message, a timer, a blob upload — and on the Consumption plan you pay only for execution and scale to zero. Use it for intermittent, event-driven, short-lived work. Watch for cold starts on latency-sensitive paths.
• Container Apps — serverless containers built on Kubernetes and KEDA, without exposing Kubernetes. Scale to zero, revisions, traffic splitting, and Dapr integration. Use it for microservices and background workers where you want containers but not cluster management.
• AKS — managed Kubernetes. Maximum control and portability, and maximum operational burden: upgrades, node pools, networking, and monitoring are all yours.

How to choose: pick the highest level of abstraction that meets the requirement. AKS is justified by genuine need for Kubernetes-specific capability or an existing Kubernetes estate — not by a preference for containers.

Azure Monitor is the umbrella, collecting two kinds of telemetry: metrics (numeric, time-series, cheap, near real-time) and logs (structured records in a Log Analytics workspace, queried with KQL).

The components:

• Application Insights — application-level telemetry: requests, dependencies, exceptions, traces, and custom events. The end-to-end transaction view is what lets you see which downstream call made a request slow, and the application map shows the dependency topology.
• Log Analytics — the query engine. KQL across platform logs, application logs, and metrics together.
• Alerts — on metric thresholds, log query results, or activity log events, routed through action groups to email, SMS, webhooks, or a paging tool.
• Workbooks and dashboards for visualisation.
• Service Health — platform-side incidents affecting your resources. Always check this first.

Practices that matter: enable diagnostic settings on every resource so logs actually go somewhere; use a correlation id across services so one request is traceable end to end; log structured data rather than formatted strings; and set retention deliberately, because Log Analytics ingestion is a common surprise on the bill.

Note: Alert on symptoms users feel — error rate, latency, availability — rather than on causes like CPU. Alerting on CPU produces noise; alerting on failed requests produces action.

The shared responsibility model defines what the cloud provider secures and what remains yours. Misunderstanding it is a leading cause of cloud breaches, which is why it is asked so often.

Microsoft is always responsible for the physical datacentres, the physical network, and the physical hosts.

You are always responsible for your data, your endpoints, your accounts, and your access management — regardless of service model.

What shifts depends on the model:

• IaaS — you manage the operating system, patching, network configuration, applications, and identity. Microsoft manages the virtualisation layer down.
• PaaS — Microsoft manages the OS and runtime. You manage the application, its configuration, identity, and data.
• SaaS — Microsoft manages nearly everything except your data, users, and access policies.

The practical consequences worth stating:

• Azure guarantees infrastructure durability, but backup of your data is your responsibility. Accidentally deleting a database is not something the platform undoes for you.
• A storage account left publicly accessible is a customer misconfiguration, not a platform failure. Most cloud data exposures are of exactly this kind.
• Patching a virtual machine's operating system is yours under IaaS and Microsoft's under PaaS — which is itself a strong argument for PaaS.

Work outside in, applying defence in depth.

• Virtual networks and subnets. Segment by tier — web, application, data — with each in its own subnet so traffic between them can be controlled.
• Network Security Groups on subnets and network interfaces, allowing only required ports from required sources. Deny by default; the data subnet should accept traffic only from the application subnet, never from the internet.
• Private endpoints for PaaS services. This is the most important single measure: it gives Azure SQL, Storage, and Key Vault a private IP inside your virtual network and lets you disable public access entirely. Without it, those services are internet-reachable and protected only by credentials and firewall rules.
• A hub-and-spoke topology for anything beyond a small estate — shared services such as firewall, DNS, and gateways in the hub, workloads in peered spokes.
• Azure Firewall for centralised egress filtering, and Application Gateway with WAF for inbound HTTP, protecting against common web attacks. Front Door where you need global routing plus WAF and DDoS protection at the edge.
• Bastion for administrative access, so virtual machines need no public IP and RDP or SSH is never exposed.

Note: Add that you would enforce this with Azure Policy — denying public IPs on VMs and requiring private endpoints — rather than relying on reviewers to notice.

Azure Key Vault is a managed service for storing secrets, keys, and certificates, backed by hardware security modules on the Premium tier. It gives you centralised storage, access control through RBAC or access policies, full audit logging of every access, versioning, and expiry.

The three object types: secrets (connection strings, API keys, passwords), keys (cryptographic keys for encryption and signing, which can be used without ever being exported), and certificates (TLS certificates, with automatic renewal from integrated authorities).

How secrets should be handled — the priority order:

• Best: have no secret at all. Use a managed identity so your App Service or VM authenticates to SQL, Storage, or Key Vault itself with no credential stored anywhere. This eliminates the entire class of problem and is the answer interviewers are listening for.
• Where a secret is unavoidable — a third-party API key — store it in Key Vault and retrieve it at runtime using a managed identity. Never in code, configuration files, environment variables committed to a repository, or a container image.
• Rotate on a schedule, and make sure the application handles rotation without a restart. Event Grid can notify you on expiry.
• Least privilege — an application needs Get on the specific secrets it uses, not List on the whole vault.
• Enable soft delete and purge protection so a deleted vault or secret is recoverable.

Azure organises everything in a four-level hierarchy under a single Microsoft Entra tenant.

• Management groups — containers for subscriptions, nestable several levels deep under a single root management group. They exist to apply governance — Azure Policy and RBAC — to many subscriptions at once.
• Subscriptions — the billing and scale boundary. Each has its own invoice line, service quotas and access control. They are also a strong isolation boundary, which is why production and non-production usually live in separate subscriptions.
• Resource groups — logical containers for resources that share a lifecycle: deployed, managed and deleted together. A resource belongs to exactly one resource group, but the resources inside can be in different regions. The resource group’s own region only stores its metadata.
• Resources — the individual VMs, databases, storage accounts and so on.

Inheritance: RBAC role assignments and policy assignments flow downward. A Reader role assigned at a management group applies to every subscription, resource group and resource below it. A policy denying unapproved regions at the root management group affects the whole organisation. Lower levels cannot remove what is inherited — you can only add, or use policy exemptions. Resource locks also inherit downward.

A typical design, following Cloud Adoption Framework landing zones:

• Root → organisation management group → Platform (identity, management, connectivity subscriptions), Landing zones (split into corp and online), Sandbox and Decommissioned.
• One or more subscriptions per workload and environment.
• Resource groups per application component or lifecycle.

Tagging complements the hierarchy for cost allocation and ownership, because tags on a resource group are not inherited automatically — use Azure Policy to inherit or require them.

Note: Assign access at the highest scope that is correct and no higher. An Owner assignment at the root management group is effectively owner of everything.

Azure role-based access control grants access to Azure resources through role assignments. Each assignment combines three things:

• Security principal — who: a user, group, service principal or managed identity. Assign to groups rather than individuals.
• Role definition — what: a collection of permitted operations. Actions and NotActions cover the control plane (managing resources); DataActions and NotDataActions cover the data plane (reading blobs, sending messages).
• Scope — where: management group, subscription, resource group or single resource. Assignments inherit downward.

RBAC is additive: effective permissions are the union of all assignments. Deny assignments, created by the platform for features such as deployment stacks or managed applications, block actions even when a role allows them.

The key built-in roles:

• Owner — full management of resources and the ability to assign roles to others.
• Contributor — create and manage all resources, but cannot grant access to others.
• Reader — view resources only.
• User Access Administrator — manage role assignments without managing resources. The newer Role Based Access Control Administrator role can be restricted with conditions, for example to assign only specific roles.

Points interviewers probe:

• Control plane versus data plane: reading blob data through Entra ID needs a data role such as Storage Blob Data Reader. But a Contributor can list storage account keys, which effectively gives data access — one reason to disable shared-key access.
• Prefer narrow built-in roles such as Website Contributor or Key Vault Secrets User over broad ones, and create custom roles only when nothing built-in fits.
• Use PIM for privileged roles, so they are eligible and activated when needed rather than standing.

Note: Azure RBAC controls Azure resources. Entra ID roles such as Global Administrator control the directory itself — they are separate systems.

A managed identity is an identity in Microsoft Entra ID that Azure creates and manages for a resource. The resource can obtain tokens to call other services that support Entra authentication — Key Vault, Storage, Azure SQL, Service Bus — without any secret in code or configuration, and Azure rotates the underlying credentials automatically.

Two types:

• System-assigned
  • Enabled directly on a resource, such as a VM or App Service.
  • Tied to that resource’s lifecycle: deleted automatically when the resource is deleted.
  • One per resource, not shareable.
  • Best for a single resource with its own distinct permissions.
• User-assigned
  • A standalone Azure resource that you create and attach to one or more resources.
  • Survives when the resources using it are deleted.
  • Can be created and granted roles before the workload is deployed, avoiding a chicken-and-egg problem in infrastructure code.
  • Best for scale sets, multiple instances of the same app, or blue-green deployments that should share permissions.

How it works in code: the Azure SDK’s DefaultAzureCredential picks up the managed identity automatically in Azure and falls back to your developer login locally.

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

client = SecretClient(
    vault_url='https://kv-orders-prod.vault.azure.net',
    credential=DefaultAzureCredential())
secret = client.get_secret('db-password')

You then grant the identity an RBAC role on the target, such as Key Vault Secrets User on one vault.

Practical points: tokens are cached, so a new role assignment can take a little time to take effect. For workloads outside Azure — GitHub Actions, Kubernetes pods on AKS — use workload identity federation, which trusts an external OIDC token instead of a stored secret.

Note: The best credential is one nobody can leak. Using managed identities to connect to Azure SQL, and removing SQL passwords entirely, is a strong example to give.

Conditional Access is Entra ID’s policy engine for sign-ins. Each policy is essentially an if-then statement: if certain signals are present, then require certain controls — or block the sign-in. It is the core of a Zero Trust identity model and requires Entra ID P1 licensing, with risk-based conditions needing P2.

Signals (the “if”):

• User or group, including directory roles such as administrators.
• Target application — for example, the Azure management portal and APIs.
• Location — named locations such as office IP ranges or countries.
• Device platform and state — compliant with Intune, or hybrid joined.
• Sign-in risk and user risk from Entra ID Protection.
• Client app type, which lets you block legacy authentication.

Controls (the “then”): block access, require MFA or phishing-resistant authentication strength, require a compliant device, require an approved app, require a password change for risky users, and session controls such as sign-in frequency.

Common baseline policies:

• Require MFA for all users, with stronger methods for administrators.
• Block legacy authentication protocols that cannot do MFA.
• Require MFA for Azure management.
• Block or challenge high-risk sign-ins.

Rolling it out safely:

1. Start every new policy in report-only mode and review the sign-in logs to see who would be affected.
2. Always exclude two break-glass emergency accounts, secured separately and monitored, so a misconfigured policy cannot lock everyone out.
3. Pilot with a small group before applying to all users.
4. Use the What If tool to test specific scenarios.
5. Communicate with users, especially before enforcing MFA registration.

Note: For tenants without P1 licences, security defaults provide a free baseline of MFA and legacy-authentication blocking — but they are not customisable.

A network security group (NSG) filters traffic to and from Azure resources in a virtual network. It is stateful: if an inbound connection is allowed, the return traffic is allowed automatically.

Rules:

• Each rule has a priority (a number from 100 upwards), source, destination, port, protocol, direction and allow or deny action.
• Rules are processed in priority order, lowest number first, and processing stops at the first match. Leave gaps between priorities so you can insert rules later.

Default rules sit at the lowest priority and cannot be deleted, only overridden:

• Inbound: allow traffic within the virtual network, allow the Azure Load Balancer health probes, deny everything else.
• Outbound: allow traffic within the virtual network, allow internet, deny everything else.

Note that “virtual network” in the default rules includes peered networks and connected on-premises ranges, so it is broader than it sounds.

Association: an NSG can be attached to a subnet, a network interface, or both. When both exist, traffic must pass both — for inbound, the subnet NSG then the NIC NSG; for outbound, the reverse. Attaching at subnet level is simpler to manage.

Service tags are Microsoft-maintained groups of IP ranges, such as Internet, VirtualNetwork, AzureLoadBalancer or Storage.CentralIndia. They let you allow a service without tracking its changing IP addresses.

Application security groups (ASGs) group network interfaces by role — asg-web, asg-db — so rules read “allow asg-web to asg-db on 1433”. Adding a new VM to the right ASG applies the rules automatically, with no IP addresses in rules.

Troubleshooting: use effective security rules on a NIC and Network Watcher’s IP flow verify, and enable virtual network flow logs for visibility.

Note: NSGs filter by IP and port only. For FQDN filtering, threat intelligence or TLS inspection, route traffic through Azure Firewall.

VNet peering connects two virtual networks so resources communicate using private IP addresses over the Microsoft backbone, with low latency and no gateway in the path. It works within a region and across regions (global peering), and across subscriptions and tenants.

Key properties:

• Address spaces of peered VNets must not overlap.
• Peering is configured from both sides; each side has its own settings.
• Data transfer across a peering is charged, in both directions, and more for global peering.
• NSGs still apply, so peering alone does not mean everything can talk.

Why it is not transitive: if Spoke A peers with the Hub, and Spoke B peers with the Hub, A cannot reach B through the Hub by default. Each peering only exchanges routes for the two VNets involved. This is deliberate — connectivity is explicit, which keeps isolation predictable.

Getting spoke-to-spoke traffic in a hub-and-spoke design:

• Deploy Azure Firewall or a network virtual appliance in the hub, and add user-defined routes in each spoke that send other spokes’ traffic to the firewall. You gain inspection and logging as a bonus. Enable allow forwarded traffic on the peerings.
• Use Azure Virtual WAN, where the Microsoft-managed hub provides transitive routing.
• Use Azure Virtual Network Manager to create mesh or hub-and-spoke connectivity configurations across many VNets centrally.

Gateway transit: lets spokes use the hub’s VPN or ExpressRoute gateway to reach on-premises, instead of each spoke having its own gateway. Enable allow gateway transit on the hub side of the peering and use remote gateways on the spoke side. This saves cost and centralises hybrid connectivity.

Note: Plan the address space for the whole estate — hubs, spokes and on-premises — before building. Overlapping ranges cannot be peered, and re-addressing a live VNet is painful.

Both connect an on-premises network to Azure virtual networks. The difference is whether traffic crosses the public internet.

• VPN Gateway
  • Site-to-site IPsec/IKE tunnels over the internet between your on-premises VPN device and a gateway deployed in the VNet’s GatewaySubnet.
  • Point-to-site connections for individual users or devices, authenticated with certificates or Entra ID.
  • Quick to set up and inexpensive. The gateway SKU determines throughput and the number of tunnels.
  • Performance depends on the internet path, so latency and throughput vary.
  • Deploy it active-active and zone-redundant for resilience.
• ExpressRoute
  • A private connection through a connectivity provider at a peering location, or directly with ExpressRoute Direct. Traffic does not traverse the public internet.
  • Predictable latency, higher bandwidth options and an SLA-backed connection.
  • Private peering connects to your VNets through an ExpressRoute gateway; Microsoft peering reaches Microsoft public services such as Microsoft 365.
  • Not encrypted by default. Add MACsec on ExpressRoute Direct or run IPsec over ExpressRoute when encryption in transit is required.
  • Takes weeks to provision and costs more — circuit, provider and gateway charges.
  • Global Reach can link on-premises sites to each other through the Microsoft backbone.

How to choose: VPN for smaller or temporary workloads, branch offices, and fast starts. ExpressRoute for large data volumes, latency-sensitive applications, regulated industries, and when consistent performance matters.

Resilience pattern: a single circuit has a single peering location. Production designs use circuits in two peering locations, or pair ExpressRoute with a site-to-site VPN as a failover path — the routing prefers ExpressRoute while it is available.

Note: Both require a gateway in the hub VNet; with gateway transit, spokes reach on-premises through it without their own gateways.

Both let resources in a VNet reach Azure PaaS services such as Storage or Azure SQL without going over the public internet, but they work differently.

Service endpoints: you enable them on a subnet, then add a network rule on the service allowing that subnet. Simple and free, but the service keeps its public endpoint, and traffic could still reach other instances of the same service — a data-exfiltration concern.

Private endpoints: built on Azure Private Link. Because the endpoint maps to a single resource, you can then disable public network access on the service entirely. This is the preferred pattern for production and regulated workloads.

Why DNS is the critical part: applications still connect to the normal hostname, such as mystore.blob.core.windows.net. For traffic to use the private endpoint, that name must resolve to the private IP.

• Create the matching private DNS zone, for example privatelink.blob.core.windows.net, and link it to the VNets that need it — usually centrally in the hub.
• For on-premises clients, forward queries for those zones to Azure using Azure DNS Private Resolver.
• If DNS is wrong, clients resolve the public IP and are blocked by the firewall — the most common private endpoint failure.

Note: Use nslookup from inside the VNet to confirm the hostname returns a private address. It is the first diagnostic step for most private endpoint issues.

Azure’s load-balancing services differ on two axes: global or regional, and HTTP (layer 7) or any TCP/UDP (layer 4).

• Azure Front Door — a global entry point using Microsoft’s edge network and anycast. TLS termination near users, CDN caching, path-based routing, fast failover between regions, and an integrated web application firewall. The Premium tier can reach origins privately through Private Link.
• Application Gateway — a regional layer-7 load balancer that lives inside your VNet. Path and host-based routing, TLS termination and end-to-end TLS, cookie-based affinity, autoscaling and WAF. Good for internal web apps or as the regional tier behind Front Door. For AKS, Application Gateway for Containers is the newer ingress option.
• Azure Load Balancer — regional layer 4 for any TCP or UDP traffic, very high throughput and low latency. Public or internal, zone-redundant on the Standard SKU, and supports HA ports for network virtual appliances. It does not understand HTTP.
• Traffic Manager — DNS-based global routing with priority, weighted, performance and geographic methods. Works for any protocol because it only answers DNS queries, but failover speed depends on DNS TTLs and client caching.

A simple decision path: is it HTTP? If yes and global, Front Door; if yes and regional or internal, Application Gateway. If not HTTP, use Load Balancer regionally, and Traffic Manager in front if you need global distribution.

Note: These services combine. A common pattern is Front Door globally with a WAF, then Application Gateway or an internal load balancer in each region.

Every Azure subnet gets system routes automatically: traffic within the VNet and to peered VNets is routed directly, and 0.0.0.0/0 goes to the internet. User-defined routes (UDRs) in a route table override those defaults for the subnets the table is associated with.

How Azure chooses a route: longest prefix match wins. If prefixes are equal, a user-defined route takes precedence over a BGP route, which takes precedence over a system route.

Forcing traffic through Azure Firewall:

1. Deploy Azure Firewall in the hub VNet in a subnet named AzureFirewallSubnet.
2. Create a route table for each spoke with:
   • 0.0.0.0/0 → next hop virtual appliance at the firewall’s private IP, so internet-bound traffic is inspected.
   • Routes for other spokes’ address ranges, or the whole private range, to the same next hop, so spoke-to-spoke traffic passes through the firewall.
3. Associate the route tables with the workload subnets and enable allow forwarded traffic on the peerings.
4. For traffic from on-premises, add a route table on the GatewaySubnet sending spoke ranges to the firewall, so both directions follow the same path.
5. Define rules in a Firewall Policy: network rules, application rules with FQDN filtering, and DNAT for inbound publishing.

Pitfalls:

• Asymmetric routing — if the request goes through the firewall but the response does not, the stateful firewall drops it.
• Some PaaS services and platform traffic need specific routes or exceptions.
• Do not disable BGP route propagation on spokes without replacing the routes they need.

Troubleshooting: view effective routes on a VM’s network interface and use Network Watcher’s next hop tool.

Note: Azure Firewall Premium adds TLS inspection and IDPS. Azure Firewall Manager or Virtual WAN secured hubs can centralise policies across many hubs.

A Virtual Machine Scale Set (VMSS) manages a group of load-balanced VMs as one unit, adding and removing instances automatically. It is Azure’s equivalent of an AWS Auto Scaling group.

Orchestration modes:

• Flexible — the recommended mode for new deployments. Instances are standard VMs you can manage individually, sizes can be mixed, and Spot and regular VMs can be combined.
• Uniform — identical instances built from one model, the older mode, still common for large stateless fleets.

Autoscaling:

• Metric-based rules — for example, add two instances when average CPU exceeds 70% for ten minutes, remove one when below 30%. Scale-in should be more conservative than scale-out to avoid flapping.
• Schedule-based profiles — higher minimums during business hours.
• Predictive autoscale — forecasts cyclical load and scales ahead of it.
• Set sensible minimum and maximum counts, and a scale-in policy deciding which instances are removed first.

Upgrades:

• Upgrade policy — manual, automatic, or rolling, which updates batches of instances while respecting health.
• Automatic OS image upgrades keep instances patched with the latest image version.
• Build images with Azure Image Builder and store versions in an Azure Compute Gallery.

Resilience:

• Spread instances across availability zones to survive a datacentre failure. Within a zone or region, fault domains separate instances across racks.
• Use the Application Health extension or load-balancer health probes so the platform knows when the application — not just the VM — is unhealthy.
• Enable automatic instance repairs to replace instances that stay unhealthy.

Note: Keep instances stateless — sessions in Redis, files in Storage, data in a database — so any instance can be removed during scale-in or repair without losing anything.

Managed disks are block storage volumes for Azure VMs, managed by the platform. The types differ in performance, latency and cost.

• Standard HDD — cheapest, highest latency. Backups, rarely accessed data, and non-critical development machines.
• Standard SSD — consistent performance at low cost. Web servers, lightly used applications, and development and test.
• Premium SSD — high performance with low latency for production workloads and databases. Performance is tied to disk size, so you sometimes provision a bigger disk just to get more IOPS; bursting helps with short spikes.
• Premium SSD v2 — IOPS, throughput and capacity are configured independently, which is often more cost-effective for databases because you no longer over-provision capacity to get performance.
• Ultra Disk — the highest IOPS and throughput with sub-millisecond latency, adjustable without downtime. For demanding databases such as SAP HANA or top-tier SQL Server.

How to choose:

1. Measure the workload’s IOPS, throughput and latency needs rather than guessing.
2. Check the VM size limits — each VM size caps total disk IOPS and throughput. A fast disk on a small VM will be throttled by the VM, a very common performance mistake.
3. Use host caching wisely: read-only caching suits read-heavy data disks; transaction log disks usually use none.
4. For stateless scale-set instances, consider ephemeral OS disks, which live on local VM storage for faster boot and no storage cost, but lose data on reimage.

Resilience and security:

• Disks can be locally redundant or zone-redundant, which keeps copies across availability zones.
• All disks are encrypted at rest with platform-managed keys by default; use a disk encryption set for customer-managed keys, and encryption at host to cover temporary disks and caches.
• Protect data with snapshots and Azure Backup.

Note: Unattached disks keep billing after a VM is deleted. Finding orphaned disks is an easy cost-saving win in most subscriptions.

An App Service plan is the compute that hosts your web apps: a set of VM instances of a given size and pricing tier. Every app in a plan runs on all of that plan’s instances and shares their CPU and memory — so one noisy app can slow the others, and the plan, not the app, is what you pay for.

Tiers, broadly:

• Free and Shared — for testing only; no SLA and shared infrastructure.
• Basic — dedicated instances but limited features, fine for development.
• Standard and Premium — production tiers with autoscale, deployment slots, backups and VNet integration. Premium v3 offers better price-performance and zone redundancy.
• Isolated — runs in an App Service Environment inside your VNet, for strict isolation or very large scale.

Scaling:

• Scale up — change to a bigger size or higher tier for more CPU, memory or features.
• Scale out — add instances, either with autoscale rules based on metrics and schedules, or with the platform’s automatic scaling on Premium tiers.

Deployment slots: live apps with their own hostnames, such as a staging slot. Deploy to staging, warm it up and test it, then swap with production. The swap is near-instant, and swapping back is an easy rollback. Mark environment-specific settings as slot settings so they stay with the slot rather than moving during the swap.

Networking:

• VNet integration handles outbound traffic — the app can reach databases or APIs on private IPs in your VNet or on-premises.
• Private endpoints handle inbound traffic — making the app reachable only on a private IP. Access restrictions can limit public inbound traffic by IP or service tag.

Production settings worth mentioning: Always On to avoid the app idling out, a health-check path so unhealthy instances are removed, and managed identities for connecting to other services.

Note: Group apps into plans by scaling needs and criticality. Putting a busy production API in the same plan as internal tools is a common cause of mysterious slowdowns.

Azure Functions runs event-driven code without managing servers. The hosting plan controls scaling, cold starts, networking and cost.

• Flex Consumption — the current recommended serverless plan. Scales to zero and bills per execution, but adds VNet integration, configurable instance memory and optional always-ready instances to reduce cold starts.
• Consumption — the original serverless plan. Pay per execution, scales to zero, with cold starts after idle periods and a limited maximum execution time.
• Premium (Elastic Premium) — pre-warmed instances that eliminate cold starts, VNet integration, more powerful instances and longer execution times. You pay for a minimum number of instances even when idle.
• Dedicated — runs on an App Service plan you already pay for. Predictable cost, no scale-to-zero, useful when spare capacity exists.
• Functions can also be hosted in Azure Container Apps alongside other containerised microservices.

Triggers and bindings are what make Functions productive:

• Trigger — the event that starts the function. Each function has exactly one: HTTP request, timer (CRON schedule), Storage queue message, Service Bus message, Event Hubs event, Event Grid event, Blob change or Cosmos DB change feed.
• Input bindings — declaratively read data, such as a Cosmos DB document by ID, passed into the function as a parameter.
• Output bindings — declaratively write data, such as returning a value that is written to a queue or table.

Bindings remove boilerplate connection code, and when combined with identity-based connections they need no connection strings.

Design considerations:

• Keep functions short and stateless; for long-running or multi-step workflows use Durable Functions.
• HTTP-triggered functions must respond within the platform’s request timeout, so queue long work and return quickly.
• Make queue-triggered functions idempotent, because messages can be delivered more than once.
• Use Application Insights for monitoring and managed identities for access.

Note: Choosing a plan is a trade-off between cold-start latency, networking needs and idle cost. Explain that trade-off rather than naming one plan as always best.

Durable Functions is an extension of Azure Functions for writing stateful, long-running workflows in code. The framework checkpoints progress to storage, so a workflow can run for minutes or months, survive restarts, and scale out without you managing state.

Function types:

• Orchestrator functions — define the workflow: which activities to call, in what order, with what error handling.
• Activity functions — do the actual work, such as calling an API or writing to a database.
• Entity functions — small, durable stateful objects, such as a counter or a per-device state.
• Client functions — start, query or signal orchestrations, often from an HTTP trigger.

How it works: orchestrators use event sourcing and replay. Each time an orchestrator wakes, it replays its history to rebuild state, skipping activities that already completed. This means orchestrator code must be deterministic: no direct I/O, no random numbers, no reading the current time directly — use the context’s time and call activities for anything non-deterministic.

Patterns it supports:

• Function chaining — run steps in sequence, passing output along.
• Fan-out/fan-in — run many activities in parallel and aggregate the results.
• Async HTTP APIs — return a status URL immediately and let clients poll for the result of long work.
• Monitor — a flexible recurring loop, such as polling until a job completes.
• Human interaction — wait for an external event such as an approval, with a timeout and escalation.
• Aggregator — collect events into a stateful entity over time.

def orchestrator(context: df.DurableOrchestrationContext):
    files = yield context.call_activity('ListFiles', None)
    tasks = [context.call_activity('ProcessFile', f) for f in files]
    results = yield context.task_all(tasks)
    yield context.call_activity('WriteSummary', results)

When to use something else: for low-code integration workflows with many connectors, Logic Apps may be a better fit.

Note: Breaking the determinism rule is the most common Durable Functions bug. Interviewers often ask why an orchestrator should not call DateTime.Now or an HTTP API directly.

Azure Kubernetes Service (AKS) is managed Kubernetes. Microsoft runs the control plane — API server, etcd, scheduler — and you manage the worker nodes and workloads. The control plane is free on the Free tier; the Standard tier adds a financially backed uptime SLA for production.

Node pools:

• Nodes run in VM scale sets, grouped into node pools of one VM size.
• A system node pool hosts critical add-ons such as CoreDNS; user node pools host applications. Separate pools allow different VM sizes, GPUs, Spot nodes or Windows nodes.
• Spread pools across availability zones for resilience.

Networking options:

• Azure CNI Overlay — pods get IPs from a private overlay range, conserving VNet address space. The usual default for new clusters, as kubenet is being retired.
• Azure CNI with VNet IPs — pods get addresses directly from the subnet, reachable without NAT but consuming many IPs.
• Azure CNI powered by Cilium — eBPF-based data plane with network policy and better performance.
• Ingress through the application routing add-on, Application Gateway for Containers, or your own controller.

Identity and security:

• Entra ID integration for cluster access, with Kubernetes RBAC or Azure RBAC for authorisation. Disable local accounts.
• Microsoft Entra Workload ID lets pods use a managed identity through federated service-account tokens, so no secrets are needed to reach Key Vault or Storage.
• Grant the kubelet identity pull access to Azure Container Registry, and use the Key Vault CSI driver for secrets.
• Consider a private cluster so the API server has no public endpoint.

Scaling:

• Horizontal Pod Autoscaler scales pods on metrics; KEDA scales on events such as queue length, including to zero.
• Cluster autoscaler or node auto-provisioning adds nodes when pods cannot be scheduled.

Operations: Kubernetes versions have a limited support window, so plan upgrades with auto-upgrade channels, maintenance windows and PodDisruptionBudgets. Monitor with Container Insights and managed Prometheus and Grafana.

Note: AKS is powerful but operationally demanding. Mention when Container Apps would be the simpler choice.

Azure Storage always keeps multiple copies of your data. The redundancy option decides where those copies live and so which failures you survive.

Read-access variants — RA-GRS and RA-GZRS — expose a secondary endpoint you can read from at any time, not just after failover. Applications can fall back to reading from the secondary during a primary outage.

Important details:

• Replication to the secondary is asynchronous, so a regional failover can lose the most recent writes. The Last Sync Time property shows how far behind the secondary is.
• Without read access, the secondary is not usable until a failover is initiated. Customer-managed failover makes the secondary the new primary, after which the account is no longer geo-redundant until you reconfigure it.
• ZRS writes are synchronous across zones, so a zone failure loses no acknowledged data.
• Not every storage type and tier supports every option — check before designing around one.

How to choose:

• LRS — data you can recreate, dev/test, or where data must stay in one location.
• ZRS — the sensible default for production in a region with zones: high availability with no data loss on a zone failure.
• GZRS or RA-GZRS — critical data needing both zone resilience and a regional DR copy.

Note: Redundancy is not backup. A deleted or ransomware-encrypted blob is faithfully replicated everywhere, so also enable soft delete, versioning and point-in-time restore.

Blob Storage access tiers trade a lower storage price against higher access charges and, in some cases, minimum retention periods. Choose by how often data is read.

• Hot — highest storage cost, lowest access cost. Data in active use, such as images served by a website.
• Cool — lower storage cost, higher access cost, and an early deletion charge if removed within a minimum period. For short-term backups and data accessed occasionally.
• Cold — cheaper still, with a longer minimum period. For data rarely accessed but still needed online, instantly.
• Archive — the cheapest storage, but offline. Blobs must be rehydrated to an online tier before they can be read, which can take hours at standard priority; high priority is faster and more expensive. The longest minimum period applies. For compliance records and long-term retention.

The account has a default tier (hot or cool), and individual blobs can be set to any tier.

Lifecycle management policies automate tier changes and deletion with rules that run daily:

• Move blobs to Cool 30 days after last modification, to Cold after 90, to Archive after 180.
• With last access time tracking enabled, tier based on when a blob was last read rather than modified — and move it back to Hot automatically when accessed again.
• Delete temporary data, logs or exports after a set age.
• Clean up old blob versions and snapshots, which otherwise accumulate silently.
• Filter rules by container prefix or blob index tags so different datasets follow different policies.

Watch the trade-offs:

• Moving data too early can cost more — early deletion fees and higher read charges can outweigh storage savings for data that is still accessed.
• Archive retrieval time must fit your recovery requirements.
• Tier changes themselves are billed operations, which matters with millions of small blobs.

Note: Analyse access patterns first — storage metrics or blob inventory reports — then design lifecycle rules. Guessing usually leads to paying retrieval charges on data that was not as cold as assumed.

Storage accounts support several authorisation methods of very different strength. The goal is to move from shared secrets towards identity-based access, and to lock down the network path.

Authorisation methods, weakest to strongest:

• Account keys — two keys that give full access to everything in the account. Like a root password: hard to audit and dangerous if leaked. If used, store them in Key Vault and rotate them. Better still, disable shared-key authorisation entirely.
• Shared access signatures (SAS) — signed URLs granting limited permissions for a limited time.
  • Account SAS and service SAS are signed with an account key, so they inherit its risks. A service SAS can be tied to a stored access policy so you can revoke it.
  • User delegation SAS is signed with Microsoft Entra credentials, is scoped to the permissions of that identity, and is the recommended type.
  • Keep expiry short, grant minimum permissions, and require HTTPS.
• Microsoft Entra ID with RBAC — the preferred method. Applications use managed identities; users and groups get data roles such as Storage Blob Data Reader or Storage Blob Data Contributor, scoped to a container where possible. Every access is tied to an identity and auditable.

Network controls:

• Disable anonymous public blob access unless genuinely needed for public content.
• Use the storage firewall to allow only selected VNets or IP ranges, or disable public network access and use private endpoints.
• Require secure transfer (HTTPS) and a minimum TLS version.

Data protection and monitoring:

• Enable soft delete, versioning and, for regulated data, immutable storage policies.
• Send resource logs to Log Analytics and enable Microsoft Defender for Storage to detect unusual access or malware uploads.
• Use Azure Policy to enforce these settings across all accounts.

Note: Remember that a Contributor on the account can list the keys. Disabling shared-key access closes that back door and forces everything through Entra ID.

Azure offers SQL Server at three levels of management, from fully managed PaaS to full control on IaaS.

• Azure SQL Database — a fully managed database with the latest engine features, built-in high availability, automatic backups with point-in-time restore, and automatic patching.
  • Single database — one database with its own resources.
  • Elastic pool — many databases sharing a pool of resources, ideal for multi-tenant SaaS where each tenant’s database is busy at different times.
  • Service tiers: General Purpose for most workloads, Business Critical for low latency with local SSD storage and readable replicas, and Hyperscale for very large databases with fast scaling and rapid restores.
  • The serverless compute tier auto-scales and can auto-pause when idle, billing per second — good for intermittent workloads.
• Azure SQL Managed Instance — a managed SQL Server instance deployed inside your VNet with near-complete compatibility with on-premises SQL Server: SQL Agent jobs, cross-database queries, CLR, Database Mail and linked servers. The best target for lift-and-shift migrations of applications that rely on instance-level features, without managing an operating system.
• SQL Server on Azure VMs — full control over the OS and SQL Server version, for features not available in PaaS, third-party software on the same server, or specific version requirements. You own patching, backups and high availability, although the SQL IaaS Agent extension automates some of it.

Purchasing models: the vCore model lets you choose compute and storage separately and apply Azure Hybrid Benefit for existing SQL Server licences. The older DTU model bundles resources into simple tiers.

How to choose: new cloud applications — SQL Database. Migrating an existing application that uses instance-level features — Managed Instance. Needs OS access or unsupported features — a VM. Azure Migrate and the Data Migration Assistant can assess compatibility before you decide.

Note: For regional resilience, mention auto-failover groups, which replicate databases to another region and provide listener endpoints that stay the same after failover.

The decision comes down to the shape of your data and your access patterns, not which service is more modern.

Choose Azure SQL when:

• Data is naturally relational — orders, customers, invoices — with integrity constraints.
• You need ad-hoc queries, joins and reporting.
• Transactions span many entities, as in financial or ERP systems.
• The team knows SQL and the scale fits a single primary.

Choose Cosmos DB when:

• You need low, predictable latency at very high scale, for example user profiles, product catalogues, IoT telemetry or gaming state.
• Users are spread globally and need local reads, or writes, in several regions.
• The schema evolves frequently or varies between items.
• Access patterns are known and mostly key-based, so a good partition key can be chosen.
• You want to migrate a MongoDB or Cassandra workload using compatible APIs.

Common trade-offs: Cosmos DB punishes poorly designed partition keys and cross-partition queries with high request-unit cost. Azure SQL is more forgiving of unknown query patterns but harder to scale writes horizontally.

Note: Many systems use both — Azure SQL for transactional records and Cosmos DB for a high-traffic read model, kept in sync through the change feed or events.

These three concepts determine Cosmos DB’s performance, cost and correctness, and interviewers ask about all of them.

Partitioning:

• Every container has a partition key. Items with the same key value form a logical partition; Cosmos DB spreads logical partitions across physical partitions and splits them as data and throughput grow.
• A good key has high cardinality, spreads reads and writes evenly, and appears in the filter of most queries — for example userId or tenantId, not country or status.
• A single logical partition has a size limit, so avoid keys where one value grows without bound. Hierarchical partition keys, such as tenant then user, help large multi-tenant designs.
• Queries that include the partition key go to one partition; cross-partition queries fan out and cost far more.
• The partition key cannot be changed after creation without migrating data.

Request units (RUs):

• A normalised measure of the CPU, memory and I/O an operation uses. A point read of a small item by ID and partition key is the cheapest operation; queries, writes and indexing cost more.
• Throughput is provisioned (manual or autoscale) at container or database level, or billed per request on serverless.
• Exceeding throughput returns HTTP 429 with a retry-after hint; the SDKs retry automatically. Sustained 429s mean a hot partition or under-provisioning.
• Tune the indexing policy to exclude unused paths and reduce write cost.

Consistency levels, strongest to weakest:

1. Strong — reads always see the latest committed write.
2. Bounded staleness — reads lag by at most a set number of versions or time.
3. Session — the default; a client always reads its own writes, in order.
4. Consistent prefix — reads never see writes out of order.
5. Eventual — no ordering guarantee; lowest latency and cost.

Stronger levels increase latency and RU cost, and have restrictions with multi-region writes.

Note: Session consistency suits most user-facing applications — users see their own changes immediately without paying for strong consistency globally.

All three move information between systems, but they are built for different kinds of information: messages, discrete events and event streams.

• Service Bus — enterprise messaging where each message has business value and must not be lost. Queues for point-to-point work, topics and subscriptions with filters for publish-subscribe. Features: dead-letter queues, sessions for ordered processing, duplicate detection, scheduled delivery, and transactions.
• Event Grid — lightweight reactive routing. Azure services publish events such as “blob created” or “resource deleted”, and Event Grid pushes them to Functions, Logic Apps, webhooks or queues, with filtering on type and subject. Supports custom topics, the CloudEvents schema, and MQTT messaging.
• Event Hubs — a big-data ingestion service handling millions of events per second. Data is written to partitions; each consumer group reads independently and can replay from any offset. Supports the Apache Kafka protocol, and Capture writes the stream to Storage or Data Lake automatically.

How to choose:

• Must this unit of work be processed exactly once, reliably, possibly in order? — Service Bus.
• Do you just need to react when something changes? — Event Grid.
• Is it a continuous high-volume stream you will analyse, possibly more than once? — Event Hubs.

Note: They combine well — Event Grid can route a blob-created event into a Service Bus queue for reliable processing, and Event Hubs can feed Stream Analytics or Fabric for real-time analytics.

Azure Monitor collects two kinds of data: metrics (numeric time series, collected automatically) and logs (detailed records). Most log data does not flow anywhere until you configure it, and that is where these pieces come in.

Diagnostic settings:

• Platform resource logs — for example Key Vault access, SQL query waits, Application Gateway access and firewall logs — are not stored unless you create a diagnostic setting. This surprises many teams during their first incident.
• A diagnostic setting sends chosen log categories and metrics to one or more destinations: a Log Analytics workspace for querying, a Storage account for cheap long-term archive, or Event Hubs to stream to a third-party SIEM.
• Enforce them at scale with Azure Policy using the DeployIfNotExists effect.
• The subscription Activity Log, which records control-plane operations, should also be exported this way.
• For VMs, the Azure Monitor Agent with data collection rules gathers guest OS logs and performance counters.

Log Analytics workspace design:

• Fewer, centralised workspaces make cross-resource queries easy; resource-context and table-level RBAC keep teams seeing only their own data.
• Control cost with retention settings, long-term archive, cheaper table plans for high-volume verbose logs, and commitment tiers for large ingestion.
• Application Insights stores its telemetry in a workspace too, so application and infrastructure data can be correlated.

KQL (Kusto Query Language) is how you query the workspace. Queries start from a table and chain operators with the pipe symbol, typically: filter with where on TimeGenerated using ago(1h), aggregate with summarize count() by a column, compute bins over time with bin(TimeGenerated, 5m), sort with order by, and visualise with render timechart. Joins and extend let you correlate and derive fields.

Turning it into action: log search alerts run KQL on a schedule, metric alerts react quickly to thresholds, and action groups notify people or trigger automation. Workbooks and dashboards visualise the same queries.

Note: Being able to write a short KQL query live — failed requests grouped by operation over the last hour — is a practical skill interviewers increasingly test.

Bicep is Azure’s domain-specific language for infrastructure as code; it compiles to ARM templates. Good structure keeps one set of templates that deploys safely to every environment.

Modules: split infrastructure into reusable files — networking, App Service, SQL, Key Vault — each with parameters and outputs. A main.bicep composes them:

param env string
param location string = resourceGroup().location

module app 'modules/appservice.bicep' = {
  name: 'app-${env}'
  params: {
    name: 'orders-${env}'
    location: location
    skuName: env == 'prod' ? 'P1v3' : 'B1'
  }
}

• Share modules across teams through a Bicep registry in Azure Container Registry, or start from Azure Verified Modules, which follow Microsoft’s best practices.
• Use outputs to pass values such as resource IDs between modules, and the existing keyword to reference resources you do not deploy.

Parameters per environment:

• One .bicepparam file per environment — dev, test, prod — with SKUs, instance counts and names.
• Decorators such as @allowed, @minLength and @description validate input.
• Mark sensitive parameters with @secure(), and reference Key Vault secrets rather than storing values in files.

What-if previews: az deployment group what-if shows which resources will be created, modified or deleted before anything changes. In a pipeline, publish the what-if output on the pull request and require approval for production.

A typical pipeline: bicep build and the linter on every commit, deploy to dev automatically, what-if plus approval for production, and authentication through workload identity federation rather than stored secrets.

Managing lifecycle: the default incremental mode never deletes resources missing from a template. Deployment stacks track what a deployment owns, can delete or detach removed resources, and can apply deny settings to prevent manual changes.

Note: Keep naming conventions and tags in shared variables or a module, so every environment is consistent and cost reporting works from day one.

Azure Policy evaluates resource properties against rules to enforce standards and report compliance. Where RBAC controls who can act, Policy controls what state resources are allowed to be in.

Policy definition: a JSON rule with an if condition on resource properties, exposed through aliases, and a then effect.

Main effects:

• Deny — blocks non-compliant create or update requests. Example: disallow public IPs in production.
• Audit — allows the request but marks the resource non-compliant. Ideal for measuring impact before enforcing.
• AuditIfNotExists — flags a resource when a related resource is missing, such as a VM without an antimalware extension.
• DeployIfNotExists — deploys the missing related resource, such as diagnostic settings or a backup configuration.
• Modify — adds, changes or removes properties or tags during creation or update, such as inheriting a cost-centre tag from the resource group.
• Append — adds fields to a request, an older effect largely superseded by Modify.
• DenyAction — blocks specific actions, such as deleting critical resources.
• Disabled — turns the policy off, handy when a parameter controls the effect.

Initiatives group many definitions into one unit, such as the Microsoft cloud security benchmark or a regulatory standard, so they can be assigned and tracked together.

Assignments apply a definition or initiative at a scope — management group, subscription or resource group — with parameters and exclusions. Exemptions waive specific resources, ideally with an expiry date and a reason.

Remediation: Deny, Modify and DeployIfNotExists act on new and updated resources. For existing non-compliant resources, create a remediation task. DeployIfNotExists and Modify assignments need a managed identity with the right roles to make changes.

A safe rollout: assign in Audit mode, review the compliance dashboard, clean up, then switch to Deny. Manage definitions and assignments as code.

Note: Compliance results are not instant — evaluation runs on changes and periodically — so do not assume a new assignment immediately reflects the true state.

Azure offers several ways to pay less than pay-as-you-go rates. The right mix depends on how predictable and how interruptible each workload is.

• Pay-as-you-go — per-second or per-hour billing with no commitment. Right for new, variable or short-lived workloads.
• Azure Reservations — commit to a specific resource type in a region, such as a VM series, for one or three years in exchange for a large discount. Instance size flexibility lets a reservation apply across sizes in the same series. Reservations also exist for Azure SQL, Cosmos DB, App Service and other services. Best for stable workloads that will not change region or family.
• Azure savings plan for compute — commit to a fixed hourly spend for one or three years. The discount is usually smaller than a reservation’s, but applies flexibly across VM sizes, regions and other eligible compute services, such as premium App Service and Azure Functions plans. Best when the estate is steady in total but changing in shape.
• Spot VMs — unused capacity at deep discounts, which Azure can evict when it needs the capacity back or when the price exceeds your maximum, with only a short notice through Scheduled Events. Right for batch processing, rendering, CI agents and stateless scale-set instances.
• Azure Hybrid Benefit — reuse existing Windows Server and SQL Server licences with Software Assurance, or qualifying subscriptions, to avoid paying for the licence component. Often a large saving for Windows and SQL workloads.
• Dev/Test pricing — discounted rates for non-production subscriptions under eligible agreements.

Before committing:

1. Right-size using Azure Advisor recommendations and actual utilisation.
2. Shut down non-production outside working hours with auto-shutdown or automation.
3. Then cover the steady baseline with reservations or a savings plan, leaving peaks on pay-as-you-go.

Governance: track utilisation of reservations in Cost Management, set budgets with alerts per subscription, and enable cost anomaly alerts.

Note: Reservations and savings plans are billing discounts only — they do not reserve capacity. Use on-demand capacity reservations if guaranteed capacity is the actual requirement.

They solve different problems, and a complete plan usually needs both. Azure Backup protects against data loss; Azure Site Recovery (ASR) protects against downtime.

• Azure Backup
  • Takes point-in-time copies of data so you can restore to an earlier state after deletion, corruption or ransomware.
  • Covers Azure VMs, managed disks, Azure Files, Blob Storage, SQL Server and SAP HANA in VMs, PostgreSQL, AKS and on-premises servers.
  • Backups live in a Recovery Services vault or Backup vault, governed by policies defining frequency and retention — daily, weekly, monthly and yearly.
  • Security features: soft delete, immutable vaults, and multi-user authorisation so a single compromised admin cannot delete backups.
  • Geo-redundant vaults with cross-region restore allow recovery in the paired region.
  • Recovery point objective is typically hours, set by backup frequency.
• Azure Site Recovery
  • Continuously replicates VMs to another Azure region, or from on-premises VMware, Hyper-V or physical servers to Azure.
  • On failover, VMs start in the target region from recent recovery points. RPO is typically minutes, and RTO depends on your recovery plan.
  • Recovery plans orchestrate failover order — database tier first, then application, then web — with scripts or runbooks for steps such as DNS changes.
  • Test failover into an isolated network lets you rehearse without affecting production.
  • After the incident, you fail back.

Why you need both: replication copies corruption and ransomware to the DR site within minutes. Backups give clean, older restore points. ASR gets you running quickly; Backup gets your data back.

Also consider native options: PaaS services often have their own mechanisms — auto-failover groups for Azure SQL, multi-region Cosmos DB, GZRS storage — which are simpler than ASR for those tiers.

Note: Define RTO and RPO per workload with the business, then pick the mechanism. And schedule regular test failovers and restore tests — an untested recovery is only a hope.

Both are Microsoft guidance frameworks, but they operate at different levels: the Well-Architected Framework (WAF) is about designing a good workload; the Cloud Adoption Framework (CAF) is about how an organisation adopts the cloud.

Well-Architected Framework — five pillars:

1. Reliability — resilience and recovery: availability zones, redundancy, health probes, retries, tested disaster recovery aligned to RTO and RPO.
2. Security — Zero Trust principles: identity as the perimeter, least privilege, encryption, network segmentation, and threat detection.
3. Cost Optimization — spending on what delivers value: right-sizing, reservations and savings plans, scaling to demand, and cost visibility through tagging.
4. Operational Excellence — DevOps practices: infrastructure as code, safe deployment practices, observability and incident management.
5. Performance Efficiency — scaling to meet demand efficiently: choosing the right services, caching, load testing and capacity planning.

Tools include the Well-Architected Review assessment, Azure Advisor recommendations grouped by pillar, and service guides explaining how each Azure service maps to the pillars. The pillars involve trade-offs — for example, multi-region reliability increases cost and operational complexity.

Cloud Adoption Framework: guidance for the organisation’s cloud journey, organised into phases such as Strategy, Plan, Ready, Adopt, Govern, Secure and Manage. Its most practical output is the Azure landing zone — a reference architecture for management groups, subscriptions, identity, networking, policy and monitoring, deployable through accelerators — so every workload lands in a well-governed environment.

How they connect: CAF builds the platform — the landing zones, governance and operating model. WAF guides each application team designing workloads inside those landing zones.

Note: In an interview, relate a pillar to a real decision you made — for instance, choosing zone redundancy over multi-region after weighing reliability against cost — rather than simply listing the pillars.

They cover different parts of cloud security operations. Defender for Cloud hardens and protects your resources; Microsoft Sentinel is where security teams detect, investigate and respond across the whole estate.

Microsoft Defender for Cloud — a cloud-native application protection platform with two main roles:

• Security posture management (CSPM) — continuously assesses resources against the Microsoft cloud security benchmark and other standards, producing a secure score and prioritised recommendations, such as enabling MFA, closing management ports or encrypting storage. The paid Defender CSPM plan adds attack path analysis and a cloud security graph. It also assesses AWS and GCP accounts.
• Workload protection — Defender plans for specific resource types: Servers (endpoint detection and vulnerability assessment), Storage (malware scanning and suspicious access), SQL, Containers (image scanning and runtime threats), Key Vault, App Service and Resource Manager. They raise security alerts when threats are detected.
• A regulatory compliance dashboard maps controls to standards such as ISO 27001 or PCI DSS.

Microsoft Sentinel — a cloud-native SIEM and SOAR built on Log Analytics:

• Data connectors ingest logs from Entra ID, Microsoft 365, Defender products, Azure activity, firewalls, other clouds and on-premises systems.
• Analytics rules written in KQL correlate signals and create incidents.
• Hunting queries let analysts search proactively; UEBA spots anomalous user behaviour.
• Playbooks built on Logic Apps automate response — disabling a user, isolating a VM or opening a ticket.
• Increasingly used through the unified Microsoft Defender portal alongside Defender XDR.

Working together: Defender for Cloud reduces the attack surface and produces alerts; those alerts flow into Sentinel, where they are correlated with identity, network and endpoint signals to form a full incident picture and trigger automated response.

Note: Sentinel cost is driven by data ingestion. Choosing which logs to ingest, and using cheaper log tiers for high-volume sources, is a key design decision.