# Azure App Service

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/azure-app-service

## Quick definition

Azure App Service lets you host websites and web APIs without worrying about the servers. You upload your code and Microsoft takes care of the rest, like security patches and scaling. It works with many programming languages and connects to databases easily. This makes it simpler to run web applications in the cloud.

## Simple meaning

Think of Azure App Service as a managed apartment building for your web applications. When you own a house, you are responsible for everything from fixing the roof to mowing the lawn. But if you rent an apartment, the landlord handles maintenance, repairs, and upkeep. Similarly, with Azure App Service, you do not own or manage the servers that run your web app. Microsoft owns them, and their team ensures the operating system is patched, the network is stable, and the hardware is working. You just move your code in like furnishing an apartment, and the application runs. 

 In a traditional setup, you would buy a server, install an operating system, configure a web server like IIS or Apache, set up a database, and then handle backups and scaling manually. If your website gets popular and many people visit, you would need to buy more servers or upgrade the hardware. That would take time and money. With Azure App Service, you can change a setting to add more resources instantly, often with just a click or a command. The platform automatically balances incoming traffic across multiple instances of your app, ensuring users get fast responses even during traffic spikes. 

Azure App Service provides built-in features that you would otherwise need to configure separately. It supports deployment slots, so you can test a new version of your site before making it live. It integrates with Azure Active Directory for authentication, so users can log in with their work or school accounts. It also provides automatic SSL certificates for HTTPS, so data between users and your site is encrypted. All of these features are part of the service. You do not need to install or configure additional software yourself. This dramatically reduces the complexity of hosting web applications, especially for teams that want to focus on writing code rather than managing infrastructure.

## Technical definition

Azure App Service is a Platform as a Service (PaaS) compute offering within Microsoft Azure that enables developers to host web applications, RESTful APIs, and mobile backends. It abstracts the underlying infrastructure, including virtual machines, operating system patches, and load balancing, allowing developers to focus on code. The service supports multiple runtime stacks such as .NET, .NET Core, Java, Node.js, Python, PHP, and Ruby, and it can run custom containers via Web App for Containers. 

 The architecture of Azure App Service is built on a multi-tenant system where each App Service Plan defines a set of compute resources and scaling capabilities. An App Service Plan specifies the region, the number of virtual machine instances, the size of each instance (e.g., B1, S1, P1v2), and whether the plan is shared or dedicated. All apps within the same plan share these resources. When you scale out, Azure adds more VM instances to the plan, and the load balancer distributes requests across them. 

 The service integrates with Azure DevOps, GitHub, Bitbucket, and local Git repositories for continuous deployment. Behind the scenes, Azure manages a sandbox that isolates each app. This sandbox restricts file system access, network calls, and memory usage, ensuring one tenant does not interfere with another. For high density hosting, Azure uses a technology called 'App Service Environment' which runs in a customer's virtual network, providing dedicated and isolated instances. 

 Networking features include custom domains, SSL/TLS termination at the front end, and integration with Azure Virtual Network for accessing on-premises resources via VPN or ExpressRoute. Authentication and authorization are handled at the platform level using Azure Active Directory, Facebook, Google, and other identity providers, without requiring code changes. The service also offers built-in auto-scaling rules based on metrics like CPU percentage or memory usage, and manual scaling for planned capacity. 

 In terms of monitoring, Azure App Service integrates with Azure Monitor and Application Insights for tracing, logging, and performance analysis. The 'Diagnose and Solve Problems' blade offers automated checks for common issues like high memory or slow requests. Deployment slots allow zero-downtime deployments: you can swap a staging slot with the production slot after testing, and automatically warm up the instance before switching traffic. 

 For exam AZ-104 and Azure Fundamentals, it is important to understand the difference between App Service Plan and App Service, how scaling works, and the fact that it is a PaaS offering. The AWS practitioner and developer exams may compare it to AWS Elastic Beanstalk or AWS App Runner. For Google ACE and Digital Leader, the comparable service is Google App Engine. Knowing the shared responsibility model is also key: with PaaS like App Service, you manage the application and data, while Microsoft manages the OS, runtime, and infrastructure. 

 Finally, App Service supports hybrid connectivity: you can connect to Azure SQL Database, Cosmos DB, or on-prem SQL Server using hybrid connections or VNet integration. The service also offers managed backups, auto-healing, and staging environments. However, some limitations exist: long-running background tasks may require Azure Functions or WebJobs, and custom Windows authentication requires additional configuration. Understanding these boundaries helps avoid confusion in exam questions about when to use App Service versus other compute options like Azure Virtual Machines or Azure Kubernetes Service.

