Java / Azure Functions Interview questions

Azure Functions is Microsoft's serverless, event-driven compute service. You write a small piece of code, called a function, and Azure runs it when an event occurs, such as an HTTP request, a timer tick, or a new message in a queue.

You don't provision or patch servers. Azure allocates instances, scales them with the incoming load, and on the Consumption and Flex Consumption plans bills you for execution rather than idle capacity. Functions can be written in C#, JavaScript, TypeScript, Python, Java, PowerShell, and other languages through custom handlers.

Typical uses include lightweight APIs, webhooks, scheduled jobs, queue and event processing, and file handling when a blob is uploaded.

A trigger defines how a function is invoked. It listens to an event source, and when the event occurs it starts the function and passes the event payload in as a parameter.

Every function has exactly one trigger. If you need to react to two different sources, you write two functions. Common triggers are HTTP, Timer, Blob, Queue, Service Bus, Event Hubs, Event Grid, and Cosmos DB.

The trigger type also decides how the function scales, because the platform watches that source (queue depth, partition lag, request rate) to add or remove instances.

Bindings are a declarative way to connect a function to other services without writing the connection code yourself. You describe the resource, and the runtime reads from it or writes to it for you.

An input binding pulls data in (for example, a Cosmos DB document or a blob). An output binding sends data out (for example, adding a message to a queue). A trigger is a special kind of input binding that also starts the function.

Bindings are optional. A function needs a trigger, but you can skip bindings and use an SDK client directly when you need more control.

Azure Functions can run on five hosting options. They differ mainly in scaling behaviour, cold start, networking features, and how you are billed.

Most new serverless workloads should evaluate Flex Consumption first, then Premium if they need other capabilities.

A function app is the deployment and management unit for Azure Functions. It is the container that hosts one or more individual functions.

All functions in an app share the same hosting plan, runtime version, app settings, and deployment. On Consumption and Premium plans they also scale together as one unit. Flex Consumption is the exception, since it scales some trigger groups (HTTP, Durable, Blob via Event Grid) independently.

Group related functions that change and scale together in one app. Put functions with very different load profiles or language stacks in separate apps.

Azure Functions ships with triggers for most Azure services. These are the ones that come up most in practice:

Kafka, SignalR, RabbitMQ, and SQL triggers are also available through extensions.

Add a method with the HttpTrigger attribute on its first parameter. The attribute sets the authorization level and the allowed HTTP methods. This is a C# isolated worker example with ASP.NET Core integration:

[Function("Hello")]
public IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req)
{
    string name = req.Query["name"];
    return new OkObjectResult($"Hello, {name ?? "world"}");
}

You can scaffold the same thing with func new --template "HTTP trigger". One limit to remember: an HTTP response must start within 230 seconds on every plan, because of the Azure load balancer idle timeout. Longer jobs should return 202 Accepted and finish in the background.

The Timer trigger runs a function on a schedule. The schedule is an NCRONTAB expression with six fields: {second} {minute} {hour} {day} {month} {day-of-week}.

Times are in UTC unless you set the WEBSITE_TIME_ZONE app setting. You can also store the expression in an app setting and refer to it as %MY_SCHEDULE% so it can change without redeploying.

Azure Functions has first-class support for C# and F# (.NET), JavaScript, TypeScript, Python, Java, and PowerShell. The exact versions depend on the runtime version you target.

Any other language, such as Go or Rust, can run through a custom handler, where the Functions host forwards events to your own HTTP server process.

Newer programming models are code-first. Python v2 uses decorators and Node.js v4 registers functions in code, so neither needs a hand-written function.json. Check the supported runtime versions for each language before choosing, since they change as the platform evolves.

host.json holds global configuration that applies to every function in the function app. It controls the behaviour of the Functions host rather than any one function.

Typical settings are functionTimeout, logging and Application Insights sampling, extension bundle version, retry policy, and trigger tuning such as queue batchSize or Service Bus maxConcurrentCalls. Changes take effect when the app restarts, and the file is deployed together with your code.

