Serverless and Azure Functions Interview Questions for .NET Developers

Q1 Explain the .NET isolated worker model for Azure Functions. Why did it replace the in-process model, and what do you actually gain?#

Short answer: The isolated worker model runs your function code in its own process, separate from the Azure Functions host, communicating over gRPC, instead of loading your assemblies directly into the host's process the way the in-process model did — which removes the constraint that your app's dependencies had to be binary-compatible with whatever versions the host itself referenced, gives you full control over Program.cs, startup and middleware the way an ordinary ASP.NET Core application does, and lets you target current .NET releases rather than being pinned to whichever version the host runtime shipped with.

The in-process model loaded your compiled assembly directly into the same process as the Functions host runtime, which meant a transitive dependency version conflict between your app and the host was a real, recurring failure mode — upgrading an unrelated NuGet package could break your function in ways that had nothing to do with your own code. The isolated worker model fixes this with a genuine process boundary: the worker owns its entire dependency graph independently, dependency injection and middleware work like a normal .NET application — standard HostBuilder, ordinary IServiceCollection registration, no function-host-flavored container — and middleware genuinely wraps the invocation pipeline the way ASP.NET Core middleware wraps a request, which the in-process model never properly supported. The trade-off is a small added latency per invocation from gRPC serialization between the host and worker process, compared to in-process's direct in-memory call, which matters for extremely latency-sensitive workloads but is negligible for the overwhelming majority of function workloads. Because the in-process model doesn't track new .NET feature releases going forward, the isolated worker model is effectively mandatory for any new Azure Functions project now, not a stylistic preference.

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.AddSingleton<IOrderRepository, OrderRepository>();
    })
    .Build();

host.Run();

What interviewers look for: a correct process-boundary explanation, not just "it's the newer option," and specific gains — DI/middleware parity with ASP.NET Core, version independence from the host — rather than vague modernization language.

Common mistakes: describing the isolated worker model as a configuration flag rather than a genuine process and architecture change with real dependency injection and middleware implications.

Q2 What causes a cold start in Azure Functions, and how do you actually mitigate it for a .NET workload, beyond "just use Premium"?#

Short answer: A cold start is the latency of provisioning a brand-new worker instance from nothing — pulling the runtime, loading your assembly, running static initializers and JIT-compiling the code paths the first request touches — and it's worst on plans that scale to zero, so mitigation really breaks into three separate levers: reduce how much work the app does at startup, reduce how often a request actually hits a cold instance with pre-warmed capacity, and reduce per-request JIT cost with ReadyToRun or ahead-of-time compilation.

At the application level, keep static constructors and DI registration lean, avoid real synchronous I/O during startup — a config fetch or a warm-up query that could instead happen lazily on first use — and be deliberate about how many assemblies load eagerly, since every additional assembly is more code to JIT before the first request completes. At the instance-availability level, always-ready instances (Premium's pre-warmed workers, or Flex Consumption's optional always-ready setting, which defaults to zero) keep a warm worker sitting idle specifically so a request never waits for provisioning, at the direct cost of paying for that idle capacity continuously. At the JIT level, publishing with ReadyToRun precompiles most method bodies the runtime would otherwise JIT on first use, which measurably shrinks cold start time without Native AOT's compatibility trade-offs, while Native AOT-published functions (supported for the isolated worker model) start dramatically faster still, at the cost of losing the runtime reflection some libraries depend on. The framing that separates a strong answer: cold start severity is trigger-dependent, not universal — an HTTP-triggered function facing real user latency needs it solved aggressively, while a queue-triggered background job that only needs to finish within a few extra seconds of the message arriving often doesn't justify any mitigation investment at all, so the first question is always whether this trigger's latency actually matters to anyone, not how to eliminate cold starts everywhere uniformly.

What interviewers look for: the three distinct levers — startup work, instance availability, JIT cost — rather than a single reflexive "enable Premium," plus the trigger-dependent framing that not every cold start is worth paying to eliminate.

Follow-up questions:

• How would you measure whether ReadyToRun publishing actually helped your specific workload?
• What's the trade-off of moving a workload to Native AOT specifically to cut cold starts?

Q3 Walk through the core Durable Functions application patterns and when you'd reach for each one.#