## Real-life example

Imagine you want to open a food truck. You have a secret recipe for tacos, and you want to sell them in a busy downtown area. The classic way to do this is to buy a truck, get a generator, install a cooking station, stock ingredients, and hire a driver. You need to maintain the engine, pass health inspections, and park in different spots each day. That is like running your own server. You have full control but also full responsibility for everything mechanical and logistical. 

 Now consider using a service like Azure App Service. Instead of buying a food truck, you rent a permanent booth inside a popular food hall. The food hall provides the building, the electricity, the ventilation hood, water, waste disposal, and cleaning staff. They also manage the dining area and handle health code compliance. All you need to do is bring your taco recipe, prepare the food, and serve customers. If the lunch rush is huge, the food hall can open more serving windows for you, or even clone your booth with extra staff. They handle the infrastructure; you handle the food. 

 In cloud terms, the food hall is the App Service environment. The building and utilities are the underlying servers, network, and storage. The ability to open more serving windows when lines are long is like scaling out your App Service Plan to add more instances. The food hall's licensing and insurance are equivalent to Microsoft managing security patches and compliance certifications. If you want to test a new salsa recipe before serving it to the public, you can use a side prep station that is not open to customers. This is like a deployment slot, allowing you to swap in the new version only after you are confident it works. 

 You also do not have to worry about the food hall losing its lease or closing down. If one booth area needs repair, they move you to another. Similarly, Azure App Service has high availability and will automatically recover your app if a physical server fails. This analogy shows how moving from infrastructure management to a managed platform lets you focus on what matters: your core business or application logic, rather than the underlying hardware and networking.

## Why it matters

For IT professionals, Azure App Service represents a paradigm shift from managing infrastructure to delivering applications. In traditional environments, each new web application required provisioning a server, installing an OS, setting up a web server, configuring a database connection string, and ensuring network security. This process could take days or weeks. With App Service, the same task takes minutes, and the platform handles patching and uptime automatically. This time saving allows teams to iterate faster, deploy more frequently, and reduce the risk of human error during manual configuration. 

 From a cost perspective, App Service uses a consumption-based model. You pay only for the compute resources your app uses, described by the App Service Plan tier and instance count. During off-peak hours, you can scale in to save money, and during high traffic, scale out automatically. This elasticity is impossible with fixed on-premises servers. For organizations migrating from on-premises, App Service reduces capital expenditure on hardware and ongoing operational costs for power, cooling, and maintenance. 

 In terms of operations, App Service provides diagnostic tools, log streaming, and integration with Azure Monitor. When an application crashes, the platform can auto-heal by restarting the process. For compliance, App Service holds certifications like SOC, ISO, PCI DSS, so regulated industries can host applications without building custom security controls. However, IT pros must understand the shared responsibility: Microsoft secures the infrastructure, but the application code, data, and identity configuration remain the customer's responsibility. Misunderstanding this boundary leads to security gaps, such as leaving default settings or weak authentication methods. 

 Finally, the skill of using PaaS services like App Service is increasingly important for cloud architects and DevOps engineers. Knowing when to use App Service versus Azure Kubernetes Service, Azure Functions, or Virtual Machines is a common decision point in real-world projects and in certification exams. The wrong choice can lead to overpaying, under-scaling, or unnecessary complexity. Hence, mastering App Service fundamentals is a foundational step in cloud proficiency.

## Why it matters in exams

