Azure Fundamentals AZ-900

☁ Scenario — picking the right cloud service model

Situation: A 200-person company wants to move email, calendar, and document collaboration to the cloud. The IT team has 2 people and can only manage user accounts — they cannot patch servers, deploy application updates, or maintain uptime.

Decision: This is SaaS (Microsoft 365). The provider manages everything from the physical datacenter to the running application. IT manages only identities, licenses, and data. If the team needed to host their own app, the answer would be PaaS; if they needed full OS control for a legacy system, IaaS.

Shared responsibility check: Under SaaS the customer is still responsible for which users have access, what data they put in, and MFA enrollment. "The provider handles security" is never the full answer — data and identities stay with the customer regardless of model.

☁ Scenario — designing an Azure resource hierarchy for 3 teams

Situation: You're onboarding Dev, QA, and Production teams. Each needs isolated billing and separate governance policies, but all employees use the same company directory (Entra ID tenant).

Design: One Entra ID tenant (single directory, shared identities). One Management Group with baseline Policy applied (e.g., "allowed regions = West Europe + North Europe"). Three Subscriptions — one per team — for billing isolation and quota separation. Within each subscription, Resource Groups per project lifecycle (e.g., webapp-prod-rg, database-prod-rg). Tags (env=prod, team=production) on every resource for cost reporting.

Why not one subscription? You can't easily split billing or apply different governance rules without subscription-level boundaries. The management group enforces the "must not deploy outside Europe" policy across all three subscriptions automatically — no need to repeat it per subscription.

☁ Scenario — choosing the right compute service for a web migration

Situation: A startup runs a Django web app on 3 on-premises Linux VMs. They want to move to Azure, eliminate OS patching overhead, and add auto-scaling for Black Friday traffic spikes — without rewriting any code.

Answer: Azure App Service (PaaS). No OS to patch, built-in auto-scale rules, HTTPS/TLS included, custom domain support, and Django is natively supported. The team just pushes code.

Why not the others? Azure VMs would preserve the existing setup but keep the patching burden. Azure Functions would require rewriting the app as event-driven handlers — too invasive. AKS is powerful but adds Kubernetes operational complexity they don't need. App Service is the sweet spot: less management than VMs, less rework than Functions, less ops than AKS.

Exam pattern: "Reduce infrastructure management" + "no code changes" = App Service. "Respond to events/triggers" = Functions. "Full OS control" = VMs.

☁ Scenario — enforcing MFA only for remote logins via Conditional Access

Situation: The CFO accesses Azure-hosted financial reports from a personal laptop at home. Company policy: MFA is required whenever a sign-in originates outside the corporate office network. Office logins should remain seamless (no MFA prompt).

Conditional Access policy: Users = Finance group; Cloud apps = All cloud apps; Conditions → Locations = "Any location" EXCEPT the Named Location "Corporate HQ" (defined as the office's public IP range); Grant = Require multi-factor authentication. Save and enable the policy.

Result: Sign-ins from the office IP match the exception and pass through without MFA. Remote sign-ins (home, coffee shop, hotel) fall into "any location not excluded" and trigger the MFA grant control automatically.

Exam note: Conditional Access evaluates signals — user identity, device compliance, location, risk level — and returns a grant or block decision in real time. It is the Zero Trust policy engine in Entra ID.

☁ Scenario — preventing accidental deletion with a resource lock

Situation: A junior admin accidentally deleted the production SQL server last month during routine cleanup, causing 4 hours of downtime. Your task: prevent this from happening again, but don't block routine deployments or configuration updates.

Solution: CanNotDelete lock on the production resource group. Navigate to the resource group → Settings → Locks → Add lock. Set Name = "prod-no-delete", Lock type = CanNotDelete. Save.

Why CanNotDelete and not ReadOnly? ReadOnly would block all writes including legitimate deployments and configuration changes — too restrictive. CanNotDelete allows updates and new resource creation, but prevents the delete operation. Developers can still deploy; they just can't destroy production resources.

Key exam point: Locks override RBAC. Even a user with the Owner role cannot delete a CanNotDelete-locked resource without first removing the lock — which creates an intentional, auditable pause before destruction.

☁ Scenario — diagnosing a $3,000 bill spike

Situation: The Azure invoice jumped $3,000 more than last month. Your manager wants an explanation before tomorrow's meeting.

Step 1 — Cost Management: Portal → Cost Management + Billing → Cost Analysis. Set date range to current month vs prior month. Group by Resource type → Virtual Machines cost doubled. Group by Resource → four new D4s_v3 VMs show up that weren't there last month, each running 24/7.

Step 2 — Azure Advisor: Portal → Advisor → Cost tab. Advisor flags those same four VMs: average CPU utilization under 5% over the past 7 days. Recommendation: right-size from D4s_v3 ($0.192/hr) to D2s_v3 ($0.096/hr). Estimated monthly saving: $1,800.

Step 3 — Set a budget: Cost Management → Budgets → Create budget at the previous month's baseline + 10%. Add an alert at 80% threshold → email the team. Note: budgets send alerts; they do not stop provisioning.

For the meeting: "Cost spike traced to 4 oversized VMs provisioned for load testing and never shut down. Right-sizing will save $1,800/month. Budget alert added to catch this next time."