Azure App Service – Complete Guide to Hosting, Deployment, Scaling, Security, and Monitoring

Azure Cloud Computing | Beginner to Advanced | Hands-on Tutorials | Interview Preparation

What You'll Learn

1. What Azure App Service is and how it differs from Azure Virtual Machines.

2. IaaS vs PaaS and the shared responsibility model.

3. Azure App Service architecture and request processing.

4. App Service Plans, pricing tiers, and billing.

5. Supported programming languages, runtimes, and operating systems.

6. Creating an Azure Web App using the Azure Portal.

7. Deploying applications using ZIP Deploy, GitHub Actions, Azure DevOps, Local Git, and FTP.

8. Deploying ASP.NET Core Web API applications.

9. Application settings, connection strings, and environment variables.

10. Custom domains, SSL certificates, and HTTPS.

11. Deployment slots, slot swapping, and rollback.

12. Vertical scaling, horizontal scaling, and autoscaling.

13. Managed Identity and Azure Key Vault integration.

14. Azure SQL Database connectivity.

15. VNet Integration, Private Endpoints, and access restrictions.

16. Monitoring applications using Application Insights and Azure Monitor.

17. Application security, backups, and disaster recovery.

18. Common deployment problems and troubleshooting.

19. App Service cost optimization and best practices.

20. Important Azure App Service interview questions and answers.

Part 1 – Introduction to Azure App Service

1. What Is Azure App Service?

Azure App Service is a fully managed Platform-as-a-Service (PaaS) offering from Microsoft Azure that allows developers to build, deploy, and host web applications, REST APIs, and backend services without manually managing the underlying servers.

It supports popular development technologies, including:

• ASP.NET Core and .NET

• Node.js

• Python

• Java

• PHP

• Custom Linux containers

For example, suppose you develop an ASP.NET Core Web API application.

With a traditional server, you must install and configure the operating system, web server, runtime, security patches, and hosting infrastructure.

With Azure App Service, you publish your application, configure its runtime and environment, and Azure manages the underlying hosting platform.

Azure App Service architecture

             Internet Users
                   |
                   v
          Azure App Service URL
                   |
                   v
             HTTPS Endpoint
                   |
                   v
         Azure Front-End Layer
                   |
                   v
          App Service Workers
                   |
          +--------+--------+
          |                 |
          v                 v
      Instance 1        Instance 2
          |                 |
          +--------+--------+
                   |
                   v
           ASP.NET Core API
                   |
                   v
           Azure SQL Database

Explanation:

1. A user sends an HTTPS request to the application.

2. Azure's front-end infrastructure routes the request to an available worker instance.

3. The worker hosts the application.

4. The application executes its business logic.

5. If necessary, the application connects to Azure SQL Database.

6. The response returns to the user.

Key points

• App Service is a PaaS hosting solution.

• Developers focus primarily on application code and configuration.

• Azure manages the underlying operating system and hosting infrastructure.

• Multiple applications can run within a single App Service Plan.

• Applications can scale horizontally across multiple instances.

2. Why Do We Need Azure App Service?

Consider an organization hosting an ASP.NET Core application on an Azure Windows Virtual Machine.

The infrastructure team must manage:

• Windows Server maintenance and updates.

• IIS installation and configuration.

• ASP.NET Core Hosting Bundle installation.

• Security patches.

• SSL certificates.

• Server availability.

• Load balancing and scaling.

• Application deployment and monitoring.

These activities require ongoing administration.

Azure App Service reduces this operational burden by providing a managed application hosting platform.

Traditional VM hosting

             Developer
                 |
                 v
         ASP.NET Core Code
                 |
                 v
          Windows Server VM
                 |
          +------+------+
          |             |
          v             v
         IIS       .NET Runtime
          |             |
          +------+------+
                 |
                 v
          Application
                 |
                 v
           SQL Database

  OS + IIS + Runtime + Patching
        Managed by Customer

Azure App Service hosting

             Developer
                 |
                 v
         ASP.NET Core Code
                 |
                 v
          Deploy Application
                 |
                 v
          Azure App Service
                 |
       +---------+---------+
       |         |         |
       v         v         v
    Hosting   Runtime   Patching
       |         |         |
       +---------+---------+
                 |
                 v
          Application
                 |
                 v
           SQL Database

     Underlying Platform
        Managed by Azure

App Service simplifies infrastructure management, but the customer remains responsible for application security, supported runtime choices, dependencies, configuration, and data protection.

