AZ-900: Microsoft Azure Fundamentals

Cloud computing is renting computing power, storage and software over the internet from a provider's datacenters, and paying only for what you use.

Instead of buying servers, you ask the provider for what you need ("a VM with 4 CPUs and 16 GB of memory in West Europe") and it is ready in minutes. Underneath, virtualisation splits huge fleets of physical servers into virtual machines, so many customers share the same hardware safely. You never choose, see or visit the physical server.

What you can rent:

• Compute: processing power to run applications, such as virtual machines and Azure Functions.
• Storage: space for files and data, such as Blob Storage and Azure Files.
• Networking: connections between your resources, and to your users.
• Databases, analytics and AI: managed services you use without running the servers yourself.

Every cloud service has the same five characteristics:

Why organisations move: a new server takes minutes instead of weeks, there's no hardware to buy up front, capacity follows demand instead of being guessed years ahead, failed hardware is the provider's problem, and an app can be placed near users anywhere in the world.

Security in the cloud is split between you and the provider, and the split moves with the service type: the more managed the service, the more the provider does.

How it plays out for each service type:

• IaaS (a virtual machine): you patch the operating system, set the network rules and look after the applications. Microsoft looks after the hardware and the building.
• PaaS (a managed platform): Microsoft runs the operating system and the platform; you own your application's code, its data and who can use it.
• SaaS (a finished application): Microsoft runs almost everything, but your data, your devices and your accounts are still yours.

A worked example: a company runs its website on an Azure VM. Installing security updates on the VM's Windows is the company's job. Replacing a failed disk in the server underneath is Microsoft's. Moving to the cloud changes the split, but it never moves all the security work to the provider.

A cloud model describes where the resources live and who can use them. The exam expects you to pick the right one for a scenario.

• Public cloud: the provider's hardware, shared by many customers and used over the internet. No up-front cost, no hardware to manage, and it scales quickly. You get the least control over the hardware.
• Private cloud: cloud resources used by one organisation only, in its own datacenter or hosted for it by a third party. The most control, but the organisation pays for and maintains everything.
• Hybrid cloud: public cloud and a private cloud or on-premises systems, connected and working together. Sensitive systems can stay on-premises while the rest uses the public cloud; extra capacity can be borrowed at busy times (cloud bursting).
• Multi-cloud: two or more public cloud providers at once, for example after a merger, or to use each provider's strongest services.

Two Azure tools help across models: Azure Arc manages servers, Kubernetes clusters and databases outside Azure as if they were Azure resources, and Azure VMware Solution runs existing VMware workloads in Azure.

The cloud changes how IT is paid for: from buying hardware up front to paying for what you use, month by month.

• Capital expenditure (CapEx) is money spent up front on things you keep, like servers and datacenters. You pay the full cost at the start, guess the capacity you'll need for years, and the value of the hardware drops over time.
• Operational expenditure (OpEx) is money spent on services as you use them, like a utility bill. There's nothing to buy up front, and spending follows use.

Moving to the cloud shifts IT spending from CapEx to OpEx. That is the consumption-based model:

• no up-front costs, and no hardware to buy, house or maintain;
• you pay for what you use, and can pay for more when demand rises;
• you stop paying for what you stop using.

Azure offers several ways to pay for the same resources: no commitment at all, a commitment in return for a discount, or spare capacity at a deep discount.

For example, a database server that runs day and night for the next three years suits a reservation. Overnight batch jobs that can stop and restart suit spot VMs. A brand-new app whose usage nobody knows yet stays on pay-as-you-go until a pattern appears.

Serverless means running code without managing any servers: the provider runs, scales and maintains everything underneath, and you pay only when your code runs.

What makes a service serverless:

• No infrastructure to manage: no VMs to size, patch or keep running.
• Event-driven: code runs in response to an event, such as a file upload, an HTTP request, a message or a timer.
• Automatic scaling, down to zero when nothing is happening.
• Pay per execution: you're billed for the work done, not for idle servers.

