Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.
You plan to deploy several Azure virtual machines.
You need to ensure that the services running on the virtual machines are available if a single data center fails.
Solution: You deploy the virtual machines to two or more scale sets.
Does this meet the goal?
Yes is incorrect because it assumes that using multiple scale sets automatically provides datacenter-level redundancy. VM Scale Sets primarily address scaling and uniform management, and their placement across datacenters is not guaranteed unless Availability Zones are explicitly used. Two scale sets can still be created in the same zone/datacenter, meaning a single datacenter outage could take down all instances. To meet the goal, you must design for zonal redundancy (or equivalent) rather than relying on multiple scale sets alone.
No is correct because deploying VMs to two or more scale sets does not, by itself, ensure the VMs are distributed across separate datacenters. Without explicitly configuring Availability Zones (or a zone-redundant architecture), multiple scale sets can be deployed into the same zone or underlying datacenter. The requirement is resiliency to a single datacenter failure, which typically maps to multi-zone deployment with a zone-redundant load-balancing front end. Therefore, the proposed solution is insufficient to guarantee the stated availability goal.
問題分析
Core concept:
This question tests high availability design for Azure virtual machines across datacenters within a region, specifically whether the proposed deployment approach provides resiliency to a single datacenter failure.
Why the answer is correct:
Deploying VMs to two or more Virtual Machine Scale Sets (VMSS) does not inherently guarantee placement across multiple datacenters. A VMSS, by default, can place instances within a single availability zone or even within a single datacenter depending on configuration, and multiple scale sets can still end up in the same zone/datacenter. To ensure availability when a single datacenter fails, you must use Availability Zones (zonal or zone-redundant architecture) or, in non-zonal regions, Availability Sets (which protect against rack-level failures, not full datacenter failures). Therefore, the solution as stated does not meet the goal.
Key features / configurations:
- Availability Zones: Deploy VMs/VMSS across multiple zones (e.g., zones 1, 2, 3) to survive a datacenter (zone) outage.
- VM Scale Sets zonal deployment: Pin a scale set to a specific zone; use multiple scale sets across different zones, or use zone-redundant load balancing.
- Load balancing: Use Standard Load Balancer/Application Gateway with zone-redundant frontend to distribute traffic across zonal backends.
- Availability Sets: Provide fault/update domain separation within a datacenter; not sufficient for a datacenter outage.
Common misconceptions:
- Assuming “multiple scale sets” automatically means “multiple datacenters.” Placement is not guaranteed unless you explicitly use zones.
- Confusing Availability Sets (intra-datacenter resiliency) with Availability Zones (inter-datacenter resiliency).
- Believing VMSS alone provides datacenter-level HA without zonal configuration and a zone-redundant traffic entry point.
Exam tips:
- If the requirement says “single datacenter fails,” think Availability Zones.
- VMSS improves scalability and instance-level resiliency, but you must configure zones to get datacenter-level resiliency.
- Availability Sets protect against host/rack maintenance and failures, not full datacenter outages.
- Ensure the ingress component (Load Balancer/App Gateway) is also zone-redundant when designing zonal HA.
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.
You plan to deploy several Azure virtual machines.
You need to ensure that the services running on the virtual machines are available if a single data center fails.
Solution: You deploy the virtual machines to two or more regions.
Does this meet the goal?
Yes is incorrect because regions are larger geographic constructs that contain one or more datacenters, so deploying across regions addresses a broader failure domain than the one described. Although a multi-region design can certainly improve overall availability, it is not the Azure feature typically used to satisfy a requirement about a single datacenter failing. For AZ-900 questions, the expected match for datacenter-level fault tolerance is Availability Zones rather than multiple regions.
No. Deploying virtual machines to two or more regions is aimed at protecting against a regional outage, not specifically the failure of a single datacenter. The Azure feature designed for datacenter-level resiliency is Availability Zones, which place resources in separate physical locations within the same region. Because the requirement is narrowly focused on surviving a single datacenter failure, multi-region deployment does not best meet the stated goal in this exam context.
問題分析
Core Concept:
This question tests understanding of Azure regions, availability zones, and datacenter-level fault tolerance. In AZ-900, a single Azure region contains one or more datacenters, and availability zones are specifically designed to protect workloads from the failure of a single datacenter within a region.
Why the Answer is Correct:
Deploying virtual machines to two or more regions does not directly target the requirement of surviving a single datacenter failure. A single datacenter failure is more appropriately addressed by using Availability Zones or, in some cases, Availability Sets within the same region. Regions are geographically separate and are typically used for broader disaster recovery and business continuity scenarios, not specifically for single-datacenter resilience.
Key Features / What to Know:
- Availability Zones provide physically separate locations within an Azure region, each with independent power, cooling, and networking.
- Availability Sets distribute VMs across fault domains and update domains within a datacenter environment, helping reduce localized hardware failure impact.
- Regions are separate geographic areas and are mainly used for regional disaster recovery, compliance, and latency considerations.
- Multi-region deployments can improve resilience, but they are not the standard answer when the requirement is specifically a single datacenter failure.
Common Misconceptions:
A common mistake is assuming that a more resilient or broader architecture automatically best matches the requirement. While multiple regions can provide higher-level disaster recovery, the question asks specifically about a single datacenter failure, which points to Availability Zones. Another misconception is treating regions and datacenters as interchangeable; they are not the same scope of failure.
Exam Tips:
- If the requirement mentions a single datacenter failure, think Availability Zones first.
- If the requirement mentions an entire region outage or disaster recovery, think paired regions or multi-region deployment.
- In AZ-900, always match the Azure service to the exact failure scope described in the question.
3
問題 3
(2つ選択)
Which two types of customers are eligible to use Azure Government to develop a cloud solution? Each correct answer presents a complete solution.
NOTE: Each correct selection is worth one point.
Incorrect. A Canadian government contractor is not automatically eligible for Azure Government. Azure Government is a U.S. sovereign cloud intended for U.S. government entities and approved U.S. government contractors. Canadian public sector organizations typically use commercial Azure regions in Canada (or other arrangements), but they do not qualify for Azure Government based solely on being a government contractor.
Incorrect. A European government contractor is not eligible for Azure Government by default. Azure Government is restricted to U.S. government entities and validated U.S. government contractors. European contractors may use commercial Azure regions in Europe or other sovereign solutions, but they cannot use Azure Government unless they meet specific U.S. eligibility requirements (which this option does not imply).
Correct. A United States government entity (federal, state, local, or tribal) is a primary intended customer for Azure Government. The platform is designed to meet U.S. public sector compliance requirements and provides isolation from commercial Azure, supporting regulated workloads and governance needs that U.S. government agencies commonly have.
Correct. A United States government contractor can be eligible for Azure Government, provided they complete Microsoft’s eligibility validation and are supporting U.S. government workloads. This is a key audience for Azure Government because many regulated solutions are built and operated by contractors on behalf of U.S. government agencies.
Incorrect. A European government entity is not eligible for Azure Government. The service is a U.S. sovereign cloud environment with restricted access for U.S. public sector customers and approved contractors. European government entities generally use commercial Azure in European regions or other sovereign offerings, but not Azure Government.
問題分析
Core concept:
Azure Government is a sovereign cloud environment designed for U.S. public sector workloads. It is physically isolated from the commercial Azure cloud, operated by screened U.S. persons, and built to meet U.S. government compliance requirements (for example, FedRAMP High, DoD IL levels for certain services/regions, CJIS support in specific scenarios). The exam is testing who is eligible to use this environment.
Why the answer is correct:
Eligible customers for Azure Government include (1) U.S. federal, state, local, and tribal government entities and (2) U.S. government contractors that meet eligibility requirements and can validate their relationship to U.S. government workloads. Therefore, a United States government entity (C) and a United States government contractor (D) are the two correct choices.
Key features / important details:
Azure Government uses separate datacenters, separate network, and separate identity endpoints (for example, *.usgovcloudapi.net) to support regulatory and contractual requirements. Access is not “open sign-up” like commercial Azure; customers must go through an eligibility validation process. From an Azure Well-Architected Framework perspective, this supports Security and Compliance requirements (data residency, personnel screening, and regulatory attestations) and helps meet governance needs for public sector workloads.
Common misconceptions:
A frequent trap is assuming “any government” or “any contractor” qualifies. Azure Government is specifically for U.S. government and its approved ecosystem. Canadian or European entities/contractors do not qualify for Azure Government simply because they are governmental; they would typically use commercial Azure in-region, or other sovereign offerings where available (for example, certain national clouds/sovereign solutions), but not Azure Government.
Exam tips:
For AZ-900, remember the three common cloud environments: Public (commercial Azure), Sovereign (Azure Government), and specialized clouds. If the question says “Azure Government,” think “U.S. public sector eligibility + isolated environment + compliance-driven access.” If the option is non-U.S. (European/Canadian), it is almost always incorrect for Azure Government eligibility questions.
4
問題 4
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.
Your Azure environment contains multiple Azure virtual machines.
You need to ensure that a virtual machine named VM1 is accessible from the Internet over HTTP.
Solution: You modify a DDoS protection plan.
Does this meet the goal?
Answering "Yes" is incorrect because DDoS Protection does not control whether HTTP traffic is permitted to reach a VM. Even with DDoS Standard enabled, if VM1 lacks a public IP (or a public load balancer/app gateway front end) or if an NSG blocks TCP/80, HTTP access from the Internet will fail. DDoS protection is additive security for already-public resources; it does not publish services or open ports. You still need explicit networking configuration to expose VM1 over HTTP.
A DDoS protection plan is designed to mitigate DDoS attacks against public IP resources, not to configure inbound connectivity. Changing the plan will not assign a public IP to VM1, create a load balancer rule, or add an NSG rule to allow TCP port 80. Therefore, VM1 will not become accessible over HTTP simply by modifying DDoS protection settings. To meet the goal, you must configure a public endpoint and allow inbound TCP/80 via NSG (and/or load balancer/application gateway rules).
問題分析
Core concept:
This question tests how to expose an Azure VM to the Internet over HTTP and which Azure services/configurations actually control inbound HTTP reachability (public IP, NSG rules, load balancer/NAT, and optionally Azure Firewall/WAF).
Why the answer is correct:
Modifying an Azure DDoS Protection plan does not make a VM reachable over HTTP. DDoS Protection (Standard) is a network protection service that mitigates volumetric and protocol attacks against public IP resources, but it does not create or change inbound allow rules, does not assign a public IP, and does not publish port 80 to the Internet. To make VM1 accessible over HTTP, you must ensure VM1 has a public endpoint (e.g., a public IP directly on the NIC, or a public Load Balancer with an inbound NAT rule / load-balancing rule) and that network security rules allow TCP/80.
Key features / configurations:
- Public exposure: Public IP on VM NIC or Azure Load Balancer (public) front end.
- Traffic allowance: NSG inbound rule allowing TCP 80 from Internet (or specific source ranges) to VM1.
- Optional: Application Gateway/WAF for HTTP(S) layer protection; Azure Firewall for centralized filtering.
- DDoS Standard: Enabled at the VNet level; protects public IP resources in that VNet but does not open ports.
Common misconceptions:
- Assuming DDoS Protection “enables” Internet access or opens ports; it only mitigates attacks.
- Confusing security services (DDoS/WAF) with connectivity configuration (public IP/NSG/LB rules).
- Believing that enabling a protection plan automatically publishes services; publishing requires explicit inbound configuration.
Exam tips:
- DDoS Protection Standard mitigates attacks; it does not change NSG rules or create public endpoints.
- For Internet HTTP access to a VM, think: public IP (or public LB/App Gateway) + NSG allow TCP/80.
- Always separate “reachability” (routing/endpoints) from “protection” (DDoS/WAF/firewall).
5
問題 5
(2つ選択)
You have an Azure environment that contains multiple Azure virtual machines.
You plan to implement a solution that enables the client computers on your on-premises network to communicate to the Azure virtual machines.
You need to recommend which Azure resources must be created for the planned solution.
Which two Azure resources should you include in the recommendation? Each correct answer presents part of the solution.
NOTE: Each correct selection is worth one point.
A virtual network gateway is the Azure-side VPN endpoint used for site-to-site VPN (or VNet-to-VNet) connectivity. It enables encrypted IPsec/IKE tunnels and routing between on-premises networks and Azure VNets so on-premises clients can reach Azure VM private IPs. It must be deployed into a dedicated GatewaySubnet and requires an appropriate gateway SKU and a public IP for VPN scenarios.
A load balancer distributes network traffic across multiple VMs (Layer 4) to improve availability and scale for inbound or internal traffic. It does not create a private connection from on-premises to Azure; it only balances traffic once it is already in Azure (or coming from the internet/VNet). Therefore it is not a required resource for enabling on-premises client communication to Azure VMs.
An application gateway is a Layer 7 (HTTP/HTTPS) load balancer with features like SSL termination, path-based routing, and WAF. It is used to publish and protect web applications, not to establish hybrid network connectivity. Even if you wanted to expose a web app to on-premises users, it would not replace the need for a VPN/ExpressRoute gateway for private network communication.
A virtual network provides the private IP address space and subnets where Azure VMs reside. While a VNet is foundational for hosting VMs, the question focuses on enabling on-premises clients to communicate with those VMs. The specific hybrid connectivity requirements from the options are the Virtual Network Gateway and the GatewaySubnet; the VNet is assumed to already exist because the environment contains VMs.
A gateway subnet (named exactly GatewaySubnet) is a required, dedicated subnet within a VNet that hosts the virtual network gateway resources. Azure requires this subnet to deploy a VPN gateway, and it should not contain other workloads. Proper sizing is important for future scalability and features (for example, active-active gateways or additional gateway-related services).
問題分析
Core concept:
This question is testing connectivity from an on-premises network to Azure virtual machines. In Azure, the standard way to enable private network communication between on-premises clients and Azure VNets is a VPN connection (site-to-site VPN) or ExpressRoute. For AZ-900, the expected building blocks for a site-to-site VPN are a Virtual Network Gateway and its required GatewaySubnet.
Why the answer is correct:
To allow on-premises client computers to communicate with VMs in Azure over a private, encrypted tunnel, you deploy a Virtual Network Gateway (VPN gateway) in the Azure virtual network. The gateway provides the VPN endpoint in Azure and handles IPsec/IKE negotiation and routing between the on-premises network and the Azure VNet. A Virtual Network Gateway must be deployed into a dedicated subnet named GatewaySubnet; without it, the gateway cannot be created. Therefore, the two required Azure resources from the list are (A) a virtual network gateway and (E) a gateway subnet.
Key features / configurations / best practices:
A GatewaySubnet is a special subnet reserved for gateway resources. Best practice is to size it appropriately (often /27 or larger) to allow future growth (additional gateway instances, active-active, or other gateway-related features). The Virtual Network Gateway is chosen as VPN type (route-based is common) and is associated with a public IP. You then create a connection to the on-premises VPN device (Local Network Gateway is also typically required, but it is not an option here). From an Azure Well-Architected Framework perspective, this supports Security (encrypted traffic), Reliability (gateway SKUs and active-active options), and Operational Excellence (standardized connectivity pattern).
Common misconceptions:
Many learners pick “virtual network” because VMs live in a VNet; however, the question asks which resources must be created for on-premises communication, and the gateway components are the critical requirements. Load Balancer and Application Gateway are for distributing inbound traffic to services/VMs, not for establishing private hybrid connectivity.
Exam tips:
For hybrid connectivity questions: Site-to-site VPN typically requires Virtual Network Gateway + GatewaySubnet (and usually Local Network Gateway + VPN connection). If the question emphasizes private connectivity rather than web traffic distribution, think “gateway,” not “load balancer/application gateway.”
6
問題 6
HOTSPOT -
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
NOTE: Each correct selection is worth one point.
Hot Area:
パート1:
All Azure services in private preview must be accessed by using a separate Azure portal.
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.
パート2:
Azure services in public preview can be used in production environments.
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.
パート3:
Azure services in public preview are subject to a Service Level Agreement (SLA).
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.
7
問題 7
You need to configure an Azure solution that meets the following requirements:
✑ Secures websites from attacks
✑ Generates reports that contain details of attempted attacks
What should you include in the solution?
Azure Firewall is a managed network firewall used to control and inspect traffic with centralized rules, but it is not the primary service for protecting websites from DDoS-style internet attacks. It can log traffic and enforce policy, yet the question’s wording aligns more closely with Azure DDoS Protection, which is specifically built to defend public-facing applications from attack floods and provide attack reports. In AZ-900, if DDoS Protection is explicitly offered for website attack protection, it is typically the expected answer. Therefore, Azure Firewall is not the best fit here.
A network security group provides basic Layer 3 and Layer 4 filtering for Azure subnets and network interfaces. NSGs can allow or deny traffic based on source, destination, port, and protocol, but they are not specialized website protection services and do not provide rich attack mitigation reporting. They are mainly used for segmentation and access control rather than defending public websites from large-scale attacks. As a result, an NSG does not satisfy the full requirement.
Azure Information Protection is a data protection and classification service used to label, encrypt, and protect sensitive documents and emails. It has nothing to do with defending websites from network-based attacks or generating reports about attempted attacks against web endpoints. Its focus is information governance and rights management, not perimeter or application availability protection. Therefore, it is clearly not the correct choice.
Azure DDoS Protection is designed to protect Azure-hosted internet-facing resources, such as websites and applications, from Distributed Denial of Service attacks. It continuously monitors traffic patterns and automatically mitigates attacks when malicious volumetric or protocol-based activity is detected. The service also provides telemetry, metrics, and mitigation reports that show details about attempted attacks, which directly satisfies the reporting requirement. Among the listed options, it is the best match for both protection of websites and generation of attack-related reports.
問題分析
Core concept: This question is testing recognition of the Azure service that protects internet-facing websites from denial-of-service attacks and provides reporting on attack attempts. In AZ-900, Azure DDoS Protection is the service associated with defending public endpoints against DDoS attacks and producing attack analytics and mitigation reports. Why correct: DDoS Protection is purpose-built for protecting websites and applications exposed to the internet, and it includes telemetry, metrics, and post-mitigation reporting about attacks. Key features: always-on traffic monitoring, automatic attack detection and mitigation, attack analytics, and integration with Azure Monitor for visibility. Common misconceptions: Azure Firewall is a network security control, but it is not the primary AZ-900 answer for website attack protection/reporting when DDoS Protection is explicitly listed; NSGs are basic packet filters, and Azure Information Protection is for data classification. Exam tips: when the prompt mentions protecting websites from attacks and reporting on attempted attacks, and DDoS Protection is an option, it is usually the intended answer unless the question specifically mentions web application attacks or WAF features.
8
問題 8
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.
Your company plans to purchase an Azure subscription.
The company's support policy states that the Azure environment must provide an option to access support engineers by phone or email.
You need to recommend which support plan meets the support policy requirement.
Solution: Recommend a Professional Direct support plan.
Does this meet the goal?
Yes. Professional Direct support includes access to Microsoft support engineers for technical support cases and supports communication through phone and email channels. The company policy requires an option to contact support engineers by phone or email, and Professional Direct clearly provides that capability. Although it may offer more features than strictly required, it still satisfies the stated goal. In these scenario questions, a solution is valid if it meets the requirement, even if it is not the minimum plan needed.
No is incorrect because Professional Direct does provide access to support engineers through phone and email for technical support. The requirement is not asking for the cheapest qualifying support plan, only whether the proposed plan meets the communication policy. Since Professional Direct is a paid support tier above Standard and includes those support channels, rejecting it would be based on a misunderstanding of Azure support plan capabilities. The only plans that would fail this requirement are those without appropriate technical engineer access, such as Basic.
問題分析
Core Concept:
This question tests knowledge of Azure support plans and whether a given plan satisfies a stated communication requirement for technical support. The requirement is specifically that the company must have an option to access support engineers by phone or email.
Why the Answer is Correct:
Professional Direct support does meet this requirement because it provides access to Microsoft support engineers and includes phone and email support channels for technical issues. Since the policy only requires the availability of phone or email access, Professional Direct clearly satisfies the goal.
Key Features / What to Know:
- Basic support includes billing and subscription support, but not full technical support from support engineers.
- Developer support provides technical support for non-production environments, primarily via email during business hours.
- Standard support provides technical support for production workloads with phone and email access.
- Professional Direct includes the capabilities of Standard and adds faster response times, advisory support, and proactive services.
- Higher-tier enterprise offerings such as Unified provide even broader support coverage.
Common Misconceptions:
A common mistake is assuming the question asks for the lowest-cost qualifying plan. In these scenario questions, the task is only to determine whether the proposed solution meets the requirement, not whether it is the most cost-effective option. Another misconception is confusing Basic support with technical support access; Basic does not provide the same engineer access as paid support plans.
Exam Tips:
- In 'Does this meet the goal?' questions, focus only on whether the proposed solution satisfies the requirement, not whether another option might also work.
- If a plan includes phone or email access to support engineers, it satisfies this type of requirement.
- Professional Direct is a higher-tier plan than Standard, so if Standard would qualify, Professional Direct would also qualify.
9
問題 9
HOTSPOT -
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
NOTE: Each correct selection is worth one point.
Hot Area:
パート1:
Azure provides flexibility between capital expenditure (CapEx) and operational expenditure (OpEx).
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.
パート2:
If you create two Azure virtual machines that use the B2S size, each virtual machine will always generate the same monthly costs.
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.”
パート3:
When an Azure virtual machine is stopped, you continue to pay storage costs associated to the virtual machine.
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.
10
問題 10
HOTSPOT -
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
NOTE: Each correct selection is worth one point.
Hot Area:
パート1:
Azure resources can only access other resources in the same resource group.
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.
パート2:
If you delete a resource group, all the resources in the resource group will be deleted.
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.
パート3:
A resource group can contain resources from multiple Azure regions.
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.
