Practice Test #1
Simuliere die echte Prüfungserfahrung mit 50 Fragen und einem Zeitlimit von 45 Minuten. Übe mit KI-verifizierten Antworten und detaillierten Erklärungen.
50Fragen45Minuten
Simuliere die echte Prüfungserfahrung mit 50 Fragen und einem Zeitlimit von 45 Minuten. Übe mit KI-verifizierten Antworten und detaillierten Erklärungen.
KI-gestützt
Jede Antwort wird von 3 führenden KI-Modellen kreuzverifiziert, um maximale Genauigkeit zu gewährleisten. Erhalte detaillierte Erklärungen zu jeder Option und tiefgehende Fragenanalysen.
A team of developers at your company plans to deploy, and then remove, 50 customized virtual machines each week. Thirty of the virtual machines run Windows Server 2016 and 20 of the virtual machines run Ubuntu Linux. You need to recommend which Azure service will minimize the administrative effort required to deploy and remove the virtual machines. What should you recommend?
Azure Reserved VM Instances are a pricing commitment (1-year or 3-year) that reduces compute cost for VMs that run continuously. They do not simplify deployment or deletion, and they are a poor fit for workloads that are created and removed weekly. Reserved Instances address cost optimization for steady-state usage, not administrative effort or lifecycle automation.
Azure virtual machine scale sets help you deploy and manage a set of identical VMs with autoscaling and automated instance repair, commonly used for stateless application tiers. While they reduce effort for large fleets, they are not primarily designed for frequently created and destroyed customized dev/test VMs across mixed configurations. Customization is possible but less aligned than DevTest Labs for this scenario.
Azure DevTest Labs is designed for dev/test scenarios where teams need fast, repeatable provisioning and easy cleanup of environments. It supports Windows and Linux, provides formulas and artifacts for standardized customization, and includes policies like quotas and auto-shutdown to reduce cost and governance overhead. This directly minimizes administrative effort for deploying and removing many VMs each week.
Microsoft Managed Desktop is a managed service for providing and operating Windows desktops (endpoint management, security, updates) for users. It is not intended for rapid provisioning and teardown of server VMs or Linux VMs for development/testing. It focuses on end-user computing management rather than automated VM lifecycle management.
Core concept: This question tests which Azure service best supports rapid, repeatable provisioning and teardown of many customized VMs with minimal administrative effort. In Azure, that typically means using a service designed for self-service environments, reusable templates, and automated lifecycle management. Why the answer is correct: Azure DevTest Labs is purpose-built to quickly create, manage, and delete lab environments (including Windows and Linux VMs) using reusable artifacts, formulas, and policies. For a team deploying and removing 50 customized VMs weekly, DevTest Labs minimizes admin overhead by enabling standardized VM creation (preconfigured images and settings) and easy cleanup (deleting VMs or entire lab resources). It also supports both Windows Server 2016 and Ubuntu, aligning with the mixed OS requirement. Key features and best practices: DevTest Labs provides: - Formulas (predefined VM configurations) to deploy consistent “customized” VMs repeatedly. - Artifacts to automatically install software and apply configuration during provisioning. - Policies (quotas, allowed VM sizes, auto-shutdown) to control sprawl and cost, aligning with Azure Well-Architected Framework cost optimization and governance. - Self-service provisioning for developers, reducing central IT tickets and manual steps. This combination directly targets the “deploy and then remove frequently” scenario. Common misconceptions: VM Scale Sets can automate deployment of many VMs, but they are optimized for scaling identical instances behind a load balancer (stateless workloads) rather than ad-hoc, customized dev/test machines that are created and destroyed weekly. Reserved Instances reduce cost for long-running VMs, not admin effort, and they conflict with short-lived weekly churn. Microsoft Managed Desktop is a managed endpoint/desktop service, not a rapid VM lifecycle platform. Exam tips: When you see “developers,” “frequently create and delete,” “customized VMs,” and “minimize administrative effort,” think DevTest Labs. When you see “autoscale identical VMs for an app,” think VM Scale Sets. When you see “commitment discount,” think Reserved Instances.
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:
Azure Advisor can generate a list of Azure virtual machines that are protected by Azure Backup.
Azure Advisor cannot be relied on to generate a definitive list of Azure virtual machines that are protected by Azure Backup. Advisor’s purpose is to provide recommendations (for example, “enable backup for VMs” if it detects VMs without backup), not to serve as an authoritative reporting inventory of backup-protected resources. To list which VMs are protected, you would typically use Recovery Services vault/Backup center views, Azure Backup reports, or queries via Azure Resource Graph/Log Analytics depending on your reporting needs. Those tools are designed to show protection status, backup items, and compliance across subscriptions. Therefore, the statement is false: Advisor may highlight missing backups as a recommendation, but it does not function as the primary mechanism to generate a complete list of VMs currently protected by Azure Backup.
If you implement the security recommendations provided by Azure Advisor, your company’s secure score will decrease.
Implementing security recommendations increases your company’s Secure Score; it does not decrease it. Secure Score is a Microsoft Defender for Cloud metric that reflects your security posture based on implemented controls and remediated recommendations. As you address recommendations (e.g., enabling MFA, applying just-in-time VM access, enabling Defender plans, fixing NSG rules), your score typically goes up because you reduce risk and close security gaps. Azure Advisor can surface security recommendations, but the scoring concept is tied to Defender for Cloud. The directionality is important for the exam: remediation improves posture and raises Secure Score. So the statement is false because it claims the score will decrease when implementing recommendations, which is the opposite of how Secure Score works.
To maintain Microsoft support, you must implement the security recommendations provided by Azure Advisor within a period of 30 days.
There is no Microsoft policy requiring you to implement Azure Advisor security recommendations within 30 days to maintain Microsoft support. Azure Advisor recommendations are best-practice guidance intended to help optimize and secure workloads; they are optional and prioritized based on impact. Microsoft support eligibility is not contingent on implementing Advisor recommendations by a fixed deadline. Support requirements are generally related to using supported products/versions, maintaining proper licensing, and meeting contractual terms—not remediating advisory guidance within a specific timeframe. In regulated environments, an organization may set internal SLAs (e.g., remediate high-severity findings within 30 days) using governance tools like Azure Policy, Defender for Cloud regulatory compliance, or ITSM processes, but that is a customer-defined control, not a Microsoft support mandate. Therefore, the statement is false.
You have 1,000 virtual machines hosted on the Hyper-V hosts in a data center. You plan to migrate all the virtual machines to an Azure pay-as-you-go subscription. You need to identify which expenditure model to use for the planned Azure solution. Which expenditure model should you identify?
Operational expenditure (OpEx) is correct because Azure pay-as-you-go is consumption-based and billed periodically as an ongoing operating cost. Instead of purchasing and owning physical servers to host the 1,000 VMs, you rent compute capacity and pay for what you use. This is the classic cloud financial shift emphasized in AZ-900: CapEx to OpEx.
Elastic is not an expenditure model; it is a cloud characteristic describing the ability to automatically or quickly scale resources up and down based on demand. Elasticity can help reduce operational costs by avoiding overprovisioning, but it does not define whether spending is CapEx or OpEx. Therefore it’s not the right choice for an expenditure model question.
Capital expenditure (CapEx) refers to upfront investment in physical infrastructure and long-lived assets, such as buying Hyper-V hosts, storage arrays, and networking equipment for a datacenter. The scenario explicitly uses an Azure pay-as-you-go subscription, which is billed as ongoing service consumption rather than upfront asset purchase, so CapEx is not the correct model here.
Scalable is also not an expenditure model; it describes the capability of a system to handle increased load by adding resources (scale out) or increasing capacity (scale up). Like elasticity, scalability is a cloud benefit that can affect how much you spend, but it is not an accounting classification like OpEx or CapEx.
Core Concept: This question tests the cloud financial model shift from capital expenditure (CapEx) to operational expenditure (OpEx). In Azure, especially with a pay-as-you-go subscription, you pay for what you consume (compute, storage, networking, etc.) as an ongoing operating cost rather than buying hardware upfront. Why the Answer is Correct: Migrating 1,000 Hyper-V virtual machines from an on-premises datacenter to an Azure pay-as-you-go subscription aligns with an operational expenditure model. On-premises typically requires purchasing servers, storage, networking gear, and datacenter capacity upfront (CapEx). In contrast, Azure pay-as-you-go charges are metered and billed periodically (monthly), making them operating expenses. This is a foundational AZ-900 concept: cloud services convert large upfront investments into ongoing, usage-based costs. Key Features / Considerations: With OpEx in Azure, costs scale with usage and can be optimized using governance and cost management practices (Azure Cost Management + Billing, budgets, tagging, and alerts). While the question doesn’t ask for optimization, in real-world migrations you might reduce OpEx further with Reserved Instances/Savings Plans, Azure Hybrid Benefit (if you have eligible Windows Server licenses), and rightsizing. These are still OpEx-oriented because you’re paying for service consumption over time, even if you commit to discounted terms. Common Misconceptions: “Elastic” and “scalable” describe cloud characteristics (ability to scale resources up/down), not expenditure models. They can influence cost behavior, but they are not accounting categories. “Capital” might seem plausible because you’re moving many VMs and may think of it as a big project investment, but Azure pay-as-you-go is not an upfront purchase of infrastructure assets. Exam Tips: For AZ-900, map subscription/payment types to expenditure models: - Pay-as-you-go cloud services → OpEx. - Buying datacenter hardware/licenses upfront → CapEx. Also remember: elasticity/scalability are cloud benefits, not financial models. Tie “metered billing” and “consumption-based pricing” directly to OpEx and the Azure Well-Architected Framework Cost Optimization pillar (optimize ongoing spend through visibility and governance).
You have an on-premises application that sends email notifications automatically based on a rule. You plan to migrate the application to Azure. You need to recommend a serverless computing solution for the application. What should you include in the recommendation?
A web app (Azure App Service) is a PaaS hosting option for running web applications and APIs. While you can implement email notifications inside a web app, you must deploy and manage the application code and typically keep the app available continuously. It’s not the best match for a serverless, rule-driven workflow with built-in email connectors and pay-per-execution characteristics.
A server image in Azure Marketplace usually implies deploying a virtual machine (IaaS) from a prebuilt image. This requires managing VM sizing, patching, availability, scaling, and uptime. That approach is not serverless and increases operational overhead and cost compared to managed serverless services like Logic Apps for simple notification automation.
A logic app is a serverless workflow service that uses triggers and actions to automate processes. It’s ideal for rule-based email notifications because it offers built-in connectors (Outlook, SMTP, SendGrid), visual design, retries, and monitoring without managing infrastructure. It aligns with the scenario’s need for automatic notifications and a serverless approach.
An API app is an App Service-based approach for hosting APIs (historically tied to App Service). It can expose endpoints but does not inherently provide workflow orchestration, rule evaluation, or email connectors. You would still need to build logic and integrate additional services to send emails, making it less suitable than Logic Apps for this serverless automation scenario.
Core concept: This question tests recognition of Azure serverless options for workflow-based automation. In Azure Fundamentals, “serverless” commonly maps to Azure Functions (code-first) and Azure Logic Apps (workflow/low-code). The scenario describes sending email notifications automatically based on a rule, which is a classic event-driven workflow. Why the answer is correct: Azure Logic Apps is purpose-built for orchestrating workflows using triggers (for example, “when a record is created,” “on a schedule,” “when an HTTP request is received”) and actions (for example, “send email,” “post to Teams,” “create a ticket”). It is serverless: you don’t manage servers, scaling is handled by the platform, and you typically pay per execution/consumption depending on the plan. For an application that sends email notifications based on rules, Logic Apps can implement the rule evaluation and email delivery using built-in connectors (Office 365 Outlook, SMTP, SendGrid, etc.) with minimal custom code. Key features / best practices: Logic Apps provides hundreds of connectors, built-in retry policies, error handling, and monitoring via Azure Monitor and run history. It aligns with Azure Well-Architected Framework principles: operational excellence (visual workflow, run history), reliability (retries, resilient connectors), and cost optimization (pay-per-use in Consumption). For email notifications, using managed connectors reduces maintenance and improves security via managed identities and Azure AD where supported. Common misconceptions: A web app (App Service) can send emails, but it’s not inherently serverless in the exam sense and typically requires hosting an application continuously. A server image from Azure Marketplace is IaaS (VM-based) and the opposite of serverless. An API app is an App Service capability for hosting APIs; it doesn’t directly provide rule-based workflow automation and is not the best fit for “send email based on a rule” without additional components. Exam tips: When you see “automatically based on a rule,” “workflow,” “connectors,” “no/low code,” and “send email,” think Logic Apps. When you see “run code on demand” or “event-driven code,” think Azure Functions. For AZ-900, Logic Apps is the most direct serverless workflow service for notification scenarios.
A support engineer plans to perform several Azure management tasks by using the Azure CLI. You install the CLI on a computer. You need to tell the support engineer which tools to use to run the CLI. Which two tools should you instruct the support engineer to use? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.
Command Prompt is a Windows command-line shell where you can run executables available in the PATH, including the Azure CLI (`az`). After installation, you can open cmd.exe and run commands like `az login` and `az account show`. It’s a valid and common environment for executing Azure CLI commands on Windows.
Azure Resource Explorer is a web-based tool in the Azure portal used to view and interact with Azure Resource Manager (ARM) resource definitions and properties. It helps with troubleshooting and inspecting resource JSON, but it is not a command-line shell and does not run Azure CLI (`az`) commands.
Windows PowerShell is a scripting and automation shell on Windows that can run command-line tools such as Azure CLI. After installing the CLI, you can execute `az` commands directly in PowerShell and automate tasks with scripts. PowerShell is commonly used by administrators and aligns well with automation and operational excellence practices.
Windows Defender Firewall is a host firewall used to control inbound and outbound network traffic on a Windows machine. It is not a terminal or scripting environment and cannot be used to execute Azure CLI commands. While firewall rules might affect connectivity to Azure endpoints, it’s not a tool for running the CLI.
Network and Sharing Center is a Windows control panel interface for viewing and configuring network connections and sharing settings. It is unrelated to Azure management tooling and does not provide a command-line interface to run Azure CLI commands.
Core concept: This question tests how you run Azure CLI commands after installing the Azure CLI. Azure CLI is a cross-platform command-line tool (the executable is typically `az`) used to manage Azure resources (create, configure, query, and delete) and is part of Azure’s management tooling alongside the Azure portal, Azure PowerShell, ARM/Bicep, and REST APIs. Why the answer is correct: On Windows, once Azure CLI is installed, you can run `az` commands from any supported command shell. Two common and fully supported shells are Command Prompt (cmd.exe) and Windows PowerShell. Both provide an interactive terminal where the `az` executable can be invoked, authenticated (for example, `az login`), and used to perform management tasks (for example, `az group create`, `az vm list`). Therefore, instructing the engineer to use Command Prompt and Windows PowerShell provides complete solutions. Key features and best practices: Azure CLI supports scripting and automation, which aligns with Azure Well-Architected Framework operational excellence (repeatable deployments, reduced manual error, and consistent configuration). In practice, engineers often use PowerShell for richer scripting on Windows, while Command Prompt is a simple, universally available shell. Azure CLI can also be used in Azure Cloud Shell, but that option is not listed here. Common misconceptions: Some may confuse “Azure management tools” with “tools that run Azure CLI.” Azure Resource Explorer is a portal-based resource inspection tool for viewing and troubleshooting ARM resources; it does not execute Azure CLI commands. Windows Defender Firewall and Network and Sharing Center are networking/security configuration tools and are unrelated to running command-line management commands. Exam tips: For AZ-900, remember: Azure CLI is run from a terminal/shell (PowerShell, Command Prompt, Bash, Cloud Shell). If the option is a shell/terminal, it’s likely correct. If it’s a portal feature or Windows control panel applet, it’s not a CLI execution environment.
Möchtest du alle Fragen unterwegs üben?
Lade Cloud Pass kostenlos herunter – mit Übungstests, Fortschrittsverfolgung und mehr.
HOTSPOT - You have an Azure environment that contains 10 web apps. To which URL should you connect to manage all the Azure resources? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Hot Area:
Protocol
Correct is B (portal.) because the Azure portal is accessed at https://portal.azure.com and is the standard web interface to manage all Azure resources across subscriptions, resource groups, and services (including all 10 web apps). The portal is part of the Azure management plane and integrates governance capabilities such as RBAC, policy, resource locks, and cost management. A (admin.) is not the standard subdomain for Azure’s global management portal. While some services may have admin-related endpoints in other Microsoft products, Azure resource management is not done via an admin.azure.com URL. C (www.) is a common public website prefix but is not used for the Azure portal. Using www.azure.com would take you to marketing/documentation pages, not the authenticated management experience required to administer resources.
Domain
Correct is A (azure.) because the full portal URL is portal.azure.com. The domain azure.com is used for Azure’s primary web presence and includes the authenticated portal endpoint. B (azurewebsites.) is associated with Azure App Service default application hostnames (for example, <appname>.azurewebsites.net). That domain is for accessing the deployed web application (data plane / app endpoint), not for managing all Azure resources. You might use it to browse a specific web app, but not to administer subscriptions, resource groups, networking, identities, etc. C (microsoft.) is not the domain used for the Azure portal. Although Microsoft owns Azure, the portal is not hosted at portal.microsoft.com for Azure resource management in this context.
You plan to provision Infrastructure as a Service (IaaS) resources in Azure. Which resource is an example of IaaS?
An Azure web app (Azure App Service) is PaaS, not IaaS. You deploy your application code and configure settings (runtime, scaling rules, custom domains), but Microsoft manages the underlying servers, OS patching, and platform maintenance. It can seem like “infrastructure” because you choose plans/tiers, but you do not administer the VM OS layer, which is the key IaaS indicator.
An Azure virtual machine is IaaS. You provision compute resources and choose the OS image and VM size, then you manage the guest OS, patches, installed software, and application stack. Microsoft manages the physical hardware, datacenter, and hypervisor. This clear split of responsibilities is the hallmark of IaaS and is the best answer for an IaaS example.
An Azure Logic App is PaaS (serverless integration/workflow). You design workflows using connectors and triggers, and Azure runs and scales the execution environment for you. There is no VM or OS for you to manage. It may be confused with IaaS because it integrates with many systems and can be part of infrastructure automation, but it is a managed platform service.
Azure SQL Database is PaaS (managed database). Microsoft handles OS management, SQL engine patching, backups (configurable retention), and high availability options depending on tier. You manage the database schema, queries, security configuration (e.g., firewall rules, authentication), and data. Because you don’t manage the underlying server/OS, it is not IaaS.
Core concept: This question tests the cloud service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). In AZ-900, you must recognize which Azure offerings map to each model based on who manages what (customer vs. Microsoft). Why the answer is correct: An Azure virtual machine (VM) is a classic IaaS resource. With IaaS, Microsoft provides and manages the underlying physical datacenter, networking, storage infrastructure, and the virtualization layer. You (the customer) are responsible for configuring and managing the guest operating system, patches and updates for that OS, installed software/runtime, application configuration, and often security controls inside the VM (e.g., host firewall rules, endpoint protection). This aligns directly with the IaaS definition: you rent compute infrastructure and retain significant control. Key features and best practices: Azure VMs let you choose OS images, VM sizes, disks (managed disks), and networking (VNets, NICs, NSGs). For resilience (Azure Well-Architected Framework: Reliability), you typically use Availability Sets or Availability Zones and design for scale-out where possible. For security (Security pillar), apply least privilege, use NSGs, enable Azure Backup, and consider Azure Update Manager/automation for patching. For cost optimization, right-size VM SKUs, use Reserved Instances/Savings Plans, and shut down dev/test VMs when not needed. Common misconceptions: Many Azure services “feel” like infrastructure because you deploy them in Azure, but PaaS services abstract away OS management. Web Apps, Logic Apps, and Azure SQL Database are PaaS: Microsoft manages the OS and platform components, and you focus on code, workflows, or data. Exam tips: If you manage the OS (patching, configuration, installed software), it’s almost always IaaS (VMs). If you deploy code without managing servers/OS, it’s PaaS (App Service, Logic Apps, Azure SQL Database). Remember the shared responsibility model: more customer responsibility generally indicates IaaS.
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 has an Azure subscription that contains the following unused resources: ✑ 20 user accounts in Azure Active Directory (Azure AD) ✑ Five groups in Azure AD ✑ 10 public IP addresses ✑ 10 network interfaces You need to reduce the Azure costs for the company. Solution: You remove the unused groups. Does this meet the goal?
Yes is incorrect because it assumes Azure AD groups generate ongoing Azure charges that can be reduced by deletion. In practice, Azure AD groups do not incur direct per-object costs; charges are typically associated with licensing tiers and premium features, not the number of groups. Removing groups may simplify administration, but it does not lower Azure resource consumption billing. To reduce costs, you would target billable resources like allocated public IP addresses or other metered services.
No is correct because deleting unused Azure AD groups does not reduce Azure consumption charges. Azure AD groups are directory objects and are not billed on a per-group basis in standard Azure billing. Cost reductions would come from removing or deallocating billable resources such as public IP addresses (especially if allocated) or other metered services. Therefore, removing groups does not meet the goal of reducing Azure costs.
Core concept: This question tests which Azure resources generate ongoing charges and which are free, so you can identify actions that actually reduce Azure costs. Why the answer is correct: Removing unused Azure AD groups does not reduce Azure costs because Azure AD groups themselves do not incur per-group charges in a typical Azure subscription billing model. Costs in Azure AD are generally tied to licensing (e.g., Microsoft Entra ID Free/P1/P2) and premium features used by users, not to the existence of groups. Therefore, deleting groups does not meaningfully change the bill, while other listed resources (notably public IP addresses) can incur charges when allocated. Key features / configurations: - Microsoft Entra ID (Azure AD) objects (users, groups) are directory objects and are not billed per object. - Azure costs are commonly driven by metered resources such as compute, storage, bandwidth, and certain networking allocations. - Public IP addresses can be billable when reserved/allocated (especially Standard SKU), even if not attached/used. Common misconceptions: - Assuming “unused” directory objects (users/groups) create Azure consumption charges like compute/network resources. - Confusing Microsoft 365/Entra licensing costs (per user/feature) with Azure resource consumption costs (metered usage). - Overlooking that allocated networking resources (e.g., public IPs) can cost money even when idle. Exam tips: - Focus cost-optimization on metered Azure resources (compute, disks, public IPs, gateways), not directory objects. - Remember: Entra ID groups are not a direct Azure consumption cost item; licensing is typically per user/feature. - For networking, check whether resources are “allocated/reserved” (often billable) vs. merely defined as objects.
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:
An Azure service in private preview is released to all Azure customers.
No. A service in private preview is not released to all Azure customers. Private preview is intentionally limited to a small, selected group—often by invitation, application, or nomination—so Microsoft can validate functionality, performance, security, and usability with controlled feedback. In private preview, features may be incomplete, documentation may be limited, and breaking changes are more likely. It typically does not include an SLA and is not intended for broad production use. Because access is restricted, it cannot be considered “released to all Azure customers.” Why “Yes” is wrong: “released to all customers” aligns more closely with public preview (opt-in) or general availability (fully released), not private preview. Private preview is the most restricted stage in the release lifecycle.
An Azure service in public preview is released to all Azure customers.
Yes. A service in public preview is generally available for Azure customers to try, meaning it is released broadly rather than to a hand-picked subset. In public preview, customers can typically enable or deploy the service themselves (opt-in), though there may be limitations such as supported regions, specific subscription types, quotas, or feature gaps. Public preview is still pre-release from a production standpoint: Microsoft often provides it without an SLA and may recommend against mission-critical production workloads. However, the key exam concept is that public preview is open to the public (Azure customers) rather than invitation-only. Why “No” is wrong: “No” would describe private preview (restricted access). Public preview expands access beyond a limited pilot group, even if it’s not available in every region or for every scenario yet.
An Azure service in general availability is released to a subset of Azure customers.
No. General availability (GA) means the service is fully released for production use and is broadly available to Azure customers. GA typically comes with full supportability and, where applicable, a published SLA. The defining characteristic is that it is no longer a preview and is considered ready for mainstream adoption. While Microsoft may sometimes roll out GA features progressively by region or cloud (public vs sovereign), GA is not described as being released only to a subset of customers. A “subset of customers” aligns more with private preview (invite-only) or limited preview programs. Why “Yes” is wrong: If a service is only available to a subset of customers, it is not truly GA; it would more accurately be categorized as private preview or a limited/controlled release rather than general availability.
Your company plans to migrate to Azure. The company has several departments. All the Azure resources used by each department will be managed by a department administrator. What are two possible techniques to segment Azure for the departments? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.
Multiple subscriptions provide a strong boundary for departments: separate billing/chargeback, independent service quotas/limits, and clear administrative separation. You can assign a department administrator RBAC roles at the subscription scope to manage all departmental resources. This is a common enterprise pattern for governance and cost management, especially when departments need independent budgets and reporting.
Multiple Azure AD directories (tenants) primarily segment identity, not day-to-day resource organization for departments within the same company. Using separate directories increases complexity (user lifecycle, cross-tenant collaboration, licensing, and administration). While possible, it’s not the typical technique for departmental segmentation in Azure governance compared to subscriptions/resource groups.
Multiple regions are used to place workloads geographically for latency, compliance/data residency, and resiliency/DR. Regions do not provide an administrative or governance boundary for departments. Department administrators can still manage resources across regions within the same subscription/resource group, so regions are not a segmentation technique for departmental management.
Multiple resource groups segment resources logically within a subscription. They are ideal for delegating administration because RBAC roles can be assigned at the resource group scope, allowing a department administrator to manage only that group’s resources. Resource groups also support lifecycle management (deploy/update/delete as a unit) and governance via Azure Policy and tagging.
Core concept: This question tests Azure management and governance segmentation. In Azure, you commonly segment resources for different teams/departments using management boundaries that support delegated administration, access control (RBAC), policy enforcement, and cost tracking. The primary constructs for this are subscriptions and resource groups (often complemented by management groups, though not listed). Why the answer is correct: A. Multiple subscriptions is correct because a subscription is a strong isolation and billing boundary. Each department can have its own subscription, enabling separate cost management/chargeback, independent quota limits, and clearer administrative separation. You can assign department administrators roles (e.g., Owner/Contributor) at the subscription scope, giving them broad control over their department’s resources without impacting others. D. Multiple resource groups is also correct because a resource group is a logical container for resources that share a lifecycle, permissions, and governance controls. You can delegate management by assigning RBAC roles at the resource group scope to a department administrator. Resource groups also support applying Azure Policy and tags consistently, and they simplify operations such as deploying, updating, and deleting related resources. Key features and best practices: Subscriptions: billing separation, quota boundaries, and strong administrative scope. Often used for departmental separation when you need independent budgets and limits. Resource groups: lifecycle management, RBAC scoping, policy application, and organization of resources by application/environment/department. From an Azure Well-Architected Framework governance perspective, both approaches support cost management (Cost Optimization), operational management (Operational Excellence), and security through least privilege (Security). Common misconceptions: Multiple Azure AD directories (tenants) can separate identity environments, but it’s not the typical or recommended way to segment departments within one company. It adds complexity (cross-tenant access, duplicated identities) and doesn’t inherently provide the best resource governance model for departments. Multiple regions relates to geographic placement for latency, resiliency, and data residency—not administrative segmentation. Exam tips: For AZ-900, remember: subscriptions are the primary boundary for billing and quotas; resource groups are the primary boundary for organizing resources and delegating access within a subscription. If the question emphasizes departmental administration and segmentation, subscriptions and/or resource groups are the go-to answers.
Lade Cloud Pass herunter und erhalte kostenlosen Zugang zu allen Microsoft AZ-900-Übungsfragen.
Möchtest du alle Fragen unterwegs üben?
Kostenlose App holen
Lade Cloud Pass kostenlos herunter – mit Übungstests, Fortschrittsverfolgung und mehr.