Azure Fundamentals AZ-900

💻 Concrete example — the IaaS VM that got cryptomined while Azure itself stayed intact

Situation: A team lifts an old Windows app onto an Azure VM, opens RDP (3389) to the internet "just for the migration weekend", and forgets. Three weeks later the VM sits at 100% CPU and the invoice is up. The developer opens a support case claiming Azure was compromised.

Walk: 1) Nothing on Microsoft's side failed. The hypervisor, the host and the physical datacenter are the provider's responsibility and they held. 2) The VM is IaaS, so the guest OS, its patch level, the local accounts and the NSG rules in front of it are all the customer's — a brute-forced local administrator password is squarely on the customer's side of the line. 3) The fix is customer-side too: remove the 3389 allow rule, reach the VM through Bastion or a VPN instead, enforce a strong password and patch the OS.

Verify: Ask the same question about the same app running on App Service (PaaS): the OS patching moves to Microsoft, but the app code, the credentials it uses and who can sign in stay yours. On Microsoft 365 (SaaS) almost everything moves to Microsoft — except the data you put in and the identities that can reach it, which never move at any tier.

💻 Concrete example — the "99.99%" service that measured 99.6%

Situation: A team promises the business 99.99% availability for an internal app. It runs as a single VM talking to a single Azure SQL database. Over a quarter the app is unreachable for roughly three hours — about 99.6% — and nobody can explain the gap.

Walk: 1) Nothing was promised in the first place: a single VM only carries an SLA at all if it uses premium storage, and even then it is 99.9% — roughly 8.7 hours a year, not 52 minutes. 2) Availability is bought with redundancy: spreading the same VMs across an availability set raises it to 99.95%, and across availability zones to 99.99%. 3) Dependencies multiply, they do not average. A front end at 99.95% in front of a database at 99.99% gives a composite of 0.9995 × 0.9999 ≈ 99.94% — every extra component in the request path can only lower the number.

Verify: Redeploy the VMs zonally, re-run the composite arithmetic against the new tier numbers, and quote that figure to the business. The same exercise explains why elasticity is not just a cost story: autoscale that adds instances also removes the single instance whose reboot took the service down.

💻 Concrete example — the insurer that was told "cloud-first" and still could not move the policy database

Situation: An insurer runs a mainframe-era policy database plus a customer portal. The board mandates cloud-first to stop buying hardware. The regulator requires policyholder records to stay physically in-country, and the country has no Azure region.

Walk: 1) Public cloud for everything fails the residency test, and it fails on the regulation, not on security — Azure's compliance portfolio is broader than the insurer's own datacenter. 2) Private cloud for everything satisfies the regulator and defeats the mandate: the portal is the part that needs elastic capacity at renewal season, and keeping it on-premises means buying for the peak again. 3) Hybrid splits along the constraint. The policy records stay in the on-premises private cloud; the portal, the reporting and the dev/test estate run in Azure and reach the records over a private link.

Verify: Check that the split holds under the money question too. The portal is now OpEx and scales at renewal season; the datacenter shrinks to the one workload that has to be there; and the next audit asks only about the records that never left. If the regulator later approves an in-country region, the same split becomes a migration plan rather than a redesign.

💻 Concrete example — three VMs, one availability set, and a datacenter that still took the app down

Situation: An app runs on three VMs in an availability set in West Europe, described in the design document as "highly available". A power and cooling incident in one West Europe datacenter takes all three offline at once. The team insists the design was correct.

Walk: 1) The availability set did what it is for: it spread the VMs across fault domains (separate racks, power and switches) and update domains (so platform patching never reboots them together). It does not promise they are in different buildings. 2) The failure was datacenter-sized, and the control for that is availability zones — physically separate locations inside the region, each with independent power, cooling and networking, linked by private high-speed fibre rather than the public internet. 3) A region-wide failure is a third case again, and that is what the region pair is for: West Europe is paired with North Europe, platform updates roll one half of a pair at a time, and geo-redundant storage replicates between the two.

