### The problem this module actually solves A team at a Bengaluru fintech moves their app to Azure. Someone spins up a virtual machine, opens every port to the internet "just to get it working," puts the database password directly in the app's config file, and forgets to turn off a test VM that then runs - and bills - for three months straight. None of this was malicious. Nobody had ever learned the difference between a resource group and a subscription, or why a Network Security Group exists, or that Azure Cost Management could have warned them before the bill arrived. Azure administration is the discipline that prevents exactly this. It is not about knowing every Azure service that exists - it is about knowing the small set of services you touch constantly, understanding how they fit together, and building the instinct for what to check first when something breaks or costs more than expected. ### How this module is organized This module builds that instinct from zero. It follows the same broad structure as the AZ-104 Azure Administrator Associate exam, but the goal is not memorizing exam trivia - it is being able to actually run a production Azure environment competently, with the certification as a natural byproduct of real understanding. It moves through identity and governance, storage, compute, networking, and monitoring, in that order, since each later section assumes the fundamentals of the ones before it. > 📌 **Remember:** Everything in Azure lives inside a hierarchy - Management Groups, then Subscriptions, then Resource Groups, then individual Resources. Getting lost in Azure almost always means losing track of where you are in this hierarchy. ---
### Why three different tools exist for the same job Azure gives you three ways to manage resources - the Portal, the CLI, and PowerShell - and a beginner's first instinct is to wonder why bother with more than one. The answer becomes obvious the first time you need to create twelve identical virtual machines. Clicking through the Portal's wizard twelve times is slow and error-prone. A single CLI command with a loop does it in seconds, identically, every time. * **Azure Portal** - the web-based GUI at portal.azure.com. Best for exploring, one-off changes, and understanding what a resource actually looks like before you script it. * **Azure CLI** - a cross-platform command-line tool (`az` commands) that works identically on Windows, Mac, and Linux. Best for repeatable tasks and automation. * **Azure PowerShell** - a PowerShell module (`Az` commands) with the same automation power as the CLI, more natural if your team already lives in PowerShell. > 🔴 **Common Mistake:** Trying to use the Portal to create many similar resources at once - like a batch of VMs for a training environment. The Portal's wizards are built for one resource at a time. Any repetitive task belongs in the CLI or PowerShell, not because the Portal can't technically do it, but because doing it manually invites mistakes and wastes hours. ### The three regions of the Portal itself The Azure Portal's layout is not random - it is deliberately split into three functional zones, and knowing this split makes navigating any unfamiliar part of the Portal faster. Azure Portal Layout TOP - Search bar (find any resource or service instantly) Notification bell, Cloud Shell icon, account menu LEFT - The full list of resources and services Your "Favorites" pinned for quick access CENTER - Your dashboard - tiles you can customize Public or private views depending on what you need to see The search bar at the top is worth building a habit around immediately - typing a partial service name there is almost always faster than hunting through the left-hand menu. ### Creating your first resource - a Resource Group A **Resource Group** is a logical container - it does not physically hold anything, but every resource you create must belong to exactly one Resource Group. Think of it like a labeled folder: the VM, its disk, its network card, and its public IP might all sit in the same Resource Group even though they are technically separate Azure resources. ```bash ## Create a resource group in the Mumbai region for a demo environment az group create \ --name rg-demo-mumbai \ --location centralindia ``` > **Note:** `--location centralindia` tells Azure which physical region this Resource Group's metadata is stored in. Resources inside the group can still be created in other regions individually - the group's location mostly affects where its own management data lives. Deleting a Resource Group deletes everything inside it - all VMs, disks, and networks that belong to it, permanently. This is exactly why naming conventions matter from day one: a Resource Group named `rg-test-rahul-delete-later` immediately signals its purpose and lifespan to anyone else who opens the subscription. > ⚠️ **Security:** Deleting a Resource Group is irreversible and cascades to every resource inside it. Before running any delete command in a real environment, double-check the Resource Group name - Azure will not ask "are you sure this is the right one," only "are you sure you want to delete this." ### Azure CLI and PowerShell through Cloud Shell **Cloud Shell** is a browser-based terminal built directly into the Portal, with the Azure CLI and PowerShell pre-installed and already authenticated to your account - no local setup needed to start practicing immediately. ```bash ## List every resource group in your subscription az group list --output table ## Switch Cloud Shell between Bash and PowerShell using the dropdown in the top-left of the Cloud Shell pane ``` > 💡 **Tip:** Cloud Shell gives you a small amount of persistent storage (an Azure Files share) so your scripts and files survive between sessions. This is the fastest way to start practicing Azure CLI commands without installing anything locally. ### Understanding Azure Resource Manager - the engine behind every action Every single action you take in Azure - clicking a button in the Portal, running a CLI command, calling the REST API directly - goes through the same underlying engine: **Azure Resource Manager (ARM)**. ARM receives the request, checks whether you're authenticated and authorized to do it, then passes the actual work to the relevant Azure service. Request Flow Through ARM You (Portal, CLI, PowerShell, or API) | Azure Resource Manager | Authenticates: are you who you say you are? | Authorizes: are you allowed to do this specific action? | Forwards the request to the actual service (VM, Storage, etc.) This is exactly why the Portal, CLI, and PowerShell always show consistent results - they are three different front doors into the same single engine, not three separate systems that might disagree with each other. ### Understanding Azure Pricing and the Free Tier Azure's core financial model is consumption-based - you are billed for what you actually use, not for pre-purchased fixed capacity, though committed and reserved options exist for predictable workloads at a discount. * **Always free** - a small set of services with a permanent free allowance, like a limited amount of Functions executions per month. * **12 months free** - a curated list of popular services (like a small VM) free for the first year on a new account. * **Free trial credit** - a one-time credit (commonly around $200 USD equivalent) usable across almost any service in the first 30 days. The **Azure Pricing Calculator** lets you estimate cost for a specific configuration - region, VM size, storage type - before you actually deploy anything, which is the responsible way to sanity-check a design before committing real money to it. > 📌 **Remember:** Region choice directly affects price. The same VM size can cost meaningfully more or less depending on which Azure region you deploy it in - always check pricing for your actual target region, not just the default one the calculator shows first. ### Setting a budget before you need one **Azure Cost Management** lets you define a budget and get alerted before you exceed it - this single feature prevents the vast majority of "surprise bill" incidents that new Azure users experience. ```bash ## Check current month-to-date cost for your subscription az consumption usage list --output table ``` > 🔴 **Common Mistake:** Creating a free trial account, spinning up test resources, then forgetting about them entirely. A VM left running for a month can easily consume your entire trial credit on compute alone, even if you never actually use it after the first day. Set a budget alert at 80% of your trial credit on day one, before you create a single resource. ### Understanding Azure Advisor and Azure Security Center **Azure Advisor** continuously scans your actual deployed resources and gives personalized recommendations across five categories: Reliability, Security, Performance, Cost, and Operational Excellence. It is the closest thing Azure has to an automated senior engineer reviewing your setup and pointing out what you missed. **Azure Security Center** (now part of Microsoft Defender for Cloud) gives you a **Secure Score** - a single number reflecting how many recommended security controls you have actually implemented, out of the total that apply to your environment. A low Secure Score is not a vague warning - it points to specific, actionable fixes like "enable disk encryption on this VM" or "this storage account allows public access." > 💡 **Tip:** Check Azure Advisor's Cost recommendations specifically after your first week of experimentation - it is very good at spotting VMs that were resized too large, or disks that are more expensive than the workload actually needs. ---
### Why identity is the real security boundary in the cloud On-premises, a locked server room was a meaningful security layer. In the cloud, there is no server room - the only thing standing between an attacker and your entire environment is whether they can authenticate as a valid identity. This is exactly why the module treats identity as the foundation everything else builds on top of, not an afterthought bolted on later. ### Understanding Azure Active Directory (Microsoft Entra ID) **Azure Active Directory (Azure AD)**, now branded **Microsoft Entra ID**, is Azure's cloud-based identity and access management service. It is easy to confuse with the traditional on-premises Active Directory most IT admins already know, but the two are genuinely different products solving overlapping problems in different environments. Traditional Active Directory Azure AD (Entra ID) Runs on your own Windows Server Fully managed by Microsoft You manage the domain controllers No servers for you to manage at all Primarily on-premises identity Cloud-native identity, works globally Uses LDAP and Kerberos primarily Uses modern protocols like OAuth, SAML A **Tenant** is your organization's own dedicated, isolated instance of Azure AD - every Azure subscription is associated with exactly one Azure AD tenant, and that tenant is where all your organization's user accounts, groups, and app registrations actually live. ```bash ## List all users in your Azure AD tenant az ad user list --output table ## Create a new user in Azure AD az ad user create \ --display-name "Priya Sharma" \ --user-principal-name priya.sharma@yourtenant.onmicrosoft.com \ --password "TempPass@2026!" \ --force-change-password-next-sign-in true ``` > **Note:** `--force-change-password-next-sign-in true` means the temporary password you set only works for the very first login - the user is required to set their own password immediately afterward, which is standard practice for any account creation. ### Groups - the correct way to manage access at scale Assigning permissions to individual users one at a time does not scale past a handful of people. **Groups** let you assign a permission once, to the group, and have it automatically apply to every current and future member. ```bash ## Create a group for the finance team az ad group create \ --display-name "Finance-Team" \ --mail-nickname "financeteam" ## Add a user to that group az ad group member add \ --group "Finance-Team" \ --member-id <user-object-id> ``` > 📌 **Remember:** When a new employee joins a team, add them to the team's existing group rather than assigning permissions individually. When they leave, removing them from the group instantly revokes every permission that group granted - individual permission assignments are far easier to forget to clean up. ### Multi-Factor Authentication - the single highest-impact security control **Multi-Factor Authentication (MFA)** requires a second proof of identity beyond just a password - typically a code from an authenticator app, an SMS, or a phone call. Microsoft's own security research consistently shows MFA blocks the overwhelming majority of account compromise attempts, even when the attacker already has a stolen password. **Security Defaults** is the fastest way to get baseline MFA protection turned on for an entire tenant with a single toggle - it enforces MFA for administrators and blocks legacy authentication protocols that don't support modern security checks, with no per-user configuration needed. > ⚠️ **Security:** If Security Defaults feels too broad for your organization's specific needs, **Conditional Access** policies (available with Azure AD Premium) let you require MFA selectively - for example, only when a login attempt comes from an unfamiliar country, or only for users accessing a specific sensitive application. Never disable MFA entirely to "simplify things" - narrow its scope instead of removing it. ### Understanding Role-Based Access Control **Role-Based Access Control (RBAC)** is how Azure decides what a specific identity is allowed to do, and to which specific resources. Every RBAC assignment has exactly three parts. RBAC Assignment = Security Principal + Role + Scope Security Principal -> WHO: a user, a group, or an application Role -> WHAT: the specific set of permitted actions Scope -> WHERE: which resource(s) this applies to **Scope** can be set at four different levels, and permissions granted at a higher level automatically flow down to everything beneath it. Management Group (broadest - affects every subscription inside it) | Subscription | Resource Group | Individual Resource (narrowest - affects only this one resource) Three built-in roles cover the vast majority of real-world scenarios: * **Owner** - full access to everything, including the ability to grant access to others * **Contributor** - full access to create and manage resources, but cannot grant access to other users * **Reader** - can view everything, but cannot make any changes at all ```bash ## Grant a user Contributor access, scoped only to one specific resource group az role assignment create \ --assignee priya.sharma@yourtenant.onmicrosoft.com \ --role "Contributor" \ --resource-group rg-demo-mumbai ``` > 🔴 **Common Mistake:** Assigning the Owner role by default because it "definitely won't cause a permissions error." Owner includes the ability to grant other people access, which is rarely actually needed - Contributor covers almost every real day-to-day task without that extra, riskier capability. Start with Contributor, and only escalate to Owner when a specific need actually requires it. ### Azure Policy - enforcing rules automatically instead of asking nicely **Azure Policy** lets you define rules about what resources are allowed to look like, then automatically evaluates every resource against those rules - and can even block non-compliant resources from being created in the first place, rather than just reporting on them after the fact. Without Azure Policy: Tell the team "always tag resources with a cost center" Some people forget, tags become inconsistent, reporting breaks With Azure Policy: Define a policy requiring the CostCenter tag on every resource Azure Policy blocks (or flags) any resource created without it Compliance becomes automatic, not a matter of individual discipline ```bash ## Assign a built-in policy requiring a specific tag on all resources in a resource group az policy assignment create \ --name "require-costcenter-tag" \ --scope "/subscriptions/<sub-id>/resourceGroups/rg-demo-mumbai" \ --policy "<built-in-policy-definition-id-for-tag-enforcement>" ``` An **Initiative** groups several related individual policies into one assignable package - useful when you want to enforce an entire compliance standard (like "every resource must be tagged, encrypted, and in an approved region") as a single unit rather than three separate assignments. > 💡 **Tip:** Start any new Azure Policy in **Audit** mode rather than **Deny** mode. Audit mode reports which existing resources would fail the policy without blocking anything, letting you see the real-world impact before you risk blocking a legitimate deployment. ### Azure Service Health - knowing about outages before your customers tell you **Azure Service Health** gives you a personalized dashboard of any Azure-wide incidents, planned maintenance, or health advisories that specifically affect the services and regions you actually use - filtering out the noise of issues affecting services or regions you have nothing deployed in. > 📌 **Remember:** Set up a Service Health alert before you need it, not during an actual incident. Being notified proactively that "Azure Storage in Central India is experiencing degraded performance" is far more useful than discovering it only because your own application started failing with no explanation. ---
### Why every Azure account starts with a Storage Account Almost nothing in Azure exists without touching storage somewhere underneath - VM disks, backups, application logs, and static website files all ultimately live inside a **Storage Account**, which acts as the top-level container and unique namespace for several distinct storage services underneath it. Storage Account | +-- Blob Storage (unstructured files - images, backups, videos) +-- File Storage (SMB/NFS file shares - like a network drive) +-- Queue Storage (message queues for decoupling application components) +-- Table Storage (simple NoSQL key-value data) +-- Disk Storage (the actual data behind a VM's virtual hard disk) ### Azure Blob Storage - object storage for unstructured data **Blob Storage** stores unstructured data - anything that isn't rows and columns in a traditional database: images, videos, log files, backups, or any raw binary data. It scales to enormous volumes and is accessible from anywhere with an internet connection and the right credentials. Blobs live inside **Containers**, which work like a top-level folder inside the Storage Account - every blob must belong to exactly one container. ```bash ## Create a storage account az storage account create \ --name stprodmumbai01 \ --resource-group rg-demo-mumbai \ --location centralindia \ --sku Standard_LRS ## Create a container inside it az storage container create \ --name product-images \ --account-name stprodmumbai01 ## Upload a file as a blob az storage blob upload \ --account-name stprodmumbai01 \ --container-name product-images \ --name laptop-hero.jpg \ --file ./laptop-hero.jpg ``` > **Note:** `--sku Standard_LRS` sets the storage redundancy option to Locally Redundant Storage - three copies of your data kept within a single physical datacenter. Other options (covered next) replicate further for stronger protection at higher cost. ### Choosing the right access tier for cost Blob Storage offers three access tiers, and choosing correctly can meaningfully change your monthly bill for the exact same data. | Tier | Best for | Storage cost | Retrieval cost | |:---|:---|:---|:---| | Hot | Data accessed frequently (product images on a live site) | Highest | Lowest | | Cool | Data accessed infrequently, kept 30+ days (old invoices) | Lower | Higher | | Archive | Rarely accessed, kept 180+ days (compliance backups) | Lowest | Highest, plus a retrieval delay | > 🔴 **Common Mistake:** Leaving old backup data in the Hot tier indefinitely because nobody revisited the setting after the initial upload. A **Lifecycle Management** policy can automatically move blobs to Cool, then Archive, based on age - set it once and stop paying Hot-tier prices for data nobody has touched in months. ### Securing blob access - keys versus SAS tokens **Access Keys** grant full access to the entire storage account - anyone with a key can read, write, and delete everything in every container. This makes keys powerful but dangerous to share broadly. **Shared Access Signatures (SAS)** grant narrow, time-limited access to a specific resource - a single blob, or a single container - with specific permissions (read-only, for example) and an expiration time built directly into the token itself. ```bash ## Generate a SAS token allowing read-only access to one blob, expiring in 24 hours az storage blob generate-sas \ --account-name stprodmumbai01 \ --container-name product-images \ --name laptop-hero.jpg \ --permissions r \ --expiry $(date -u -d "24 hours" '+%Y-%m-%dT%H:%MZ') ``` > ⚠️ **Security:** Never share an Access Key when a SAS token would do the job. An Access Key handed to a third-party contractor grants them full control over your entire storage account forever, until you manually rotate the key - a SAS token scoped to exactly what they need, expiring automatically, contains the damage a leaked credential could cause. ### Azure Files - a network file share in the cloud **Azure Files** provides fully managed file shares accessible over the standard SMB or NFS protocols - the same protocols a traditional on-premises network drive uses. This means existing applications that expect a mapped network drive can often point at an Azure File Share with no code changes at all. ```bash ## Create a file share for configuration files shared across multiple VMs az storage share create \ --name shared-configs \ --account-name stprodmumbai01 \ --quota 100 ``` > 💡 **Tip:** Azure Files is the right choice specifically when multiple VMs need to read and write the exact same files simultaneously - a scenario Blob Storage does not handle natively, since blobs are not designed to be mounted as a shared drive the way a File Share is. ### Azure Disk Storage - the drives behind your virtual machines **Managed Disks** are the virtual hard disks attached to Azure VMs, and Azure handles the underlying storage infrastructure entirely - you choose a disk type and size, and never worry about the physical storage hardware behind it. | Disk type | Best for | |:---|:---| | Standard HDD | Backup, infrequently accessed data, lowest cost | | Standard SSD | Web servers, lightly used applications | | Premium SSD | Production databases, I/O-intensive workloads | | Ultra Disk | The most demanding workloads needing configurable, very high performance | > 📌 **Remember:** A VM has an OS Disk (holding the operating system, created automatically) and can optionally have one or more Data Disks attached for application data. Keep application data on separate Data Disks rather than the OS Disk - it makes resizing, snapshotting, and eventually replacing the VM itself far cleaner. ### Queue Storage and Table Storage - the quieter storage services **Queue Storage** holds messages that decouple different parts of an application - a web app can drop a message onto a queue ("resize this uploaded image") and a separate background process picks it up and processes it whenever it's ready, without the web app waiting around for that work to finish. **Table Storage** is a simple NoSQL key-value store, good for large volumes of structured data that doesn't need complex relationships or joins - think of it as a very fast, very simple spreadsheet-like store rather than a full relational database. > 💡 **Tip:** If your data-storage needs start growing more complex - needing indexes, richer queries, or global distribution - that's usually the signal to move to Azure Cosmos DB rather than stretching Table Storage beyond what it was designed for. ### Azure Key Vault - never store secrets in application code A team hardcodes a database password directly into their application's configuration file, commits it to source control, and six months later that repository becomes public by accident. This exact scenario is why **Azure Key Vault** exists - a centralized, secure service for storing secrets, encryption keys, and certificates, so application code never contains a raw credential. ```bash ## Create a Key Vault az keyvault create \ --name kv-prod-mumbai \ --resource-group rg-demo-mumbai \ --location centralindia ## Store a database connection secret in it az keyvault secret set \ --vault-name kv-prod-mumbai \ --name "sql-connection-string" \ --value "Server=prod-sql.database.windows.net;..." ``` Applications retrieve secrets from Key Vault at runtime using their own **Managed Identity** (covered in more depth in the compute section) rather than a hardcoded credential - meaning even if someone reads the application's source code in full, there is no actual secret sitting inside it to steal. > ⚠️ **Security:** Enable **soft-delete** and **purge protection** on every production Key Vault. Soft-delete means an accidentally deleted secret can be recovered within a retention window rather than being gone instantly and permanently - a small setting that has saved many teams from a genuinely bad day. ---
### Understanding Azure Virtual Machines A **Virtual Machine (VM)** is Azure's Infrastructure-as-a-Service offering - you get a full, unmanaged operating system running on hardware Azure manages behind the scenes. You choose the operating system, install any software you need, and take on responsibility for OS patching and configuration in exchange for complete control. What Azure manages for a VM: What you manage: Physical hardware Operating system patching Hypervisor Installed software Physical networking Firewall rules inside the OS Physical datacenter security Application configuration Every VM is defined by three core choices made at creation time: * **Region** - where in the world it physically runs * **Image** - the starting OS and any pre-installed software (Windows Server, Ubuntu, or a custom image you built yourself) * **Size** - how much CPU, memory, and network performance it gets, which directly drives cost ```bash ## Create a Linux VM sized for a small production web server az vm create \ --resource-group rg-demo-mumbai \ --name vm-web-prod-01 \ --image Ubuntu2204 \ --size Standard_B2s \ --admin-username azureadmin \ --generate-ssh-keys ``` > **Note:** `--generate-ssh-keys` creates a new SSH key pair automatically if one doesn't already exist locally, rather than requiring a password login - key-based authentication is the standard, more secure way to access a Linux VM. ### Understanding what you actually pay for with a VM A common surprise for beginners is realizing a VM's advertised hourly compute price is not the whole bill. A real production VM typically bundles at least three separate charges: the compute itself, the managed disk(s) attached to it, and a Public IP address if one is assigned - each billed independently. > 🔴 **Common Mistake:** Estimating VM cost using only the compute price shown in a size comparison chart, then being surprised when the actual monthly bill is noticeably higher once disk and networking charges are added. Always use the Pricing Calculator with the actual disk type and size you plan to attach, not just the bare compute rate. ### Reducing the real cost of running VMs * **Auto-shutdown** - automatically powers off a VM on a schedule (like every night at 9 PM), ideal for dev/test VMs nobody uses outside business hours. * **Reserved Instances** - commit to 1 or 3 years of usage for a specific VM size in exchange for a substantial discount versus pay-as-you-go pricing, appropriate for stable, predictable production workloads. * **Spot VMs** - use Azure's spare, unused capacity at a steep discount, with the catch that Azure can reclaim the VM with short notice when it needs that capacity back - a strong fit for fault-tolerant batch jobs, a poor fit for anything customer-facing. * **Right-sizing** - periodically checking actual CPU and memory utilization and downsizing VMs that are consistently over-provisioned for the load they actually carry. > 💡 **Tip:** For any VM that only needs to run during business hours - a dev/test box, an internal tool - auto-shutdown alone can cut that VM's compute cost by more than half, since it simply isn't billed while powered off. ### Designing for VM availability - Availability Sets and Availability Zones A single VM is a single point of failure - if the physical host it runs on fails, your application goes down with it. Azure gives you two mechanisms to spread VMs across separate failure boundaries. **Availability Sets** spread VMs across multiple **Fault Domains** (separate physical racks with independent power and networking) and **Update Domains** (groups that Azure patches and reboots at different times), all within a single datacenter. **Availability Zones** go a level further, spreading VMs across physically separate datacenters within the same region, each with independent power, cooling, and networking - protecting against an entire datacenter failure, not just a single rack. Availability Set: Availability Zone: Same datacenter Different datacenters Protects against rack/host failure Protects against datacenter failure Fault Domains + Update Domains Zones are numbered (1, 2, 3) > 📌 **Remember:** A single VM with no Availability Set or Zone configuration has no built-in resilience against hardware failure at all. Any workload where downtime genuinely matters needs at least two VMs spread across Fault Domains or Zones, fronted by a Load Balancer. ### Virtual Machine Scale Sets - identical VMs that grow and shrink automatically A **Virtual Machine Scale Set (VMSS)** manages a group of identical, load-balanced VMs as a single unit, automatically adding instances when demand rises and removing them when it falls - solving the exact problem of a website that gets ten times its normal traffic during a sale event and needs capacity to match, then doesn't want to keep paying for that capacity once traffic normalizes. ```bash ## Create a scale set with autoscaling based on CPU load az vmss create \ --resource-group rg-demo-mumbai \ --name vmss-web-prod \ --image Ubuntu2204 \ --instance-count 2 \ --admin-username azureadmin \ --generate-ssh-keys ## Add an autoscale rule - scale out when average CPU exceeds 70% az monitor autoscale create \ --resource-group rg-demo-mumbai \ --resource vmss-web-prod \ --resource-type Microsoft.Compute/virtualMachineScaleSets \ --min-count 2 --max-count 10 --count 2 ``` > 💡 **Tip:** Scale sets update by rolling out a new VM image rather than patching individual running instances one by one - build your application updates into a new image and let the scale set roll it out, rather than trying to SSH into every instance manually. ### Azure App Service - hosting web apps without managing a VM at all **App Service** is Azure's Platform-as-a-Service for web applications - you deploy your code (from a Git repo, GitHub Actions, or a Docker container) and Azure handles the underlying OS, runtime, patching, and scaling entirely. There is no VM for you to log into or maintain. Virtual Machine App Service You manage the OS Azure manages the OS Full control, full responsibility Less control, far less overhead Any software you want Supports .NET, Node, Python, Java, PHP, and custom containers App Service is organized around **Service Plans**, which determine the pricing tier and the compute resources backing your app - from a Free tier for testing to Premium tiers offering better performance and features like custom domains and autoscaling. ```bash ## Create an App Service Plan az appservice plan create \ --name asp-prod-mumbai \ --resource-group rg-demo-mumbai \ --sku S1 \ --is-linux ## Create the actual web app on that plan az webapp create \ --resource-group rg-demo-mumbai \ --plan asp-prod-mumbai \ --name readit-inventory-prod \ --runtime "DOTNETCORE:8.0" ``` > 📌 **Remember:** App Service is almost always the right default choice for a standard web application, unless you have a specific reason to need full OS-level control - App Service's automatic scaling, built-in deployment slots, and zero OS maintenance overhead outweigh the flexibility of a raw VM for the vast majority of web workloads. ### Deployment Slots - testing in production without risking production A **Deployment Slot** is a fully separate, live instance of your App Service, with its own distinct URL, that you can deploy a new version of your code to and test independently of your actual production traffic - then swap it into production only once you've confirmed it works. ```bash ## Create a staging slot for testing new releases az webapp deployment slot create \ --name readit-inventory-prod \ --resource-group rg-demo-mumbai \ --slot staging ## Swap staging into production once verified az webapp deployment slot swap \ --name readit-inventory-prod \ --resource-group rg-demo-mumbai \ --slot staging \ --target-slot production ``` > 💡 **Tip:** A slot swap is nearly instantaneous and can be immediately reversed by swapping back - this makes it one of the lowest-risk ways to deploy a new version, since a bad release can be undone in seconds rather than requiring a full redeploy of the previous version. ### Containers - Azure Container Registry, Container Instances, and Kubernetes Service A **Container** packages an application together with everything it needs to run - libraries, dependencies, configuration - into one portable unit that behaves identically whether it's running on a developer's laptop or in Azure. **Azure Container Registry (ACR)** is your own private, secure place to store container images before deploying them, similar in concept to how a Storage Account holds blobs, but purpose-built for container images specifically. ```bash ## Create a container registry az acr create \ --resource-group rg-demo-mumbai \ --name acrprodmumbai \ --sku Basic ## Build and push an image directly in ACR, no local Docker build needed az acr build \ --registry acrprodmumbai \ --image cart-service:v1 . ``` **Azure Container Instances (ACI)** is the fastest, simplest way to run a single container in Azure - no cluster, no orchestration layer, just "run this container" - appropriate for a quick task or a simple, low-complexity service. **Azure Kubernetes Service (AKS)** is a fully managed Kubernetes cluster for when you need to run many containers together, with automated scaling, self-healing, and rolling updates across a distributed set of services - the right tool once container orchestration complexity genuinely justifies it. ```bash ## Create a managed AKS cluster az aks create \ --resource-group rg-demo-mumbai \ --name aks-prod-mumbai \ --node-count 2 \ --attach-acr acrprodmumbai \ --generate-ssh-keys ``` > 📌 **Remember:** Reach for ACI when you need to run one container simply and quickly. Reach for AKS specifically once you have multiple interdependent containerized services that need coordinated scaling, service discovery, and self-healing - AKS adds real operational complexity that isn't worth taking on for a single simple container. ---
### Understanding the Virtual Network as your private space in Azure A **Virtual Network (VNet)** is your own isolated, private network inside Azure - conceptually identical to a network you'd build in a physical datacenter, just software-defined. Every VM, App Service (when integrated), and most other Azure resources ultimately live inside a VNet, and resources inside the same VNet can talk to each other by default. A VNet is defined by a CIDR address range - for example `10.0.0.0/16` - and is then divided into **Subnets**, smaller address ranges within that overall range, each typically dedicated to a specific tier of your application (web servers in one subnet, databases in another). ```bash ## Create a VNet with an address space of 10.0.0.0/16 az network vnet create \ --resource-group rg-demo-mumbai \ --name vnet-prod-mumbai \ --address-prefix 10.0.0.0/16 \ --subnet-name subnet-web \ --subnet-prefix 10.0.1.0/24 ``` > **Note:** `/16` and `/24` are CIDR notation describing how many addresses a range contains. A `/16` gives roughly 65,000 addresses total for the whole VNet; a `/24` subnet within it gives 256 addresses for that specific subnet - planning subnet sizes around expected resource counts prevents running out of addresses later. ### Network Security Groups - the firewall in front of your resources A **Network Security Group (NSG)** is a set of allow and deny rules that control inbound and outbound traffic to a subnet or a specific network interface. Each rule specifies a priority, a source, a destination, a port, and whether to allow or deny that traffic. Default NSG Behavior: Inbound -> denies everything from the internet by default Outbound -> allows everything out to the internet by default ```bash ## Create an NSG allowing inbound HTTPS traffic only az network nsg create \ --resource-group rg-demo-mumbai \ --name nsg-web az network nsg rule create \ --resource-group rg-demo-mumbai \ --nsg-name nsg-web \ --name allow-https \ --priority 100 \ --destination-port-ranges 443 \ --access Allow \ --protocol Tcp ``` > ⚠️ **Security:** Never open management ports like RDP (3389) or SSH (22) directly to the internet (`0.0.0.0/0`) on a production NSG. This is one of the single most common causes of real-world VM compromise - use **Azure Bastion** (covered next) or restrict the source IP range to your organization's own known, trusted network instead. ### Azure Bastion - secure access without exposing management ports **Azure Bastion** provides secure RDP and SSH access to your VMs directly through the Azure Portal in your browser, without ever exposing port 3389 or 22 to the public internet at all. The VM's management port stays completely closed to the internet; Bastion handles the secure connection on your behalf from inside Azure's own network. > 📌 **Remember:** The moment you find yourself opening RDP or SSH to the internet "just for now, I'll close it later" - that is the exact moment to deploy Azure Bastion instead. "Just for now" is how real compromises happen. ### Azure DNS - hosting your domain's name resolution in Azure **Azure DNS** lets you host your domain's DNS records directly in Azure, alongside the resources those records point to, using the same authentication and management tools as everything else in your subscription. ```bash ## Create a DNS zone for your domain az network dns zone create \ --resource-group rg-demo-mumbai \ --name zerodha-clone-demo.com ## Add an A record pointing to your web server's public IP az network dns record-set a add-record \ --resource-group rg-demo-mumbai \ --zone-name zerodha-clone-demo.com \ --record-set-name www \ --ipv4-address 20.192.100.50 ``` ### Load Balancer versus Application Gateway - two different jobs Both distribute traffic across multiple backend targets, but they operate at different layers and solve genuinely different problems, and confusing them is one of the most common early-career networking mistakes. **Azure Load Balancer** operates at Layer 4 (TCP/UDP) - it distributes traffic based purely on IP address and port, with no visibility into the actual content of the request. Fast, simple, and appropriate for non-HTTP traffic or when you don't need content-based routing decisions. **Azure Application Gateway** operates at Layer 7 (HTTP/HTTPS) - it can inspect the actual URL path, headers, and cookies, and route traffic based on that content. It also includes a built-in **Web Application Firewall (WAF)** option to block common web attacks like SQL injection. Load Balancer: Application Gateway: Layer 4 - TCP/UDP Layer 7 - HTTP/HTTPS Routes by IP and port only Can route by URL path, host header No content inspection Can inspect and filter web requests Simpler, faster WAF option for web-specific attacks > 📌 **Remember:** If your traffic is plain TCP (a custom game server, a database listener) - Load Balancer. If your traffic is HTTP web traffic and you want path-based routing (`/api` to one backend, `/images` to another) or WAF protection - Application Gateway. ### Azure Traffic Manager and Azure Front Door - directing traffic across regions Both services route users to the best-performing or nearest healthy region when you run your application in more than one Azure region, but they solve it at different layers - Traffic Manager works at the DNS level, Front Door works at the HTTP application layer with additional capabilities like caching and a global WAF. **Azure Traffic Manager** uses DNS to direct a user's request to a specific region's endpoint - based on performance, geography, weighted distribution, or priority-based failover. **Azure Front Door** is a global, application-layer entry point that also load balances across regions, but additionally offers content caching (similar to a CDN) and a global Web Application Firewall. > 💡 **Tip:** Traffic Manager works purely at the DNS level, meaning it can direct users to the right region but cannot inspect or cache the actual HTTP traffic. Front Door operates as an actual application-layer proxy, giving it richer capabilities at a correspondingly higher cost and complexity. ### Azure VPN Gateway and ExpressRoute - connecting to on-premises networks **VPN Gateway** creates an encrypted tunnel over the public internet between your on-premises network and your Azure VNet - a Site-to-Site connection for connecting an entire office network, or a Point-to-Site connection for a single remote user's laptop. **ExpressRoute** is a dedicated, private physical connection from your on-premises network to Azure that never touches the public internet at all - offering more consistent latency, higher bandwidth, and typically better reliability than a VPN, at a meaningfully higher cost. VPN Gateway: ExpressRoute: Encrypted tunnel over public internet Dedicated private physical circuit Faster and cheaper to set up Slower to provision, higher cost Good for backup connectivity Best for production hybrid workloads or lower-bandwidth needs needing consistent performance > 📌 **Remember:** A common, resilient real-world pattern uses ExpressRoute as the primary connection for its performance and reliability, with a VPN Gateway configured as an automatic backup path if the ExpressRoute circuit ever fails. ### Azure Content Delivery Network - serving content from the edge **Azure CDN** caches your static content - images, videos, CSS, JavaScript files - at points of presence physically distributed around the world, so a user in Chennai gets that content from a nearby edge location instead of every request traveling all the way back to your origin server, wherever it happens to be. > 💡 **Tip:** CDN is specifically valuable for content that doesn't change often and gets accessed repeatedly by many geographically distributed users - product images, downloadable files, and video are classic fits. Highly dynamic, personalized content per-user is a poor fit for CDN caching. ---
The problem this module actually solves A team at a Bengaluru fintech moves their app to Azure. Someone spins up a virtu...
Why three different tools exist for the same job Azure gives you three ways to manage resources - the Portal, the CLI, a...
Why identity is the real security boundary in the cloud On-premises, a locked server room was a meaningful security laye...
Why every Azure account starts with a Storage Account Almost nothing in Azure exists without touching storage somewhere ...
Understanding Azure Virtual Machines A Virtual Machine (VM) is Azure's Infrastructure-as-a-Service offering - you get a ...
Understanding the Virtual Network as your private space in Azure A Virtual Network (VNet) is your own isolated, private ...
Azure Monitor - the platform underneath every metric and log Azure Monitor is the umbrella platform for collecting, anal...
This lab builds a connected environment touching every major area of this module - identity, storage, compute, and netwo...
Concept Key fact Resource Group Deleting it deletes everything inside it, permanently RBAC Principal + Role + Scope - al...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.