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.

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.