Verify: Redeploy the three VMs as zonal instances in zones 1, 2 and 3, and confirm the storage account is at least ZRS. Then check availability: not every region offers zones, and not every service is present in every region, so "which region" is a decision about latency, service availability, data residency and price before it is a decision about redundancy.

💻 Concrete example — the cleanup that deleted a shared VNet along with its resource group

Situation: A proof-of-concept resource group is deleted at the end of a quarter to tidy the subscription. Within minutes, two unrelated applications in other resource groups lose connectivity. Nobody deleted anything belonging to those apps.

Walk: 1) The virtual network the two apps were peered to had been created inside the proof-of-concept group months earlier, because that is where the person who built it was working. 2) Deleting a resource group deletes everything inside it — it is a lifecycle boundary, not a label. Resources in different groups can talk to each other freely, which is exactly why a dependency can end up crossing the boundary unnoticed. 3) Each resource lives in exactly one group, and groups do not nest, so the only durable fix is to place shared infrastructure in a group whose name states its lifetime, for example a platform or networking group, and to put a CanNotDelete lock on it.

Verify: The same reasoning answers the neighbouring exam questions. Quota exhaustion — "we cannot start more VMs in West Europe" — is a subscription limit per region, not a resource-group one, so another subscription has its own headroom. And a rule that must hold for dev, test and production subscriptions alike belongs on the management group above them, where it is inherited once rather than assigned three times.

💻 Concrete example — the portal hotfix that vanished on the next pipeline run

Situation: An engineer fixes a production incident at 02:00 by raising an App Service plan from S1 to S3 in the portal. The service recovers. Four days later the release pipeline redeploys the Bicep template and the site slows to a crawl again at the next traffic peak.

Walk: 1) The template still says S1, and a declarative deployment reconciles reality to the template — it does not merge the manual change in. This is configuration drift, and idempotence is precisely what caused it: deploying the same template twice produces the same end state both times. 2) The change was never wrong, it was never written down. The fix is to put S3 in the template (or in the parameter file for that environment) and let the pipeline be the source of truth. 3) Note what ARM did not do: it did not create a second plan. Templates are not scripts that run again; they are a desired state that gets compared.

Verify: Re-run the deployment with no changes and confirm it completes with nothing modified — that no-op is the signature of a declarative system. The same property is what lets one template plus three parameter files produce dev, test and production without three copies drifting apart, and it is why Microsoft steers new work to Bicep, which compiles to the same ARM JSON with far less of it.

💻 Concrete example — the nightly batch job paying for a VM that idles 23 hours a day

Situation: A nightly job resizes the day's uploaded images. It runs for about 20 minutes at 01:00 and does nothing else. It lives on a D2s_v3 VM kept on all month so the scheduler is never late, at roughly $70 a month for about 10 hours of actual work.

Walk: 1) The workload is not "a server", it is a task with a start and an end — a VM charges for allocated time whether it computes or not, so 97% of the bill buys idleness. 2) Azure Container Instances fits directly: package the existing script as a container, start it on a schedule, pay per second while it runs, and there is no orchestrator and no host to patch. 3) Azure Functions fits if the work can be expressed as a trigger — per image uploaded, on a timer — and costs nothing while idle, with the caveat that the consumption plan has an execution time limit, so one 20-minute monolithic run must be split into per-image invocations. 4) AKS would run it happily and bring a cluster to operate for a job that takes 20 minutes. That is the trap answer.

Verify: After the move, the monthly compute line for this job falls to cents and the only thing the team maintains is the image. Apply the same test in reverse: a licensed application that must see a specific OS build and a kernel driver still belongs on a VM — full OS control is the one thing every rung above it takes away.

💻 Concrete example — the allow rule that never matched because a deny sat above it

Situation: A web tier cannot reach the database subnet on 1433. The team adds an inbound rule "Allow-SQL-from-Web" at priority 200 on the database subnet's NSG. Nothing changes. They then add an outbound allow rule on the web tier for the return traffic. Still nothing.

