Microsoft Azure interview questions

Azure App Service natively supports hosting web apps on both Windows and Linux. macOS and ChromeOS are not supported operating systems for App Service.

This is a foundational Azure VM design question. A correct answer selects a general-purpose VM family, chooses an appropriate managed disk type, and describes VNet + NSG for network access control.

This question tests understanding of Azure Availability Sets as a basic resiliency feature. The rubric rewards justified feature selection (why Availability Sets fit this scenario), a concrete explanation of the fault-domain/update-domain mechanism including the two-VM requirement, and a limitation analysis that names both the root cause and the escalation path with its trade-off.

As of the current major version of Azure App Service, Basic and Standard are active pricing tiers available for new App Service Plans. The Free (F1) and Shared (D1) tiers are legacy/retired and no longer available for new plans in most regions. There is no 'Community' tier in Azure App Service. Other current tiers include Premium (Pv2, Pv3) and Isolated (I1, I2, I3).

App Service is Azure's platform-as-a-service for web apps and APIs: Azure manages the underlying OS, patching, and runtime, and provides built-in features like autoscale, deployment slots for staged rollouts, and easy custom-domain/TLS setup, so the team deploys code rather than managing infrastructure. A VM is infrastructure-as-a-service — full OS control, but the team owns patching, scaling, and everything else, which only pays off when the workload needs OS-level customization App Service can't provide (a specific kernel module, unusual networking, legacy software). Cost isn't a blanket win either way — it depends on utilization and plan tier. The claim that App Service gives full root/administrator access has it backwards: a VM gives full OS access, App Service deliberately does not (that's the tradeoff for not managing it).

Blob Storage's access tiers trade storage cost against access cost and latency: Hot is for frequently-accessed data (highest storage cost, cheapest/fastest reads); Cool and Cold sit in between, for data accessed less often but still available online immediately, each with a minimum retention period before early-deletion fees kick in; Archive is offline — the cheapest storage of all, but a blob has to be explicitly rehydrated (typically hours of latency) before it can be read. Rarely-accessed compliance logs with an 'hours is fine' retrieval SLA are the textbook Archive use case: you're paying to store data you almost never touch, so minimizing storage cost dominates, and Archive's rehydration delay is an acceptable tradeoff for that access pattern.

True. ARM templates (JSON) and Bicep (a more concise DSL that compiles down to the same ARM JSON) both describe what the infrastructure should look like — which resources should exist and how they're configured — and Azure Resource Manager figures out how to get there: creating what's missing, updating what's changed, and leaving unchanged resources alone. This is the opposite of an imperative script that issues a fixed sequence of az CLI commands; the declarative model is what makes deployments idempotent — re-running the same template against infrastructure that already matches it is a safe no-op.

This distinction trips people up because Bicep looks like a different tool; in practice it's ARM JSON with better ergonomics (less boilerplate, real modules, type checking), compiled down before Resource Manager ever sees it.

Adding more instances is horizontal scaling, universally called 'scaling out' in Azure documentation. Increasing the size (SKU) of an existing instance is 'scaling up' or vertical scaling.

Azure Virtual Machine Scale Sets (VMSS) is the service purpose-built for managing a fleet of identical VMs with built-in autoscale support, enabling horizontal scaling based on metrics or schedules.

The cooldown period prevents rapid, cascading scale actions by enforcing a wait time between consecutive autoscale operations, giving the system time to stabilize before the next scaling decision.

This tests applied knowledge of the two most common hosting plans. Consumption is the default serverless model billed per execution and subject to cold starts; Premium pre-warms instances to eliminate cold starts, adds VNet integration, and still auto-scales but at a higher cost.

The Consumption plan is Azure Functions' pure serverless tier: you're billed per execution and per GB-second of memory used, and instances scale to zero when there's no traffic — which is exactly what makes it cheap for spiky or infrequent workloads. The cost of that model is 'cold start': the first request after an idle period has to provision a new instance and load the function app/runtime before it can execute, adding latency that a warm instance wouldn't have. The Premium plan exists specifically to remove this by keeping a configurable number of pre-warmed instances always ready, at a fixed baseline cost — the tradeoff every 'which Functions plan' interview question is really testing.