Azure App Service appears across multiple certification exams because it is a core PaaS compute service. For the AZ-104 Microsoft Azure Administrator exam, you must understand how to create and configure App Service plans, deploy applications, scale the plan, and configure custom domains and SSL certificates. Questions may ask about the appropriate pricing tier for a given workload or how to enable auto-scaling. You might be asked to troubleshoot a deployment failure related to incorrect app settings or a misconfigured VNet integration. 

 In the Azure Fundamentals (AZ-900) exam, App Service is introduced as a prime example of PaaS. You will need to differentiate it from Infrastructure as a Service (IaaS) like Azure Virtual Machines. A typical question: 'Which service provides a fully managed platform for hosting web applications without managing the OS?' The correct answer is Azure App Service. This is a straightforward recall question but foundational. 

 For AWS certification exams, particularly AWS Cloud Practitioner and AWS Developer Associate, Azure App Service is not directly tested. However, understanding it helps in comparison questions or in general cloud concepts like PaaS. The exam may ask about the equivalent AWS service, AWS Elastic Beanstalk. If you are cross-trained, being able to map concepts aids in answering scenario-based questions that ask you to choose the right compute service. 

 Google Cloud exams (ACE, Digital Leader) include Google App Engine, which is functionally similar to Azure App Service. Questions may test your understanding of managed platforms versus serverless versus containers. Knowing the features of App Service (auto-scaling, deployment slots, custom domains, VNet integration) helps you recognize analogous features on Google Cloud. The 'Digital Leader' exam may ask for a high-level understanding of how App Service fits into an enterprise cloud strategy. 

 In all these exams, common question themes include: identifying the service for a web app with minimal management, scaling behaviors, high-availability configurations (e.g., deploying across multiple instances), and hybrid connectivity. Questions often present a scenario where a company wants to move from on-premises IIS to the cloud, and you need to recommend App Service with appropriate scaling and cost options. The tricky part is recognizing when App Service is inappropriate, such as when the application requires full OS-level customizations or specific Windows features not exposed by the sandbox. In such cases, Azure Virtual Machines or Azure Kubernetes Service would be better answers. 

 To succeed, memorize the core concepts: App Service Plan (tiers: Free, Shared, Basic, Standard, Premium, Isolated), scaling (vertical vs. horizontal), deployment slots, auto-healing, 'always on' setting, and integration with Azure AD. Practice scenario questions that mix these terms, like 'A web app needs 99.95% SLA, supports HTTPS, and must be able to scale to 10 instances.' That requires Standard tier or above. Understanding these details sharpens your exam readiness.

## How it appears in exam questions

In certification exams, Azure App Service questions typically fall into scenario, configuration, and troubleshooting patterns. A common scenario question describes a company wanting to host an e-commerce website that experiences high traffic during holidays. The question might offer three options: Azure Virtual Machines, Azure App Service, or Azure Functions. The correct answer is Azure App Service because it supports automatic scaling, has a consistent SLA for production workloads, and the company does not need OS-level control. The distractor is Azure Functions, which is better for event-driven, short-lived tasks, not for a full website. 

 Configuration questions often present a developer who has deployed a web app but users report HTTP 500 errors. The question shows a configuration screen with connection strings, app settings, and the 'Always On' toggle. You might need to identify which setting is missing or misconfigured, such as the database connection string in the 'Connection Strings' section rather than in 'Application Settings.' Another common config question is about enabling HTTPS-only traffic: you must select the 'HTTPS Only' setting in the TLS/SSL settings blade. 

 Troubleshooting questions might describe a situation where after a deployment, the new version of the app is behaving incorrectly, but the traffic is still going to the old version. The cause could be that the deployment slot swap was not performed, or the auto-swap feature was misconfigured. Another troubleshooting scenario: a web app runs slowly when many users are active. The question gives metrics showing high CPU and memory. The solution is to scale up (increase instance size) or scale out (increase instance count), depending on whether the bottleneck is per-instance capacity or overall throughput. You must know that scaling out requires Standard tier or higher. 

 Questions may also test your understanding of the 'Shared responsibility model.' For example, 'You deployed a web app to Azure App Service. Who is responsible for patching the operating system?' The correct answer is Microsoft. A common trick: the question might mention 'security updates for the .NET framework' which is part of the runtime, still managed by Microsoft. Another angle: 'Who is responsible for the application code's security vulnerabilities?' The answer is the customer. 

 Finally, some questions require linking App Service with other Azure services. For instance, 'You need to add authentication for corporate users to access an App Service web app. Which Azure service should you use?' Azure Active Directory. Or 'You want to connect a web app to an on-premises database without opening firewall ports.' The answer is Hybrid Connections or VNet integration. These integration questions test your ability to compose solutions. They are common in AZ-104 and AWS SAA cross-cloud comparisons.

