
Simulate the real exam experience with 50 questions and a 45-minute time limit. Practice with AI-verified answers and detailed explanations.
AI-Powered
Every answer is cross-verified by 3 leading AI models to ensure maximum accuracy. Get detailed per-option explanations and in-depth question analysis.
Your company hosts an accounting application named App1 that is used by all the customers of the company. App1 has low usage during the first three weeks of each month and very high usage during the last week of each month. Which benefit of Azure Cloud Services supports cost management for this type of usage pattern?
High availability is about keeping an application running despite failures by using redundancy (multiple instances, zones, regions) and failover. While it improves resiliency and supports uptime SLAs, it typically increases cost because you run extra capacity. It does not specifically address the need to reduce resources during low-demand periods, so it’s not the best cost-management benefit for this usage pattern.
High latency means slower response times between users and the application, usually caused by distance, network congestion, or inefficient architecture. It is not a benefit of cloud services and does not support cost management. In exam terms, latency is something you try to minimize using regions close to users, CDNs, caching, and optimized networking—not something you select as an advantage.
Elasticity is the ability to automatically or quickly scale resources out/in (or up/down) to match demand. For an app with low usage most of the month and a predictable spike at month-end, elasticity enables adding capacity only when needed and removing it afterward. This aligns directly with cost optimization because you avoid paying for peak resources all month and can use autoscale rules or schedules.
Load balancing distributes incoming traffic across multiple instances to improve performance and reliability. It helps handle high traffic, but it doesn’t inherently reduce costs because you still must provision (or scale) the instances behind the load balancer. Load balancing is often used together with elasticity (autoscaling + load balancing), but by itself it doesn’t address scaling down during low usage.
Core Concept: This question tests the cloud concept of elasticity (and its close partner, scalability) as a cost-management benefit. In Azure, elasticity means you can automatically or quickly add/remove compute resources to match demand, then pay only for what you use. Why the Answer is Correct: App1 has a predictable usage pattern: low demand for ~3 weeks and a spike in the last week. Elasticity enables scaling out (adding instances/compute) during the high-usage period and scaling in (removing instances/compute) during the low-usage period. This directly supports cost management because you avoid paying for peak capacity all month. In Azure, this is commonly implemented with autoscaling rules (for example, based on CPU, queue length, requests, or schedules) so capacity increases during the last week and decreases afterward. Key Features / Best Practices: Elasticity is delivered through services and features such as Virtual Machine Scale Sets autoscale, App Service autoscale, AKS cluster autoscaler, and serverless options (Azure Functions) that scale dynamically. From an Azure Well-Architected Framework Cost Optimization perspective, elasticity is a primary lever: right-size resources, scale based on demand, and use automation to prevent overprovisioning. For predictable spikes (like “last week of the month”), schedule-based autoscale is often ideal, sometimes combined with metric-based rules for unexpected surges. Common Misconceptions: High availability and load balancing are often associated with “handling high traffic,” but they don’t inherently reduce cost. High availability focuses on resiliency and uptime (often increasing cost due to redundancy). Load balancing distributes traffic across instances, but you still need enough instances provisioned; it doesn’t automatically reduce capacity when demand drops. “High latency” is not a benefit; it’s a performance problem. Exam Tips: For AZ-900, map keywords to concepts: “variable demand,” “spikes,” “pay only for what you use,” and “scale up/down” point to elasticity. If the question emphasizes uptime/SLAs, think high availability. If it emphasizes distributing traffic across multiple servers, think load balancing. If it emphasizes cost savings from matching capacity to demand, choose elasticity.
Want to practice all questions on the go?
Download Cloud Pass for free — includes practice tests, progress tracking & more.


