Practice Test #5

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.

Correct answer: D. Azure Advanced Threat Protection (ATP). “Monitor threats by using sensors” aligns with Azure ATP (now Microsoft Defender for Identity). It deploys sensors (typically on domain controllers, or via a standalone sensor) to collect network traffic and security events, then analyzes them to detect identity-related threats such as reconnaissance, credential theft techniques, and suspicious lateral movement. The explicit mention of “sensors” is the giveaway for this product in exam questions. Why the others are wrong: - A. Azure Monitor: collects metrics/logs for resources and apps; it doesn’t provide dedicated identity threat sensors. - B. Azure Security Center (Defender for Cloud): focuses on security posture management and workload protection; it uses agents/extensions for telemetry, but the exam phrasing “using sensors” is classically tied to Azure ATP/Defender for Identity. - C. Azure AD Identity Protection: detects risky users/sign-ins in Azure AD, but it doesn’t rely on “sensors” in the same sense; it uses Azure AD signals and risk analytics.

Correct answer: C. Azure Active Directory (Azure AD) Identity Protection. Enforcing Azure MFA “based on a condition” maps to risk-based or conditional enforcement. Azure AD Identity Protection evaluates user risk and sign-in risk (based on detected anomalies and leaked credentials signals) and can automatically remediate by requiring password change or requiring MFA when risk thresholds are met. In AZ-900-style questions, this is the service most directly associated with conditional/risk-based MFA enforcement. Why the others are wrong: - A. Azure Monitor: not an identity access control service. - B. Azure Security Center (Defender for Cloud): can recommend enabling MFA and improve security posture, but it doesn’t enforce MFA conditions for sign-ins. - D. Azure Advanced Threat Protection (Defender for Identity): detects and investigates identity attacks using sensors, but it is not the control plane for enforcing MFA conditions; that enforcement is done through Azure AD capabilities (Identity Protection/Conditional Access).

Correct answer: D. configuring the SaaS solution. In a SaaS model, the cloud provider delivers and operates the full application stack. Your responsibility is primarily at the tenant/application configuration level: setting up users and roles, configuring features, workflows, policies, integrations, and ensuring the service is used in a compliant way (for example, configuring retention or access controls available within the SaaS product). Why the others are wrong: A (configuring high availability) is typically the provider’s responsibility in SaaS. The provider designs and operates the service to meet published SLAs and handles redundancy, failover, and patching. B (defining scalability rules) is generally not a customer task in SaaS because you don’t manage the underlying compute resources or autoscale settings; the provider scales the service. C (installing the SaaS solution) is incorrect because SaaS is consumed as a ready-to-use application; you do not install or maintain the application binaries or servers.

Correct selection: Use the “Help + support” (or “Support + troubleshooting”) blade to create a support request for a quota increase. Why this is correct: Subscription quota increases are processed by Microsoft through a support request workflow. In the Azure portal, you typically go to Help + support, then create a Support request, and select the issue type related to “Service and subscription limits (quotas)”. This is the standard path for requesting increases to limits like vCPU cores, networking limits, or other subscription-level quotas. Why other blades are wrong: Blades such as Virtual machines, Resource groups, SQL databases, etc., are for managing those resources, but they do not provide the subscription-level quota increase request process. Even if the quota relates to VMs, the request is still submitted through Support rather than from the VM blade.