## Example scenario

A startup called 'PetPics' wants to launch a web application where users can upload photos of their pets and see them displayed in a gallery. The founders are not server experts; they are software developers. They choose Azure App Service because they can focus on writing the code for uploading and displaying pictures. 

 They create an Azure App Service plan in the Standard tier, which provides 99.95% uptime, supports auto-scaling, and includes deployment slots. They write their app in Node.js and configure a connection to Azure Blob Storage for storing the uploaded images. They set up continuous deployment from a GitHub repository, so every time they push code to the main branch, Azure automatically builds and deploys the new version to a staging slot. 

 After testing, they perform a slot swap to move the new version to production with zero downtime. Soon the app goes viral. Pet owners across the globe start uploading millions of photos. Traffic spikes, but the App Service auto-scales from 2 instances to 10 instances within minutes, based on CPU usage. Users do not experience slowdowns. The startup pays more during the peak, but the cost is still much lower than provisioning servers for peak capacity. 

 Later, they add authentication so users log in with their Google accounts. They enable the built-in authentication module in App Service, which handles the OAuth flow. They also enable HTTPS-only and configure a custom domain 'petpics.com' with a free App Service Managed Certificate. The entire infrastructure management is handled by Azure. The scenario demonstrates how App Service accelerates time to market, handles scaling, and integrates with other services without requiring infrastructure expertise.

## Common mistakes

- **Mistake:** Confusing App Service with Azure Virtual Machines for every web application.
  - Why it is wrong: Virtual Machines are IaaS requiring full OS and application management. App Service is PaaS, easier and cheaper for standard web apps.
  - Fix: Use App Service when you don't need OS-level control. Use VMs only for custom software or configurations not supported by PaaS.
- **Mistake:** Thinking you must configure a web server (like IIS or NGINX) inside App Service.
  - Why it is wrong: Azure App Service provides the web server runtime automatically. You only need to upload your code.
  - Fix: Just deploy your application code; the platform handles the web server.
- **Mistake:** Assuming the Free tier is suitable for production workloads.
  - Why it is wrong: The Free tier has resource limits and no SLA, no custom domains, and no auto-scaling. It is for testing only.
  - Fix: Use at least the Basic tier for production; Standard or higher for scaling and deployment slots.
- **Mistake:** Setting connection strings under 'Application Settings' instead of 'Connection Strings.'
  - Why it is wrong: Connection strings must be in the dedicated 'Connection Strings' section to be correctly injected into the application environment.
  - Fix: Use the 'Connection Strings' blade for SQL or other database connections; use 'Application Settings' for simple key-value config values.
- **Mistake:** Forgetting to enable 'HTTPS Only' and assuming HTTPS is automatic.
  - Why it is wrong: App Service supports both HTTP and HTTPs. Without enforcing HTTPS, users can access the site over unencrypted connections.
  - Fix: In the TLS/SSL settings blade, set 'HTTPS Only' to On.
- **Mistake:** Attempting to use deployment slots without being in the Standard tier or higher.
  - Why it is wrong: Deployment slots are only available in Standard, Premium, and Isolated tiers. Using Basic tier will not show the slots option.
  - Fix: Upgrade the App Service Plan to Standard or higher to use deployment slots.