Short answer: Function chaining runs a sequence of activities where each one's output feeds the next, replacing a hand-rolled pipeline of queues; fan-out/fan-in dispatches many activities in parallel and waits for all of them before continuing, replacing manual completion-counting; the async HTTP API pattern wraps a long-running orchestration behind a status-polling endpoint the runtime manages for you; and human interaction patterns pause an orchestration on an external event — an approval, a timeout — using durable timers and event correlation instead of a polling loop.

Function chaining is the simplest and most common: a document processing pipeline (extract, validate, transform, store) where each stage's failure should halt the pipeline and each stage's state should survive a process restart, a guarantee an ordinary sequential await chain in a non-durable function can't give you once host recycling mid-execution is a real possibility. Fan-out/fan-in is the pattern for "process N independent items, then aggregate" — calling Task.WhenAll on a list of activity calls inside the orchestrator — and its real value over a hand-rolled parallel dispatch is that the orchestration's progress is itself durable, so a host restart mid-fan-out resumes from where it left off instead of losing track of what already completed. The async HTTP API pattern matters for anything client-facing that takes longer than an HTTP request should reasonably block for: the client starts the orchestration, gets back a status-check URL, and polls it, with the Durable Functions extension providing that status-tracking endpoint automatically instead of requiring a hand-built job-status table. Human interaction combines a durable timer with WaitForExternalEvent via Task.WhenAny, so an orchestration can wait for "whichever comes first — approval or a 48-hour timeout" without polling anything or holding a thread open, which is the detail that makes Durable Functions genuinely different from a naive polling-based workflow engine.

What interviewers look for: each pattern mapped to a concrete scenario with a reason it beats the hand-rolled alternative, not pattern names recited from documentation.

Common mistakes: describing fan-out/fan-in without mentioning that durability is what makes it resilient to a host restart mid-fan-out, which is the actual reason to reach for Durable Functions instead of a plain Task.WhenAll.

Q4 Why must Durable Functions orchestrator code be deterministic, and what actually happens if you call DateTime.Now or make an HTTP call directly inside an orchestrator?#

Short answer: The Durable Task Framework implements orchestration state through event sourcing — it replays the orchestrator function's code from the beginning every time it resumes after an await, reconstructing state by feeding the historical sequence of completed events back through the same code path — so any non-deterministic operation (the current time, a random number, a direct network call, a new GUID) produces a different result on replay than it did originally, which desynchronizes the orchestrator from its own history and causes subtle, hard-to-diagnose state corruption rather than a clean, loud error.

Every time an orchestrator awaits an activity call or a durable timer, the framework can unload it from memory entirely for scale and efficiency, and when the awaited work completes, it doesn't resume mid-function the way a normal async continuation would — it re-runs the orchestrator function from the top, replaying every previously recorded event (completed activity results, elapsed timers, external events already received) so the code arrives back at the same logical point with the same state, then continues past it. If the orchestrator called DateTime.Now directly, replay produces a different value than the original run did, and any branching logic based on that value can diverge between the original execution and the replay — the orchestration doesn't crash, it silently takes a different path than it took the first time, which is far more dangerous than an exception would be. The fix is using the context-provided deterministic equivalents for everything non-deterministic: context.CurrentUtcDateTime instead of DateTime.UtcNow, context.NewGuid() instead of Guid.NewGuid(), and — critically — any real I/O has to happen inside an activity function, never directly in the orchestrator, because activity results are exactly what gets recorded in history and replayed deterministically; the orchestrator's job is to sequence work, never to do work itself.

[Function(nameof(ApprovalOrchestrator))]
public static async Task RunOrchestrator([OrchestrationTrigger] TaskOrchestrationContext context)
{
    // Correct: context.CurrentUtcDateTime is deterministic on replay; DateTime.UtcNow is not.
    var deadline = context.CurrentUtcDateTime.AddHours(48);

    var approvalTask = context.WaitForExternalEvent<bool>("Approval");
    var timeoutTask = context.CreateTimer(deadline, CancellationToken.None);
    var winner = await Task.WhenAny(approvalTask, timeoutTask);

    // Real I/O happens inside an activity, never directly in the orchestrator.
    await context.CallActivityAsync(nameof(NotifyRequesterActivity), winner == approvalTask);
}

What interviewers look for: the replay mechanism explained accurately as event-sourced re-execution from the top, not a resumed continuation, plus the correct, specific list of what has to move into activity functions or context APIs.

Common mistakes: believing replay "resumes" the orchestrator mid-function like a normal async continuation, rather than understanding it re-executes the function from the beginning against recorded history.

