You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
An App Service plan represents the physical compute resources that host your web applications in Azure. When creating a plan, you must choose its region, operating system, and pricing tier, which together determine the overall cost and hardware capabilities. Azure organizes these into shared, dedicated, and isolated tiers depending on how much resource isolation your workload requires. While shared tiers use a shared CPU quota and are meant only for testing, dedicated tiers provide private virtual machines, and isolated tiers run inside a secure, dedicated virtual network.
Selecting the right pricing model helps balance application performance and budget constraints. The Flex Consumption Plan bills based on execution count and memory usage, which fits unpredictable workloads perfectly. The Premium Plan charges for CPU and memory usage of warm instances to guarantee quick response times during sudden traffic spikes. The Dedicated Plan uses a flat rate for physical hardware and charges per vCPU inside an App Service Environment (ASE). To maintain high availability, you can deploy your plan with zone redundancy, which spreads instances across multiple physical datacenters.
Administrators have several choices for deploying and managing plans. The Azure Portal offers a simple graphical interface for step-by-step setup. For automated workflows, you can use Azure CLI commands like az appservice plan create or Azure PowerShell cmdlets like New-AzAppServicePlan. For large-scale infrastructure, declarative tools like ARM Templates and Terraform define plans as code to ensure consistency across environments. Standard and higher tiers also unlock deployment slots, which allow teams to safely test and swap code without interrupting users.
Scaling changes how many resources your applications can use to handle shifting traffic demands. Vertical scaling, or scaling up, upgrades your plan to a higher pricing tier to get faster CPUs and more memory on a single server. Horizontal scaling, or scaling out, adds more virtual machine instances to your plan so they can share the traffic load. Scaling actions occur quickly and immediately affect every application hosted within the same plan. The maximum number of instances you can scale out to depends entirely on your pricing tier, ranging from 3 instances on Basic up to 100 on Isolated.
Administrators can automate and control scaling through three main workflows. Manual scaling lets you set a fixed number of instances directly when you want strict control over your infrastructure. Autoscale uses custom rules to add or remove instances based on real-time metrics like CPU usage or memory consumption. Automatic scaling, available in Premium tiers, bypasses custom rules by automatically adjusting instances based on incoming HTTP traffic. For cost efficiency, dedicated plans charge for each VM instance hourly, which means scaling in directly reduces your Azure bill.
To make accurate scaling decisions, you must monitor performance metrics that signal resource strain. High CPU or memory usage suggests a need to scale up vertically, while a growing HTTP queue length indicates requests are waiting and you should scale out horizontally. For plans hosting multiple applications, you can enable the PerSiteScaling property to set specific instance limits on individual apps. This is called per-app scaling, and it prevents one heavy application from consuming all the resources in a shared plan. Additionally, disabling Session affinity in your app settings helps distribute incoming requests evenly across your scaled-out instances.
Azure App Service is a platform-as-a-service (PaaS) offering that lets you run web and mobile applications without managing physical servers. You can create a web app in the Azure Portal by specifying its subscription, resource group, unique name, runtime stack, and underlying App Service plan. The platform supports multiple development stacks, such as .NET, Java, Node.js, and Python, or you can package your code in custom containers. While hosting multiple applications in a single plan reduces costs, they all share the same resources, so you should isolate heavy applications to their own plans.
Once created, you configure your application behavior through encrypted app settings that act as secure environment variables at runtime. You can deploy your code using simple methods like FTP or use version control systems like Git. For professional development, integrating with Azure DevOps or GitHub allows you to automate the entire build and release process. To protect your application and its data, you should use Microsoft Entra ID for secure user authentication, implement role-based access control (RBAC), and store sensitive secrets in Azure Key Vault.
Transport Layer Security (TLS) encrypts the data traveling between your users and your web application to keep it secure. Azure App Service configures TLS 1.2 as the minimum default version for new apps, but you can upgrade to TLS 1.3 for the strongest protection. To secure custom domains, you must bind a certificate using either SNI SSL, which allows multiple certificates to share one IP, or IP-based SSL, which requires a dedicated public IP address. You can choose a free App Service Managed Certificate, a paid App Service Certificate stored in Azure Key Vault, or upload your own certificate as a PFX file.
For high-security APIs and internal tools, Mutual TLS (mTLS) forces clients to present their own certificates before a connection is established. You can configure the client certificate mode to Required, Optional, or Optional Interactive User depending on how strictly you want to verify client identities. The platform forwards these certificates in the X-ARR-ClientCert header so your application code can validate them. Implementing custom certificates or mTLS requires at least a Basic tier App Service plan, as free tiers do not support these secure bindings.
To maintain constant availability, you must carefully manage certificate renewals. While App Service Managed Certificates renew automatically, custom certificates require manual updates. When updating a custom certificate, you must upload the new PFX file and update the domain binding before deleting the old certificate to prevent the application's inbound IP address from changing. Additionally, if you use path exclusions to bypass certificate prompts for certain URLs, be aware that this limits request sizes to 100 KB and can trigger 403 errors due to TLS renegotiation.
Using a Custom Domain replaces the default Azure URL to make your application look professional and build brand trust. Before you can map a custom name, you must prove you own the domain by adding a special TXT record with your Domain Verification ID at your DNS provider. This validation process prevents a subdomain takeover, which occurs when a threat actor attempts to claim a domain that is no longer in use but still points to Azure. Once this verification step is complete, you can map the actual traffic records to route users to your application.
To route traffic correctly, you must choose the right type of DNS record based on your domain structure. An A record points a root domain directly to your App Service's dedicated public IP address. A CNAME record is preferred for subdomains because it maps the subdomain to the default Azure hostname, which continues working even if Azure changes your inbound IP address. After updating your DNS provider, you validate the records in the Azure Portal to complete the binding.
After mapping your domain, you must bind an SSL/TLS certificate to secure the traffic with HTTPS. You can use a free App Service Managed Certificate, which Azure automatically issues and renews as long as your DNS records remain unchanged. However, managed certificates do not support wildcard domains, so you must upload a custom PFX certificate or import one from Azure Key Vault for more complex setups. Finally, you should enforce HTTPS redirects and set a minimum TLS version to satisfy modern security compliance standards.
Azure App Service offers backup solutions to protect your application code, configurations, and connected databases from data loss. Automatic backups run hourly without any configuration, keeping your files and settings for up to 30 days. For more control, you can set up custom backups to run on a custom schedule (up to every 2 hours) and store them in an Azure Storage account. Custom backups can save your website files, configurations, and linked databases, though support for backing up linked databases directly in custom backups will end after March 31, 2028.
When choosing an Azure Storage account for your custom backups, you must select an appropriate redundancy tier. Locally Redundant Storage (LRS) is the most cost-effective option, keeping three copies of your data inside a single datacenter. Zone-Redundant Storage (ZRS) replicates your data across different physical availability zones to protect against datacenter failures, while Geo-Redundant Storage (GRS) copies your data to a secondary region. To automate these backup schedules at scale, administrators can use Azure CLI scripts or Azure PowerShell cmdlets.
Restoring an application involves selecting a backup and choosing where to deploy the recovered files. You can restore directly to the production app, which overwrites the current content, or restore to a staging deployment slot. Restoring to a slot is a best practice because it allows you to test the recovered application before swapping it into production. Keep in mind that backups do not include custom domains or TLS certificates, which you must reconfigure manually. Finally, backup capabilities are tied to your pricing tier, with the Basic tier restricting you to backing up only the production slot.
You can secure your application's network traffic by configuring inbound and outbound firewall rules. Access restrictions act as a network-level firewall, allowing you to create a prioritized list of rules that permit or block traffic based on IP addresses or virtual network subnets. When you configure access restrictions, Azure automatically applies an implicit "deny all" rule at the end of the list. For deeper security, you can deploy a Private Endpoint to assign your app a private IP address, which removes it from the public internet entirely and routes all traffic securely over Azure Private Link.
To connect your application to resources inside a private network, you must configure outbound connectivity. Virtual Network integration (VNet Integration) sends all outbound traffic from your application into a delegated subnet in your Azure Virtual Network. This integration allows your app to access secure back-end databases or virtual machines without exposing them to the internet. For reaching resources that live outside of Azure entirely, Hybrid Connections use Azure Relay to establish a secure tunnel over port 443 without requiring you to open inbound firewall ports on your local network.
You must also configure settings that control pre-startup operations and network routing. By adjusting settings like vnetImagePullEnabled and vnetContentShareEnabled, you ensure that startup tasks like pulling container images or accessing file shares follow your virtual network's security rules. You can also apply Network Security Groups (NSGs) and user-defined routes (UDRs) to the integration subnet to restrict where your app can send data. For the highest level of network isolation, you can run your applications inside a single-tenant App Service Environment (ASE), which provides complete physical isolation.
Deployment slots are live web applications with their own unique URLs that run within the same App Service plan as your production application. Available in Standard, Premium, and Isolated tiers, slots serve as isolated staging environments where you can safely test code changes. The core mechanism for updating your production application is the swap operation, which exchanges the content and configuration of the staging slot with the production slot. During a swap, the platform prepares the target slot, restarts instances, and warms up the application with HTTP requests to prevent initial latency for users.
Administrators can automate deployment slot management using continuous integration pipelines or command-line tools. You can create a slot using the Azure CLI command az webapp deployment slot create or the Azure PowerShell cmdlet New-AzWebAppSlot. To protect your production environment, you should configure continuous deployment tools like GitHub Actions to push code to a staging slot rather than directly to production. If an error occurs after a swap, you can perform an immediate reverse swap to instantly restore your application to its last known healthy state.
Managing which settings change during a swap is essential for keeping your application stable. While application code and general configurations travel with the swap, certain "sticky" settings remain bound to their physical slot. These sticky settings include custom domains, IP restrictions, private endpoints, and diagnostic configurations, which you must keep separate to avoid routing production users to staging databases. Finally, you can use slots for canary testing by routing a small percentage of production traffic to your staging slot, using cookies to pin users to that specific environment for a consistent session.
When provisioning an App Service plan in Azure, you must analyze the available pricing tiers and scalability options to match your application's performance needs with your budget. Azure offer…
When provisioning an App Service plan in Azure, you must analyze the available pricing tiers and scalability options to match your application's performance needs with your budget. Azure offer…
Azure App Service plans define the compute resources that web apps run on, including the operating system, region, number of VM instances, VM size, and pricing tier. The pricing tier determines wh…
Azure App Service plans define the compute resources that web apps run on, including the operating system, region, number of VM instances, VM size, and pricing tier. The pricing tier determines wh…
Access restrictions in Azure App Service work like a network-level firewall that checks each incoming request before it reaches your application. You create a priority-ordered list of rules that e…
Access restrictions in Azure App Service work like a network-level firewall that checks each incoming request before it reaches your application. You create a priority-ordered list of rules that e…
Differentiate App Service Plan Scaling Methods
Differentiate App Service Plan Scaling Methods
Transport Layer Security (TLS) secures data traveling between clients and servers. In Azure App Service, TLS 1.2 is configured as the default minimum version for new applications, while **…
Transport Layer Security (TLS) secures data traveling between clients and servers. In Azure App Service, TLS 1.2 is configured as the default minimum version for new applications, while **…
Define Backup Components and Storage Strategies
Define Backup Components and Storage Strategies
Azure App Service deployment slots are live apps with their own hostnames that function as isolated environments. These slots are available in the Standard, Premium, and Isolated servi…
Azure App Service deployment slots are live apps with their own hostnames that function as isolated environments. These slots are available in the Standard, Premium, and Isolated servi…
Before mapping a custom domain to an Azure App Service, the administrator must prove ownership of the domain through a verification step. This requires the App Service app to be running on a tier …
Before mapping a custom domain to an Azure App Service, the administrator must prove ownership of the domain through a verification step. This requires the App Service app to be running on a tier …
StudyCerts
StudyCerts