- **Mistake:** Assuming scaling out (adding instances) happens instantly and for free.
  - Why it is wrong: Scaling out takes a few minutes and increases cost. Free and Shared tiers do not support scaling out.
  - Fix: Use Standard tier or higher, and plan scaling based on expected traffic. Auto-scale can be configured, but be mindful of cost.

## Exam trap

{"trap":"A question states: 'You deploy a web app to Azure App Service on the Free tier. Users report that the site is slow. What should you do?' One option is 'Scale up to a larger instance size.' Another is 'Scale out to more instances.'","why_learners_choose_it":"Learners see 'scale up' or 'scale out' as standard fixes and may pick either, not realizing the Free tier does not support scaling in any direction.","how_to_avoid_it":"Always check the tier. If the scenario says Free or Shared tier, scaling is not available. The solution would be to change the App Service Plan to a higher tier first. Never assume scaling is possible without verifying the plan tier."}

## Commonly confused with

- **Azure App Service vs Azure Virtual Machines (IaaS):** Azure App Service is a fully managed PaaS where you upload code and Microsoft manages the OS and runtime. VMs require you to configure and maintain the entire operating system, install web server software, and manage patches. App Service is simpler but less flexible for custom software installations. (Example: If you need to install a third-party plugin that requires direct access to the Windows registry, you need a VM. If you only need to run PHP code from a git repository, use App Service.)
- **Azure App Service vs Azure Functions (Serverless):** App Service hosts web apps and APIs that are always running and listening for requests. Azure Functions runs only when triggered by an event, and it scales down to zero when idle. Functions are ideal for short-lived, event-driven tasks; App Service is for long-running web applications. (Example: A restaurant website that shows a menu works best on App Service because it responds to user requests at any time. A function that processes an uploaded image after a file is saved to Blob Storage is better as an Azure Function.)
- **Azure App Service vs Azure Kubernetes Service (AKS):** AKS is a container orchestration service that provides more control over containerized applications, including scaling, networking, and service discovery. App Service can run containers but abstracts the underlying orchestration. AKS requires more configuration but offers more flexibility for microservices architectures. (Example: If you have a single web app with a few web pages, use App Service. If you have 20 microservices that need to communicate and scale independently, consider AKS.)
- **Azure App Service vs Azure Cloud Services (Classic, PaaS for roles):** Cloud Services is an older PaaS offering that uses web and worker roles. It is being retired in favor of App Service and other modern services. App Service provides a simpler deployment model, better scaling options, and integrated deployment slots, whereas Cloud Services allowed more customization of the VM but at the cost of complexity. (Example: If you are starting a new project, choose App Service. Only maintain legacy Cloud Services if you have to, and plan migration.)
- **Azure App Service vs App Service Environment (ASE):** ASE is a fully isolated and dedicated version of App Service running inside a customer's virtual network. It provides extreme scale and network isolation but is more expensive. Regular App Service is multi-tenant and less expensive, but network integration is more limited. (Example: A bank that requires the web app to be completely isolated from other tenants and must meet strict regulatory requirements would use an ASE. A small e-commerce site can use regular App Service.)

## Step-by-step breakdown