{
  "version": "2.0",
  "functionTimeout": "00:10:00",
  "logging": {
    "applicationInsights": { "samplingSettings": { "isEnabled": true } }
  }
}

local.settings.json stores app settings and connection strings for local development. Core Tools reads it when you run func start, and the values show up as environment variables in your code.

It is never published to Azure. In the cloud, the same values live in the function app's application settings. Because it often holds secrets, keep it out of source control. It also carries a Host section for local settings such as the port and CORS origins, and a ConnectionStrings section for named connections.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
  }
}

function.json is a per-function metadata file that declares the function's trigger, bindings, and their direction. The host reads it to know what to listen to and what to inject.

You write it by hand for script-style languages in the older models, such as JavaScript v3, Python v1, and PowerShell. Code-first models, including C# attributes, Python v2, and Node.js v4, generate the equivalent metadata at build time.

{
  "bindings": [
    { "type": "queueTrigger", "direction": "in", "name": "msg", "queueName": "orders", "connection": "AzureWebJobsStorage" },
    { "type": "blob", "direction": "out", "name": "outBlob", "path": "archive/{rand-guid}.json", "connection": "AzureWebJobsStorage" }
  ]
}

HTTP-triggered functions use one of three authorization levels, set in the HttpTrigger attribute.

Send the key in the code query string or, better, in the x-functions-key header. Keys are shared secrets, so treat them as a basic safeguard and not as real user authentication. For user-level security, use Microsoft Entra ID through built-in authentication. Rotate keys regularly, and never embed them in client-side code, where anyone can read them.

Azure Functions Core Tools is a command-line toolset for creating, running, and deploying function apps from your machine. It includes the same Functions host that runs in Azure, so what you debug locally behaves closely like production.

1. func init creates a new project.
2. func new adds a function from a template.
3. func start runs the host locally.
4. func azure functionapp publish <APP_NAME> deploys to Azure.

For queue, blob, or timer triggers you also need a storage target locally. Azurite is the usual choice.

AzureWebJobsStorage points to the storage account the Functions runtime uses internally. It is not just for your data.

The host uses it to keep Event Hubs checkpoints, blob receipts, timer singleton locks, function keys, and the state of Durable Functions. If the connection is wrong or the account is unreachable, many triggers silently stop firing.

It is required for every trigger type except HTTP, and it is still recommended for HTTP-only apps. You can use identity-based access with AzureWebJobsStorage__accountName instead of a connection string.

Durable Functions is an extension of Azure Functions that lets you write stateful workflows in code while staying serverless. The framework checkpoints progress for you, so a workflow can pause for hours or days and resume after a restart.

It adds four building blocks:

• Client functions start and query orchestrations.
• Orchestrator functions define the workflow steps.
• Activity functions do the actual work.
• Entity functions hold small pieces of state.

It suits chaining, parallel processing, long-running approvals, and retry-heavy flows. State is stored in a task hub, which by default uses Azure Storage but can use other providers.

There are several supported routes. The right one depends on how repeatable you need the process to be.

• Core Tools: func azure functionapp publish for quick manual deploys.
• Zip deploy / run from package: upload a zip and set WEBSITE_RUN_FROM_PACKAGE=1 so the app runs read-only from the package.
• CI/CD: GitHub Actions (Azure/functions-action) or Azure Pipelines.
• VS Code and Visual Studio: publish from the IDE.
• Containers: push an image and point a Premium, Dedicated, or Container Apps host at it.

For teams, a pipeline with infrastructure as code (Bicep or Terraform) plus a staging slot or a validation step is the safest pattern. Flex Consumption uses its own one-deploy package flow.

The standard tool is Application Insights. Connect it by setting APPLICATIONINSIGHTS_CONNECTION_STRING on the function app, and the host starts sending traces, requests, dependencies, and exceptions automatically.

• Live Metrics for real-time debugging.
• Failures and Performance blades for exceptions and slow dependencies.
• Logs (KQL) for custom queries on the requests and traces tables.
• Alerts on failure rate or execution count.

To control cost, configure sampling in host.json. You can also write your own logs through ILogger, and those messages appear in the traces table with the invocation ID, so you can follow a single run end to end.

