Java / Azure App Service Interview questions

Azure App Service is a fully managed platform-as-a-service (PaaS) for hosting web apps, REST APIs, and mobile backends. You supply the code or a container image, and Azure takes care of the operating system, patching, load balancing, and capacity.

It runs .NET, Java, Node.js, Python, and PHP on Windows or Linux, and ships with deployment slots, autoscale, custom domains, TLS certificates, and CI/CD integration out of the box.

Billing is based on the compute you reserve in an App Service plan, not per app.

App Service is built for HTTP-based workloads. The common types are:

• Web apps such as ASP.NET, Spring Boot, Express, Django, or Laravel sites
• REST and GraphQL APIs consumed by SPAs, mobile apps, or other services
• Background jobs through WebJobs running alongside the app
• Custom containers built from your own Docker image
• Azure Functions, when you pick the Dedicated (App Service) hosting plan

It is not the right place for workloads that need arbitrary inbound TCP or UDP ports, because only HTTP (80) and HTTPS (443) are exposed publicly.

An App Service plan is the set of compute resources that runs one or more apps. It defines the region, operating system, VM size, number of instances, and pricing tier.

Every app in the plan runs on every instance of that plan, so apps share CPU, memory, and disk. The plan, not the app, is what you are billed for, even if an app inside it is stopped.

App Service offers five main tier families, from shared development tiers up to a fully isolated environment. Higher tiers add instances, slots, networking features, and performance.

Limits change over time, so confirm numbers on the current pricing page before sizing.

App Service supports .NET, Java, Node.js, Python, and PHP on Linux, plus Ruby on Linux and ASP.NET (.NET Framework 4.x) on Windows. Java comes in flavors for Java SE, Tomcat, and JBoss EAP.

If your stack is not covered, bring a custom container and run anything that serves HTTP. Supported versions change as languages reach end of life, so list the current ones from the CLI instead of memorizing them:

az webapp list-runtimes --os linux
az webapp list-runtimes --os windows

A deployment slot is a live app instance with its own hostname that runs in the same App Service plan as your production app. Typical examples are staging and qa.

You deploy and test a new build in a slot, then swap it into production after warm-up. The swap just changes routing, so users see no downtime, and if something breaks you can swap back to roll the change out.

Slots share the plan's compute, so a busy staging slot can slow down production. The number of slots depends on the tier.

You can push a ZIP, WAR, or JAR package with the CLI, or wire up a pipeline. The main options are:

• CI/CD with GitHub Actions or Azure Pipelines (recommended for repeatable releases)
• ZIP or WAR deploy through az webapp deploy or the Kudu API
• IDE publish from Visual Studio or VS Code
• Local Git or FTPS for small or legacy setups
• Container images pulled from Azure Container Registry or Docker Hub

az webapp deploy --resource-group my-rg --name my-app --src-path app.zip --type zip

Scale up changes the size or tier of each instance (vertical scaling). Scale out changes how many instances run your app (horizontal scaling).

Scale out is usually preferred for web workloads because it also improves availability.

Autoscale lives under Scale out (App Service plan) and is powered by Azure Monitor. You pick a custom autoscale condition, set minimum, maximum, and default instance counts, then add rules.

A rule pairs a metric with a threshold and an action, for example: if average CPU is above 70% for 10 minutes, add 1 instance. Always pair a scale-out rule with a scale-in rule, and use a cooldown so the plan does not flap.

You can also scale on a schedule, such as more instances during business hours. Autoscale needs the Standard tier or higher.

Open Settings > Environment variables (formerly Configuration) and add name/value pairs under App settings or Connection strings. They are encrypted at rest and injected into your app as environment variables.

They override matching values in appsettings.json or web.config, which keeps secrets out of source control. Tick Deployment slot setting to pin a value to one slot.

On Linux, nested keys use a double underscore because colons are not valid in variable names:

az webapp config appsettings set -g my-rg -n my-app \
  --settings "Logging__LogLevel__Default=Warning" "FEATURE_X=on"

Always On keeps the app loaded by sending a request to the site root regularly. Without it, an app with no traffic is unloaded after roughly 20 minutes, and the next visitor pays for a cold start.

It is available from the Basic tier upward and is not offered on Free or Shared. Turn it on for production sites, and it is required for continuous WebJobs and any in-process timers that must keep running.