1. **Plan the App Service Plan** — Before creating the app, decide on the region, pricing tier (Free, Shared, Basic, Standard, Premium, Isolated), and instance size. The tier determines available features and SLA. The plan is the container that holds one or more apps.
2. **Create the App Service resource in Azure Portal** — Search for 'App Service' in the Azure Portal. Provide a unique name, select the runtime stack (e.g., .NET 6, Node.js 14, Python 3.9), and choose the App Service Plan created in step 1. This step provisions the infrastructure.
3. **Configure application settings and connection strings** — In the App Service blade, go to Settings > Configuration. Add any environment variables (app settings) and database connection strings. These are injected into the application at runtime. This is how you avoid hard-coding secrets in code.
4. **Enable logging and monitoring** — Turn on Application Logging (file system or blob) and web server logging. Set up Application Insights for deeper performance monitoring. This helps in troubleshooting later.
5. **Configure custom domain and SSL/TLS** — Under Custom domains, add your domain (e.g., example.com). Then in TLS/SSL settings, upload or create a free App Service Managed Certificate. Enable HTTPS Only to enforce encrypted traffic.
6. **Deploy application code** — Use one of the supported deployment methods: local Git, GitHub Actions, Azure DevOps, FTP, or ZipDeploy. Push your code to the deploy endpoint. The platform builds and starts the app automatically.
7. **Set up deployment slots (for production apps)** — Create a staging slot under Deployment Slots. Deploy new code to staging, test it, then swap with production. This provides zero-downtime deployments. Auto-swap can be configured to swap automatically after successful deployment.
8. **Configure scaling rules** — In the Scale Out (App Service Plan) section, set rules for auto-scaling based on metrics like CPU percentage or memory usage. You can also schedule scaling based on time (e.g., scale out during business hours). Manual scaling is also available.
9. **Enable authentication and authorization** — Under Authentication / Authorization, turn on App Service Authentication. Choose a provider (Azure AD, Google, Facebook, etc.). The platform handles OAuth handshake and token validation without requiring code changes.
10. **Test and go live** — Browse the staging slot URL to verify the app works. After confirmation, perform the swap to make the staging slot the production slot. Monitor Application Insights for user traffic and errors. Adjust scaling rules if needed.

## Practical mini-lesson

In a real-world enterprise, Azure App Service is often used to host internal business applications, customer-facing websites, and API backends for mobile apps. A typical deployment process involves setting up a CI/CD pipeline using Azure DevOps or GitHub Actions. The pipeline builds the code, runs unit tests, packages the build, and then deploys it to a staging slot in App Service. After integration tests pass in staging, the pipeline automatically swaps the staging and production slots. This pattern eliminates downtime and reduces risk. 

 One important configuration detail professionals must know is the difference between 'Always On' and regular behavior. For basic tier apps, the platform may unload idle apps to save resources. If your app needs to respond quickly even after periods of inactivity, enable 'Always On' in the Application Settings. This keeps the app loaded, but it is only available in Basic tier and above. Without it, the first request after idle time can be slow because the app needs to warm up. 

 Another aspect is the use of WebJobs for background tasks. If your web app needs to process queues or run scheduled tasks, you can upload a WebJob as part of the App Service. This is simpler than creating a separate Azure Function, but has limitations like being tied to the App Service plan's resources. For heavy background processing, Azure Functions or a dedicated worker role is better. 

 When troubleshooting a misbehaving app, professionals first check the App Service logs by using the 'Log Stream' feature in the portal. Common issues include missing application settings, incorrect connection string format, or an unhandled exception in code. The 'Diagnose and Solve Problems' tool can detect common problems like high memory, slow page loads, or application crashes. It also provides actionable recommendations. 

 From a security perspective, you should never store secrets in code. Use Azure Key Vault with a managed identity to access credentials securely. The App Service can be given a system-assigned managed identity that authenticates to Key Vault without storing any keys. This is a best practice for production environments. Network restrictions can be implemented via IP restrictions and Access Restrictions, allowing access only from specific IP ranges or virtual networks. 

 Cost management is another practical concern. An App Service charges for each instance in the plan for the entire hour, even if the app uses low resources. Therefore, scaling down during off-hours or consolidating multiple low-traffic apps into one plan saves money. The Premium V3 tier offers faster CPUs and more memory per instance, suitable for compute-intensive applications. The Isolated tier via ASE is the most expensive and used only when strict isolation is required. 

using Azure App Service in practice involves planning the tier, setting up CI/CD, configuring network and authentication, monitoring performance, and managing cost. Professionals who master these steps can deploy and maintain robust web applications in the cloud efficiently.

## Commands

```
az webapp create --resource-group myRG --plan myPlan --name myApp --runtime "DOTNET|8.0"
```
Creates a new Azure App Service web app within a specified resource group and App Service plan, with a specific runtime stack.