Keep secrets out of code and out of local.settings.json in source control. Store them in Azure Key Vault and reference them from app settings.

@Microsoft.KeyVault(SecretUri=https://my-vault.vault.azure.net/secrets/DbPassword/)

Enable a managed identity on the function app and grant it the Key Vault Secrets User role. The platform resolves the reference at runtime, and your code just reads the setting as an environment variable. Application settings are also encrypted at rest. If the vault is behind a firewall, the function app needs network access to it as well, otherwise the reference will fail to resolve and the setting stays empty.

The Consumption plan is pay-per-use. You are charged for two things: the number of executions and the resources used while running, measured in gigabyte-seconds (memory multiplied by duration).

Each month includes a free grant of 1 million executions and 400,000 GB-seconds. Memory is rounded up to the nearest 128 MB and time to the nearest millisecond, with a 100 ms minimum per execution.

Because idle time costs nothing, it is cheap for spiky workloads. Steady, heavy workloads often cost less on Premium or Dedicated.

Both are event-driven and scale out automatically. The difference is that Premium keeps pre-warmed instances ready and offers more networking and runtime headroom, at a higher baseline cost.

Choose Consumption for sporadic, short jobs. Choose Premium when you need private networking, no cold starts, or long executions.

Flex Consumption is the newer serverless plan that keeps pay-for-use billing but adds features that used to need Premium. It runs on Linux only.

• Per-function scaling: HTTP, Durable, and Blob (Event Grid) groups scale independently, and other triggers scale per function.
• Always-ready instances to cut cold starts.
• VNet integration with private endpoints.
• Configurable instance memory (512 MB, 2,048 MB, or 4,096 MB) and a high scale-out ceiling.

Limitations to know: it has no deployment slots, so you use rolling updates, and not every region or language version is available yet. For new serverless apps it is generally the first plan to evaluate.

These are the two ways to run .NET functions. In the in-process model your code loads into the same process as the Functions host. In the isolated worker model it runs in its own process and talks to the host over gRPC.

New projects should use isolated. Existing in-process apps need to migrate before support ends, since the tooling and new .NET releases target isolated only.

Scaling is handled by the scale controller, a platform component that watches the event source and decides how many instances the app needs. On Consumption, Flex Consumption, and Premium plans it adds instances when the load grows and removes them when it falls.

What it measures depends on the trigger:

• Queue: queue length and age of the oldest message.
• Event Hubs: unprocessed events, capped by the number of partitions.
• HTTP: concurrent requests and response times.
• Timer: never scales out, because only one instance runs a schedule.

Consumption on Windows can reach 200 instances per app and Linux 100. You can lower the cap with functionAppScaleLimit to protect a downstream database.

A cold start is the delay on the first request when no warm instance is available. Azure has to allocate a worker, start the host and language runtime, and load your code before the function can run.

It mostly affects the Consumption plan after idle periods. These steps help:

1. Use always-ready instances (Flex Consumption) or pre-warmed instances (Premium).
2. Deploy with WEBSITE_RUN_FROM_PACKAGE so file loading is fast.
3. Trim dependencies and avoid heavy work in startup code.
4. Prefer lighter runtimes where latency matters, and reuse clients instead of creating them on each call.
5. As a last resort, use a timer ping, though it is no substitute for a plan that has warm capacity.

Both are serverless and event-driven, but Functions is code-first and Logic Apps is designer-first. Functions gives you full control through code. Logic Apps connects services visually with prebuilt connectors.

They are often combined. A Logic App handles the workflow and approvals, and calls a function for any step that needs custom code.

Azure Functions is built on the WebJobs SDK, so they share the trigger and binding model. The difference is the hosting and scaling experience.

Pick WebJobs only when you already have an App Service app and want a background job next to it. Otherwise Functions is the better default.

In the isolated worker model you build the host yourself in Program.cs and register services on the IServiceCollection. Functions then receive them through constructor injection.

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        services.AddHttpClient();
        services.AddSingleton<IOrderService, OrderService>();
    })
    .Build();

host.Run();