WebJobs run scripts or programs in the same sandbox as your web app, which is handy for background work such as queue processing, report generation, or cleanup. Supported file types include .exe, .cmd, .ps1, .sh, .py, .js, and .php.

For new event-driven code, Azure Functions is often the better choice.

Add the domain under Settings > Custom domains, create the DNS records Azure shows you, then validate and bind a certificate.

1. Use a paid or Shared tier (Free does not allow custom domains).
2. For a subdomain such as www, create a CNAME pointing to <app>.azurewebsites.net.
3. For an apex domain, create an A record to the app's IP address.
4. Add a TXT record named asuid containing the app's custom domain verification ID.
5. Select Validate, then Add, and bind a TLS certificate.

The default *.azurewebsites.net hostname already has a valid certificate. For a custom domain you need your own certificate and a TLS binding.

Certificate options are a free App Service Managed Certificate (no wildcards), a purchased App Service Certificate, a certificate imported from Key Vault, or an uploaded .pfx file.

After binding, switch on HTTPS Only so HTTP requests are redirected, and set the minimum TLS version to 1.2 or higher.

Easy Auth is a built-in authentication module that sits in front of your app, so sign-in works without writing auth code. It supports Microsoft Entra ID, Google, Facebook, GitHub, Apple, X, and any OpenID Connect provider.

You choose whether unauthenticated requests are allowed or redirected to login. After sign-in, the platform passes the user's identity to your code in headers such as X-MS-CLIENT-PRINCIPAL, and exposes endpoints like /.auth/login/<provider>.

It handles sign-in only. Authorization rules, like which roles can call an endpoint, still belong in your app.

Kudu is the engine behind deployments and diagnostics for App Service. It runs as a separate site at https://<app>.scm.azurewebsites.net, sometimes called the SCM site.

From there you get a debug console (CMD or PowerShell, plus SSH on Linux), a process explorer, environment variables, deployment logs, a WebJobs dashboard, site extensions, and a ZIP deploy API.

Because it exposes file and process access, lock it down with its own access restrictions and Entra sign-in.

Turn on logging under Monitoring > App Service logs, then watch it live in Log stream or from the CLI.

Application logging can write to the file system (temporary, about 12 hours) or to Blob storage. You can also enable web server logs, detailed error messages, and failed request tracing on Windows.

For long-term search, add a diagnostic setting that sends AppServiceHTTPLogs, AppServiceConsoleLogs, and AppServiceAppLogs to a Log Analytics workspace and query them with KQL.

az webapp log config -g my-rg -n my-app --application-logging filesystem --level information
az webapp log tail -g my-rg -n my-app

Open Monitoring > Application Insights on the app, choose Enable, and pick or create a workspace-based resource. For .NET, Java, Node.js, and Python this turns on auto-instrumentation with no code change, though some runtimes support only parts of it.

For more control, add the Azure Monitor OpenTelemetry distro or the SDK to your code and supply the connection string through the APPLICATIONINSIGHTS_CONNECTION_STRING app setting.

You then get request rates, dependency calls, exceptions, Live Metrics, and the Application Map.

A managed identity is an Entra ID identity that Azure creates and rotates for your app, so the app can call Key Vault, Storage, SQL, or Service Bus without any stored password or secret.

Grant the identity an Azure RBAC role on the target resource, then use DefaultAzureCredential in code:

var client = new SecretClient(
    new Uri("https://my-vault.vault.azure.net/"),
    new DefaultAzureCredential());

Web App for Containers runs your own Docker image on App Service, with the same plan, scaling, slots, and domain features as code-based apps. Images can come from Azure Container Registry, Docker Hub, or another private registry.

Your container must listen on an HTTP port. App Service detects an exposed port, or you can set it explicitly with the WEBSITES_PORT app setting. Using managed identity to pull from ACR avoids storing registry credentials.

Container logs are available through Log stream and Kudu, and persistent storage can be mounted under /home.

Free (F1) and Shared (D1) run on shared VMs with daily CPU quotas. Once you use the quota, the app is stopped until the quota resets.

Use them for learning and quick tests, not for production.

Open API > CORS on the app and list the allowed origins, such as https://contoso.com. You can also tick Enable Access-Control-Allow-Credentials if cookies or auth headers must be sent.

Avoid mixing this with CORS code in your app. When both are present, the platform setting takes precedence and your code's headers have no effect, which makes debugging confusing. Pick one place.

az webapp cors add -g my-rg -n my-app --allowed-origins https://contoso.com