PaaS trades control for managed convenience: you lose OS-level access (you give up low-level OS access (no admin/root shell, can't install arbitrary system-level software) in exchange for not managing it) but gain built-in autoscale, deployment slots, and automatic patching/runtime updates (you gain built-in autoscale and deployment slots without writing your own scaling/rollout automation, Azure handles OS-level patching and runtime updates for you) without building that automation yourself — that's the actual value proposition. The claim that you gain full control over the OS patch schedule, so you can defer security patches indefinitely is backwards: giving up OS control means you can't defer OS patches at all, since Azure controls that schedule, not you. The claim that App Service workloads are exempt from the shared responsibility model — Microsoft is solely responsible for application-level security misdescribes the shared responsibility model, which still applies to PaaS — Microsoft secures the underlying platform/OS, but the customer remains responsible for their application code, configuration, secrets, and data; no Azure service model removes the customer's side of that split.

True. NSGs track connection state: once inbound traffic is allowed by a rule, the return traffic for that same established connection is automatically permitted, regardless of what the outbound rules say. This mirrors how stateful firewalls (and AWS security groups) behave, and it's frequently the point of confusion for someone used to a stateless model — they add an inbound-allow rule, assume they also need a matching outbound-allow rule for replies, and end up with unnecessary or overly broad outbound rules. Outbound rules only matter for genuinely new outbound-initiated connections, not for replies to already-permitted inbound traffic.

A hardcoded connection string with a plaintext password checked into source control is a real, common security finding: it lands permanently in git history (rotating the password later doesn't remove it from history), it's visible to anyone with repo read access — often a much wider group than anyone who should know the production DB password — and it can't be rotated without a code change and redeploy. The fix is to store the secret in Azure Key Vault and have the App Service retrieve it at runtime via a managed identity (no credentials embedded anywhere) — either directly through the Key Vault SDK, or via a Key Vault reference in App Service's application settings, which resolves the secret automatically without the app code ever seeing a raw connection string in source.

This tests whether a candidate understands Azure networking as layered concerns rather than one blob of 'networking config': the VNet is addressing/isolation, the subnet is segmentation within that address space, and the NSG is the actual access-control layer. A strong answer names all three and states what each one specifically controls, since conflating an NSG with a VNet (a very common beginner mistake) leads to wrong assumptions about where security rules actually apply.

The mechanism matters more than the vocabulary: scaling up changes the resources of a single instance (bounded by the largest SKU, no availability benefit); scaling out adds instances (elastic via autoscale, and improves availability since load isn't on one box). A senior-leaning answer states the default preference for scaling out under variable/peak load and names the tradeoff — cost efficiency and elasticity versus scaling up's simplicity and its fit for genuinely per-request-resource-bound workloads.

The what-if step is what makes a declarative IaC deployment safe to run against real infrastructure: because Resource Manager reconciles the template against current state rather than running a blind script, --what-if can show exactly what will change — including deletions, which are easy to introduce by accident (e.g. removing a resource block) and expensive to discover after the fact. Skipping straight from authoring to az deployment group create means the first time you see the actual diff is after it's already applied. Verifying afterward closes the loop — confirming the deployed state matches what what-if predicted, catching any drift or deployment-time failures the CLI's exit code alone might not surface clearly.

publicAccess: 'Container' sets anonymous read access at the container level — anyone with the URL (or who enumerates it) can list and read every blob inside with no authentication, which for user-uploaded photos likely means personal data exposed to the entire internet. This exact misconfiguration (an accidentally-public storage container) is one of the most common real-world cloud data exposure incidents. allowBlobPublicAccess: true on the storage account (line 4) only permits public access to be configured at the container/blob level — it doesn't grant it by itself, but it's what makes line 11's setting possible, so tightening it to false at the account level (when public access genuinely isn't needed anywhere in that account) is defense in depth. The correct fix here is publicAccess: 'None' and serving photos through authenticated access — a SAS token, or a CDN/App Service layer that enforces auth — instead of a bare public container.

In the in-process model the user code loaded into the same process as the Functions host, tightly coupling the app's .NET version to the host's runtime. The isolated worker model (GA in .NET 5, required for .NET 8+) moves user code into a separate process; the host and worker exchange binding metadata and invocation requests over gRPC channels with protobuf messages. This decouples runtime versions, improves resilience (a worker crash does not crash the host), and aligns .NET Functions with the cross-language worker architecture already used by Node, Python, and Java.

Ephemeral OS disks are stored on the local SSD attached to the physical host running the VM, so their size is bounded by that host-local storage. Two constraints gate their use: (1) the VM size must be in the list of sizes that support ephemeral OS disks, and (2) the cache size (or temp-disk size for VM families that map ephemeral storage to the temp disk instead of the cache) must be greater than or equal to the OS disk size specified in the VM profile. If either constraint is violated, Azure rejects the deployment. This is a depth question because it tests understanding of the host-local storage model rather than the default Azure Storage-backed model.

The described behavior is the inverse of how slot swaps actually work. During a swap, the app content and all non-sticky configuration settings (application settings and connection strings not marked as 'slot setting') are swapped between the two slots. Settings that ARE marked as 'slot setting' (sticky) remain attached to their original slot and are not swapped. This design allows environment-specific configuration (e.g., a production database connection string) to stay bound to the production slot while code and shared settings move freely between slots during a swap.

A cold start begins when a request hits the front end and there is no warm instance to serve it. The Functions scale controller — the external monitoring service for the Consumption/Elastic Premium plans — detects this and provisions a new compute instance. Once the instance is allocated, the Azure Functions host (the runtime) starts on it. The host then spins up the appropriate language worker process (e.g., dotnet, node, python) which loads and JIT/interprets the function application's code. Only after all of that is the function method actually invoked and its response returned to the caller. The four-step preamble before execution is what makes cold-start latency significantly higher than warm-invocation latency.

The Functions host binding pipeline follows a strict order. First, the trigger fires — whether it is an HTTP request, a timer tick, a queue message, or an event — and the host extracts the trigger payload and associated binding data. Second, the host resolves any input bindings (e.g., Cosmos DB, Blob storage lookups) by fetching their data from the respective sources before the function method is called, so the data is available as method parameters. Third, the function method is invoked with both the trigger data and the resolved input binding parameters. Fourth, the function method body executes and returns. Fifth, and only after the method returns, the host processes output bindings — writing the function's return value or out parameters to destinations such as queues, tables, or HTTP responses. Output bindings never fire if the function throws an unhandled exception, confirming they are post-execution.