Azure's serverless services include Azure Functions (small pieces of code run by events), Azure Logic Apps (automated workflows that connect apps, with little or no code) and Azure Container Apps (containers that scale with demand). For example, a function can resize every photo the moment it is uploaded, and cost nothing while no photos arrive. The servers still exist; they are entirely the provider's problem.

High availability means a service keeps running even when parts of it fail, and it's measured as uptime: the share of time the service is available.

Microsoft states the uptime it promises for each service in a service-level agreement (SLA), such as 99.9% or 99.99%. If Microsoft misses it, you can claim service credits: a percentage off that service's bill. An SLA doesn't pay for your own losses, and free tiers usually have no SLA.

Your own design changes what you get. A single VM with premium SSD or ultra disks has a 99.9% SLA; two or more VMs in an availability set get 99.95%; two or more spread across availability zones get 99.99%.

When one service depends on another, multiply their SLAs to get the composite SLA, which is always lower than either one: a web app at 99.95% that needs a database at 99.99% gives 99.95% × 99.99% ≈ 99.94%.

Scalability is adjusting resources to match demand: more when it's busy, less when it's quiet, so you stop paying for what you don't need.

There are two directions:

• Scale up (vertical): make one resource bigger, with more CPUs or memory. Simple, but there is a largest size, it often needs a restart, and it's still one machine that can fail.
• Scale out (horizontal): add more instances behind a load balancer. There's practically no limit, nothing stops while instances join, and the others carry on if one fails.

Scaling back down is scale down, and back in is scale in.

Elasticity is scaling automatically as demand changes. In Azure this is autoscale, with rules such as "add an instance when average CPU stays above 70% for 10 minutes; remove one when it falls below 30%". An online shop that adds web servers during a sale and removes them afterwards is elastic.

Reliability is a workload's ability to recover from failures and keep working; predictability is knowing in advance how it will perform and what it will cost.

Reliability comes from not putting everything in one place. Azure has regions all over the world and availability zones inside them, so copies of a workload in different places keep it going when one place fails. Four related terms:

A disaster recovery plan sets two numbers: how long you can afford to be down (RTO, recovery time objective) and how much recent data you can afford to lose (RPO, recovery point objective). Tools such as Azure Site Recovery, backups in another region and region pairs help meet them.

Predictability comes in two kinds:

• Performance predictability: autoscaling, load balancing and high availability keep performance steady when demand changes.
• Cost predictability: you can forecast and track spending with the pricing calculator, Cost Management and budgets.

The Azure Well-Architected Framework collects Microsoft's guidance in five pillars: reliability, security, cost optimisation, operational excellence and performance efficiency.

The cloud makes security stronger, rules easier to enforce, and resources easier to manage, often automatically.

Security. Microsoft secures the physical datacenters, every Azure service gets basic protection against floods of traffic (DDoS protection), Azure Storage encrypts data at rest by default, and Microsoft patches the platform. You choose how much else you manage: IaaS leaves you the most control, while PaaS and SaaS take patching off your hands.

Governance and compliance. The cloud makes it easier to set standards and prove you meet regulations, with tools that apply across everything you own:

• Azure Policy enforces rules, such as "only these regions" or "every resource needs a CostCenter tag";
• resource locks stop resources being deleted or changed by accident;
• role-based access control gives each person only the access they need;
• management groups apply policies and access to many subscriptions at once.

Manageability comes in two kinds:

• Management of the cloud is what the cloud does for your resources: scale them automatically, deploy them from templates, watch their health, replace failing resources automatically, and send alerts.
• Management in the cloud is how you manage them: the Azure portal, a command line, APIs and PowerShell.

The three cloud service types differ in how much the provider runs for you: infrastructure, a whole platform, or a finished application.

Where each one fits:

• IaaS: moving existing servers to the cloud unchanged (lift and shift), test and development environments that come and go, websites that need a custom server set-up, storage and backup, high-performance computing.
• PaaS: building and running apps without managing servers, APIs and back ends, analytics and reporting on managed databases.
• SaaS: email and messaging, office productivity, customer relationship management, finance and expense tracking.

One company often uses all three: its old accounting server moves to a VM (IaaS), its new website runs on App Service (PaaS), and its staff use Microsoft 365 for email (SaaS).

