Describe Azure management and governance practice questions

Templates automatically scale resources based on demand.

Why wrong: ARM templates are deployment-time declarations; they define a static configuration (e.g., VM sizes, network settings, storage SKUs) but contain no runtime logic to add or remove capacity based on load. Automatic scaling is achieved by separate Azure services such as Autoscale settings, Virtual Machine Scale Sets, or App Service scale-out rules, which can be deployed via a template but act independently during runtime. Therefore, the template itself never scales resources automatically—it only provisions the infrastructure that may include autoscaling configuration.

Templates are limited to a specific Azure region.

Why wrong: An ARM template is not region-bound; it can be deployed to any Azure region by passing a location parameter at deployment time or by using a resource group that resides in the desired region. Best practice is to parameterize location rather than hardcoding it, which makes the same template reusable across regions for disaster recovery or multi-region deployments. While certain resource types or VM SKUs may not be available in every region, that is a regional capacity limitation, not a constraint of the template format itself.

A) Azure Policy

Why wrong: Azure Policy is incorrect because it only enforces rules and evaluates resource compliance, such as allowed locations or required tags, but it cannot deploy resource groups, assign RBAC roles, or bundle a set of governance components. While Policy assignments can be applied across subscriptions through management groups, they are declarative constraints rather than a deployment artifact. To achieve the full suite of common governance, you would still need separate role assignments and template deployments.

B) Azure Blueprints

Why wrong: Azure Blueprints is the correct choice because it packages multiple governance components — Azure Policy assignments, RBAC role assignments, and resource group/ARM template deployments — into a single, versioned definition that can be assigned to multiple subscriptions. This orchestration capability is designed specifically to help IT teams apply a consistent baseline across many subscriptions in an enterprise, with each assignment tracking the version and lock settings. Unlike a bare ARM template, Blueprints also manages the dependencies and the assignment lifecycle.

C) Azure Resource Manager

Why wrong: Azure Resource Manager (ARM) is incorrect because it is the deployment and management layer for Azure, not a governance packaging service. ARM templates can define resources and their dependencies, but they cannot pre-assemble policy assignments, role assignments, and template deployments as a unified governance artifact. Each new subscription would require manual template deployment and separate configuration of policies and RBAC, unlike Blueprints which orchestrates all of those together.

Modify the policy effect to 'deny' instead of 'append'.

Why wrong: Changing the effect to 'deny' would prevent creation of untagged resources but would not add tags to existing ones.

Use Azure Resource Graph to identify and manually tag.

Why wrong: Using Azure Resource Graph to manually identify and tag resources is not automatic and requires manual intervention.

Reassign the policy with a new scope.

Why wrong: Reassigning the policy with a new scope does not apply the tags to existing resources; it only applies to resources within the new scope on future updates.

Assign an Azure Policy with deny effect on delete operations.

Why wrong: An Azure Policy with deny effect on delete operations continuously blocks delete at the Azure Resource Manager level based on policy rules, but this is designed for governance compliance, not reversible operational control. Disabling or altering the policy assignment to allow a temporary maintenance window requires editing the assignment, excluding a scope, or using an exemption, all of which are slower and riskier than simply removing a lock. These changes must be carefully audited and reverted, so policy deny effects are not practical for routine lock/unlock maintenance.

Use Azure RBAC with a custom role that denies delete.

Why wrong: Azure RBAC custom roles or deny assignments restrict delete operations based on the identity of the caller, not the resource object itself, and are scoped to users, groups, or managed identities. Temporarily permitting deletion during maintenance means creating a new role assignment, removing a deny assignment, or escalating privileges, which is cumbersome and could inadvertently grant delete rights to other users if misconfigured. Deny assignments also affect all resources within their scope, so they are a coarse control and not meant for short-lived protection of a single resource group.

Use Azure Blueprints to enforce protection.