public class OrderFunctions(IOrderService orders, ILogger<OrderFunctions> log)
{
    [Function("GetOrder")]
    public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req) { ... }
}

Use IHttpClientFactory instead of creating HttpClient per call, since that avoids socket exhaustion. Choose lifetimes carefully, because singletons are shared across concurrent invocations.

When a queue-triggered function throws, the message returns to the queue after its visibility timeout and is picked up again. The host tracks the dequeue count on the message.

After the count reaches maxDequeueCount (default 5), the runtime moves the message to a queue named <originalqueue>-poison and stops retrying it. You can then inspect it, fix the bug, and requeue it.

{
  "extensions": {
    "queues": { "maxDequeueCount": 3, "batchSize": 16, "visibilityTimeout": "00:00:30" }
  }
}

Add a second function with a trigger on the poison queue if you want alerts or automated handling.

By default the extension completes the message automatically when your function returns without an error. If the function throws, the message is abandoned and becomes available again for another attempt.

Each attempt increments the delivery count. When it exceeds the queue or subscription's MaxDeliveryCount (default 10), Service Bus moves the message to the dead-letter queue. You can also dead-letter explicitly through ServiceBusMessageActions when you set autoCompleteMessages to false.

For ordered processing, enable sessions so each session is handled by one consumer at a time.

Event Hubs splits a stream into partitions. The trigger assigns each partition to one instance at a time, which preserves ordering within that partition. That means the number of partitions is the ceiling on parallel instances.

The function receives events in batches when cardinality is set to many. After a batch finishes successfully, the host writes a checkpoint (offset and sequence number) to a blob container in the AzureWebJobsStorage account. If an instance dies, another resumes from the last checkpoint.

Because a checkpoint covers the batch, a failure can replay events. Make handlers idempotent, and use batch size and prefetch settings in host.json to tune throughput.

Both can start a function when a blob changes, but they detect changes differently. The classic Blob trigger polls the container and uses blob receipts, while an Event Grid-based setup is pushed by the storage account.

Use the event-based mode for production workloads. Flex Consumption supports only the event-based Blob trigger.

Built-in retry policies re-run a function when it throws. There are two strategies: fixed delay, which waits the same interval between attempts, and exponential backoff, where the wait grows each time up to a maximum.

You can set them per function with an attribute, or for the whole app in host.json:

[Function("ProcessOrder")]
[FixedDelayRetry(5, "00:00:10")]
public void Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer) { ... }

{
  "retry": {
    "strategy": "exponentialBackoff",
    "maxRetryCount": 5,
    "minimumInterval": "00:00:05",
    "maximumInterval": "00:15:00"
  }
}

These policies apply to non-HTTP triggers that support them, such as Timer, Event Hubs, and Cosmos DB. Queue and Service Bus triggers use their own redelivery rules, and HTTP clients must retry on their side.

Only one instance runs a given schedule at any moment. The Timer extension uses the singleton lock pattern, taking a blob lease in the AzureWebJobsStorage account. The instance that holds the lease fires the schedule, and the others skip it.

If that instance goes down, another takes the lease and continues. A missed run is reported through TimerInfo.IsPastDue when the host starts late.

Be careful with RunOnStartup, which fires the function every time the host starts, including each scale-out or deployment. It is meant for testing and should not be on in production. Also, a staging slot runs timers too unless you disable the function there.

Orchestrators use event sourcing. After each await, the framework saves history to the task hub, and when the orchestrator resumes it replays the code from the top, using the saved history to skip completed steps.

Replay only works if the code takes the same path each time. If a replay produces a different sequence of calls than the history recorded, you get a non-determinism error or corrupt workflow state.

Avoid in orchestrators:

• DateTime.Now (use context.CurrentUtcDateTime)
• Guid.NewGuid() (use context.NewGuid())
• Random numbers, environment reads that can change, and direct network or file I/O
• Task.Delay (use context.CreateTimer)

Put anything non-deterministic inside an activity function, which runs once and has its result recorded.

A client function starts an orchestration by writing a start message to the task hub (storage-backed queues and tables by default). The orchestrator is triggered, runs until it hits an await on an activity, and then unloads.