Azure's physical building blocks nest inside each other: datacenters make up availability zones, zones make up regions, and regions make up geographies.

• Datacenters are buildings full of servers with their own power, cooling and networking. You can't choose or visit one; Microsoft secures them, and you choose a region.
• A region is a geographical area with one or more datacenters close together on a low-latency network, such as West Europe or East US. You choose one for each resource, by distance to your users, data residency and compliance rules, which services and sizes it offers, and price. Some services are global and belong to no region, such as Microsoft Entra ID and Azure DNS.
• An availability zone is a physically separate location inside a region: one or more datacenters with independent power, cooling and networking. Regions that have zones have at least three, so if one zone fails (a fire, a power cut), the others keep running.

Services use zones in three ways: zonal services are pinned to one zone (a VM in zone 1, so for resilience you deploy copies in several zones); zone-redundant services replicate across zones automatically (zone-redundant storage, Azure SQL Database); non-regional services are available everywhere.

Most regions are paired with another region far away in the same geography, as a safety net against a whole region going down.

A region pair joins two regions in the same geography, usually at least 300 miles (480 km) apart, such as East US with West US. Pairs help with disaster recovery:

• some services replicate data to the paired region automatically, such as geo-redundant storage;
• in a broad outage, one region of each pair is restored first;
• planned Azure updates roll out to one region of a pair at a time;
• data stays in the same geography, for legal and tax reasons (with rare exceptions, such as Brazil South).

A few pairs are one-way, and some newer regions have no pair and rely on availability zones instead.

A geography is a market, usually a country, holding two or more regions, which keeps data residency and compliance boundaries.

Sovereign regions are separate instances of Azure, isolated from the main public cloud for legal or compliance reasons: Azure Government for US government agencies and their partners, and Azure operated by 21Vianet in China.

Azure organises everything you create in four levels: resources go in resource groups, resource groups in subscriptions, and subscriptions in management groups.