App Service hosts whole applications that stay running on reserved compute. Azure Functions hosts small event-triggered units of code and can scale to zero.

Functions can also run on an App Service plan if you want predictable cost and no cold starts.

Choose App Service when you have a standard web app or API and want the platform to handle patching, scaling, TLS, and deployments, so your team spends time on code instead of infrastructure.

Move to AKS when you outgrow the platform, for example needing service meshes or non-HTTP protocols.

A swap is a warm-up followed by a routing change, not a file copy. That is why it causes no downtime.

1. App Service applies the target slot's settings (including slot-specific app settings) to the source slot and restarts its instances.
2. It waits for each instance to restart. If any fails, the swap is cancelled and the slots revert.
3. It sends warm-up requests, honoring applicationInitialization rules if you defined them.
4. Once the source is warm, it swaps the routing rules. The source becomes production.
5. The old production code now sits in the source slot, so you can swap back to roll back.

flowchart LR
  A["Deploy to staging"] --> B["Apply target slot settings"]
  B --> C["Restart and warm up source"]
  C --> D{All instances healthy?}
  D -- No --> E["Cancel swap and revert"]
  D -- Yes --> F["Swap routing rules"]
  F --> G["Old prod now in staging slot"]

Swap with preview lets you pause after step 1 to test the app with production settings before completing.

A slot setting (also called a sticky setting) stays with the slot during a swap instead of moving with the code. You mark an app setting or connection string as such with Deployment slot setting.

This lets production keep its production database string and staging keep its test one, no matter which build is running where.

Under Deployment slots you set a traffic percentage per slot, which sends that share of production traffic to a non-production slot. This is called testing in production, and is handy for canary releases.

Once a client is routed to a slot it stays there, through a x-ms-routing-name cookie. You can also force a route with ?x-ms-routing-name=staging in a link, or use self to return to production.

Ramp the percentage up while watching errors and latency, then do the final swap.

Every app in a plan runs on every instance of that plan. With 3 instances and 5 apps, each app has a worker process on all 3 VMs, and they compete for the same CPU, memory, and disk.

This makes plans cost-efficient but exposes you to noisy neighbors: one leaky or CPU-heavy app can slow the rest. Deployment slots also count, since they run on the same instances.

Keep critical or heavy apps in their own plan, and watch the plan-level CPU and memory metrics, not just per-app ones.

Cold starts happen after idle unload, a restart, a scale-out, or a deployment. Reduce them at both the platform and code level:

• Enable Always On so the app is not unloaded when idle
• Use slot swap so the new build is warm before it takes traffic
• Define applicationInitialization in web.config to hit key URLs at startup
• Use automatic scaling on Premium plans for pre-warmed instances
• Cut startup work: ReadyToRun or AOT for .NET, lazy loading, fewer startup dependencies
• Use Run From Package to shorten file-system access at startup

Configure Health check as well, so new instances only receive traffic once they respond properly.

You give App Service a health check path, such as /healthz. The platform pings it about every minute on each instance.

Any response from 200 to 299 counts as healthy. If an instance fails the configured number of consecutive pings (the load-balancing threshold, 2 to 10), it is removed from the load balancer rotation, but only when the plan has two or more instances.

If it stays unhealthy for about an hour, App Service replaces the instance with a new one. Make the endpoint check real dependencies such as the database, but keep it fast and cheap.

Regional VNet integration lets your app make outbound calls into a virtual network, for example to a private database or an on-premises system over VPN. It does not make the app itself reachable from the VNet.

Setup needs a dedicated, empty subnet delegated to Microsoft.Web/serverFarms, one subnet per plan. A /26 is the usual recommendation so there is room to scale out.

By default only private (RFC 1918) traffic goes through the VNet. Enable route all (outbound internet traffic) if NSGs, UDRs, or a firewall must see everything, and set WEBSITE_DNS_SERVER when you need custom DNS.

They solve opposite directions. VNet integration is outbound, letting the app reach private resources. A private endpoint is inbound, giving the app a private IP so clients in your network can reach it.

Many secure designs use both: a private endpoint in front and VNet integration behind.

An App Service Environment (ASE v3) is a single-tenant deployment of App Service inside your own virtual network. Plans in it use the Isolated v2 tier and run on dedicated hardware.

It can be external (public VIP) or internal (private load balancer IP), so apps can be hidden from the internet completely. A plan scales to 100 instances, and an ASE to 200 across plans.

