Practice Test #6

No. Private preview does not mean you must use a separate Azure portal. Most private preview features are accessed through the same Azure portal and management plane (Azure Resource Manager), but require explicit enablement—such as being allowlisted by Microsoft, registering a feature flag, using a specific API version, or deploying via CLI/PowerShell/ARM templates. The defining characteristic of private preview is restricted availability (invite-only) and limited support, not a different portal. A separate portal is not a standard requirement for preview services and is not how Microsoft generally delivers previews. On the exam, treat “separate portal” as a distractor; focus instead on access restrictions and the lack of production guarantees.

No. Public preview services/features are generally not recommended for production environments. While Microsoft may allow you to deploy and test them, public preview is intended for evaluation, feedback, and non-critical workloads. Because the service can change, may have limited support, and typically has no SLA, using it for production workloads conflicts with reliability best practices. For AZ-900, the safe rule is: production workloads should use GA services unless Microsoft explicitly states otherwise for a specific preview. In Well-Architected terms, running production on preview increases operational and reliability risk due to potential breaking changes and lack of uptime commitments.

No. Azure services in public preview are typically not covered by an SLA. SLAs are generally associated with GA services and specify Microsoft’s uptime commitments when the service is deployed according to the SLA requirements. Preview offerings (public preview and private preview) commonly exclude SLA guarantees and may also have limited support. This is a frequent AZ-900 exam point: “Preview = no SLA.” Even if a preview feature is available broadly, Microsoft does not usually provide the same contractual uptime commitments until the service reaches GA.

Yes. Azure provides flexibility between capital expenditure (CapEx) and operational expenditure (OpEx). Traditionally, on-premises requires CapEx: buying hardware, facilities, and long depreciation cycles. Azure’s default consumption model is OpEx: you pay for resources as you use them (per second/minute/hour depending on the service), which improves agility and aligns cost with demand. Azure also offers options that let you plan and optimize spend (e.g., Reserved VM Instances and Azure Savings Plans), which can feel more “CapEx-like” in terms of commitment, but it is still generally treated as operational spending because you are purchasing a service commitment rather than owning physical assets. This flexibility is a key cloud value proposition and a common AZ-900 exam theme.

No. Two Azure VMs of the same size (B2s) will not always generate the same monthly costs. VM size defines the compute capacity, but total cost depends on multiple variables: region (prices differ by geography), operating system (Windows typically costs more due to licensing), number and type of disks (Standard HDD/SSD vs Premium SSD, disk size), and usage pattern (hours running in the month). Additionally, pricing options can change costs significantly: one VM could be covered by a Reservation/Savings Plan while the other is pay-as-you-go; one could be Spot (if applicable) while the other is not. Network egress charges and additional services (backup, monitoring) can also differ. Therefore, “same size” does not guarantee “same monthly cost.”

Yes. When an Azure virtual machine is stopped, you continue to pay storage costs associated with the VM. The key concept is that compute and storage are billed separately. If a VM is stopped/deallocated, Azure stops billing for the VM’s compute (vCPU/RAM), but the managed disks (OS disk and any data disks) still exist in your storage account/managed disk service and continue to incur charges. You may also continue to pay for related storage-based features such as snapshots, images, and Azure Backup recovery points if configured. To stop storage charges, you must delete the disks (and any snapshots/backup data) after ensuring you no longer need the data. This distinction is frequently tested in AZ-900: stopping a VM reduces compute cost, but persistent storage remains billable.

No. Azure resources are not limited to accessing only other resources in the same resource group. A resource group is a management boundary, not a network or security boundary. Runtime access between resources is determined by factors such as virtual network design (VNets/subnets/peering), routing, private endpoints/service endpoints, firewall rules, NSGs, application configuration, and identity/authorization (for example, Entra ID and RBAC for management-plane actions, or service-specific auth for data-plane access). For example, a VM in resource group RG1 can access a storage account in RG2 if network rules allow it and the VM/app has appropriate credentials. Similarly, a web app in one resource group can call an API hosted in another resource group. Resource groups help you organize and manage resources together, but they do not enforce communication restrictions. Therefore, the statement is false.

Yes. When you delete a resource group, Azure deletes all resources contained within that resource group. This is a key lifecycle behavior of ARM: the resource group acts as a container, and deletion is a cascading operation across the contained resources. This is why resource groups are often used to manage environments (dev/test) where you want to remove everything cleanly. Important nuance for exam readiness: the deletion is intended to remove all resources, but some deletions can be delayed due to dependencies, locks, or long-running operations. If a resource has a resource lock (CanNotDelete) at the resource or resource group scope, the deletion will fail until the lock is removed. In general, however, the correct principle is that deleting the resource group deletes all resources in it, making the statement true.

Yes. A single resource group can contain resources from multiple Azure regions. The resource group itself has a location (region) that stores the resource group’s metadata, but that does not constrain the regions where its resources can be deployed. Real-world example: you might place an application’s primary VM in East US and a secondary VM in West US for resiliency, while keeping both in the same resource group to manage them together (RBAC, tags, policy assignments, and coordinated deployments). This aligns with governance and operational management practices: grouping by application, workload, or lifecycle rather than strictly by geography. The only consistent regional attribute is the resource group metadata location, not the resources’ locations. Therefore, the statement is true.