Q5 Compare how each Azure Functions hosting plan actually scales, and name the limit most likely to surprise a team under real load.#

Short answer: Consumption scales event-driven from zero up to a per-platform ceiling (200 instances on Windows, 100 on Linux) and is being succeeded by Flex Consumption, which raises that ceiling to 1,000 instances and scales per function rather than per app; Premium adds pre-warmed instances and a smaller, VM-backed ceiling (roughly 100 on Windows, 20 to 100 on Linux depending on region) for workloads that need to avoid cold starts or need VNet integration without moving to Flex; and the surprise that catches teams most often isn't the instance ceiling at all — it's that scale-out is driven by the trigger's own backlog signal, not CPU or memory, so a function that's individually slow but has a shallow backlog may never scale out as aggressively as its latency would suggest it should.

The scale controller (Consumption and Premium) or the per-function scaling logic (Flex) monitors trigger-specific signals — queue length and age for Storage Queues, partition lag for Event Hubs, message count for Service Bus — and decides how many instances to add, which means a function's own execution time isn't the primary scaling signal; a function that takes ten seconds per invocation but only receives one message at a time never scales beyond one or two instances no matter how slow it looks in isolation, because there's no backlog for the controller to react to. Flex Consumption's per-function scaling, contrasted with Consumption and Premium's per-app scaling, matters when one function in an app is disproportionately busier than its siblings — Flex scales that one function's instances independently instead of scaling the whole app together, avoiding over-provisioning quieter functions just because a noisy neighbor in the same app needs more capacity. The ceiling most teams actually hit in practice isn't the platform's instance maximum at all — it's a downstream dependency's own connection or throughput limit, well before Azure Functions itself runs out of room to scale, which is why scaling has to be reasoned about across the whole call chain, not the Functions app in isolation.

What interviewers look for: trigger-driven, not CPU-driven, scaling explained correctly, Flex's per-function scaling contrasted with per-app scaling, and awareness that the real bottleneck is usually a downstream dependency, not the platform's own ceiling.

Follow-up questions:

• How would you diagnose whether a scaling problem is Functions-side or caused by a downstream dependency?
• Why might per-function scaling in Flex Consumption change how you group functions into apps?

Q6 Why does an Azure Function have to be written idempotently, and how do you implement that for a queue-triggered function that writes to a database?#

Short answer: Most Azure Functions triggers — Storage Queues, Service Bus, Event Hubs — guarantee at-least-once delivery, not exactly-once, so any transient failure after a message is dequeued but before processing fully completes results in the same message being delivered again; that idempotency requirement has to be satisfied in the function's own logic, typically by making the database write naturally idempotent (an upsert keyed on a business identifier) or by explicitly tracking which message IDs have already been fully processed and short-circuiting on a repeat.

The mechanism that causes duplicates isn't exotic: a Storage Queue message becomes invisible for a configured visibility timeout when dequeued, and is only deleted after the function completes successfully; if the function crashes, times out, or the host scales in mid-processing, no delete happens, and the message becomes visible again for another instance to pick up, having potentially already done partial work on the first attempt. The cleanest fix, where the domain allows it, is making the operation itself idempotent rather than trying to prevent redelivery: an upsert keyed on the order ID instead of a plain insert, or a message-processing table with a unique constraint on the message ID that a duplicate insert simply violates and gets caught. Where the operation can't be made naturally idempotent — sending an email, calling a non-idempotent external API — you need an explicit idempotency record: persist the message ID in the same transaction as the side effect, and check for it before performing the side effect at all, the same discipline behind the transactional outbox pattern discussed in depth in CAP, consistency and idempotency. The detail that separates a strong answer here: the idempotency check has to be enforced atomically with the side effect it's guarding — checking "have I seen this ID" and then writing as two separate, non-transactional steps reintroduces the exact race condition idempotency was supposed to close.

[Function(nameof(ProcessOrderPaid))]
public async Task Run([ServiceBusTrigger("orders-paid")] ServiceBusReceivedMessage message,
    OrdersDbContext db, CancellationToken cancellationToken)
{
    var messageId = message.MessageId;
    if (await db.ProcessedMessages.AnyAsync(m => m.Id == messageId, cancellationToken))
    {
        return; // already handled this exact delivery
    }

    db.ProcessedMessages.Add(new ProcessedMessage { Id = messageId });
    await ApplyPaymentAsync(message, db, cancellationToken);
    await db.SaveChangesAsync(cancellationToken); // both writes commit together, or neither does
}