Why wrong: Azure Blueprints package environment definition artifacts such as policies, role assignments, and Resource Manager templates for repeatable subscription or management group deployment, but they offer no runtime 'protect this resource group' operation. While a blueprint could include a resource lock artifact, applying or removing such protection requires redeploying or editing the blueprint assignment—a heavyweight orchestration process that treats the lock as part of an immutable environment definition. Blueprints are for provisioning and governance, not for flexible, on-demand temporary locks for a specific existing resource group.

ReadOnly

Why wrong: Incorrect. A ReadOnly lock prevents any modifications to the resource group and its resources, including updates and deletions. This is stricter than needed, as the team still requires the ability to create, update, and delete individual resources.

DoNotDelete

Why wrong: The option 'DoNotDelete' is not a valid Azure Resource Lock type, even though its name sounds like it might prevent deletion. Azure only provides 'CanNotDelete' and 'ReadOnly' as official lock types. Using 'DoNotDelete' in a deployment or portal would fail because the service does not recognize it as a legitimate lock. The correct way to prevent deletion while still allowing updates and creates is to use the 'CanNotDelete' lock.

ModifyOnly

Why wrong: The option 'ModifyOnly' is not a recognized Azure Resource Lock type. Azure Resource Manager only supports two lock types: CanNotDelete and ReadOnly. Assigning a lock with an unsupported name like 'ModifyOnly' would result in an invalid configuration error, as it cannot be applied or executed. Even if the intent is to prevent modifications while allowing reads, that behavior aligns with the ReadOnly lock, not a custom 'ModifyOnly' type.

Create a policy exclusion on the resource group.

Why wrong: A policy exclusion is not something you create on a resource group after the fact; exclusions are defined within the policy assignment itself, in the "excludedScopes" array of the assignment's properties. Adding or changing an exclusion requires editing the original assignment, which is expressly forbidden in the scenario. Even if the portal appears to show an exclusion option, it modifies the assignment, so it is not the correct answer.

Modify the policy assignment to include a compliance exception.

Why wrong: Azure Policy does not have a construct called a "compliance exception" — the only supported way to exclude a scope from compliance evaluation is an exemption. Furthermore, modifying the policy assignment to add anything would violate the scenario's explicit requirement that the original assignment remain unchanged. Therefore this option is both conceptually wrong and practically disallowed.

Create a resource lock on the resource group.

Why wrong: A resource lock is an Azure Resource Manager control that prevents deletion or modification of a resource or resource group, but it has no influence on Azure Policy compliance evaluation. Policy enforcement continues to assess your resources for required tags regardless of any locks; locks only guard against accidental destructive operations. Thus, a lock would not allow resources without the required tag to be created, as the policy would still block them.

Azure Resource Manager (ARM) templates

Why wrong: Azure Resource Manager (ARM) templates are Infrastructure-as-Code artifacts that declaratively define Azure resources and their properties for consistent, repeatable deployment. Templates are executed at a specific subscription or resource group scope and cannot define inheritance relationships between subscriptions or apply persistent governance controls across a hierarchy. While ARM templates can deploy policies or RBAC assignments, the templates themselves are not a management plane for organizing subscriptions or enforcing central governance.

Azure resource groups

Why wrong: Azure resource groups are logical containers within a single subscription used to group related resources for lifecycle and access management. A resource group cannot contain subscriptions or span multiple subscriptions, and its RBAC and policy assignments are scoped only to the resources inside that group. Thus, resource groups are unsuitable for centrally governing a set of subscriptions, as they have no visibility or authority over subscription-level configuration.

Azure Blueprints

Why wrong: Azure Blueprints are a deployment orchestration service that packages ARM templates, policies, roles, and resource groups into a single, repeatable artifact for creating new environments. While blueprints can assign policies and RBAC when deploying a subscription, they do not create or manage the subscription hierarchy itself, so they cannot provide ongoing inheritance of governance settings across many existing subscriptions. Blueprints operate at the scope of one subscription at a time, not across a set of subscriptions as a permanent organizational structure.