3. Azure App Service vs Azure Virtual Machine

When should you choose Azure App Service?

Choose App Service when:

• Hosting ASP.NET Core Web API or MVC applications.

• Building enterprise REST APIs.

• Hosting Node.js or Python web applications.

• Implementing CI/CD deployment.

• Requiring straightforward horizontal scaling.

• Reducing server administration.

Choose Azure VMs when:

• Full operating system control is required.

• Applications depend on unsupported OS-level components.

• Custom server software must be installed.

• Legacy applications require specific infrastructure configurations.

Interview key point: Azure App Service is generally preferable for standard web applications and APIs when the managed platform supports their requirements. VMs provide greater operating-system flexibility but introduce additional administration.

Part 2 – Azure App Service Architecture

4. What Are the Main Components of Azure App Service?

Azure App Service has several important components.

1. App Service Plan

Defines the compute resources and pricing tier used to host applications.

2. Web App

The actual web application or API hosted on Azure.

3. Worker Instance

The compute instance on which application processes run.

4. Front-End Infrastructure

Handles incoming requests and routes traffic to application workers.

5. Deployment Slots

Separate deployment environments associated with a web app.

6. Application Settings

Environment-specific configuration values injected into the application.

Architecture diagram

              Azure Subscription
                      |
                      v
                 Resource Group
                      |
            +---------+----------+
            |                    |
            v                    v
      App Service Plan      Azure SQL Database
            |
     +------+------+ 
     |             |
     v             v
   Web App 1     Web App 2
   (Frontend)    (Web API)
     |             |
     v             v
   Workers       Workers
   (Shared Compute Resources)

Both applications can share the same App Service Plan when their hosting requirements are compatible.

However, sharing a plan also means sharing CPU, memory, and other worker resources.

5. What Is the Difference Between a Web App and an App Service Plan?

This is an important Azure interview question.

App Service Plan: Defines where an application runs and the compute capacity available.

Web App: Contains the application's hosting configuration, deployment, and runtime settings.

For example:

       App Service Plan
       (Standard S1)
              |
      +-------+-------+
      |       |       |
      v       v       v
    Web 1   Web 2   Web 3
    MVC     API     Admin
      |       |       |
      +-------+-------+
              |
       Shared CPU / RAM

Suppose the plan has three applications.

Even if one application receives very little traffic, all three consume resources from the same plan.

If the API experiences unusually high CPU usage, it can affect the performance of the MVC and Admin applications.

This is called the noisy-neighbor problem within a shared App Service Plan.

For critical applications, separate App Service Plans may provide better workload isolation.

Part 3 – Azure App Service Plans and Pricing

6. What Is an App Service Plan?

An App Service Plan defines the compute capacity allocated to one or more Azure web applications.

It determines:

• Available CPU and memory.

• Worker instance count.

• Supported features.

• Scaling capabilities.

• Deployment slot availability.

• Networking capabilities.

• Compute billing.

7. Azure App Service Pricing Tiers

The main tiers covered in the original training material are Free, Basic, Standard, Premium, and Isolated. Azure also offers Shared and newer Premium variants in applicable configurations.

Pricing and supported SKUs depend on region, operating system, and configuration. The approximate dollar amounts in the training material are illustrative rather than reliable current quotations.

Free F1 tier

Suitable for learning and demonstrations.

Features include:

• Shared compute infrastructure.

• Limited daily CPU quota.

• Default azurewebsites.net hostname.

• No custom domain binding.

• No deployment slots.

• No production SLA.

The source material identifies a 60 CPU-minute daily quota for Free F1.

This refers to CPU consumption, not simply 60 minutes of elapsed application uptime.

Basic tier

Provides dedicated compute resources.

Important capabilities:

• Custom domain support.

• HTTPS support.

• Manual scaling.

• Better workload isolation than Free.

Basic is appropriate for small applications that do not require deployment slots or autoscaling.

Standard tier

Adds production-oriented capabilities:

• Deployment slots.

• Autoscaling.

• Backup features.

• More advanced scaling options.

Standard is a common starting point when an application requires staging-to-production slot swaps.

Premium tier

Provides additional compute capacity and higher scaling limits.

It is suitable for applications with demanding performance, networking, or availability requirements.

Isolated tier

Designed for workloads hosted in an App Service Environment (ASE), providing dedicated network and infrastructure isolation.

8. How Does Azure App Service Billing Work?