*Exam note: Exam questions test that the --runtime parameter explicitly defines the language stack (e.g., DOTNET|8.0, NODE|18-lts). Remember that --plan must reference an existing App Service plan.*

```
az webapp config set --resource-group myRG --name myApp --startup-file "node index.js"
```
Sets a custom startup file or command for the web app, used for Node.js or custom containers.

*Exam note: Used in questions about custom startup commands for Linux web apps or containers. Exams may ask about --startup-file vs configuring startup in the portal.*

```
az webapp log tail --resource-group myRG --name myApp
```
Streams real-time logs from the web app to the console for debugging runtime issues.

*Exam note: Tests knowledge of live log streaming vs downloading logs via az webapp log download. Common in troubleshooting scenarios.*

```
az webapp config appsettings set --resource-group myRG --name myApp --settings "DB_CONNECTION_STRING=Server=tcp:myserver.database.windows.net"
```
Adds or updates application settings (environment variables) for the web app, overriding appsettings.json values.

*Exam note: Critical for managing connection strings and secrets. Exams test that app settings are encrypted at rest and can be referenced in code as environment variables.*

```
az webapp deployment slot create --resource-group myRG --name myApp --slot staging
```
Creates a deployment slot (e.g., staging) to enable staging environments and swap deployments.

*Exam note: Heavily tested in AZ-204 and AZ-305. Questions focus on slot-swapping behavior, auto-swap, and traffic routing.*

```
az webapp scale --resource-group myRG --plan myPlan --name myApp --number-of-workers 3
```
Scales out the App Service plan to three instances (workers) for high availability.

*Exam note: Tests the difference between scaling up (changing plan tier) and scaling out (increasing instance count). Keys: --number-of-workers scales out within the existing plan tier.*

```
az webapp config hostname add --resource-group myRG --webapp-name myApp --hostname www.customdomain.com
```
Binds a custom domain name to the web app after DNS verification.

*Exam note: Appears in custom domain and SSL/TLS questions. Remember that domain ownership must be verified via TXT or CNAME record before binding.*

## Troubleshooting clues