Azure Advisor

Why wrong: Azure Advisor provides proactive, personalized recommendations to optimize your Azure workloads across cost, security, reliability, and performance. While its cost recommendations may suggest rightsizing or shutting down idle resources to reduce spending, it does not allow you to configure budget thresholds or create custom spending alerts. Azure Advisor has no built-in mechanism to track a subscription's cumulative costs against a financial cap or to notify you when your spending reaches a certain percentage of a budget. Its cost-related features are advisory only, not monitoring or alerting.

Azure Policy

Why wrong: Azure Policy is an Azure service designed for governance, not cost management. It enforces organizational standards through rules that can deny, audit, or modify resource configurations—such as restricting VM sizes or requiring specific tags. While it can influence costs by preventing non-compliant deployments, it has no mechanism to define monetary thresholds, track actual spending over time, or trigger notifications when costs exceed a budget. Thus, it cannot be used to alert the finance team about exceeding the subscription budget.

Azure Pricing Calculator

Why wrong: The Azure Pricing Calculator is a pre-deployment estimation tool that helps you compute expected monthly costs for Azure services based on your anticipated configuration and usage assumptions. It does not connect to your live Azure subscription and therefore has no access to actual spending data, resource consumption, or incurred charges. Since it cannot monitor real-time or historical costs, it also cannot evaluate budget thresholds or send any kind of alert when actual spending approaches a limit.

Azure Policy with the Deny effect

Why wrong: Azure Policy with a Deny effect can prevent creation of non-compliant resources and block modifications that violate a policy rule, but it does not directly protect against deletion of existing resources by users with Owner or Contributor roles. Resource Locks are specifically designed for this purpose.

Azure RBAC role assignment (e.g., restrict to Reader role)

Why wrong: RBAC roles control who can perform actions, but a user with the Owner role can delete any resource. Changing roles for all users is not practical and does not prevent an Owner from removing the role assignment. Resource Locks are additive and require a lock removal step.

Azure management group

Why wrong: Management groups are used to organize subscriptions and apply governance at scale (e.g., policies, RBAC). They do not provide protection at the resource group level. Applying a management group is not a direct safeguard for a single resource group.

Create a new Azure Policy assignment at the marketing subscription scope with the 'Allowed Locations' initiative set to 'Audit' instead of 'Deny' and include North Europe in the allowed list.

Why wrong: Creating a new assignment at the subscription scope would not override the deny effect from the parent management group. Policy effects are additive, and a deny effect from a higher scope cannot be overridden by an audit effect at a lower scope. This would not grant the permission to deploy in North Europe.

Create an Azure Blueprint that includes the 'Allowed Locations' policy and assign it to the marketing subscription.

Why wrong: An Azure Blueprint can include policy assignments, but it would still apply the deny effect to the marketing subscription since the root management group assignment is still in effect. This does not provide an exception; it only duplicates the restriction.

Assign a custom RBAC role to the marketing subscription that bypasses the policy.

Why wrong: Azure Role-Based Access Control (RBAC) controls who can perform actions on resources, not whether resources can be created. Azure Policy is independent of RBAC; custom roles cannot bypass policy effects. Only exemptions or modifications to the policy itself can grant exceptions.

Assign a new policy with the 'Audit' effect at the Development management group to override the Deny effect.

Why wrong: Incorrect. Policy effects are not overridden by less restrictive effects at a child scope. The Deny policy from the parent management group still applies to Development subscriptions because policy inheritance is cumulative. An Audit policy does not prevent the Deny from blocking encryption-free storage accounts.

Remove the policy assignment from the root management group and assign it individually to each Production subscription.

Why wrong: Incorrect. While this would technically allow Development subscriptions to not have the policy, it negates the benefit of management groups and increases administrative overhead. It also does not address the need to keep the policy enforced for Production. Azure Policy exemptions provide a cleaner, more scalable approach.