Want to practice all questions on the go?
Get the free app
Download Cloud Pass for free — includes practice tests, progress tracking & more.
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:
Each Azure subscription can contain multiple account administrators.
No. Each Azure subscription has only one Account Administrator. The Account Administrator is a legacy role tied to the billing account and has broad administrative capabilities for the subscription, but it is singular per subscription. You can change (transfer) the Account Administrator, but you cannot assign multiple Account Administrators to the same subscription simultaneously. What you can have multiple of are RBAC role assignments (for example, multiple users/groups can be Owners, Contributors, or Readers at the subscription scope). Many learners confuse “multiple administrators” (true in the RBAC sense) with “multiple account administrators” (not true). For AZ-900, remember: one Account Administrator per subscription, but potentially many users with administrative permissions via RBAC.
Each Azure subscription can be managed by using a Microsoft account only.
No. An Azure subscription is not managed only by using a Microsoft account. Subscriptions are commonly managed using work or school accounts in Microsoft Entra ID (organizational identities). In enterprise scenarios, administrators sign in with Entra ID accounts and manage access using RBAC, Privileged Identity Management (PIM), Conditional Access, and other governance controls. While a Microsoft account (personal account) can be used in some cases (especially for individual/trial subscriptions), it is not the only option, and it is not the standard for organizational governance. The key exam takeaway: Azure management is typically performed through Entra ID identities, and subscriptions can be associated with an Entra tenant to enable centralized identity and access management.
An Azure resource group contains multiple Azure subscriptions.
No. An Azure resource group does not contain multiple Azure subscriptions. The relationship is the opposite: a subscription contains multiple resource groups. A resource group is a container for Azure resources within a single subscription and a single region for metadata (resources can be in different regions, but the resource group itself is created in a specific region). Resource groups are used to manage lifecycle (deploy/update/delete as a unit), apply RBAC at a convenient scope, and apply governance controls like Azure Policy and resource locks. Because resource groups are scoped to exactly one subscription, they cannot span or include multiple subscriptions. If you need to organize across subscriptions, you use management groups, not resource groups.
Your network contains an Active Directory forest. The forest contains 5,000 user accounts. Your company plans to migrate all network resources to Azure and to decommission the on-premises data center. You need to recommend a solution to minimize the impact on users after the planned migration. What should you recommend?
Azure MFA increases security by requiring an additional verification method during sign-in. However, it does not migrate or preserve the existing on-prem AD identities in Azure. In fact, enabling MFA can increase user impact because it introduces a new step and potential enrollment requirements. MFA is often added after identity synchronization as part of a broader security posture (e.g., Conditional Access).
Syncing AD user accounts to Azure AD (Microsoft Entra ID) using Entra Connect is the most direct way to minimize user disruption during migration. It preserves user identities and, with Password Hash Synchronization, allows users to keep the same password when signing into Azure services. This reduces password reset requests and maintains continuity for access to cloud resources as the on-prem datacenter is decommissioned.
Instructing all users to change their password creates significant disruption and increases support overhead. It does not address the core requirement of migrating identities to Azure AD, and it can cause authentication issues with cached credentials, mobile devices, and integrated applications. Password changes might be required for security reasons, but they are not a primary strategy to minimize impact during migration.
Guest accounts in Azure AD are intended for external users (Azure AD B2B collaboration), not for internal employees. Creating guest accounts for all employees would complicate licensing, access management, and user experience, and it would not provide the same seamless integration as synchronized member accounts. This approach would increase, not minimize, impact on users and administrators.
Core concept: This question tests identity migration to Azure and how to preserve user sign-in experience when moving from on-premises Active Directory Domain Services (AD DS) to cloud-based identity with Azure Active Directory (Microsoft Entra ID). When decommissioning the on-premises datacenter, you must ensure users can continue to authenticate to Azure resources (Microsoft 365, Azure portal, SaaS apps, etc.) with minimal disruption. Why the answer is correct: Synchronizing all AD user accounts to Azure AD (typically using Azure AD Connect / Microsoft Entra Connect Sync) is the standard approach to migrate identities while keeping usernames, group memberships, and (depending on configuration) passwords consistent. With Password Hash Synchronization (PHS) or Pass-through Authentication (PTA), users can keep using the same credentials, reducing helpdesk calls and avoiding mass password resets. This aligns with the Azure Well-Architected Framework’s Operational Excellence and Security pillars by enabling centralized identity management, consistent access control, and smoother cutover. Key features and best practices: Use Microsoft Entra Connect to synchronize users, groups, and optionally password hashes. For a full cloud-only end state after datacenter decommissioning, PHS is commonly used because it allows authentication in Azure AD without requiring on-prem infrastructure. You can also enable Seamless SSO (when applicable) during transition. After sync, you can use Conditional Access and MFA to strengthen security, but those are security enhancements rather than the primary “minimize impact” migration step. Common misconceptions: MFA (Option A) improves security but adds a new user interaction and does not migrate identities. Forcing password changes (Option C) increases disruption. Creating guest accounts (Option D) is for external collaboration (B2B) and would break the normal employee identity model and management. Exam tips: For AZ-900, when you see “minimize impact on users” during identity migration, think “synchronize identities to Azure AD” (Entra ID). MFA/Conditional Access are important, but they are not the primary mechanism to preserve sign-in continuity during a directory migration.
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:
Authorization to access Azure resources can be provided only to Azure Active Directory (Azure AD) users.
No. Authorization to access Azure resources is not provided only to Azure AD (Microsoft Entra ID) “users.” Azure authorization commonly uses Azure RBAC, which can assign roles to multiple security principals, including: - Users - Groups - Service principals (application identities) - Managed identities (system-assigned or user-assigned) Additionally, Azure can grant access to external identities such as guest users (Entra ID B2B) and identities federated from other identity providers. The word “only” makes the statement incorrect because Azure supports non-user identities and external identities for authorization. In practice, many workloads use managed identities or service principals to access resources securely without user credentials, which is a best practice for automation and applications. Therefore, limiting authorization to only Azure AD users is inaccurate.
Identities stored in Azure Active Directory (Azure AD), third-party cloud services, and on-premises Active Directory can be used to access Azure resources.
Yes. Identities from Azure Active Directory (Microsoft Entra ID), third-party cloud services, and on-premises Active Directory can be used to access Azure resources, typically through federation or synchronization. - On-premises Active Directory identities can be synchronized to Entra ID using Azure AD Connect (or cloud sync), enabling the same identity to authenticate to Azure. - Third-party identity providers (IdPs) can be federated with Entra ID using standards such as SAML, WS-Federation, or OpenID Connect, allowing users to sign in with external identities. - Entra ID B2B also allows inviting external users (guests) from other organizations. Once authenticated, authorization is granted via Azure RBAC (or resource-specific authorization). This supports hybrid identity and single sign-on (SSO), aligning with security best practices and common enterprise requirements.
Azure has built-in authentication and authorization services that provide secure access to Azure resources.
Yes. Azure includes built-in authentication and authorization capabilities to secure access to Azure resources. - Authentication: Microsoft Entra ID provides identity management and authentication features such as MFA, Conditional Access, Single Sign-On, and identity protection. - Authorization: Azure RBAC provides built-in role definitions and scope-based access control (management group, subscription, resource group, resource) to implement least privilege. Azure Policy can further enforce governance controls, and some services also support additional authorization models (e.g., data-plane RBAC for Azure Storage). These services are foundational to Azure’s security model and are heavily emphasized in AZ-900. They support the Azure Well-Architected Framework security pillar by enabling centralized identity, strong authentication, and least-privilege authorization across the platform.
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:
Storing 1 TB of data in Azure Blob storage will always cost the same, regardless of the Azure region in which the data is located.
No. Storing 1 TB in Azure Blob Storage does not always cost the same across regions. Azure pricing is published per region, and the per-GB (or per-TB) monthly storage rate can differ between regions (for example, East US vs. West Europe vs. Southeast Asia). In addition, the total cost of “storing 1 TB” can vary based on choices that are often tied to availability and regional offerings, such as redundancy (LRS/ZRS/GRS/GZRS) and access tier (Hot/Cool/Archive). Even if you keep the same redundancy and tier, the base storage meter is still region-dependent. The statement uses the absolute term “always,” which is a strong indicator it’s false in Azure pricing questions. Therefore, the correct selection is No.
When you use a general-purpose v2 Azure Storage account, you are only charged for the amount of data that is stored. All read and write operations are free.
No. With a general-purpose v2 (StorageV2) storage account, you are charged for more than just the amount of data stored. Azure Storage has separate billing meters for transactions/operations (such as read, write, list, and other requests). The exact operation costs depend on the service (Blob, Files, Queues, Tables), the access tier (Hot/Cool/Archive for Blob), and sometimes the type of operation (e.g., write vs. read). Additionally, features like data retrieval (especially from Cool/Archive), early deletion fees (Cool/Archive), and certain replication options can add cost. The statement claims “All read and write operations are free,” which is incorrect—operations are typically billed per 10,000 (or similar unit) transactions. So the correct answer is No.
Transferring data between Azure Storage accounts in different Azure regions is free.
No. Transferring data between Azure Storage accounts in different Azure regions is not generally free. While inbound data transfer to Azure is typically free, outbound data transfer (egress) is usually billed, and cross-region transfers commonly incur bandwidth charges. If you copy data from a storage account in Region A to a storage account in Region B, the data leaving Region A is treated as outbound bandwidth and is typically charged. There can also be additional costs depending on the method used (for example, transaction costs for reads/writes during the copy). This is an important cost-optimization concept: architectures that frequently move large datasets across regions can become expensive. Therefore, the statement “is free” is false, and the correct selection is No.
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:
A Standard support plan is included in an Azure free account.
Correct answer: No. An Azure free account does not include Standard support. By default, Azure subscriptions (including Free and Pay-As-You-Go) come with Basic support at no additional cost. Basic support includes access to documentation, community support, and the ability to create billing and subscription management requests, but it does not include the technical support response times and 24x7 technical access associated with paid plans. Standard support is a paid support plan (along with Developer and Professional Direct). You must explicitly purchase it, and it is billed separately from Azure resource consumption. Therefore, the statement that Standard support is included with an Azure free account is false. Why “Yes” is wrong: “Free account” refers to free credits and limited free services for a period, not bundled paid support tiers.
A Premier support plan can only be purchased by companies that have an Enterprise Agreement (EA).
Correct answer: No. A Premier support plan (now commonly aligned with Microsoft Unified Support in many contexts) is an enterprise support offering purchased via a contractual agreement with Microsoft. While Enterprise Agreements (EA) are a common way large organizations buy Azure and related services, Premier/Unified Support is not strictly limited to customers with an EA. Organizations can obtain enterprise support through various commercial arrangements depending on size, needs, and region, and it is not accurate to say it “can only be purchased” by EA customers. The key exam concept is that enterprise support is a separate, organization-level contract and not inherently tied to a specific Azure subscription billing type. Why “Yes” is wrong: it incorrectly treats EA as a mandatory prerequisite for Premier/Unified Support.
Support from MSDN forums is only provided to companies that have a pay-as-you-go subscription.
Correct answer: No. Support from MSDN forums (and similar community channels) is not restricted only to companies with a pay-as-you-go subscription. MSDN/Developer community forums are generally open community support resources. They are not an entitlement that depends on the Azure subscription type (Free, Pay-As-You-Go, Visual Studio subscription benefits, CSP, or EA). In AZ-900 terms, community support is available broadly, while Microsoft technical support with guaranteed response times requires a paid support plan (Developer/Standard/Professional Direct) or an enterprise support contract. Subscription billing model does not gate access to community forums. Why “Yes” is wrong: it confuses community support availability with paid Microsoft support entitlements and incorrectly ties it to Pay-As-You-Go.
Your company has 10 offices. You plan to generate several billing reports from the Azure portal. Each report will contain the Azure resource utilization of each office. Which Azure Resource Manager feature should you use before you generate the reports?
Tags are ARM metadata (key/value pairs) used to logically organize resources for management and reporting. They are commonly used for cost allocation by department, project, or office. In Cost Management + Billing, you can filter and group usage/cost reports by tag values (e.g., Office=NYC), enabling per-office utilization and chargeback/showback reporting.
ARM templates (Bicep/JSON) define infrastructure as code to deploy resources consistently. While templates can include tags during deployment, the template itself is not the feature used “before generating reports” to segment billing by office. Templates help standardize deployments, not provide the reporting dimension; tags provide that dimension.
Resource locks (CanNotDelete/ReadOnly) protect resources from accidental deletion or modification. They are a governance and safety feature, not a cost-management or reporting feature. Locks do not add metadata for grouping resources by office and do not affect how billing or utilization reports are generated.
Azure Policy enforces organizational standards (e.g., allowed SKUs/regions, required tags, or compliance rules). Policy can ensure that an Office tag is applied, but policy itself is not the mechanism used to group billing reports. The reporting dimension is the tag; policy is optional to enforce tagging consistency.
Core concept: This question tests Azure Resource Manager (ARM) governance features used for organizing and reporting on resources. In Azure, ARM “tags” are name/value pairs applied to resources, resource groups, or subscriptions to logically categorize them (for example, by department, cost center, environment, or office). Why the answer is correct: To generate billing reports that show Azure resource utilization per office, you need a consistent way to associate each resource with the office that owns/uses it. Tags are designed for exactly this: they enable cost allocation and reporting by metadata. Once resources are tagged (e.g., Office=London, Office=Berlin), Azure Cost Management + Billing and many portal views can filter, group, and export costs/usage by tag. This supports chargeback/showback and aligns with governance practices. Key features and best practices: - Use a standard tag taxonomy (e.g., Office, CostCenter, Department, Environment, Owner). - Apply tags broadly and consistently; consider tagging at resource group level where appropriate, but remember not all services inherit tags automatically. - Use Cost Management to group/filter by tags and export reports. - Combine tags with Azure Policy to enforce required tags at creation time (policy is enforcement; tags are the classification used for reporting). Common misconceptions: - Azure Policy sounds relevant because it’s governance-related, but policy does not itself provide the reporting dimension; it enforces rules (such as “require a tag”). - ARM templates are for deploying resources consistently, not for organizing billing reports. - Resource locks prevent accidental deletion/changes and don’t help with cost allocation. Exam tips: When you see “billing reports,” “cost allocation,” “chargeback/showback,” or “group resources by department/project,” think “tags.” If the question adds “ensure every resource has the tag,” then the best answer often becomes “Azure Policy,” but only as an enforcement mechanism on top of tagging. This maps to the Azure Well-Architected Framework Cost Optimization pillar: allocate costs to owners using tagging and governance.
You need to identify the type of failure for which an Azure Availability Zone can be used to protect access to Azure services. What should you identify?
A physical server failure is typically handled by Azure’s built-in host-level resiliency (hardware redundancy, VM restart on another host, and clustered service designs). Availability Zones can help if a server failure is part of a larger zone issue, but the primary intent of zones is not single-server protection; it is isolation from a whole datacenter/zone outage.
An Azure region failure affects an entire region (all zones in that region). Availability Zones are all inside one region, so they cannot protect against a region-wide outage. To protect against region failure, you use multi-region architectures, paired regions, and geo-replication features such as GRS/GZRS for storage or cross-region failover for databases.
A storage failure depends on the storage replication configuration (LRS, ZRS, GRS, GZRS). While ZRS uses Availability Zones to replicate data across zones, the question is about what failure type Availability Zones protect access to Azure services from in general. The broader and correct failure type is a datacenter (zone) failure, not “storage failure” specifically.
Availability Zones are designed to protect against an Azure datacenter failure by placing resources in physically separate locations within the same region, each with independent power, cooling, and networking. If one datacenter/zone goes down, workloads deployed across zones (or using zone-redundant services) can continue operating from the remaining zones, improving availability and resiliency.
Core concept: Azure Availability Zones (AZs) are physically separate locations within a single Azure region. Each zone has independent power, cooling, and networking. The purpose is to provide high availability and resiliency against failures that affect an entire datacenter location, while keeping workloads in the same region for low latency. Why the answer is correct: An Availability Zone is designed to protect your access to Azure services from an Azure datacenter failure (sometimes described as a “datacenter-level” or “zone-level” failure). If you deploy zone-redundant services (or deploy resources across multiple zones), a failure impacting one datacenter/zone should not take down the service because instances or replicas exist in other zones within the same region. Key features / best practices: - Zone-redundant vs. zonal: Some services are “zone-redundant” (the platform replicates across zones automatically), while others are “zonal” and you must deploy multiple instances across zones and use a load balancer. - Typical patterns: Deploy VMs/VMSS across zones behind a Standard Load Balancer; use zone-redundant storage options (ZRS) where applicable; use services that support zone redundancy (for example, certain SKUs of Azure SQL, App Gateway, etc.). - Well-Architected Framework alignment: This maps to the Reliability pillar—design for redundancy and fault isolation. Zones provide fault isolation within a region. Common misconceptions: - Region failure vs. zone failure: Availability Zones do not protect against a full region outage. For region-wide resiliency, you use paired regions, geo-redundancy, and multi-region architectures (e.g., active-active/active-passive). - “Physical server failure” is too narrow: While zones help, Azure already mitigates single-server failures through clustering and platform redundancy; zones specifically address broader datacenter-level failures. - “Storage failure” is ambiguous: Storage resiliency depends on the replication option (LRS/ZRS/GRS/GZRS). Zones can be part of storage resiliency, but the question asks what failure type AZs protect against in general. Exam tips: If you see “Availability Zone,” think “protect against datacenter (zone) failure within a region.” If you see “region failure,” think “multi-region/paired region/geo-redundant design.”
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. What are two possible solutions? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.
Azure Traffic Manager is a DNS-based traffic distribution service that can direct Internet client requests to a public endpoint. If VM1 already has a public-facing endpoint, modifying the Traffic Manager profile can make HTTP requests resolve to that endpoint and reach the VM. In AZ-900 exam terms, this is treated as a valid way to make an Internet-facing service accessible because it controls how users are directed to the endpoint. It does not replace port filtering, but it is considered a complete solution option in the context of directing HTTP traffic to the VM.
A network security group is the standard Azure control used to allow or deny inbound traffic to a virtual machine’s NIC or subnet. By adding or modifying an inbound rule to allow TCP port 80 from the Internet, VM1 can accept HTTP requests. NSGs are stateful and are the most common answer for enabling access to a VM on a specific port. This is the clearest and most direct Azure-native method for permitting HTTP connectivity.
An Azure DDoS protection plan helps protect public IP resources from volumetric and protocol attacks, but it does not create or modify access rules. Even with DDoS Protection enabled, HTTP traffic will still be blocked if the NSG or other filtering controls deny port 80. Its purpose is resilience and attack mitigation, not publishing a VM to the Internet. Therefore, it is not a complete solution for enabling HTTP access.
Azure Firewall is a managed network security service used for centralized filtering, logging, and advanced network control. Although it can publish internal resources by using DNAT in some architectures, that is not the standard or expected basic solution for exposing a single Azure VM over HTTP in AZ-900. The question asks for two possible solutions in a foundational context, where NSGs and Traffic Manager are the intended answers. Without explicit architecture details such as firewall DNAT or forced routing, Azure Firewall is not the best complete solution here.
Core concept: This question tests which Azure services can be used to make a virtual machine reachable from the Internet over HTTP. For a VM to be accessible over HTTP, traffic must be directed to the VM’s public endpoint and allowed through the network filtering controls. In AZ-900, the relevant services are Azure Traffic Manager for directing Internet client requests to an endpoint and Network Security Groups (NSGs) for permitting inbound TCP port 80. Why correct: B is correct because an NSG controls inbound and outbound traffic at the subnet or NIC level. Allowing inbound TCP port 80 from the Internet to VM1 is a direct and standard way to enable HTTP access. A is also correct because Azure Traffic Manager can direct Internet users to the VM’s public endpoint using DNS-based routing, making the VM accessible over HTTP when the endpoint is already exposed. Key features: NSGs provide stateful Layer 3/4 filtering and are the primary mechanism for allowing or denying traffic to Azure VMs. Traffic Manager is a DNS-based traffic distribution service that can route users to public endpoints based on priority, performance, or other routing methods. DDoS Protection mitigates attacks but does not enable connectivity, and Azure Firewall is a centralized security appliance rather than the standard answer for basic VM Internet publishing in AZ-900. Common misconceptions: A common mistake is assuming Azure Firewall is required any time Internet access is involved. In reality, Azure Firewall is optional and used for centralized inspection and DNAT scenarios, not the basic method typically tested for exposing a single VM over HTTP. Another misconception is that DDoS Protection opens access; it only protects already exposed public resources. Exam tips: For AZ-900, when asked how to make a VM accessible on a specific port, first think about whether traffic is allowed by an NSG and whether users can be directed to the endpoint. Traffic Manager helps route clients to Internet-facing endpoints, while NSGs control whether the VM accepts the traffic. Services like DDoS Protection and Azure Firewall are important, but they are not usually the expected basic answers unless the question explicitly mentions those architectures.
HOTSPOT - To complete the sentence, select the appropriate option in the answer area. Hot Area:
Azure Site Recovery provides ___ for virtual machines.
Correct answer: B (disaster recovery). Azure Site Recovery is designed to provide disaster recovery for virtual machines by replicating them to a secondary location and enabling orchestrated failover/failback. If a primary site or Azure region becomes unavailable, ASR helps restore service by starting replicated VMs in the target location, supporting recovery objectives such as RPO (data loss tolerance) and RTO (time to restore service). Why the other options are wrong: - A (fault tolerance): Fault tolerance typically refers to an architecture that continues operating despite component failures (often within the same region) through redundancy and automatic handling of failures. ASR is about recovering after a major outage, not continuous operation through component failure. - D (high availability): High availability focuses on minimizing downtime for localized failures (e.g., using Availability Zones/sets, load balancing). ASR is cross-site/cross-region recovery, not the primary mechanism for in-region HA. - C (elasticity): Elasticity is the ability to automatically scale resources up/down based on demand (e.g., VM Scale Sets, autoscaling). ASR does not provide scaling.