• A resource is anything you create: a VM, a storage account, a virtual network, a database.
• A resource group holds resources that share a lifecycle, such as everything for one app. Every resource is in exactly one resource group, resource groups can't be nested, and a resource can be moved to another group. Deleting a resource group deletes everything in it. Access and policies given to a group apply to its resources.
• A subscription is a unit of billing and of access control, linked to one Microsoft Entra tenant (your organisation's directory). Companies use separate subscriptions to get separate bills (one per department), to separate environments (development and production), or to stay within each subscription's limits. One account can have several subscriptions.
• Management groups hold subscriptions, so you can apply policies and access to many subscriptions at once. They can be nested up to six levels below the root management group, with up to 10,000 in a directory.

Settings such as policies and role assignments are inherited downwards: a policy on a management group applies to every subscription, resource group and resource beneath it.

An Azure virtual machine is IaaS: a computer in the cloud with full control of its operating system, for when you need exactly your own set-up.

Use VMs to lift and shift existing servers, to run software that needs a particular operating system or configuration, or for test labs. You pick a size from families tuned for different jobs: general purpose (web servers, small databases), compute optimised (more CPU), memory optimised (large databases), storage optimised, GPU (AI and graphics) and high performance compute.

When you create a VM, Azure creates or connects:

• a size (CPUs and memory) and an image (Windows or Linux);
• disks: an operating system disk, and data disks if needed;
• a virtual network and a network interface, and optionally a public IP address.

You pay for compute while the VM is allocated. Stopping it from the portal, CLI or PowerShell deallocates it and stops compute charges (its disks are still billed); shutting it down from inside its own operating system leaves it allocated, so you keep paying. To reach a VM without opening remote-desktop or SSH ports to the internet, use Azure Bastion.

Three ways to run VMs at scale: scale sets grow and shrink automatically, availability sets survive hardware failures, and Azure Virtual Desktop delivers desktops to users.

• Virtual Machine Scale Sets run a group of identical, load-balanced VMs that scale out and in automatically with demand, by rules or on a schedule.
• Availability sets spread VMs across fault domains (racks with their own power and network switch; up to three) and update domains (rebooted together during maintenance, one domain at a time). One failing rack, or a maintenance reboot, never takes every VM down. They cost nothing extra and protect against failures inside one datacenter; for the loss of a whole datacenter, use availability zones.
• Azure Virtual Desktop delivers Windows desktops and apps from the cloud to any device. It supports multi-session Windows 11 and Windows 10 Enterprise (many users on one VM), and since the data lives in Azure, a lost laptop holds none of it.

When you don't need a whole VM, Azure can run a container, a single function, or a whole web app for you.

A container packages an app with everything it needs, so it runs the same anywhere. Containers share the host's operating system kernel, so they are much smaller than VMs (megabytes, not gigabytes) and start in seconds instead of minutes.

App Service handles the servers, patching, load balancing and scaling. Bigger plans add autoscale, backups and deployment slots: deploy a new version to a staging copy, test it, then swap it into production with no downtime.

An Azure virtual network is your own private network in Azure: your resources talk to each other through it, and to the internet and your offices only as you allow.

An Azure Virtual Network (VNet) belongs to one region and one subscription. You choose its private address range and divide it into subnets, such as a web subnet and a database subnet, each with its own rules. A VNet provides:

• isolation and segmentation of your resources;
• internet communication, through public IP addresses or a public load balancer;
• communication between Azure resources, inside the VNet and through service endpoints;
• communication with on-premises networks, through VPN Gateway or ExpressRoute;
• routing, which you can change with route tables;
• filtering with network security groups (NSGs), which allow or deny traffic by port, protocol and address.

Virtual network peering connects two VNets so their resources talk as if they were on one network. Traffic between peered VNets travels over Microsoft's private backbone, never the public internet. Global peering connects VNets in different regions.

There are two ways to connect your own network to Azure: an encrypted tunnel over the internet (VPN Gateway), or a private connection that never touches the internet (ExpressRoute).

A VPN gateway sends encrypted traffic over the public internet. It sits in a dedicated subnet, and a VNet has one. Its connections:

• site-to-site: a whole office network to Azure;
• point-to-site: one computer to Azure;
• VNet-to-VNet: two Azure VNets.

It's quick to set up and inexpensive. For high availability it can run active-active (two tunnels at once), be zone-redundant, or act as the backup path for ExpressRoute.

ExpressRoute is a private connection between your network and Microsoft's, through a connectivity provider. It doesn't cross the public internet, so it is more reliable, faster and lower latency than a VPN. You can connect through a co-location facility with a cloud exchange, a point-to-point Ethernet link, an any-to-any (IP VPN) network, or straight to Microsoft with ExpressRoute Direct.

Azure DNS answers the question "which address is this name?" for your domains, and endpoints decide whether a service is reached over the internet or privately.

DNS turns names such as www.example.com into IP addresses. Azure DNS hosts your domain's DNS records (A, CNAME, MX, TXT and others) on Azure's global name servers, with the same access control and logs as your other resources. It also offers private DNS zones for names used only inside your VNets, and alias records that point straight at an Azure resource, even for the bare domain (example.com). Azure DNS doesn't sell domain names: you buy those from a registrar and point them at Azure DNS.

Three ways to reach an Azure service, such as a storage account:

A private endpoint uses Azure Private Link: the service appears inside your VNet like one of your own resources.

A storage account is the container for your Azure Storage data, and inside it five services store five different kinds of data.

A storage account's name must be globally unique, 3 to 24 characters, using lowercase letters and numbers only, because it becomes part of every service's web address, such as https://<account>.blob.core.windows.net.

Blobs can live in four access tiers: the less often you read the data, the cheaper it is to store, and the more it costs, or the longer it takes, to read.

Archive is offline: a blob must be rehydrated to an online tier before it can be read, which can take hours. Hot, cool and cold can be set as an account's default tier; archive is set on individual blobs only. Moving a blob out of cool, cold or archive before its minimum time costs an early deletion charge for the remaining days.

For example: product photos on a shop's website stay hot, last year's invoices go cool or cold, and records kept for seven years for the auditors go to archive.

Azure always keeps several copies of your data; the redundancy option decides how many and where, and so what kind of failure your data survives.

With plain GRS or GZRS, the copy in the secondary region can be read only after a failover. RA-GRS and RA-GZRS (read-access) let you read it at any time. LRS is the cheapest and least durable; GZRS the most durable.

Azure has tools for copying files into storage, keeping file servers in sync, and moving whole servers, including by shipping a physical device when the network is too slow.

Microsoft Entra ID is Azure's cloud identity service: it signs people in to Azure, Microsoft 365 and thousands of other apps, and decides what they can reach.

Two words first: authentication proves who you are; authorisation decides what you're allowed to do.

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud-based identity and access management service. It provides:

• authentication, including self-service password reset and multi-factor authentication;
• single sign-on: one identity for many applications;
• application management: who can use which cloud and on-premises apps;
• device management: registering devices and controlling access from them.

Microsoft Entra Connect synchronises users from an on-premises Active Directory to Entra ID, so people use the same identity everywhere.

Entra ID speaks modern web sign-in protocols and has no domain controllers or Group Policy. Older applications that need domain join, Group Policy, LDAP or Kerberos can use Microsoft Entra Domain Services: a managed domain that Azure runs and patches for you, without your own domain controllers. Users and passwords flow one way, from Entra ID into the managed domain.

Signing in should be both easy and hard to fake: single sign-on removes extra passwords, MFA adds a second proof, and passwordless removes the password altogether.

• Single sign-on (SSO): sign in once, with one identity, to many applications. Fewer passwords means fewer weak or reused ones.
• Multi-factor authentication (MFA): two or more proofs of different kinds: something you know (a password), something you have (a phone, a security key) and something you are (a fingerprint, a face). A password and a PIN are both something you know, so together they are still one factor.
• Passwordless: no password at all, replaced by something you have plus something you are or know: Windows Hello for Business, the Microsoft Authenticator app or passkeys (FIDO2) such as a hardware security key. More convenient, and much harder to phish.

External identities (Microsoft Entra External ID) let people from outside your organisation in, with accounts they already have:

• B2B collaboration: a partner company's staff sign in to your apps as guests, with their own work accounts.
• For customers (what used to be Azure AD B2C): people sign up to your public app with an email address or a social account such as Google.

Conditional Access decides whether a sign-in is allowed, role-based access control decides what a signed-in person can do, and Zero Trust is the idea behind both.

Conditional Access applies if-then policies to sign-in signals: who is signing in, to which app, from where, on which device, and how risky it looks. Then it allows, blocks, or allows only after extra steps. For example: require MFA when someone signs in from outside the office, block sign-ins that look risky, or allow the finance app only from company-managed devices.

Azure role-based access control (RBAC) grants least privilege: you assign a role (what can be done) to a security principal (a user, group or application) at a scope (a management group, subscription, resource group or single resource), and it's inherited by everything below that scope.

Zero Trust means never trust, always verify: every request is checked as though it came from an open network, instead of trusting anything inside the office network. Its three principles are verify explicitly, use least-privilege access and assume breach (limit the damage, segment access, encrypt everything, watch for threats).

Defence in depth protects your data with layers, so an attacker who gets past one meets the next; Defender for Cloud watches those layers for you.

The seven layers, from the outside in:

1. Physical security: the datacenter buildings and hardware (Microsoft's job).
2. Identity and access: Microsoft Entra ID, MFA, Conditional Access.
3. Perimeter: protection against floods of traffic (DDoS protection) and firewalls at the network edge.
4. Network: network security groups and segmentation between resources.
5. Compute: patched operating systems, endpoint protection, no open management ports.
6. Application: secure code, with secrets kept out of it in Azure Key Vault.
7. Data: encryption and access control around the data itself, at the centre.

Microsoft Defender for Cloud protects workloads in Azure, on-premises and in other clouds (AWS and Google Cloud). It does two jobs:

• Assess your security posture: it finds weaknesses and misconfigurations and gives a secure score with recommendations, such as "enable MFA for owners" or "close management ports". These foundational features are free.
• Protect your workloads: paid Defender plans for servers, storage, databases and containers detect threats and raise security alerts with what happened and how to respond.

Azure Advisor also shows security recommendations, but they come from Defender for Cloud.

What you pay in Azure depends on what you use, how much, where, and how you commit; a few habits and discounts cut the bill a lot.

The main factors:

• Resource type and options: every service has its own pricing, and a VM's cost depends on its size, operating system licence and disks, a storage account's on its tier and redundancy.
• Consumption: pay-as-you-go charges for what you use; using more costs more.
• Maintenance: resources you no longer need still cost money, including what a deleted VM can leave behind (disks, public IP addresses, network interfaces).
• Geography: the same resource costs different amounts in different regions.
• Network traffic (bandwidth): data coming into Azure (ingress) is generally free; data leaving Azure (egress) and data moving between regions is charged.
• Subscription type: some include allowances, such as the free account's 12 months of popular services; large organisations buy through agreements.
• Azure Marketplace: third-party solutions add their vendor's charges.

Estimate what a solution will cost before you deploy it with the pricing calculator; after you deploy, watch and control the real spending with Microsoft Cost Management.

The Azure pricing calculator estimates the monthly cost of the resources you configure: pick services, a region, tiers and a billing option (such as pay-as-you-go or a reservation), and it shows the estimate. Nothing is deployed.

Microsoft Cost Management works with what you actually spend:

• cost analysis: spending broken down by service, resource group, location or tag, with forecasts;
• budgets: a spending limit you set for a scope, with alerts at thresholds such as 80% and 100%, which can also trigger automated actions;
• credit alerts and spending quota alerts, and savings recommendations from Advisor.

Older courses mention a TCO (total cost of ownership) calculator for comparing on-premises with Azure. Microsoft has dropped it, and the July 2026 outline names only the pricing calculator.

Tags are labels you put on Azure resources, as name/value pairs, to organise them: who owns what, which project it belongs to, and who pays for it.

Examples: Environment: Production, CostCenter: CC-4021, Owner: asha@example.com, Project: Website.

The rules:

• up to 50 tags on each resource, resource group or subscription;
• tag names aren't case-sensitive, tag values are;
• tags are plain text, so never put passwords or other secrets in them;
• tags are not inherited: a resource group's tags don't appear on the resources inside it, and a subscription's don't appear on its resource groups.

What tags are for: cost reporting (group spending by department or project across many resource groups), ownership, operations (which machines can be switched off at night), automation and compliance. Tags never enforce anything by themselves; Azure Policy can require a tag on new resources, add one, or copy a resource group's tag onto its resources.

Azure Policy enforces rules on your Azure resources, whoever creates them: allowed regions, allowed VM sizes, required tags, HTTPS only.

How it works:

• A policy definition is a rule, such as "allowed locations: West Europe and North Europe". Microsoft provides hundreds of built-in definitions, and you can write your own.
• An initiative is a group of definitions assigned together, such as everything a compliance standard needs.
• An assignment applies a definition or initiative to a scope (a management group, subscription or resource group), and everything below inherits it.
• Azure Policy then evaluates resources and reports which comply.

What a policy does when a resource breaks the rule (its effect):

Remediation tasks fix existing resources that don't comply. Policy and RBAC work together: RBAC decides who can act, Policy decides what is allowed, whoever acts. RBAC starts from deny (no access until granted); Policy starts from allow (everything is allowed until a policy says otherwise).

A resource lock stops a resource, resource group or subscription being deleted or changed by accident, even by an Owner, until someone removes the lock.

• Locks are inherited: a lock on a resource group protects every resource in it.
• They apply to everyone, including Owners. To delete a locked resource, someone with permission to manage locks (such as an Owner or User Access Administrator) must remove the lock first.
• Locks are a safety net against mistakes, not a security control: real protection comes from giving people only the access they need, with RBAC.

Microsoft Purview is a family of data governance, risk and compliance solutions: it finds, classifies and protects your data wherever it lives.

Purview works across on-premises, multicloud and SaaS data, in two broad areas:

• Risk and compliance: protect sensitive data across Microsoft 365 (Teams, SharePoint, OneDrive, Exchange) with data loss prevention (stop sensitive data being emailed outside the company), insider-risk tools, and Compliance Manager, which scores your progress against regulations such as GDPR and suggests improvements.
• Unified data governance: the Data Map discovers and classifies data automatically, data lineage shows where data came from and how it moved, and a catalogue helps people find data they can trust.

How Purview differs from its neighbours:

Microsoft's own compliance evidence, its independent audit reports (ISO/IEC 27001, SOC 1, 2 and 3) and compliance guides, is published on the Service Trust Portal. The July 2026 outline no longer names it, but older questions may.

You can manage Azure by clicking in a browser, typing commands, from a phone, or from code: every tool does the same things through the same layer.

Cloud Shell sessions are temporary, so files you want to keep go in an Azure file share that Cloud Shell mounts for you.

Azure Arc extends Azure management to resources outside Azure, so servers in your own datacenter or another cloud are managed as if they were in Azure.

Arc connects servers (Windows and Linux), Kubernetes clusters and databases (such as SQL Server) running on-premises or in other clouds. They appear in Azure as resources, so you can:

• organise them with resource groups and tags;
• control access with RBAC;
• enforce rules with Azure Policy;
• monitor them with Azure Monitor and protect them with Defender for Cloud.

Don't confuse it with Azure Migrate: Migrate moves workloads into Azure, while Arc manages them where they are.

Infrastructure as code describes your resources in files, so environments are built the same way every time; Azure Resource Manager is the layer that carries out every request.

Infrastructure as code (IaC) means writing your infrastructure down in files kept in source control: reviewed, versioned and deployed like code, the same way every time. Declarative IaC describes the end state ("this is what should exist"); an imperative script lists the steps ("create this, then that").

Azure Resource Manager (ARM) is Azure's deployment and management service. Every request, from the portal, Azure CLI, Azure PowerShell, the SDKs or the REST API, goes through it; it authenticates and authorises the request, then acts. That's why every tool gives the same results, and why role-based access control, tags and locks apply whichever tool you use.

ARM templates are declarative JSON files describing the resources to deploy, in four sections: parameters (values you supply, such as the environment name), variables, resources and outputs. They are:

• idempotent: deploy the same template again and you get the same result, with nothing duplicated;
• orchestrated: Resource Manager works out the order, and deploys in parallel where it can;
• validated before they deploy, and modular: small templates can be linked into larger ones.

Bicep is a simpler language for the same job; Bicep files are compiled into ARM templates when you deploy them.

Azure Advisor looks at how your resources are set up and used, and gives you personalised recommendations to improve them.

Its recommendations come in five categories:

You can postpone or dismiss a recommendation that doesn't suit you, and the Advisor score shows, as a percentage, how closely you follow the recommendations, overall and per category.

Azure Service Health tells you what's happening to Azure itself: outages, planned maintenance and advisories, from the whole world down to a single resource.

Service Health reports four kinds of event: service issues happening now, planned maintenance, health advisories (changes you should act on, such as a feature being retired) and security advisories. You can set alerts so you hear about events by email or text, and it keeps a history of past incidents for reports and root-cause analysis.

Azure Monitor collects the numbers and records your resources produce, lets you search and chart them, and acts automatically when something goes wrong.

It gathers data from Azure, on-premises and other clouds:

• Metrics: numbers over time, such as CPU percentage or requests per second, arriving in near real time.
• Logs: records of events. The activity log shows who did what to your resources, and when, such as who deleted a VM, kept for 90 days with no setup. Resource logs and agents inside VMs add more detail.

What you do with the data:

• Log Analytics: write queries in KQL (Kusto Query Language) over the logs you've collected, such as "every failed sign-in in the last week".
• Alerts: fire on a metric ("CPU above 90% for 10 minutes"), a log search or an activity log event, and notify people or run automation through action groups (email, text message, webhook).
• Autoscale adds or removes instances by rules, and dashboards and workbooks put the data on screen.
• Application Insights watches your web applications: requests, response times, failures, dependencies and availability tests.

Most wrong answers in AZ-900 come from picking a neighbour of the right answer. Read this table once more before the practice.