Use it for strict compliance or isolation needs, very high scale, or when all traffic must stay on a private network. For ordinary workloads, Premium plans with private endpoints are cheaper and simpler.

Access restrictions are an ordered list of allow and deny rules evaluated by priority on inbound requests. A rule can match an IPv4 or IPv6 range, a VNet subnet (via service endpoint), or an Azure service tag.

You can also filter by HTTP headers, such as X-Forwarded-For or X-Azure-FDID, to accept traffic only from a particular proxy.

Once you add any allow rule, an implicit deny all applies to everything else. The Kudu (SCM) site has its own rule set unless you tell it to reuse the main site's rules.

A Key Vault reference is an app setting value that points to a secret instead of containing it. App Service resolves it at runtime using the app's managed identity, so your code reads a plain environment variable.

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

The identity needs the Key Vault Secrets User role (or an access policy with Get). If you leave out the secret version, the app picks up a rotated secret automatically, typically within a day. The portal shows a green check when a reference resolves.

Autoscale is rule-based and you define it. Automatic scaling is platform-managed and reacts to HTTP traffic with pre-warmed instances.

Use automatic scaling for spiky HTTP traffic and autoscale when you need schedules or non-HTTP metrics.

Per-app scaling sets a maximum number of plan instances that a given app may run on. Without it, every app runs on every instance of the plan.

It makes dense hosting practical: you scale the plan out to, say, 10 instances, then cap a low-traffic app at 2 and let a busy app use all 10. This keeps one app from consuming the whole plan.

You enable it on the plan, then set the number of workers on each app. Only apps that actually need more instances pay the resource cost.

Start with Diagnose and solve problems, then compare the logs against the usual causes.

Then work through these checks:

1. Open Log stream and Kudu for startup errors.
2. On Linux containers, confirm the port matches WEBSITES_PORT and watch WEBSITES_CONTAINER_START_TIME_LIMIT.
3. Check CPU and memory metrics for exhaustion before a restart.
4. Review recent deployments, swaps, and app setting changes.
5. Look at Application Insights failures and dependency timeouts.

First find which process and which code path is hot, then decide between a code fix and more capacity.

1. Check plan-level CPU Percentage and Memory Percentage to see whether another app in the plan is the culprit.
2. Open Diagnose and solve problems and run the CPU or memory analysis detectors.
3. Use Kudu's process explorer to see which worker process is consuming resources.
4. Capture a profile (Application Insights Profiler) or a memory dump and look for leaks or hot loops.
5. Use Auto-Heal on Windows to recycle automatically on memory or slow-request thresholds while you fix the root cause.
6. Only after that, scale up or out if the load is legitimate.

Open Deployment Center, select GitHub, and App Service commits a workflow file to your repo. The workflow builds your code and deploys it with the azure/webapps-deploy action.

For authentication, prefer OIDC federated credentials through azure/login, so no long-lived secret is stored. A downloaded publish profile also works but relies on basic authentication, which is weaker.

- uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/webapps-deploy@v3
  with:
    app-name: my-app
    slot-name: staging
    package: ./publish

Deploy to a staging slot first, run smoke tests, then swap.

Run From Package mounts a ZIP file as the read-only wwwroot instead of unpacking files onto disk. You enable it with the app setting WEBSITE_RUN_FROM_PACKAGE.

Setting it to 1 runs the package that ZIP deploy uploaded. Setting it to a URL, such as a blob with a SAS token or managed identity access, runs the package from there.

Benefits are atomic deployments (no half-copied files), no file lock conflicts, and often faster cold starts for apps with many files. The catch is that wwwroot becomes read-only, so write runtime files to /home or Azure Storage.

A request passes through a few platform roles before it reaches your code. Front ends act as load balancers and TLS terminators, workers are the VMs running your app, and a shared file storage layer holds site content.

sequenceDiagram
  participant C as Client
  participant D as DNS
  participant F as Front end (load balancer)
  participant W as Worker instance
  participant S as Shared storage (/home)
  C->>D: Resolve app.azurewebsites.net
  D-->>C: Front end IP
  C->>F: HTTPS request
  F->>F: TLS termination, access restrictions, Easy Auth
  F->>W: Route to an instance (ARR affinity optional)
  W->>S: Read site content on startup
  W-->>F: App response
  F-->>C: HTTPS response