What interviewers look for: the at-least-once delivery mechanism explained specifically (visibility timeout, redelivery on failure), and an idempotency implementation that closes the check-then-write race, not just "we check if we've seen the ID before."

Common mistakes: checking for a duplicate message ID and writing the side effect as two separate, non-atomic operations, leaving the exact race window idempotency was meant to eliminate.

Q7 When is Azure Functions the wrong choice, even for a workload that's technically "event-driven"?#

Short answer: Serverless stops being the right choice when a workload needs to run longer than the platform's execution model comfortably supports without significant orchestration overhead to work around it, when it needs continuously low, predictable latency that pre-warming can't affordably guarantee, when sustained steady-state throughput is high and constant enough that dedicated or reserved compute is simply cheaper than pay-per-execution pricing, or when the team needs OS-level or runtime-level control the platform doesn't expose.

Long-running work is the most common mismatch: while Durable Functions orchestrations can span days through the chaining and timer patterns already covered, that's a real architectural investment, not a free upgrade, so a workload that's fundamentally "run this multi-hour batch job" is often simpler and cheaper as a scheduled container than as a Durable Functions orchestration built specifically to work around the execution model's limits. Latency-critical, always-hot workloads are a second mismatch: even with Premium or Flex Consumption's always-ready instances, you're paying to keep capacity warm continuously — at that point you've re-created a dedicated compute cost model without the operational simplicity dedicated compute, such as App Service, Container Apps or AKS, actually gives you, so it's worth asking honestly whether always-ready serverless is actually cheaper or simpler than a small dedicated deployment. High, constant, predictable throughput is the clearest cost argument: consumption-based pricing is optimized for variable or bursty load, and a workload running at flat, high volume around the clock usually costs less on reserved or dedicated compute than on a per-execution model, sometimes by a wide margin. Anything needing a specific OS-level dependency, a tightly shared in-memory cache across requests, or fine-grained runtime control fights the platform's stateless-by-design execution model rather than working with it.

What interviewers look for: specific, named failure categories — long-running work, always-hot latency needs, high steady throughput, runtime control — rather than a vague "serverless isn't for everything," plus honest cost reasoning rather than platform loyalty.

Common mistakes: defaulting to a Durable Functions orchestration to work around the execution model for a workload that would be simpler and cheaper as a scheduled container job.

Q8 What problem does the Flex Consumption plan solve relative to classic Consumption, and what are its actual scaling and instance-sizing specifics?#

Short answer: Flex Consumption keeps Consumption's pay-per-execution pricing but removes its biggest production limitations — no VNet integration, coarse per-app rather than per-function scaling, and cold starts with no way to pre-warm — by adding native virtual network support, per-function scaling decisions, and an optional always-ready instance count (zero by default) that pre-warms capacity specifically for the functions that need it; it offers three fixed instance memory sizes (512 MB, 2,048 MB and 4,096 MB, with 2,048 MB as the recommended default for most workloads), scales up to 1,000 instances, and runs on Linux only.

Consumption's biggest production gaps were always the same three complaints: you couldn't put it in a VNet without moving to Premium, the whole app scaled together even when only one function was actually busy, and there was no way to pay for pre-warmed capacity to soften cold starts short of committing to Premium's continuous billing model. Flex addresses all three while keeping consumption-based billing — VNet integration is native, scaling decisions are made per function rather than per app so a noisy function doesn't force capacity onto its quiet siblings, and always-ready instances let you pre-warm a specific baseline while everything above it still scales elastically and bills per execution. The instance-size choice is a real sizing decision, not just a knob: 512 MB fits small, low-memory functions cheaply, 2,048 MB covers most general-purpose workloads, and 4,096 MB is for memory-intensive processing, and because the memory tier also determines the CPU allocated alongside it, undersizing shows up as CPU-constrained latency even when the function isn't obviously memory-bound. Zone-redundant deployments have their own floor worth knowing precisely — a minimum of two always-ready instances per function group — which changes the baseline cost calculation for a team that assumed always-ready instances could stay at zero while still being zone-redundant.

What interviewers look for: the specific numbers — 1,000 max instances, three memory tiers, zero default always-ready, Linux-only — stated correctly and tied to the concrete problems they solve, not a vague "Flex Consumption is the newer, better plan."