Walk: 1) List the effective rules in priority order and the cause is visible: an earlier hardening exercise left "Deny-All-Inbound" at priority 100. Lower number means higher priority and evaluation stops at the first match, so the allow at 200 is never reached. Moving the allow to priority 90 fixes it in one change. 2) The outbound rule was never needed. NSGs are stateful: allowing the inbound session means its replies are permitted without a matching rule, and adding one only makes the rule set harder to read. 3) Confirm which NSG is actually in the path — rules can sit on the subnet and on the NIC, and both are evaluated.

Verify: Use the effective-rules view on the database NIC to confirm the allow is now the first match, and re-test the connection. The lesson generalises to VNet peering, where the surprising default is the opposite kind: peering is not transitive, so two spokes peered to the same hub cannot reach each other without gateway transit or routes that send them through it.

💻 Concrete example — the month-end reports filed to Archive that took hours to come back

Situation: Finance must keep seven years of statements, so an admin sets a blob container's default tier to Archive and moves everything into it, including the current month's reports that accounting opens most days. The first request for a report returns an error saying the blob is not online; a week later the bill shows unexpected charges.

Walk: 1) Archive is offline storage. A blob must be rehydrated to Hot or Cool before it can be read, which takes hours at standard priority — so a tier chosen for the 7-year data made the 7-day data unusable. 2) The surprise charges are the early-deletion penalty: Archive bills a 180-day minimum, Cool 30 days and Cold 90, so moving or deleting data before that window still charges the remainder. 3) The right shape is age-based, not folder-based: keep current reports in Hot, let a lifecycle management rule move them to Cool after 30 days and to Archive after a year.

Verify: Re-read a current report immediately (Hot, no rehydration) and confirm the lifecycle rule has moved only the older blobs. Redundancy is a separate axis that the tier does not touch: LRS keeps three copies in one datacenter, ZRS spreads them across availability zones, and the GRS and GZRS options add copies in the paired region.

💻 Concrete example — the reporting database that was fast, global, and far too expensive

Situation: A team picks Cosmos DB for an internal reporting store because the brief said "modern and scalable". Six weeks in, the finance dashboard is slow, queries that join orders to customers are awkward to write, and the request-unit bill is several times the estimate.

Walk: 1) The workload is relational: a handful of analysts running ad-hoc joins and aggregates over a few million rows, from one country, during office hours. 2) Cosmos DB is priced and tuned for the opposite profile — huge volumes of small, partition-key-shaped reads and writes, served globally at single-digit-millisecond latency. Cross-partition queries and joins are exactly what its request-unit model charges most for. 3) Azure SQL Database matches the shape: full T-SQL joins, transactions and a cost that tracks a predictable workload, with the same managed patching, backups and HA.

Verify: After the move the same dashboard queries run as ordinary SQL and the bill becomes a flat tier rather than a per-query one. Keep the reverse case in view for the exam: a product catalogue read by users on three continents, with multi-region writes and a documented latency target, is genuinely Cosmos DB — and that is where its five consistency levels, from Strong to Eventual, become the interesting decision.

💻 Concrete example — the lift-and-shift VM that could not be domain-joined to "Azure AD"

Situation: A file-and-print application is moved onto an Azure VM. It needs to join the corporate domain so it can authenticate users with Kerberos and read group memberships over LDAP. The team points it at the Entra ID tenant that already contains every one of those users, and the domain join fails.

Walk: 1) The users are genuinely there — synchronised from on-premises AD by Entra Connect — but Entra ID does not serve Kerberos or LDAP, so there is nothing for the VM to join. 2) There are two legitimate fixes: extend the existing on-premises domain to the VM over the site-to-site connection (a domain controller the VM can reach), or use Microsoft Entra Domain Services, a managed domain in Azure that projects the same identities and does speak Kerberos and LDAP. 3) Nothing here is a licensing problem or a firewall problem; it is a protocol mismatch.

Verify: Once joined to a real domain, the app authenticates as before, while the organisation's SaaS applications keep signing in through Entra ID with SSO over the modern protocols. Both directories hold the same people; they answer different questions.

💻 Concrete example — one phished laptop that could reach every server in the VNet

Situation: A finance user is phished. Within an hour the attacker is enumerating file shares, database servers and a domain controller. The environment has a firewall at the perimeter, antivirus on every machine and a strong password policy.