One of the most important concepts is that dedicated App Service compute is billed primarily at the App Service Plan level, not separately for every web app.

Suppose you create:

          Standard S1 Plan
                 |
       +---------+---------+
       |         |         |
       v         v         v
      MVC       API       Admin
       |         |         |
       +---------+---------+
                 |
         1 Worker Instance

All three applications share the plan's worker capacity.

Creating three web apps does not automatically mean paying for three separate S1 plans.

However, increasing the worker instance count increases compute cost.

Illustrative billing example

Assume a hypothetical App Service Plan costs $70 per month per instance.

These are calculation examples, not current Azure prices.

Additional services such as Azure SQL Database, Application Insights, storage, networking, and bandwidth can generate separate charges.

Important: Stopping an application on a paid dedicated App Service Plan generally does not stop the plan's compute billing.

9. How to Reduce Azure App Service Costs

1. Use Free F1 for basic learning.

2. Select an appropriate paid tier rather than overprovisioning.

3. Host compatible low-traffic applications on the same plan.

4. Configure autoscaling where supported.

5. Monitor CPU, memory, and request volumes.

6. Remove unused App Service Plans and related resources.

7. Evaluate Azure Savings Plans or reservations where eligible.

8. Avoid unnecessarily maintaining separate dedicated plans for every small application.

Part 4 – Supported Runtimes and Operating Systems

10. Which Programming Languages Does Azure App Service Support?

Azure App Service provides managed runtime stacks for several programming languages.

Supported runtime versions change over time. Always check the available stack and version in the Azure Portal before deploying.

For .NET applications, select a supported version matching the application's target framework.

Windows vs Linux App Service

ASP.NET Core applications can run on both Windows and Linux App Service.

However, classic ASP.NET Framework applications generally require Windows hosting.

What about Angular applications?

Angular is commonly compiled into static HTML, CSS, and JavaScript assets.

For a standalone Angular frontend, Azure Static Web Apps is often a suitable option.

For Angular server-side rendering, App Service can host a compatible Node.js server application.

Part 5 – Creating an Azure Web App Using Azure Portal

11. Hands-on Demo: Create Your First Azure App Service

This walkthrough retains the Node.js demonstration from the attached material.

Step 1 – Open Azure Portal

Navigate to Microsoft Azure Portal.

Search for App Services.

Select:

App Services → Create → Web App

Step 2 – Configure the Basics

The Web App name must be globally unique within the applicable Azure hostname namespace.

Your application receives a default hostname similar to:

https://myapp-lwm-demo.azurewebsites.net

The exact hostname format can vary for newer deployments.

Step 3 – Configure the App Service Plan

Under the pricing configuration:

1. Select Create new.

2. Enter my-free-plan.

3. Select Explore pricing plans.

4. Choose Free F1, if available for the selected configuration.

5. Confirm the selection.

Step 4 – Review and Create

Select:

Review + create → Create

Wait for the deployment to finish.

Step 5 – Open the Web App

Select Go to resource.

On the Overview page, locate the default URL and open it.

Before deploying application code, Azure normally displays a default hosting or placeholder page.

Expected result

        Azure Portal
             |
             v
       Create Web App
             |
             v
      App Service Plan
             |
             v
       Deploy Resource
             |
             v
     Default Azure URL
             |
             v
      Web App Running

At this point, the Azure hosting resource exists, but your custom application has not yet been deployed.

Part 6 – Deploying Applications to Azure App Service

12. What Are the Different Deployment Methods?

Azure App Service supports multiple deployment approaches.

For production, automated CI/CD is generally preferable to manual FTP deployment.

13. Hands-on Demo: Deploy a Node.js Application Using ZIP Deploy

Step 1 – Create the project

Create a folder named:

nodeapp

Inside it, create two files:

nodeapp
   |
   +-- server.js
   |
   +-- package.json

Step 2 – Create server.js

const http = require('http');

const port = process.env.PORT || 8080;

const server = http.createServer((req, res) => {

    const appName =
        process.env.APP_NAME || 'Azure App Service';

    res.writeHead(200, {
        'Content-Type': 'text/html; charset=utf-8'
    });

    res.end(`
        <!DOCTYPE html>
        <html>
        <head>
            <title>Azure App Service Demo</title>
        </head>
        <body style="font-family:Arial;text-align:center">
            <h1>Hello from ${appName}!</h1>
            <p>Deployed using Azure ZIP Deploy.</p>
            <p>Hosting Platform: Azure App Service</p>
        </body>
        </html>
    `);
});