Create an Azure RBAC role assignment that grants the Development team permission to bypass the policy.

Why wrong: Incorrect. Azure Policy and Azure RBAC are separate. RBAC controls who can make changes to resources, but it does not bypass policy effects. Even if a user has Owner permissions, Azure Policy with Deny effect will block non-compliant resource creation regardless of RBAC.

Azure Virtual Machine Scale Sets

Why wrong: Azure Virtual Machine Scale Sets automatically deploy and manage a group of identical, load-balanced VMs that can scale in or out based on demand, targeting production-tier high availability and elastic compute. They lack the dev/test-specific governance capabilities such as per-user VM quotas, auto-shutdown schedules, and lab cost policies. For a managed lab environment for developers and testers, DevTest Labs is the appropriate service.

Azure DevTest Labs

Why wrong: Azure DevTest Labs is a fully managed service that enables development and test teams to create and manage VM-based lab environments with built-in cost governance, including auto-shutdown schedules, cost thresholds, and quotas per user. It supports reusable artifacts, custom images, and ARM templates to quickly spin up consistent VMs for development and testing. These capabilities directly match the scenario of setting up cost-managed, disposable VM environments for developers and testers.

Azure Batch

Why wrong: Azure Batch is a job-scheduling and compute-pool service that runs large-scale parallel and high-performance computing workloads, scaling to thousands of VMs for one-off batch executions. It does not provide interactive lab management features such as claimable VMs, per-user cost limits, or auto-shutdown policies that are required for development and testing environments. Azure Batch is intended for compute-intensive, non-interactive jobs, making it incorrect for managing dev/test labs.

Basic

Why wrong: Basic is the free support plan bundled with every Azure subscription, but it covers only billing, subscription management, and service health incidents. It does not include any technical support from engineers; users are limited to documentation, community forums, and other self-help resources. Therefore, Basic cannot be the plan that provides 24/7 technical support.

Developer

Why wrong: Developer is a paid plan designed for development and testing scenarios, but its support is limited to business-hours email only. It does not provide telephone access, and there is no 24/7 coverage, meaning critical production issues cannot be raised when the office is closed. Since the requirement is 24/7 technical support, Developer fails because of its time-of-day and channel restrictions.

Enterprise

Why wrong: Enterprise is a higher-tier Azure support plan that does provide 24/7 technical support, but it is not the minimum plan to get that coverage. Because the question asks for the lowest plan that gives 24/7 support, choosing Enterprise over Business is overly expensive and includes extra benefits (like proactive guidance and designated engineers) that are not required for 24/7 escalation. Thus, while Enterprise has 24/7 support, it is incorrect for this criterion.

Assigning Reader role to all users

Why wrong: The Reader role grants read-only access to Azure resources, allowing users to view configurations and settings but not to make changes or deletions. While it restricts direct delete operations, it does not enforce protection against deletion if a user has been granted a higher-privileged role or if the user is an owner or contributor. Additionally, Reader role does not prevent deletion by service administrators or users with permissions at a different scope, so it cannot reliably guarantee that a resource group remains undeleted.

Setting an Azure Policy to deny resource group deletion

Why wrong: Azure Policy is designed to enforce compliance and governance by evaluating resource properties during creation or update, but it does not intercept or control management-plane operations like resource group deletion. There is no built-in policy definition that targets the deletion of a resource group, and custom policies cannot be used to deny such an action. Therefore, while Azure Policy can tag or restrict resource configurations, it is an ineffective mechanism for preventing the deletion of the entire resource group.

Enabling Azure Backup for the resource group

Why wrong: Azure Backup is a data-protection service that creates recovery points for Azure VMs, files, and databases, allowing you to restore data after accidental deletion or corruption. It does not prevent the deletion of the resource group itself; even if backups exist, the resource group and its resources can still be deleted, leaving only the backup data available for recovery. Enabling Backup would allow you to recover the data from the backup, but it does not stop the deletion event from occurring, so it is not a preventive control.