Walk: 1) The perimeter was never breached — the attacker signed in as a legitimate user, from a normal-looking session, and everything after that was authorised. This is the assumption Zero Trust rejects: being inside is not evidence of anything. 2) Lateral movement was free because the VNet was flat, with management ports reachable from any subnet. Network segmentation — separate subnets with NSGs that permit only the flows the applications actually need — is the layer that would have contained this. 3) Standing administrative rights turned a user compromise into an infrastructure compromise. Least privilege with just-in-time elevation means the permissions the attacker inherited expire and have to be requested. 4) Verifying explicitly — MFA plus a device-compliance requirement — would most likely have stopped the sign-in itself.

Verify: Walk the layers outward afterwards and name the control at each one: identity (MFA, Conditional Access), perimeter (DDoS, firewall), network (subnets, NSGs), compute (patching, JIT access), application, data (encryption at rest and in transit). Any layer you cannot name is where the next incident goes unimpeded.

💻 Concrete example — the connection string that shipped to a public repository

Situation: A developer commits a configuration file containing a database connection string, complete with username and password, and the repository is public. Secret scanning raises it within the hour. The credential is valid for the production database.

Walk: 1) Rotating the password first is right, but it does not fix the pattern: the next deployment will hardcode the new one. 2) The secret belongs in Azure Key Vault, where it is stored, versioned, access-controlled and auditable — every read is logged, and the value never has to be visible to a developer. 3) The part that closes the loop is the managed identity: the App Service is given an identity of its own, that identity is granted read access to the one secret, and the app fetches it at runtime. There is now no credential in the code, in source control or in the pipeline to leak.

Verify: Check the two things that prove it worked — the configuration file contains a Key Vault reference rather than a value, and the vault's access logs show the app's identity reading the secret. Defender for Cloud would independently have flagged the same weakness as a recommendation against your secure score, which is the difference between the two tools: the vault fixes it, Defender for Cloud tells you it is there.

💻 Concrete example — the "allowed locations" policy that allowed everything

Situation: To satisfy a data-residency requirement, a governance lead assigns the built-in allowed-locations policy at the management group, restricted to two European regions. A month later an audit finds fourteen resources in East US, all created after the assignment.

Walk: 1) The assignment was made with the Audit effect, which records non-compliance and permits the deployment. Nothing was ever blocked, and the compliance dashboard had been showing exactly that for a month. 2) Changing the effect to Deny stops the next one at ARM, before the resource provider is reached — the portal, the CLI and the pipeline all fail identically, because they all go through ARM. 3) The fourteen existing resources are still non-compliant after the change, because Deny is preventive. They have to be moved or recreated; policies whose effect is DeployIfNotExists or Modify can instead be run as a remediation task over what already exists.

Verify: Attempt a deployment into East US and confirm it is refused with the policy named in the error, then re-check the compliance view once the fourteen are moved. Scope matters as much as effect: assigned at the management group, the rule covers every subscription beneath it, which is precisely why it is assigned there rather than three times over.

💻 Concrete example — the Contributor who could build anything and grant nothing

Situation: A senior engineer with Contributor on the production subscription is asked to give a new starter read access to one resource group. Creating VMs, storage and databases works fine; the role assignment fails with an authorisation error. The engineer reports a broken portal.

Walk: 1) The portal is behaving correctly. Contributor grants full management of resources and explicitly excludes managing access — that separation exists so that someone who can build infrastructure cannot quietly widen who can reach it. 2) Two clean fixes exist. User Access Administrator at the resource-group scope lets the engineer grant access there and nowhere else, or an Owner performs the one assignment. Promoting the engineer to Owner on the whole subscription solves the ticket and quietly hands them permanent rights over everything. 3) The new starter should be granted Reader at the resource group, not at the subscription: narrowest role at the narrowest scope.

Verify: Confirm the assignment is visible on the resource group and absent from its siblings. Then note the one control that is not arithmetic: a resource lock outranks RBAC entirely, so even an Owner cannot delete a CanNotDelete-locked resource until the lock is removed — an intentional, auditable pause before destruction.

💻 Concrete example — the three-year reservation bought on the wrong VM size