1. The orchestrator schedules an activity and saves that fact to the history table.
2. The activity runs, and its result is written back as a new history event.
3. The orchestrator is triggered again and replays from the start, using history to return stored results instead of re-running activities.
4. It continues past the completed step to the next await, and the cycle repeats until the workflow returns.

sequenceDiagram
  participant C as Client function
  participant H as Task hub (history)
  participant O as Orchestrator
  participant A as Activity
  C->>H: Start orchestration
  H->>O: Trigger
  O->>H: Schedule activity, then unload
  H->>A: Run activity
  A->>H: Save result
  H->>O: Trigger again (replay)
  O->>H: Mark completed

Durable Functions has a handful of well-known patterns that cover most workflow needs.

Pick the pattern first, then map it to orchestrators, activities, and entities.

Fan-out starts many activity functions in parallel, and fan-in waits for all of them and combines their results. The orchestrator is what holds the list of tasks and awaits them together.

[Function("ProcessFiles")]
public static async Task<int> Run(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var files = await context.CallActivityAsync<string[]>("GetFiles", null);

    var tasks = files.Select(f => context.CallActivityAsync<int>("ProcessFile", f));
    int[] results = await Task.WhenAll(tasks);

    return results.Sum();
}

The activities spread across available instances, so throughput scales with the app. Remember that checkpoint history grows with the number of tasks, so for very large fan-outs consider sub-orchestrations or batching. Make activities idempotent, since a retry can run one twice.

Durable entities are small stateful objects, each identified by an entity name and key. Operations on one entity are processed one at a time, so you get safe state updates without writing locking code.

An entity can be signalled (fire-and-forget) from a client or orchestrator, or called and awaited from an orchestrator. State is persisted for you.

• A counter or running total per device or user
• A shopping cart or rate limiter
• A circuit breaker or distributed lock
• Aggregating events from many sources into one record

Avoid them for large datasets, since each entity is meant to hold small state. A database is a better home for big or queryable data.

Function keys are shared secrets, so they identify an app, not a user. For real security, layer several controls:

1. Built-in authentication (Easy Auth) with Microsoft Entra ID, so callers present a valid token.
2. Azure API Management in front, validating JWTs, applying rate limits, and hiding the function URL.
3. Network restrictions: access restrictions or private endpoints so only trusted callers reach the app.
4. HTTPS only with a minimum TLS version and a tight CORS allow-list.
5. Managed identity for outbound calls so no credentials are stored in code.

Use AuthorizationLevel.Anonymous in code when Easy Auth or API Management handles authentication, and keep the function itself off the public internet where possible.

A managed identity gives the function app an identity in Microsoft Entra ID, so it can call other Azure services without keys or connection strings.

1. Enable the identity on the function app.
2. Assign it an Azure RBAC role on the target, for example Storage Blob Data Contributor.
3. Authenticate in code with DefaultAzureCredential, or use identity-based binding settings.

For triggers and bindings, replace connection strings with settings such as AzureWebJobsStorage__accountName or ServiceBusConnection__fullyQualifiedNamespace.

VNet integration controls outbound traffic from the function app through a delegated subnet, so it can reach private resources such as a database behind a private endpoint. Inbound traffic is handled separately with private endpoints or access restrictions.

If the runtime storage account is also locked behind a firewall, the app needs access to it through the VNet, and the content share settings must be configured to match. A broken storage path is a common reason a locked-down app stops starting.

Timeouts are set with functionTimeout in host.json, and the allowed range depends on the plan.

HTTP-triggered functions have a separate hard limit: the response must start within 230 seconds whatever the plan. For longer work, return 202 and continue asynchronously with a queue or Durable Functions. Also remember that unbounded does not mean the platform will never recycle an instance, so long jobs should checkpoint their progress.

Triggers like Queue, Service Bus, and Event Hubs offer at-least-once delivery, so the same message can reach your function more than once after a retry, timeout, or failover. An idempotent function produces the same end state however many times it runs.

