Practice Test #5

No. It is not true that the SLA guaranteed uptime for paid Azure services is at least 99.9% across the board. SLAs vary by service and configuration. Some services have SLAs below 99.9% in certain tiers or scenarios, and some services may have no SLA at all (especially preview features). For example, a single-instance Virtual Machine has historically had a lower SLA than a VM deployed in an Availability Set or across Availability Zones. Conversely, some services offer higher SLAs (e.g., 99.95%, 99.99%) when deployed with redundancy features. The exam expects you to understand that “paid” does not automatically mean “>= 99.9% SLA”; you must check the specific service’s SLA documentation and the required architecture to qualify for that SLA.

Yes. Deploying resources across multiple regions can increase overall solution availability (and can be part of meeting higher availability targets), because it reduces the impact of a single regional outage. In practice, you use multi-region architectures such as active-active or active-passive, combined with services like Azure Traffic Manager, Azure Front Door, or load balancing plus replicated data stores (e.g., geo-redundant options). While each individual service still has its own SLA, the composite application uptime can be improved by eliminating regional single points of failure, which is a core Reliability principle in the Azure Well-Architected Framework. The key idea: multi-region redundancy improves resiliency and can raise the effective end-to-end uptime compared to a single-region deployment.

No. Purchasing multiple subscriptions does not increase the SLA guaranteed uptime. A subscription is primarily a billing, quota, and management boundary (used for cost management, access control scoping, and governance). It does not automatically create redundancy, failover capability, or higher-availability deployment patterns for a service. If you deploy the same single-instance workload in two different subscriptions but still in the same region and without proper redundancy/failover design, you have not meaningfully improved availability. To increase uptime, you must add resilient architecture elements (multiple instances, Availability Zones, multi-region deployments, replicated data, automated failover), not simply split resources across subscriptions. Subscriptions can help with organizational separation and limits management, but they are not an SLA improvement mechanism.

No. A hybrid cloud model does not require that a company must always migrate from a private cloud model. Hybrid simply means combining private and public cloud environments, typically with integration such as networking (site-to-site VPN or ExpressRoute), identity (Microsoft Entra ID), and unified management/monitoring. A company could start as fully on-premises (not necessarily a “private cloud”), then adopt Azure for specific workloads (backup, DR, dev/test) and become hybrid. Alternatively, a company could start in the public cloud and later add private cloud/on-premises resources for compliance, data residency, or low-latency needs—also hybrid. The incorrect “Yes” implies a mandatory sequence (private → hybrid), which is not part of the definition. For exam purposes, focus on the definition: hybrid = mix of private and public, not a required migration path.

Yes. A company can extend the capacity of its internal network by using the public cloud. This is a classic hybrid use case: you keep core systems on-premises while using Azure to add capacity for compute, storage, or services when demand spikes or when you want to avoid buying more hardware. Examples include cloud bursting (temporarily running extra application instances in Azure), extending storage for backups/archives, or adding Azure-based virtual networks connected to on-prem via VPN/ExpressRoute to expand address space and host additional workloads. This supports Cost Optimization (pay-as-you-go instead of overprovisioning), Reliability (additional capacity and DR options), and Scalability/Performance Efficiency (elastic resources). The statement is broadly true in AZ-900 terms because public cloud resources can be integrated with on-prem networks to augment capacity.

No. In a public cloud model, access to cloud resources is not limited to only “guest users” at your company. Public cloud refers to the ownership and delivery model of the infrastructure (provider-owned, multi-tenant), not a restriction that only guest accounts can access resources. Access to your organization’s Azure resources is controlled by identity and authorization mechanisms such as Microsoft Entra ID tenants, Azure RBAC roles, conditional access, and network controls. Users can be internal employees (member users), external collaborators (guest users via B2B), applications/service principals, managed identities, and automated processes—depending on what the organization allows. The incorrect statement confuses the concept of “public cloud” with “public access.” Your resources are not inherently open to the public; they are private to your subscription/tenant unless you explicitly expose them (e.g., public endpoints) and authorize access.