The front end applies access restrictions and routes to a healthy worker, honoring the ARR affinity cookie when it is on. The worker runs your process (IIS on Windows, a container on Linux). Content under /home is network storage shared by all instances, while D:\local is temporary per-instance disk.

Combine deployment slots, warm-up, and backward-compatible data changes.

1. Deploy the new build to a staging slot on the same plan.
2. Mark environment-specific settings as slot settings so they stay put.
3. Add applicationInitialization or a health endpoint so the slot is warm before the swap.
4. Run smoke tests against the staging URL, optionally routing a small share of traffic first.
5. Swap into production. If something breaks, swap back immediately.

The database is the usual trap. Use the expand and contract pattern: add new columns first, ship code that works with both schemas, then remove old columns in a later release. Running at least two instances also prevents a restart from taking the site down.

The operating system decides how your app is hosted: Windows uses IIS, Linux runs your code inside a container managed by the platform. A single plan can only hold one OS, so you cannot mix them.

Choose by stack: legacy .NET Framework needs Windows, almost everything else runs well on Linux.

Cost follows the plan's size and instance count, so most savings come from right-sizing and consolidating.

• Right-size the tier using CPU and memory metrics, and avoid paying for Premium features you do not use
• Put several small apps in one plan instead of one plan per app
• Use autoscale with scale-in rules, and schedule scale-downs for off-hours in non-production
• Buy reserved instances or an Azure savings plan for steady 24x7 workloads
• Use lower tiers or Linux plans for dev and test, and delete unused plans (stopped apps still cost money)
• Trim diagnostic log volume in Log Analytics

Backup saves a snapshot of the app to an Azure Storage account you choose. It is available on paid tiers, with details depending on the tier.

A backup can include:

• App configuration and settings
• File content from the app (you can exclude folders)
• A linked database, such as Azure SQL, MySQL, or PostgreSQL

Backups have a size cap of around 10 GB for content and database combined, so large sites need another strategy. You can restore over the same app, to a new app, or to a slot, and choose whether to restore the database.

Treat backup as a safety net. Source control plus CI/CD is still the primary way to recreate an app.

High availability is built in layers, from instance redundancy up to multiple regions.

1. Multiple instances: run at least two so one failure or platform update does not take you down.
2. Health check: remove bad instances from rotation automatically.
3. Zone redundancy: on supported Premium plans, spread instances across availability zones in the region.
4. Multi-region: deploy the app to two regions and put Azure Front Door or Traffic Manager in front.
5. Data tier: use geo-replication (Azure SQL failover groups, Cosmos DB multi-region) so the second region has data.
6. Deploy to both regions from the same pipeline so they stay identical.

Paid tiers carry an SLA, so pick the topology to match your recovery targets.

Front Door sits at the edge, so you must make sure clients cannot bypass it and hit the azurewebsites.net hostname directly.

1. Add an access restriction allowing the AzureFrontDoor.Backend service tag.
2. Add a header filter on X-Azure-FDID equal to your Front Door profile ID.
3. Lock down the Kudu SCM site the same way.
4. Or, for stronger isolation, use Front Door Premium with Private Link to a private endpoint on the app and disable public access.

The header check matters because the service tag covers every Front Door customer, not just you. Put the WAF policy on Front Door, and keep the host header handling consistent so redirects and cookies work.

Prefer non-intrusive tools first and use a debugger only when you must.

• Log stream and az webapp log tail for quick runtime output
• Application Insights for exceptions, traces, Live Metrics, and the Snapshot Debugger
• Kudu console or SSH (Linux) to inspect files, processes, and environment variables
• Remote debugging from Visual Studio or VS Code, which attaches a debugger to the running worker

Remote debugging pauses request threads, so avoid it on a busy production instance. Use a staging slot instead. It also switches off automatically after 48 hours so it is not left on by accident.

Migration is easiest with an assessment first, then a staged cutover.

1. Assess readiness with the Azure Migrate web app assessment or the App Service Migration Assistant (IIS-based .NET and PHP apps).
2. Choose the OS, tier, and region, and note blockers such as GAC assemblies, registry use, or local disk writes.
3. Migrate the app with the Assistant, a ZIP deploy, or a container image.
4. Move configuration out of config files into app settings, and secrets into Key Vault.
5. Connect dependencies: migrate the database to Azure SQL, or use VNet integration or Hybrid Connections for resources that stay on-premises.
6. Test in a staging slot, then cut over DNS with a low TTL.