Microsoft AZ-900: Azure Fundamentals for Cloud Decision-Makers

AZ-900: Microsoft Azure Fundamentals introduces cloud concepts, Azure architecture and services, and governance and management. It is designed for learners who need to understand cloud decisions without first becoming Azure administrators or application developers. The examination is useful for technical newcomers as well as business or product professionals who must discuss cloud hosting, security, cost and service choices. Its value lies in clear understanding of responsibility and architecture vocabulary rather than memorizing advanced commands.

An Azure administrator manages resources in production; an AZ-900 learner should be able to explain why a virtual machine, managed database or serverless capability might be selected and who operates which part. The distinction between infrastructure, platform and software service models is especially important. AZ-104 is a later operational path for those who want to implement the concepts. AZ-900 itself should remain approachable while teaching realistic trade-offs.

Understand cloud consumption and service models

Cloud computing provides on-demand access to compute, storage and related services. Organizations can avoid owning every physical server and scale some workloads with demand, but consumption billing does not automatically make cloud cheaper. A permanently running, overprovisioned VM can cost more than a suitable alternative, while an infrequently used service may benefit greatly from flexible capacity. Decision-makers should compare expected usage, support obligations and growth before relying on marketing claims about elasticity.

IaaS, PaaS and SaaS allocate responsibilities differently. With infrastructure as a service, customers typically configure the guest OS and application while the provider manages physical infrastructure. Platform services handle more of the runtime, but customers still own identities, code, data classification and application correctness. Software as a service may reduce maintenance further while preserving customer obligations for users and information. Shared responsibility is a reasoning framework, not an excuse to assume security automatically belongs to only one side.

Public, private and hybrid cloud are deployment patterns, not simple rankings. A company may keep a regulated or latency-sensitive service locally while moving analytics or a customer portal to Azure. That design introduces network connectivity, identity synchronization and operational coordination costs. A sensible cloud discussion asks what the business is trying to achieve, which constraints are nonnegotiable and what failure conditions must be accepted or mitigated.

Recognize Azure regions, zones and resilient services

Azure regions are geographic collections of infrastructure, and availability zones provide separate fault domains within supported regions. Redundancy requirements vary by service and deployment choice. An application in one zone can experience disruption even when the broader Azure platform remains available. A second VM in the same failure domain may improve capacity but not protect against every localized incident. Learners should recognize the difference between instance redundancy, regional resilience and a tested disaster recovery plan.

Management groups, subscriptions, resource groups and resources form a hierarchy for organization and governance. A resource group groups resources for management but is not automatically a security or network boundary. Access control is implemented through roles and policies at meaningful scopes. An organization's subscription structure should reflect governance, cost and operating responsibilities while avoiding a design so fragmented that simple administration becomes difficult.

Azure's service catalog includes compute, storage, networking, database, analytics and AI capabilities. A virtual machine offers control at the operating-system layer; App Service manages a web application platform; a container service runs packaged workloads under another set of operational responsibilities. A storage account can provide blob or file capabilities, and a managed database may reduce host maintenance. AZ-900 candidates should identify what those services do and the practical reasons someone would choose them.

Explain identity, network and data protection foundations

Microsoft Entra ID manages cloud identities and authentication, while Azure RBAC controls who can operate Azure resources. Multifactor authentication reduces risk from password compromise; Conditional Access can evaluate sign-in conditions. An employee being able to sign in does not prove that they have permission to change a storage account. Likewise, an application with correct permissions may still be blocked by network rules. Separate authentication, authorization and connectivity when considering a failure.

Network security groups, private networking and firewalls protect different parts of the traffic path. An internet-facing website has different exposure requirements from a database used only by a backend application. Data protection includes encryption, access, retention and recovery. A cloud provider may encrypt stored data by default while the customer still permits far too many employees to read it. A secure plan needs clear information owners and review of permissions, not only technical encryption settings.

Governance services such as Azure Policy and resource locks reduce accidental or noncompliant changes. Policy can require properties or deny prohibited deployments; locks can protect selected resources against deletion or modification. Budgets and cost alerts do not themselves enforce identity or network security. These distinctions recur across Azure operations and are worth learning early because they prevent unrealistic expectations about what a single control can accomplish.