server.listen(port, () => {
    console.log(`Server running on port ${port}`);
});

Explanation:

• http.createServer() creates an HTTP server.

• process.env.PORT reads the port provided by the hosting environment.

• process.env.APP_NAME reads the configured application name.

• server.listen() starts the HTTP server.

This is a simple demonstration. Production applications should safely encode any configuration values inserted into HTML.

Step 3 – Create package.json

{
  "name": "azure-appservice-demo",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "start": "node server.js"
  }
}

The start script tells Node.js how to launch the application.

Step 4 – Create the ZIP file

Select:

• server.js

• package.json

Compress both files into:

nodeapp.zip

The ZIP structure should be:

nodeapp.zip
    |
    +-- server.js
    |
    +-- package.json

Avoid accidentally nesting the project inside an additional directory:

nodeapp.zip
    |
    +-- nodeapp
          |
          +-- server.js
          +-- package.json

The second structure may cause deployment or startup problems when the platform expects the application files at the deployment root.

Step 5 – Deploy using Kudu

Open your Azure Web App.

Navigate to:

Development Tools → Advanced Tools → Go

Kudu is an App Service deployment and diagnostic environment. Available interfaces vary between Windows and Linux hosting configurations.

Where supported, select:

Tools → Zip Push Deploy

Upload nodeapp.zip.

Alternatively, use Azure CLI ZIP deployment:

az webapp deploy \
  --resource-group appservice-demo-rg \
  --name myapp-lwm-demo \
  --src-path nodeapp.zip \
  --type zip

The ZIP deployment method expects a deployable application package. For projects requiring a build, install, or compilation step, perform that step in CI/CD or explicitly configure supported build automation.

Step 6 – Restart and verify

Restart the Web App if necessary.

Open the application URL.

Expected output:

Hello from Azure App Service!

Deployed using Azure ZIP Deploy.

Hosting Platform: Azure App Service

Key points

• ZIP Deploy is useful for simple deployments.

• Package the correct application files.

• Confirm that the runtime and startup command are configured correctly.

• Inspect deployment logs if the application does not start.

Part 7 – Deploying ASP.NET Core Web API to Azure App Service

This section extends the original material with a practical .NET example.

14. Create an ASP.NET Core Web API

Step 1 – Create the project

dotnet new webapi -n AzureAppServiceDemo

Navigate to the project folder:

cd AzureAppServiceDemo

Step 2 – Configure a simple endpoint

In Program.cs:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/", () => "Hello from Azure App Service!");

app.MapGet("/api/health", () =>
{
    return Results.Ok(new
    {
        Status = "Healthy",
        Application = "AzureAppServiceDemo",
        Date = DateTime.UtcNow
    });
});

app.Run();

Step 3 – Test locally

dotnet run

Open the local URL displayed in the terminal.

You should receive:

Hello from Azure App Service!

Step 4 – Publish the application

dotnet publish -c Release -o ./publish

The publish folder contains the compiled application and required deployment files.

Example:

publish
   |
   +-- AzureAppServiceDemo.dll
   +-- AzureAppServiceDemo.deps.json
   +-- AzureAppServiceDemo.runtimeconfig.json
   +-- appsettings.json
   +-- web.config (Windows publish, when generated)
   +-- Other Dependencies

Step 5 – Package the published files

Using PowerShell:

Compress-Archive `
  -Path .\publish\* `
  -DestinationPath .\app.zip `
  -Force

Step 6 – Create an Azure Web App

In the Azure Portal:

The runtime stack should be compatible with the application's target framework.

Step 7 – Deploy using Azure CLI

az login

Deploy the ZIP package:

az webapp deploy \
  --resource-group appservice-demo-rg \
  --name my-dotnet-api-demo \
  --src-path app.zip \
  --type zip

Step 8 – Test the deployed API

https://my-dotnet-api-demo.azurewebsites.net/api/health

Expected JSON response:

{
  "status": "Healthy",
  "application": "AzureAppServiceDemo",
  "date": "2026-10-15T09:00:00Z"
}

The date above is an example. The endpoint returns the actual UTC time when called.

Deployment flow

       ASP.NET Core Source
                |
                v
           dotnet restore
                |
                v
           dotnet build
                |
                v
           dotnet publish
                |
                v
          Publish Folder
                |
                v
            ZIP Package
                |
                v
          Azure App Service
                |
                v
          ASP.NET Core API
                |
                v
            HTTP Response

Interview key point: For a typical ASP.NET Core framework-dependent deployment, the application is compiled using dotnet publish, and the published output is deployed to an App Service configured with a compatible runtime.

Part 8 – Application Settings and Environment Variables

15. What Are Application Settings?

Application settings are configuration values stored in Azure App Service and made available to the application at runtime.

They allow environment-specific behavior without modifying application code.

Examples include:

• Application names.

• API endpoints.

• Feature flags.

• Connection strings.

• Logging levels.

• Authentication configuration.

16. Why Should We Avoid Hardcoding Configuration?

Consider the following example:

string apiUrl = "https://production-api.example.com";

The production URL is hardcoded.

If the application moves to a development environment, the source code must be changed or replaced.

Instead, use configuration:

string? apiUrl =
    builder.Configuration["ApiSettings:BaseUrl"];

The same code can run in multiple environments with different configuration values.

17. Configure Application Settings in Azure Portal

Open:

App Service → Settings → Environment variables

The portal may present this area as Configuration, depending on the current interface.

Add:

Save and apply the settings.

Changing App Service configuration commonly triggers an application restart.

Reading the value in Node.js

const appName = process.env.APP_NAME;

Reading the value in ASP.NET Core

var appName =
    builder.Configuration["APP_NAME"];

Nested ASP.NET Core configuration

Suppose your appsettings.json contains:

{
  "ApiSettings": {
    "BaseUrl": "https://localhost:7001"
  }
}

In Azure App Service, configure:

Name:  ApiSettings__BaseUrl
Value: https://api.example.com

ASP.NET Core interprets the double underscore __ as a configuration hierarchy separator.

var baseUrl =
    builder.Configuration["ApiSettings:BaseUrl"];

In the default ASP.NET Core configuration pipeline, environment variables override corresponding values from appsettings.json.

18. Application Settings vs Connection Strings

For ASP.NET Core, a commonly used environment-variable naming convention is:

ConnectionStrings__DefaultConnection

Then read it using:

var connectionString =
    builder.Configuration
           .GetConnectionString("DefaultConnection");

Security note: Environment variables are useful for configuration, but they are not a complete secrets-management solution. For production credentials, prefer Managed Identity and Azure Key Vault where supported.

Part 9 – Custom Domains and SSL Certificates

19. What Is a Custom Domain?

By default, Azure App Service provides a hostname under azurewebsites.net.

Example:

https://myapp.azurewebsites.net

For a business website, you may want:

https://www.example.com

This requires a custom domain binding.

Custom domain configuration flow

          Domain Registrar
                 |
                 v
          DNS Configuration
                 |
          +------+------+
          |             |
          v             v
       CNAME           TXT
       Record         Verification
          |             |
          +------+------+
                 |
                 v
         Azure App Service
                 |
                 v
        Custom Domain Binding
                 |
                 v
       https://www.example.com

20. How to Configure a Custom Domain

1. Purchase or use an existing domain.

2. Open the Azure Web App.

3. Navigate to Custom domains.

4. Select Add custom domain.

5. Enter the hostname.

6. Add the DNS records requested by Azure.

7. Complete ownership verification.

8. Create the domain binding.

CNAME records are commonly used for subdomains such as www. Apex/root domains may require different DNS record types.

Custom domain support generally requires a paid App Service tier.

21. What Is SSL/TLS in Azure App Service?

SSL/TLS encrypts communication between the browser and the hosted application.

Without HTTPS, traffic may be exposed to interception or modification.

With HTTPS, the connection is encrypted and the server's identity can be validated through its certificate.

HTTPS communication

            User Browser
                 |
                 v
          HTTPS Request
                 |
                 v
         TLS Certificate
                 |
                 v
        Azure App Service
                 |
                 v
          Web Application

Azure App Service Managed Certificate

Azure supports free App Service Managed Certificates for eligible custom domains and configurations.

Important points:

• Azure manages certificate issuance and renewal.

• Certificates have eligibility and feature limitations.

• Custom certificate import is available for other scenarios.

• HTTPS-only mode can redirect or reject insecure HTTP access according to platform behavior.

Enable:

App Service → Configuration / TLS settings → HTTPS Only

The exact portal navigation may vary.

Interview key point: A custom domain maps a business hostname to the application. A TLS certificate secures HTTPS communication for that hostname.

Part 10 – Deployment Slots and Zero-Downtime Deployment

22. What Are Deployment Slots?

A deployment slot is a separate, live environment associated with an Azure Web App.

Each slot has its own hostname and can contain a different version of the application.

For example:

Deployment slots are supported on Standard, Premium, and Isolated tiers, subject to SKU limits.

Deployment slot architecture

              Azure App Service
                     |
             App Service Plan
                     |
           +---------+---------+
           |                   |
           v                   v
     Production Slot       Staging Slot
       Version 1             Version 2
           |                   |
           v                   v
       Real Users         QA Testing
           |                   |
           +---------+---------+
                     |
                 Slot Swap
                     |
           +---------+---------+
           |                   |
           v                   v
     Production Slot       Staging Slot
       Version 2             Version 1

Why use deployment slots?

Deploying directly to production introduces risks:

• Users may experience application startup delays.

• A faulty deployment becomes visible immediately.

• Rollback may require another deployment.

• Configuration changes may cause interruptions.

Deployment slots allow a new release to be deployed, warmed up, and validated before production traffic is switched.

Microsoft recommends staging-slot deployment and swapping as a production deployment practice.

Microsoft Learn

+1

23. Hands-on Demo: Create a Staging Slot

Prerequisite: An App Service Plan that supports deployment slots, such as Standard S1.

Step 1 – Open the Web App

Navigate to:

App Service → Deployment slots

Select Add slot.

Step 2 – Configure the slot

Select Add.

The staging slot receives its own hostname, typically similar to:

https://myapp-staging.azurewebsites.net

Step 3 – Deploy Version 2 to staging

Deploy the updated application to the staging slot, not production.

For an ASP.NET Core application:

az webapp deploy \
  --resource-group appservice-demo-rg \
  --name my-dotnet-api-demo \
  --slot staging \
  --src-path app-v2.zip \
  --type zip

Step 4 – Test staging

Open the staging URL and validate:

• Application startup.

• Authentication.

• API responses.

• Database connectivity.

• Health checks.

• Critical business workflows.

Step 5 – Swap staging and production

In the Azure Portal:

Deployment slots → Swap

Choose:

Review the configuration and initiate the swap.

Azure performs the required warm-up and routing changes before completing the operation.

Step 6 – Roll back if necessary

If the new release causes problems, swap the slots again to restore the previous production application version.

Rollback is fast, but not every change is reversible. Database schema migrations, external side effects, and configuration changes must be considered separately.

24. What Are Sticky Slot Settings?

Not all configuration values should move between staging and production.

For example:

Production:
ConnectionStrings__DefaultConnection
        |
        v
Production Database

Staging:
ConnectionStrings__DefaultConnection
        |
        v
Staging Database

If these connection strings are exchanged during a swap, the new production application might connect to the staging database.

To prevent this, configure the connection string as a Deployment slot setting.

In the Azure Portal:

Staging Slot → Environment variables

Select the setting and enable the deployment slot setting option.

Sticky settings remain associated with their original slots during swapping.

Some platform configuration, including managed identities and networking integration, is also slot-specific.

Microsoft Learn

Interview key points

• Slots allow deployment without immediately affecting production.

• Slots use the resources of their App Service Plan.

• Slot swaps include application warm-up.

• Sticky settings prevent environment-specific values from moving.

• A reverse swap can restore the previous application version.

Part 11 – Scaling Azure App Service

25. What Is Scaling?

Scaling means increasing or decreasing application resources based on workload requirements.

Azure App Service supports two primary scaling approaches:

1. Vertical scaling — Scale Up/Down.

2. Horizontal scaling — Scale Out/In.

26. Vertical Scaling – Scale Up and Scale Down

Vertical scaling changes the compute size or pricing tier.

For example:

        Before Scaling
              |
              v
         Basic B1 Plan
         1 vCPU / RAM
              |
              v
           Scale Up
              |
              v
         Larger Plan
       More CPU and RAM

The CPU and memory values depend on the selected SKU.

When to use vertical scaling

Use scale-up when:

• Application memory is insufficient.

• CPU-intensive processing requires more compute.

• A feature requires a higher pricing tier.

• Individual requests need more resources.

Portal steps

1. Open the App Service Plan.

2. Select Scale up.

3. Review the available pricing tiers.

4. Select the required tier.

5. Apply the change.

Scaling operations may cause restarts or other brief application effects. Plan production changes accordingly.

27. Horizontal Scaling – Scale Out and Scale In

Horizontal scaling changes the number of worker instances.

Example:

             Incoming Traffic
                    |
                    v
              Load Balancer
                    |
          +---------+---------+
          |         |         |
          v         v         v
       Worker 1  Worker 2  Worker 3
          |         |         |
          v         v         v
        App       App       App

Scale Out

Adds more worker instances to distribute traffic.

Example:

2 Instances
     |
     v
Scale Out
     |
     v
4 Instances

Scale In

Removes unnecessary worker instances when traffic decreases.

4 Instances
     |
     v
Scale In
     |
     v
2 Instances

Scale Up vs Scale Out

28. What Is Autoscaling?

Autoscaling automatically adjusts worker capacity based on metrics or configured rules.

Common metrics include:

• CPU percentage.

• Memory percentage, where supported.

• HTTP request volume.

• Other supported Azure Monitor metrics.

Autoscaling architecture

              Azure Monitor
                    |
                    v
              CPU Metrics
                    |
          +---------+---------+
          |                   |
          v                   v
       CPU > 70%           CPU < 30%
       5 Minutes          10 Minutes
          |                   |
          v                   v
       Scale Out           Scale In
          |                   |
          v                   v
      Add Instance       Remove Instance

These thresholds are example policies, not Azure defaults.

29. Hands-on Demo: Configure Autoscale Rules

Prerequisite: An App Service Plan and scaling mode that support metric-based autoscaling.

Step 1 – Open Scale Out

Navigate to:

App Service Plan → Scale out

Select the appropriate autoscale configuration option.

Step 2 – Configure instance limits

Step 3 – Create a scale-out rule

Step 4 – Create a scale-in rule

Step 5 – Save the configuration

Azure Monitor evaluates the rules and adjusts capacity within the configured minimum and maximum limits.

Important considerations

• Autoscaling is not instantaneous.

• New instances require startup time.

• Scaling rules should avoid frequent oscillation.

• Applications should avoid storing important user session state only in local memory.

• Distributed caches and external session stores are useful for multi-instance applications.

Part 12 – Managed Identity and Azure Key Vault

Additional production-security concepts

30. What Is Managed Identity?

Managed Identity allows an Azure resource to authenticate to supported Azure services without storing credentials directly in application code.

For example, an ASP.NET Core Web API can use Managed Identity to access Azure Key Vault or Azure SQL Database.

Authentication flow

          ASP.NET Core Web API
                   |
                   v
            Managed Identity
                   |
                   v
             Microsoft Entra ID
                   |
                   v
              Access Token
                   |
                   v
              Azure Service

Types of Managed Identity

31. Enable Managed Identity in Azure App Service

1. Open the Azure Web App.

2. Navigate to Identity.

3. Select System assigned.

4. Change the status to On.

5. Save the configuration.

6. Grant the identity the required permissions on the target Azure resource.

Enabling the identity alone does not automatically grant access to Azure SQL Database or Key Vault.

32. What Is Azure Key Vault?

Azure Key Vault securely stores and manages:

• Secrets.

• Encryption keys.

• Certificates.

• Sensitive application configuration.

For example, instead of storing a third-party API key directly in an application setting, store it in Key Vault.

Key Vault integration

            ASP.NET Core API
                   |
                   v
          App Service Setting
                   |
                   v
          Key Vault Reference
                   |
                   v
             Azure Key Vault
                   |
                   v
               Secret Value

Example Key Vault reference

@Microsoft.KeyVault(
  SecretUri=https://myvault.vault.azure.net/secrets/MyApiKey
)

This is a configuration value, not C# code.

The Web App's Managed Identity must have permission to read the secret.

Azure App Service can resolve Key Vault references as ordinary application settings, keeping secret values outside the deployed source code.

Microsoft Learn

Read the setting in ASP.NET Core

var apiKey =
    builder.Configuration["MyApiKey"];

Your application can consume the resolved value through normal configuration APIs.

Key points

• Managed Identity avoids storing credentials for supported Azure authentication scenarios.

• Key Vault centralizes secret management.

• Access should follow the principle of least privilege.

• Secrets should never be written to application logs.

Part 13 – Connecting Azure App Service to Azure SQL Database

33. How Does ASP.NET Core Connect to Azure SQL?

A common enterprise architecture uses Azure App Service for the application and Azure SQL Database for persistent storage.

              Angular Frontend
                     |
                     v
                HTTPS API
                     |
                     v
             Azure App Service
                     |
                     v
              ASP.NET Core API
                     |
                     v
                 EF Core
                     |
                     v
             Azure SQL Database

Option 1 – SQL Authentication

A connection string may look like:

Server=tcp:myserver.database.windows.net,1433;
Initial Catalog=PortfolioDb;
User ID=<sql-user>;
Password=<sql-password>;
Encrypt=True;
TrustServerCertificate=False;

The placeholders must be replaced through secure configuration, not hardcoded into source code.

Option 2 – Managed Identity Authentication

For a production application, Microsoft Entra authentication with Managed Identity is often preferable.

Example connection string:

Server=tcp:myserver.database.windows.net,1433;
Database=PortfolioDb;
Authentication=Active Directory Managed Identity;
Encrypt=True;

The Managed Identity must be configured as an authorized database principal and granted appropriate permissions.

EF Core configuration

builder.Services.AddDbContext<AppDbContext>(options =>
{
    options.UseSqlServer(
        builder.Configuration.GetConnectionString(
            "DefaultConnection"));
});

Required package:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer

For managed identity authentication, ensure the application uses compatible Microsoft SQL client libraries and authentication dependencies.

Important security practices

• Prefer identity-based authentication.

• Avoid unrestricted public database access.

• Use private networking when required.

• Grant only necessary database permissions.

• Store secrets securely when passwords are unavoidable.

Part 14 – Azure App Service Networking

Additional networking concepts

34. What Is VNet Integration?

VNet Integration allows an Azure App Service application to make outbound connections to resources reachable through an Azure Virtual Network.

For example:

             Azure App Service
                    |
                    v
            VNet Integration
                    |
                    v
              Azure VNet
                    |
                    v
             Private Endpoint
                    |
                    v
             Azure SQL Database

This is useful when an application must communicate with private services.

Important distinction: VNet Integration controls outbound connectivity from App Service. It does not, by itself, make the Web App's inbound endpoint private.

Microsoft documents VNet Integration support on eligible dedicated tiers, including Basic and Standard.

Microsoft Learn

35. What Is a Private Endpoint?

A Private Endpoint provides a private IP-based connection to a supported Azure service through Azure Private Link.

For Azure App Service, a Private Endpoint can be used to provide private inbound access to the Web App.

VNet Integration vs Private Endpoint

Production architecture

            Corporate Network
                   |
                   v
               VPN / WAN
                   |
                   v
               Azure VNet
                   |
                   v
          App Service Private
               Endpoint
                   |
                   v
             ASP.NET Core API
                   |
                   v
           VNet Integration
                   |
                   v
          Azure SQL Private
               Endpoint
                   |
                   v
            Azure SQL Database

Private DNS resolution and the appropriate network access settings are essential for this architecture.

36. What Are Access Restrictions?

Access restrictions allow administrators to control which clients can reach an App Service endpoint.

For example, an internal administration application might accept requests only from approved corporate IP ranges.

Other relevant controls include:

• HTTPS Only.

• Minimum TLS version.

• Microsoft Entra authentication.

• App Service Authentication.

• Azure Web Application Firewall through a suitable front-end service.

• Private Endpoints.

• Role-based access control for Azure management operations.

Part 15 – Monitoring and Troubleshooting

Additional production-operations concepts

37. What Is Azure Application Insights?

Application Insights is an application performance monitoring capability within Azure Monitor.

It helps developers investigate:

• Application exceptions.

• Failed HTTP requests.

• Response times.

• Dependency performance.

• Database call latency.

• Application telemetry.

• Distributed traces.

Monitoring architecture

              ASP.NET Core API
                     |
                     v
              OpenTelemetry
                     |
                     v
            Application Insights
                     |
          +----------+----------+
          |          |          |
          v          v          v
       Requests   Exceptions  Dependencies
          |          |          |
          +----------+----------+
                     |
                     v
               Azure Monitor

38. Configure Application Insights for ASP.NET Core

A common approach is Azure Monitor OpenTelemetry.

Install:

dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore

In Program.cs:

using Azure.Monitor.OpenTelemetry.AspNetCore;

var builder = WebApplication

Configure the Application Insights connection string securely in Azure App Service:

The SDK can use this configuration to export telemetry to the configured Application Insights resource.

Tags: Azure App Service, Azure Web Apps, Azure App Service Plan, Azure PaaS, ASP.NET Core, Azure Deployment, Azure DevOps, CI/CD, Deployment Slots, Azure Autoscaling, Azure Key Vault, Managed Identity, Application Insights, Azure SQL Database, Azure Interview Questions