Practice Test #2

Azure Advisor does not primarily provide recommendations to improve the security of an Azure Active Directory (Azure AD) / Microsoft Entra ID environment. Advisor’s “Security” recommendations focus on Azure resources and configurations (for example, enabling secure configurations, reducing exposure, and improving security posture for workloads). Identity-specific security recommendations—such as improving sign-in risk policies, MFA coverage, conditional access posture, and other directory hardening actions—are typically provided through Microsoft Entra ID capabilities like Identity Secure Score and related identity protection/governance features. In exam terms, if the statement is explicitly about “Azure AD environment,” the best match is not Azure Advisor. Advisor may integrate with broader security guidance, but it is not the primary tool for Entra ID security posture recommendations. Therefore, the statement is false.

Azure Advisor does provide recommendations to reduce the cost of running Azure virtual machines. This is one of Advisor’s core categories: Cost. Advisor analyzes VM utilization and configuration/usage patterns and can recommend actions such as resizing (right-sizing) underutilized VMs, shutting down or deleting idle VMs, purchasing reserved instances/savings plans where appropriate, and optimizing resource selection to reduce spend. For AZ-900, remember that cost optimization guidance is a hallmark of Azure Advisor, alongside reliability, performance, security, and operational excellence. While Azure Cost Management + Billing is the primary service for cost analysis, budgeting, and chargeback/showback, Advisor is the service that turns telemetry into prescriptive cost-saving recommendations. Therefore, the statement is true.

Azure Advisor is not intended to provide general recommendations on how to configure the network settings on Azure virtual machines (for example, detailed NIC/IP configuration, subnetting strategy, NSG rule design, routing, or DNS settings). Those are typically designed using Azure networking best practices and validated with tools like Azure Network Watcher, NSG flow logs, Connection troubleshoot, and architectural guidance. Advisor can sometimes recommend certain VM-related features that touch networking (for example, enabling accelerated networking on supported VM sizes to improve throughput/latency, or other performance/reliability suggestions). However, that is not the same as providing recommendations on how to configure VM network settings broadly. In AZ-900 wording, “configure the network settings on Azure virtual machines” implies detailed network configuration guidance, which is not Advisor’s role. Therefore, the statement is false.

Yes. A hybrid cloud model requires that the organization has some form of internal environment to integrate with the public cloud—typically an on-premises network and/or private cloud resources. The defining characteristic of hybrid is the combination of two environments (private/on-premises + public cloud) with connectivity and coordination between them. In practice, this usually means an internal network connected to Azure using VPN or ExpressRoute, and often shared identity (Microsoft Entra ID), monitoring, and governance. Why “No” is wrong: If a company has no internal network or private environment at all, then it is not hybrid; it is purely public cloud. Hybrid is not just “using cloud services,” it is specifically “using cloud services together with on-premises/private resources.”

Yes. One of the most common benefits/use cases of hybrid cloud is extending on-premises computing capacity by leveraging public cloud resources. This is often described as scaling out, cloud bursting, or adding temporary/elastic capacity for peak demand, dev/test, batch jobs, or disaster recovery. For example, an organization might keep core systems on-premises but run additional web front ends or analytics workloads in Azure when demand increases. Why “No” is wrong: Hybrid cloud is specifically valued for flexibility and elasticity—keeping certain workloads local for latency, compliance, or legacy reasons while using Azure to add compute/storage on demand. This supports Well-Architected principles like Performance Efficiency (elastic scaling) and Cost Optimization (avoid overprovisioning on-prem hardware).

No. In a public cloud model, access to cloud resources is not limited to “guest users” at your company. Access is determined by authentication and authorization controls (for Azure, typically Microsoft Entra ID identities, service principals/managed identities, and Azure RBAC), plus network controls (firewalls, private endpoints, VNets) and other governance policies. Why “Yes” is wrong: “Guest user” is a specific identity concept (B2B collaboration) and is not a defining rule of public cloud access. Public cloud resources can be accessed by internal employees, external partners, customers, applications, and automation accounts—any identity that is granted permissions. The public cloud refers to the provider-owned infrastructure and shared responsibility model, not to a restriction that only guest users can access resources.