• Use natural idempotent operations: upsert by key instead of insert, set instead of increment.
• Track an idempotency key: record the message ID or business key in a table and skip it if already processed.
• Use optimistic concurrency: ETags or version columns prevent double updates.
• Use broker features: Service Bus duplicate detection drops repeated message IDs within a window.
• Order matters: write the result first, then mark the message as processed, so a crash leads to a safe replay.

Pair this with retry and poison handling, so repeated failures end up in a queue you can review.

Start by finding the bottleneck in Application Insights, then apply the changes that fit.

1. Reuse connections: share HttpClient, database, and SDK clients through DI instead of creating them per invocation.
2. Be async end to end: blocking calls tie up worker threads and limit throughput.
3. Batch where possible: process Event Hubs and Service Bus messages in batches rather than one at a time.
4. Keep functions short: split long work using queues or Durable Functions.
5. Tune concurrency in host.json, such as batchSize or maxConcurrentCalls.
6. Choose the right plan: Premium or Flex always-ready instances for latency-sensitive paths.
7. Trim package size and use run from package for faster starts.
8. Don't share one storage account between many busy apps, since runtime calls can throttle.

Re-measure after each change so you know which one actually helped.

Work from the host outward. Most trigger problems are configuration, not code.

1. Check the function is enabled. An app setting named AzureWebJobs.<FunctionName>.Disabled=true turns it off.
2. Check host health. Look in Application Insights or the Log stream for startup errors, bad host.json, or runtime mismatches.
3. Validate AzureWebJobsStorage. A bad key or firewall block stops most triggers.
4. Match connection names. The Connection property must name an existing app setting, and queue or container names must be exact.
5. Sync triggers. After some ARM or container deployments, run Sync triggers so the scale controller knows about them.
6. Check networking. A private event source needs VNet integration and DNS that resolves.
7. Test the event source. Send a known message and watch Live Metrics.

If the function runs but fails, switch to exceptions in the Failures blade instead.

The choice depends on how much control you need versus how much you want Azure to manage.

Functions also runs on Container Apps, so you can keep the programming model and still share an environment with other containers. Avoid Functions for heavy long-lived processing or when you need custom OS-level dependencies that a managed runtime can't provide.

A deployment slot is a live, separate instance of your function app with its own hostname and configuration. You deploy to a staging slot, test it, and swap it into production, which warms the new code first and avoids downtime.

Slots are supported on Premium and Dedicated plans. Flex Consumption does not offer slots and relies on rolling updates instead.

• Mark settings as slot settings (sticky) if they should stay with the slot, such as a staging connection string.
• A swap can roll back by swapping again.
• Timer, queue, and other triggers run in every slot, so disable them in staging with AzureWebJobs.<name>.Disabled to prevent double processing.

HTTP functions are the easiest to swap. For queue-based apps, plan the cutover carefully.

Concurrency can be tuned at three levels: inside one instance, across worker processes, and across instances.

Dynamic concurrency lets the host adjust parallelism automatically based on CPU and memory, and you enable it with concurrency.dynamicConcurrencyEnabled in host.json. For strictly one-at-a-time execution, use the Singleton attribute. Always size the limits against what the downstream database can handle.

Two pieces cooperate. The scale controller sits outside your app and watches event sources to decide instance counts. The Functions host runs on each instance and executes your functions.

1. The scale controller monitors triggers (queue depth, partition lag, request rate) and tells the platform to add or remove instances.
2. On each instance, the host starts, reads host.json and the function metadata, and starts a listener for each trigger.
3. When an event arrives, the host resolves input bindings and sends an invocation to the language worker over gRPC (the isolated worker or runtime for Node, Python, Java).
4. The worker runs your code and returns the result, and the host handles output bindings, checkpoints, and logging.

flowchart LR
  SC["Scale controller"] -->|add or remove instances| I["Function instance"]
  ES[(Event source)] --> L["Host listener"]
  SC -.monitors.-> ES
  subgraph I["Function instance"]
    L --> H["Functions host"]
    H -->|gRPC| W["Language worker"]
    W --> F["Your function code"]
  end
  F --> OB["Output bindings and logs"]