- **Web App HTTP 500.30 - ANCM In-Process Start Failure** — symptom: The app fails to start and returns HTTP 500.30 errors in the browser, with Event Log entries mentioning ANCM or AspNetCoreModule.. Occurs when the .NET Core runtime cannot start properly, often due to missing dependencies, incorrect runtime version, or a corrupted deployment. (Exam clue: Exams ask about diagnosing startup failures by checking Application Event Logs or using az webapp log tail to find the exact error.)
- **Deployment Slot Swap Fails Due to Connection String Mismatch** — symptom: After swapping a staging slot to production, the app connects to the wrong database or shows stale data.. Connection strings and app settings are sticky to slots unless explicitly marked as 'deployment slot settings'. If not configured, they swap with the app content. (Exam clue: Classic exam scenario: configure staging to use a test database, but after swap, production still points to test. Solution: mark the connection string as slot-specific in the configuration blade.)
- **App Service Returns 403 Forbidden for IP Requests** — symptom: Users from certain IP ranges receive 403 errors when accessing the site, while others can access it normally.. IP restrictions are configured in the web app's networking blade (or via az webapp config access-restriction). Requests from denied IPs are blocked by the platform before reaching the app. (Exam clue: Tested in scenarios where admins need to allow only corporate IPs. Questions often ask where to configure IP whitelisting and that it's a platform-level setting.)
- **High CPU Usage Causing App Slowdowns** — symptom: The app responds slowly, and metrics show high CPU consumption above 90% for extended periods.. Caused by inefficient code (e.g., infinite loops, blocking calls) or a sudden traffic spike. App Service automatically scales if auto-scale rules are configured. (Exam clue: Questions test how to view CPU metrics in Azure Monitor, how to enable auto-scaling, and when to scale out (increase instances) vs scale up (stronger plan).)
- **Custom Domain Not Resolving After DNS Change** — symptom: Even after adding a custom domain in the portal, the domain still shows a 'Not Found' page or resolves to the default azurewebsites.net URL.. DNS records (A or CNAME) were not updated correctly at the DNS provider, or the domain verification step (TXT record) was skipped. (Exam clue: Exams emphasize the two-step process: (1) add a TXT or CNAME verification record, (2) then create the A record pointing to the app's IP. Misordering causes failures.)
- **Web App Goes Down During Deployment** — symptom: When deploying a new version via Git or FTP, users see a '503 Service Unavailable' or blank page.. Default deployment behavior can cause a brief downtime because the app restarts. Using deployment slots with 'auto swap' or 'always on' setting can prevent this. (Exam clue: Tested as a best practice: enable 'Always On' in the app settings (only in Basic/Standard/Premium plans) and use deployment slots to achieve zero-downtime deployments.)
- **CORS Blocking API Requests from Browser** — symptom: Browser console shows CORS errors when a frontend app (e.g., on a different domain) tries to call the App Service API.. By default, App Service blocks cross-origin requests. CORS (Cross-Origin Resource Sharing) can be enabled in the API app's CORS settings by specifying allowed origins. (Exam clue: Exams test that CORS is configured per web app, not per site. Wildcards (*) can be used, but security best practices recommend listing specific domains.)

## Memory tip

Azure App Service: Your app is a tenant, the plan is the building, and you pay for the apartment, not the whole building.

## FAQ

**Can I install custom software on Azure App Service?**

No, because App Service is a managed platform. You cannot install software directly on the underlying VM. Instead, use Web App for Containers if you need custom runtime dependencies.

**Does Azure App Service support HTTPS by default?**

Azure App Service provides a default *.azurewebsites.net domain with HTTPS support. For custom domains, you need to add the domain and bind an SSL certificate, which can be a free App Service Managed Certificate.

**What is the difference between scaling up and scaling out in App Service?**

Scaling up means changing the instance size to a larger one (more CPU, memory). Scaling out means increasing the number of VM instances. Both are done in the App Service Plan.

**Can I use Azure App Service without an App Service Plan?**

No. Every App Service must belong to an App Service Plan. The plan defines the region, tier, and resources for the app.

**How can I connect my App Service to an on-premises database?**

You can use Hybrid Connections or VNet integration. Hybrid Connections uses a relay agent, while VNet integration connects the app to a virtual network that has a VPN or ExpressRoute to on-premises.

**Is Azure App Service suitable for hosting a static website?**

Yes, but for static content (HTML, CSS, JS), Azure Static Web Apps or Azure Storage static websites are simpler and often cheaper.

**What happens if my App Service exceeds the memory limit?**

The app process may be recycled or throttled. You should monitor memory usage and upgrade to a larger plan or scale out to avoid resource exhaustion.

**Can I run multiple domains from a single Azure App Service?**

Yes. You can add multiple custom domains to a single App Service, as long as each domain is verified and has a valid SSL binding.

## Summary

Azure App Service is a cornerstone PaaS compute service in Microsoft Azure, designed to simplify the hosting of web applications, APIs, and mobile backends. It abstracts the underlying infrastructure, freeing developers from OS patching, web server configuration, and hardware management. By offering a range of pricing tiers, built-in scaling, deployment slots, authentication, and monitoring, it enables rapid development and reliable operations. 

 For IT certification candidates, understanding App Service is critical because it appears across multiple exams, including Azure Fundamentals and Azure Administrator, and it maps to analogous services on AWS and Google Cloud. The key exam takeaways include knowing the difference between App Service and VMs, the role of App Service Plans, the features of each tier, and the shared responsibility model. Practical skills such as configuring connection strings, enabling HTTPS, setting up deployment slots, and troubleshooting common issues like slow performance or deployment failures are frequently tested. 

whether you are building a simple blog or a complex enterprise API, Azure App Service offers a balance of control and convenience. Mastering this service not only helps you pass certification exams but also equips you with a fundamental cloud skill that is widely used in the industry. Always remember: the platform manages the infrastructure, but you must manage your application's code, data, and configuration securely.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/azure-app-service