Compare spending, scaling and operational trade-offs

Azure cost can depend on active compute time, storage consumption, transactions, data transfer and support arrangements. Compute reservations, savings mechanisms and consumption plans differ by service and workload. A team choosing a resource should consider peak usage and base demand, whether it can be shut down at night and how much operational time is required. The cheapest hourly rate may not minimize the total cost of a service that needs special maintenance or repeatedly suffers downtime.

Scaling up means increasing the size of a resource; scaling out adds instances or capacity units in parallel. Each approach has application constraints. A stateful legacy program may not run correctly on several identical instances without shared data handling, while a stateless web frontend might scale horizontally. Serverless functions may reduce idle cost for intermittent events but introduce cold starts, concurrency controls and per-execution costs. The right selection follows the workload's behavior rather than a fixed preference for one service type.

Cost governance improves when tags, budgets and ownership are set from the beginning. A sandbox can spend money even when no customer uses it. Make an owner accountable for recurring resources, remove unused capacity and set alerts at a meaningful budget threshold. Azure Advisor can provide recommendations, but human context is needed before resizing a critical workload. Cloud flexibility is most valuable when teams also manage consumption and resource lifecycle deliberately.

Use observability and service agreements realistically

Service-level agreements specify particular availability commitments and exclusions for a product or configuration. Do not multiply percentages or assume a design meets a business uptime target without examining dependencies. An application that depends on identity, DNS, database and a payment gateway can fail when any critical component is unavailable. End-to-end resilience involves architecture, monitoring and recovery, not just selecting an Azure resource advertised as highly available.

Azure Monitor, Service Health and Advisor answer different questions. Monitor gathers workload and resource signals; Service Health reports relevant platform events; Advisor provides recommendations. A customer might report slow transactions while infrastructure metrics appear nominal because the bottleneck is an application query or external service. Even a fundamentals learner should understand why the evidence of user experience matters more than a green dashboard alone.

Recovery planning distinguishes high availability, backup and disaster recovery. Replication can keep data accessible after certain failures but also propagate corruption; backups preserve recoverable points when configured and tested. A business should define acceptable outage and data-loss objectives. A practice scenario comparing an availability zone fault with accidental deletion helps reveal why a single solution cannot address every problem.

A retailer deciding whether to host its storefront in Azure should distinguish capacity from resilience. More application instances can handle traffic peaks, but an application may still fail if every instance depends on a single unavailable database. Identify stateless components, stateful dependencies and acceptable interruptions. A useful cost estimate includes network egress, backups, telemetry and staffing rather than only the advertised VM price. Cloud spending should be tied to usage patterns and clearly owned by the relevant team.

The same decision exercise can reveal shared-responsibility boundaries. A provider may secure the physical infrastructure while the customer remains responsible for classifying records and granting users appropriate access. A misconfigured role assignment, a failed physical drive and a stolen employee laptop have different risk owners and responses. Selecting a cloud service does not delegate every security and privacy choice to the provider. These practical distinctions are more valuable at the Azure Fundamentals level than memorizing a list of product names.

Build confident Azure vocabulary through decisions

A useful AZ-900 practice session maps short business cases to categories: a simple website, a virtual machine that must run legacy software, archival objects, a managed relational database and an event-driven notification service. For each, choose a plausible Azure approach and describe what the customer still manages. Then introduce a requirement for stronger privacy, better recovery or lower cost. The answer may change, which demonstrates that service selection depends on constraints.

Beginner learners should be able to describe regions and zones, management groups and subscriptions, identity versus permissions, cloud service models, and the difference between scaling and resilience. Advanced CLI commands are useful for later study but are not a substitute for this conceptual structure. Microsoft's official AZ-900 guide remains the current authority for testable objectives and registration details, so review it if a course is several years old.

The broader goal is informed decision-making. People who understand Azure fundamentals can ask architects better questions, recognize where vendors or teams overpromise, and allocate resources more responsibly. That is a sound foundation for an administrator, developer, architect or nontechnical stakeholder involved in cloud adoption.