Situation: Under pressure to cut cloud spend, a team buys three-year reserved instances for twenty D4s_v3 VMs and reports a large saving. Two months later a performance review shows those VMs average under 10% CPU and should be D2s_v3 — but the commitment is already made.

Walk: 1) The discount was real and applied to twice the capacity the workload needs; a discount on waste is still waste. 2) The correct order is measure, right-size, then commit: Azure Advisor's cost recommendations are built from actual utilisation, so the smaller size was knowable before the purchase. 3) Reservations are not entirely rigid — they can be exchanged or cancelled within Azure's published limits — but the point stands: the commitment should follow the measurement. 4) Reservations suit steady, predictable workloads; interruptible ones such as batch rendering belong on Spot VMs at a far deeper discount, accepting eviction when Azure needs the capacity back; and dev/test VMs simply need auto-shutdown outside working hours.

Verify: Before any future commitment, price it in the Pricing Calculator at the size Advisor recommends, and set a budget so the next surprise arrives as an alert. Keep the two calculators distinct: Pricing Calculator estimates a planned Azure deployment, the TCO Calculator compares today's on-premises costs against Azure for a migration business case.

💻 Concrete example — the script that built a test environment in the production subscription

Situation: An engineer with access to four subscriptions runs a tested CLI script to stand up a load-test environment. It succeeds. An hour later the production subscription shows eight unfamiliar VMs and a new resource group, and the production budget alert fires.

Walk: 1) The script was correct. The context was not: the CLI holds a default subscription, and this session's default was production. Nothing in the script named a subscription, so nothing contradicted the default. 2) The fix is to make context explicit rather than inherited — select the subscription at the top of the script, or pass it on each command, and print it before creating anything. 3) The same class of mistake is much rarer in the portal, where the subscription is a visible field on the creation blade, and that is the honest trade: the portal shows you context, scripts reproduce work.

Verify: Delete the mistaken resource group, re-run with the subscription set explicitly, and confirm the resources land in the test subscription. Two details often tested alongside this: Cloud Shell needs an Azure file share to persist anything between sessions, and CLI and PowerShell are functionally equivalent — choose by the scripting language your team already uses, not by capability.

💻 Concrete example — the slow web app whose VM metrics all looked perfect

Situation: Users report that a web app takes four or five seconds to load. The infrastructure dashboard shows CPU at 12%, memory comfortable, no failed requests and no alerts. The infrastructure team says the platform is healthy; the users keep complaining.

Walk: 1) Both are right. Platform metrics describe the host, not the request, and a request spending its time waiting consumes almost no CPU. 2) Application Insights answers at the request level: the end-to-end transaction shows roughly 3.6 of the 4 seconds inside a single dependency call to the database, repeated for every row of a list. 3) The Log Analytics workspace behind it is where you confirm the pattern with KQL — group the dependency telemetry by name and look at the call count per request — and that turns "the app is slow" into "this query runs N times per page".

Verify: After the query is fixed, the same transaction view shows the dependency time collapsing and the page returning under a second. Then close the monitoring gap that let it run: add an alert on server response time with an action group that emails the team, so the next regression is detected by the platform rather than by users.

💻 Concrete example — the VMs that rebooted overnight with nothing in the application logs

Situation: Four VMs restart at 03:10. The application logs end mid-transaction and resume after the boot, with no error, no crash dump and no deployment that night. The on-call engineer starts reading application code.

Walk: 1) The wrong place to start. Resource Health for one of the VMs states plainly that it was rebooted by the platform for a host update — a platform event, not an application fault. 2) Service Health shows the matching planned-maintenance notice for that region and subscription, issued days earlier and read by nobody. 3) The durable fix is notification and design: create a Service Health alert so planned maintenance and incidents reach the team by email or webhook, and spread the VMs across an availability set or zones so platform updates never reboot them all at once.

Verify: Confirm the alert by checking the next advisory arrives, and confirm the redundancy by checking the instances now sit in different update domains or zones. Keep the three views straight: Azure Status is the public page for broad outages, Service Health is filtered to your subscriptions and services, and Resource Health is your individual resource.