99% uptime per month

Why wrong: 99% uptime per month is incorrect because it falls below the contractual SLA for a single virtual machine using Premium SSD storage. Azure commits to 99.9% uptime for that configuration, which translates to roughly 43.8 minutes of allowable downtime per month. Choosing 99% would mean accepting over 7 hours of monthly downtime, far more than what the SLA actually permits.

99.95% uptime per month

Why wrong: 99.95% uptime per month is not the SLA for a single VM; it applies only when you deploy at least two VMs inside the same Availability Set. That configuration raises the composite availability to 99.95%, which permits about 21.9 minutes of downtime per month. Since the question specifies a single VM, you cannot claim this higher tier, so this option is wrong.

99.99% uptime per month

Why wrong: 99.99% uptime per month is incorrect for a single VM because that SLA level requires deploying at least two VMs across separate Availability Zones within the same Azure region. This zone-redundant setup yields an annual downtime of approximately 52.6 minutes, but a lone VM does not qualify. Without such zone-level redundancy, Azure only guarantees 99.9% uptime for a single instance.

Azure Budgets

Why wrong: Azure Budgets are the correct choice because they let you define monetary thresholds—by subscription, resource group, or management group—using actual or forecasted costs, and send alerts via action groups when those thresholds are met. Budgets can also trigger automated actions, such as scaling down resources or stopping non-critical workloads, without requiring you to manually monitor costs. Unlike a fixed spending limit, budgets give you precision: you can set multiple thresholds (e.g., 50%, 90%, 100%) and choose whether to only alert or take an action.

Azure Reserved Instances

Why wrong: Azure Reserved Instances are not a spending control mechanism; they are a contractual commitment that saves money by prepaying or committing to a 1- or 3-year usage term for compute or other services. Selecting a reserved instance does not constrain your total expenditure, and any usage exceeding the committed capacity is simply billed at standard pay-as-you-go rates. Thus, reserved instances can reduce the cost of a fixed workload but cannot detect, alert on, or prevent cost overruns, making them irrelevant to this question's goal.

Azure Quota limits

Why wrong: Azure Quota limits cap the number of resources—such as virtual machines per region or CPU cores per subscription—that you can provision, not the amount of money you spend on them. These limits exist to protect the platform against oversubscription and to help you plan capacity, but they do not track or respond to your accrued costs. Even if you are far below your quota, you could still see a high bill, and exceeding quota would cause a provisioning failure, not a cost alert.

Azure Management Groups spanning clouds

Why wrong: Azure Management Groups organize subscriptions into logical hierarchies for policy and compliance within a single Azure AD tenant and a single Azure cloud, such as Azure commercial or Azure Government. They cannot span different Azure clouds because each cloud has its own independent tenant, subscription, and Management Group hierarchy. Thus, Management Groups are not a viable mechanism for cross-cloud governance or management.

Azure portal with subscription filter

Why wrong: The Azure portal subscription filter only controls which subscriptions within the currently connected Azure cloud environment are displayed, such as switching between payments for a single tenant. Each Azure cloud has a separate portal endpoint (for example, portal.azure.com, portal.azure.us, and portal.azure.cn), and the filter does not allow you to access or manage resources from another Azure cloud in the same session. Therefore, it lacks the ability to manage resources spanning multiple Azure clouds.

Azure Cloud Shell multi-tenant mode

Why wrong: Azure Cloud Shell is an interactive, browser-based shell that operates within a single Azure AD tenant, where each user is authenticated against that tenant's subscriptions. It does not have any multi-tenant mode that bridges separate Azure clouds such as Azure commercial, Azure Government, or Azure China; each cloud environment uses its own dedicated portal and Cloud Shell instance. As a result, Cloud Shell cannot provide unified management across different Azure clouds.

Azure Policy