Common mistakes: assuming Flex Consumption is a strict superset of Premium's capabilities rather than a different point on the trade-off curve — Premium's continuous billing model still fits workloads that want guaranteed capacity without any consumption-based variability at all.

Q9 You need to change the logic inside a Durable Functions orchestrator that has instances currently in flight in production. What's actually at risk, and how do you deploy the change safely?#

Short answer: Because replay re-executes the orchestrator function's code from the top against recorded history, changing that code's logic — adding, removing or reordering awaited calls — changes what replay produces for any instance still mid-flight when the new code deploys, since the new code's shape no longer lines up with the old history it's being replayed against; the safe approach is versioning orchestrations explicitly — routing new instances to a new orchestrator function name or version identifier and letting old instances finish on the old code path — never editing an in-place orchestrator's logic and assuming in-flight instances will simply adapt.

Concretely: if an in-flight instance's history recorded "activity A completed, then activity B was called," and the new orchestrator code now calls activity C between A and B, replay reconstructs state by matching recorded history events to the sequence of awaits in the current code — and a mismatch doesn't fail cleanly, it can throw a non-deterministic-orchestration error or, worse, silently produce corrupted state, depending on exactly how the history diverges from what the new code expects. The practical mitigation that avoids the whole problem: treat orchestrator functions as effectively immutable once any instance might be in flight against them, ship logic changes as a new orchestrator — a new function name, or an explicit version discriminator threaded through the orchestration's identity — so brand-new instances start on the new logic while existing in-flight instances keep replaying against the code version that matches their recorded history, and retire the old version only once the instance query APIs confirm nothing is still running against it. This is the same operational discipline as a database's expand/contract pattern applied to workflow logic instead of schema — add a new path alongside the old one and drain it, rather than mutating the thing in-flight state depends on — which mirrors the safe-rollout reasoning behind CI/CD and deployment strategy more broadly.

What interviewers look for: the specific mechanism — replay matching recorded history against the current code's await sequence — and a concrete versioning strategy, not just "be careful with orchestrator changes."

Follow-up questions:

• How would you detect, before a deploy, whether a code change is safe for in-flight instances or not?
• What Durable Functions API would you use to confirm no instances are still running against an old orchestrator version before retiring it?

Q10 An Azure Function that calls a SQL database starts throwing timeouts under load that it didn't throw in testing. Walk through how you'd diagnose it.#

Short answer: The prime suspect for this exact symptom — fine in testing, fails specifically under production scale-out — is database connection pool exhaustion: every scaled-out function instance maintains its own connection pool, so a function that scaled from a handful of instances in testing to dozens in production can multiply its total open-connection count far beyond the database's own connection limit, and the fix is almost never "add more database compute" — it's reducing per-instance connection footprint and adding resilience around transient exhaustion.

The diagnostic sequence: first confirm it's actually connection exhaustion and not something else by checking the database's active connection count against its limit during the failure window, correlated against the Function app's instance count over the same window — if connections scale linearly with instances and hit the ceiling right when timeouts start, that's the smoking gun. The fix set, in the order I'd apply it: confirm the function is actually reusing a singleton or scoped DbContext/connection factory rather than constructing a new connection per invocation inside the function body, a surprisingly common mistake that multiplies the problem directly; add Polly-based retry with backoff and jitter for transient SQL timeout and throttling exceptions specifically, since a momentarily saturated database needs callers to back off, not hammer it harder; and if the function's own concurrency — host.json's maxConcurrentCalls for a Service Bus trigger, or the batch size for a queue trigger — is set far above what the downstream database can actually sustain, throttling that concurrency down is often more effective than scaling the database up, because it addresses the actual bottleneck instead of paying to move it. For the underlying architecture problem this symptom points at, a connection-pool-per-instance model doesn't scale indefinitely against a single relational database; a workload that needs to scale to hundreds of instances against one database is a strong candidate for a queue-based leveling layer or a connection-pooling proxy in front of it, not indefinite host.json tuning.

{
  "extensions": {
    "serviceBus": {
      "maxConcurrentCalls": 8
    }
  }
}

What interviewers look for: connection pool exhaustion named as the primary suspect for this specific symptom pattern, a real diagnostic step (correlating connection count against instance count) before jumping to fixes, and resilience and concurrency limits named alongside the structural fix.

Common mistakes: responding to database timeouts under load by scaling up the database first, without checking whether the actual bottleneck is connection count driven by function fan-out.