Why wrong: Azure Policy is a governance service that merely evaluates and enforces compliance rules over existing resources or new deployments. It can audit, deny, or remediate non-compliant resources and apply effects like tagging, but Policy assignments alone are only one artifact type. They cannot package resource groups, ARM templates, or RBAC assignments into a single deployable unit, which is precisely what Azure Blueprints does as an orchestration service.

ARM templates alone

Why wrong: An ARM template alone is a declarative JSON or Bicep file that defines infrastructure resources like VMs, storage, and networking for a single deployment. It does not natively bundle Policy assignments or RBAC roles as part of a governance baseline; although you can inline some role definitions, the template lacks the subscription-level wrapper and artifact versioning that Blueprints offers. Thus, an ARM template is merely a component artifact inside a Blueprint, not an equivalent package.

Azure DevOps pipelines

Why wrong: Azure DevOps Pipelines is a CI/CD automation tool focused on building, testing, and delivering application code or infrastructure. While a pipeline can execute ARM template deployments or custom scripts, it is not a governance-specific service and lacks blueprint features such as built-in versioning of policies and role assignments, or subscription-level compliance tracking. Using Pipelines would require laborious custom release logic to approximate what Azure Blueprints natively provides for subscription governance.

Step 1: Register the application in Azure AD. Step 2: Map user attributes between Azure AD and the SaaS application. Step 3: Assign users and groups to the application. Step 4: Configure single sign-on (e.g., SAML). Step 5: Test the SSO configuration.

Why wrong: It configures SSO after assigning users, which is not the standard sequence. SSO configuration should precede user assignment to ensure that the SSO settings are defined before users are granted access.

Step 1: Assign users and groups to the application. Step 2: Register the application in Azure AD. Step 3: Map user attributes between Azure AD and the SaaS application. Step 4: Configure single sign-on (e.g., SAML). Step 5: Test the SSO configuration.

Why wrong: This is incorrect because you must register the application before assigning users; otherwise, there is no application to assign users to.

Step 1: Configure single sign-on (e.g., SAML). Step 2: Register the application in Azure AD. Step 3: Map user attributes between Azure AD and the SaaS application. Step 4: Assign users and groups to the application. Step 5: Test the SSO configuration.

Why wrong: This is incorrect because you cannot configure SSO before registering the application; registration provides the necessary endpoints and identifiers.

Access Azure Portal, Create Virtual Network, Add Subnets, Define Address Space, Configure DNS, Review and Create

Why wrong: This order is incorrect because subnets cannot be created before the address space exists. In the Azure portal's VNet creation flow, the IP Addresses tab first asks you to define the address space (e.g., 10.1.0.0/16) that serves as the parent CIDR block; each subnet is then specified as a smaller range within that block. Without a defined address space, the portal cannot validate any subnet prefix, so the Add Subnets step would fail. Thus, the correct sequence must place Define Address Space before Add Subnets.

Access Azure Portal, Create Virtual Network, Configure DNS, Define Address Space, Add Subnets, Review and Create

Why wrong: This order is incorrect because DNS configuration is independent of IP addressing and is not a prerequisite for defining the address space or subnets. The Azure portal presents the DNS tab after the IP Addresses tab, but DNS settings can be left at the default (Azure-provided) or modified later after the VNet exists. Placing Configure DNS before the address space and subnets misunderstands the dependency chain: subnets require an address space, whereas DNS does not require either to be set initially.

Access Azure Portal, Create Virtual Network, Review and Create, Define Address Space, Add Subnets, Configure DNS

Why wrong: This order is incorrect because Review and Create is the final validation and deployment step, not an intermediate action. In the Azure portal wizard, Review and Create triggers automated validation of all preceding configuration; if you select it before defining the address space and subnets, the validation fails because the VNet would have no IP address space to host resources. Once the VNet is deployed, you cannot go back and 'define address space' and 'add subnets' within that same creation flow—you would have to edit the deployed resource, so this sequence misrepresents the creation workflow.