Hard Difficulty Questions

Create an Azure Blueprint that includes a policy initiative

Why wrong: An Azure Blueprint packages templates, policies, and roles for orchestrated deployment, but assigning a blueprint does not retroactively fix resources that already exist. Its policy initiative would only be evaluated on new deployments or when a resource is updated, so non-compliant storage accounts created before the blueprint assignment remain unchanged. Blueprints lack the remediation engine that Azure Policy's DeployIfNotExists effect provides, making it ineffective for this governance scenario.

Assign a custom RBAC role that denies creation of storage accounts without HTTPS

Why wrong: Azure RBAC is an identity-based authorization system that determines who can perform actions like creating or deleting resources, not the configuration state of those resources. A custom role that denies creation of storage accounts without HTTPS would block future non-compliant creation but cannot inspect or modify existing storage accounts to enforce HTTPS-only traffic. Because the goal is to remediate already-deployed resources, RBAC is a prevention mechanism, not a remediation mechanism.

Configure Azure Monitor alerts to notify the security team

Why wrong: Azure Monitor alerts are designed to detect and notify, not to act; they can signal the security team that a storage account is non-compliant, but they cannot change the account's configuration. Even if an alert triggers a runbook or an Azure Function, that would be a separate, custom automation workflow, not an intrinsic governance capability. For an automated governance strategy, relying solely on alerts leaves a gap where non-compliant resources remain until a human or external process responds.

Azure Site Recovery

Why wrong: Azure Site Recovery replicates Azure VMs to a secondary region for disaster recovery, enabling failover and failback to meet recovery time objectives (RTO) and recovery point objectives (RPO). It continuously replicates ongoing changes and maintains a running replica, but it does not keep multiple point-in-time snapshots or allow granular file-level recovery from an arbitrary past date. Consequently, ASR is not a backup service; it is designed to keep the workload available during a regional outage, not to restore corrupted or accidentally deleted data.

Azure Policy

Why wrong: Azure Policy is a governance and compliance service that enforces rules using effects like Deny, Audit, or DeployIfNotExists to evaluate resource properties. It cannot create recovery points, copy data, or store backups; it only ensures resources comply with organizational standards, such as requiring a backup policy to be configured. Therefore, it is not a backup strategy, though it may be used to audit or automate the deployment of actual backup solutions.

Log Analytics workspace

Why wrong: A Log Analytics workspace becomes relevant only if you opt into Traffic Analytics, which ingests processed flow log data for advanced querying and visualization. Raw NSG flow logs are delivered to a storage account as JSON files, so the workspace is not a prerequisite for basic flow log collection. Selecting a Log Analytics workspace is an optional, secondary dependency that does not enable traffic capture itself.

Traffic Analytics

Why wrong: Traffic Analytics is an optional, built-in add-on that turns raw NSG flow log records into visibility by grouping flows, identifying top talkers, and detecting anomalies using machine learning. It does not capture data itself; instead, it processes the flow log blobs already stored in the storage account and enriches them with Azure's intelligence. Enabling Traffic Analytics adds significant querying and alerting value, but you must first have NSG flow logs feeding data.

Deploy AVD host pool in the primary region only.

Why wrong: If only a primary AVD host pool is deployed, all session-host VMs reside in one Azure region; when that region is down, the AVD service cannot route users to any available virtual desktops. Because failover requires a second set of session hosts to accept connections, a primary-only deployment offers no regional resilience and is therefore not a valid DR component.

Configure Azure Backup for the AVD session hosts.

Why wrong: Azure Backup creates recovery point snapshots of the session-host VMs, but it is designed for point-in-time data protection, not for continuous replication or low-RTO failover. Restoring an entire host pool from backup in a second region can take hours and does not address the need to serve AVD sessions during a regional outage, so it is not a required DR component.

The storage account uses GRS, which replicates data only to a secondary region within the same geography, not to a different region

Why wrong: This statement is incorrect because GRS does replicate to a different Azure region—specifically the paired secondary region within the same geography (e.g., East US to West US, or North Europe to West Europe). The option confuses 'same geography' with 'same region'; GRS always copies data asynchronously to a separate secondary region, not just to another datacenter within the primary region. So the claimed flaw (only replicating within the same geography, not another region) is false, as the paired secondary is a distinctly different region. Therefore this is not a valid reason to fail the failover requirement.

The storage account only supports HTTPS traffic, which blocks replication

Why wrong: This is wrong because the 'HTTPS only' setting (secure transfer required) on a storage account governs client-facing API calls over the public endpoint; it has no impact on Azure's internal replication plane. Replication between the primary and secondary region is performed by Azure's storage backend over its own private, secure network, independent of the account's secure-transfer configuration. Even with HTTPS enforced, data is still asynchronously replicated to the secondary region for GRS/RA-GRS. Therefore, the secure transfer setting cannot block or prevent replication, so this option does not explain the RTO issue.

The storage account is configured with the Hot access tier, which prevents failover

Why wrong: This is incorrect because the Hot access tier is a blob-level or account-level pricing/performance tier (Hot/Cool/Cold) that affects storage costs and access latency, not the replication or failover capability of the storage account. Account failover is governed by the replication type (GRS/RA-GRS or GZRS/RA-GZRS) and account kind, not by which access tier is configured. Hot-tier storage accounts with GRS still support the same manual failover behavior and same RTO constraints as Cool-tier accounts. Consequently, the access tier has no effect on whether failover is possible or how long it takes, making this option invalid.

Data encryption at rest using Azure Storage Service Encryption

Why wrong: Data encryption at rest using Azure Storage Service Encryption is a mandatory security control that protects data confidentiality when it is stored, but it has no impact on availability or recovery. Encryption operates at the disk and blob level, rendering data unreadable without keys, yet it does not influence replication, failover, or the ability to access data during an outage. This option is incorrect for a high-availability design question because encryption addresses the security pillar of the Azure Well-Architected Framework, not the reliability pillar.

Data striping with RAID 0 for performance

Why wrong: Data striping with RAID 0 is an on-premises storage technique that splits data across multiple disks to improve performance, but it provides no redundancy and actually increases the chance of data loss if any disk fails. Azure Storage abstracts the underlying hardware and automatically handles data redundancy across multiple disks, so customers do not implement RAID configurations. In Azure, performance and resilience are achieved through storage replication options (LRS, ZRS, GRS) and tier selection, not through manual disk striping, making RAID 0 irrelevant to high-availability design.

Azure Monitor Workbooks

Why wrong: Azure Monitor Workbooks are designed for creating rich, interactive reports and dashboards by querying data from Log Analytics and metrics stores. They are a presentation and analysis layer, not an active detection service — they don't continuously evaluate conditions or generate alerts. Consequently, while workbooks can surface historical trends and aid in post-incident analysis, they cannot by themselves detect or notify about performance issues in real time.

Azure Policy

Why wrong: Azure Policy is a governance service that enforces compliance rules on Azure resources, such as allowed VM SKUs or tagging conventions, using denial or audit effects. It operates on the Azure control plane and does not ingest application runtime telemetry, so it cannot detect performance bottlenecks, exceptions, or latency issues within an application. Its purpose is regulatory or organizational compliance, not operational diagnostics or monitoring.

Dashboard visual appeal and color scheme

Why wrong: Dashboard visual appeal and color scheme are secondary because monitoring design focuses on functional outcomes like data availability, cost, and alerting, not on UI aesthetics. While a well-organized dashboard improves operator efficiency, color choices and visual styling do not influence telemetry collection, retention policies, or alert behavior. Azure Monitor allows customization of workbooks and dashboards later; aesthetic preferences can be adjusted after core architectural decisions are made, so they are not a primary design consideration.

Custom metric creation for all application counters

Why wrong: Creating custom metrics for all application counters is not recommended because custom metrics incur additional ingestion and storage costs in Application Insights and Azure Monitor, and many platform-level counters are already captured by standard metrics. Standard metrics from Azure resources such as CPU, memory, and network I/O are available without extra configuration; only when you have a specific business or technical KPI that the standard metrics do not cover should you implement a custom metric. Over-provisioning custom metrics can also create noise and increase the complexity of your monitoring dashboards, without improving actionable insight. Therefore, selective custom metrics are the correct approach, not creating them for every counter.

Application Insights for every application

Why wrong: Application Insights is an Azure Monitor capability that provides application performance monitoring (APM) through client- and server-side SDK telemetry, including request rates, dependency failures, and page-view data. It is not required for every application to achieve a complete monitoring solution because Azure Monitor can also collect data directly from Azure resources, virtual machines, and custom sources without instrumenting each application. Unless the goal is specific deep-dive application-level diagnostics (like distributed tracing or user behavior analytics), adding App Insights to every app is optional and can introduce unnecessary overhead and cost.

Azure Policy assignments

Why wrong: Azure Policy is fundamentally a governance and compliance tool that evaluates resource configurations against business rules, such as enforcing tagging, restricting resource SKUs, or auditing encryption settings. It does not collect operational telemetry, store logs, or detect runtime performance degradations, and therefore cannot be a component of Azure Monitor's data pipeline. While Policy can integrate with monitoring (for example, auditing diagnostic settings or triggering remediation tasks), assigning policies is not a requisite pillar for a complete monitoring solution—it operates on resource state at deployment time, not on ongoing operational health.

Azure RBAC

Why wrong: Azure RBAC governs identity-based access to Azure resources via role assignments, defining who can perform actions against a resource's control plane. It does not inspect or enforce resource attributes such as naming conventions or tag compliance; those are metadata and configuration concerns. RBAC can delegate permission to apply policies or tags, but it cannot itself mandate a naming pattern or require tags on resource groups. Thus, while RBAC is essential for security, it is not a governance mechanism for enforcing naming/tagging rules.

Resource Locks

Why wrong: Resource locks (CanNotDelete and ReadOnly) protect resources from accidental deletion or modification by denying lifecycle operations such as delete and write at the management group, subscription, resource group, or resource scope. They do not validate or enforce naming or tagging rules; a lock only blocks operations and does not inspect resource metadata like tag existence or naming patterns. In fact, a ReadOnly lock can prevent Azure Policy's modify effect from adding required tags if remediation runs, because the resource cannot be changed. Therefore, Resource Locks are not a governance tool for naming/tagging requirements.

Self-service password reset

Why wrong: Self-service password reset (SSPR) is an end-user identity management convenience that allows users to reset their own passwords without helpdesk intervention. While it is part of Microsoft Entra ID authentication and user administration, it does not involve access recertification, entitlement lifecycle, or policy-driven review of resource access. As such, it is not a Microsoft Entra ID Governance feature.

Conditional Access

Why wrong: Conditional Access is a security policy engine that evaluates identity signals at sign-in time to enforce controls such as MFA, device compliance, or session restrictions. It is designed to protect access to resources, not to govern the lifecycle of who should have access, for how long, or why. Because it does not perform access recertification, entitlement packaging, or automated access lifecycle management, it is not a feature of Microsoft Entra ID Governance.

Privileged Identity Management

Why wrong: Privileged Identity Management (PIM) is indeed a component of Microsoft Entra ID Governance, but it is not one of the two core features this question targets. PIM specializes in just-in-time, time-bound activation of highly privileged roles with approval workflows, rather than broadly managing access entitlements for users, groups, and applications across the directory. For this question, the two definitive governance features are Access Reviews and Entitlement Management, so PIM is not a correct selection.

Use a public endpoint for profile storage.

Why wrong: Exposing the Azure Files share to a public endpoint is a security risk that contradicts the principle of least privilege. SMB traffic to a public endpoint traverses the public internet, which can be intercepted or subjected to unauthorized access if storage account keys or SAS tokens are leaked. Instead, you should use a private endpoint with a private IP address inside your virtual network, ensuring that all profile traffic stays within Azure's encrypted backbone and is isolated from internet-facing exposure.

Enable geo-redundant storage (GRS) for disaster recovery.

Why wrong: Geo-redundant storage is not a required design consideration for FSLogix profile storage because profiles are typically session-state data that can be regenerated or rebuilt, not irreplaceable business data. GRS replicates to a secondary region and introduces additional cost, write latency, and potential consistency issues, while offering little benefit for a service that is usually tied to a single region. Locally redundant storage (LRS) or zone-redundant storage (ZRS) provides sufficient resilience against hardware failures and regional zone outages without the overhead of geo-replication.

CPU utilization averaged over 1-hour intervals.

Why wrong: The query's summarize operator explicitly uses bin(TimeGenerated, 5m) to group measurements into five-minute buckets, so the timechart produces one data point per 5 minutes, not per hour. While CPU utilization could theoretically be averaged over one-hour intervals by changing the bin to 1h, that is not what this ARM template query is doing. Therefore the '1-hour intervals' answer misstates the temporal grain of the results.

Memory utilization over time.

Why wrong: Memory utilization would require querying the Memory performance object, for example '% Committed Bytes In Use' or 'Available MBytes'. This query instead filters solely on ObjectName == 'Processor' and CounterName == '% Processor Time', so it never touches memory-related counters. As a result, the output cannot show memory utilization over time; it shows only a processor metric.

Disk I/O utilization over time.

Why wrong: Disk I/O utilization is measured with PhysicalDisk or LogicalDisk performance objects, such as 'Disk Reads/sec' or '% Disk Time'. Here, the where clause restricts to the Processor object and the '% Processor Time' counter, so no disk counter is captured or aggregated. Thus the query provides no data about disk I/O behavior, making this option incorrect.

Conditional Access

Why wrong: Conditional Access is a real-time access control engine that evaluates signals like user location, device compliance, risk level, and application sensitivity to decide whether to allow or block authentication. Although it is a critical security feature of Microsoft Entra ID, it does not manage the lifecycle of access assignments, such as requesting, approving, reviewing, or removing entitlements. Since identity governance is specifically about structured processes for managing access over time, Conditional Access does not belong to the set of three governance capabilities.

Identity Protection

Why wrong: Identity Protection uses algorithmic risk detection to identify compromised accounts and suspicious sign-in behaviors, triggering policies that require password changes or block access. It is concerned with the security of authentication events, not with the governance of access rights themselves. Governance capabilities like entitlement management, access reviews, and PIM handle who should get access, why, and for how long—whereas Identity Protection reacts to potential threats, making it a security tool rather than an identity governance feature.

VM3 is not replicated properly.

Why wrong: The exhibit indicates that VM3 is included in the recovery plan, and its replication appears healthy because it can be added to the plan and shows no replication errors. A replication issue would typically prevent the VM from appearing in the plan or trigger an alert, neither of which is shown. Therefore, the failure is not due to replication state but rather how VM3 is configured within the plan's group.

The boot order is incorrect; VM3 should be before VM1.

Why wrong: The recovery plan does not define a strict boot sequence among individual VMs; it relies on the order of groups within the plan. Since no custom boot order is specified in the exhibit, moving VM3 ahead of VM1 would not change the failover behavior. The real issue is that VM3 is assigned to a Shutdown group, which is executed during the failback (shutdown) phase, not during startup.

The primary and recovery locations are swapped.

Why wrong: The exhibit clearly labels the source and target regions, and the recovery plan is configured to fail over from the primary site to the designated recovery site. If the locations were swapped, the failover test would target the wrong environment, causing connectivity or resource issues across all VMs, not just VM3. Since only VM3 fails to start, a location misconfiguration is not the cause; the issue is specific to the group assignment within the valid plan.

Management group

Why wrong: Management groups are hierarchical containers in Azure that organize subscriptions for governance and policy, but they serve as the assignment scope for blueprints, not as an artifact within the blueprint definition itself. A blueprint definition can be assigned to a management group, which then propagates the blueprint's artifacts (role assignments, policies, ARM templates) to child subscriptions, but you cannot include a management group as a deployable item in the blueprint. This distinction is critical: blueprints are composed of artifacts that deploy or control resources, whereas management groups are structural scopes.

Subscription

Why wrong: Subscriptions are billing and management boundaries in Azure that contain resource groups and resources, and they act as the target scope for blueprint assignments, not as artifacts within a blueprint. When you assign a blueprint to a subscription, the blueprint's artifacts (templates, policies, roles) are deployed into that subscription's context, but the subscription itself cannot be defined or created by the blueprint. Therefore, a subscription is not a component of the blueprint definition; it is the environment where the blueprint is applied.

Use Azure Site Recovery to replicate the HANA large instance VMs with a replication frequency of 30 seconds and enable auto-failover

Why wrong: Azure Site Recovery can replicate VMs but does not ensure HANA application consistency at the database transaction level. It may cause data loss or corruption because it captures VM-level state, not HANA-consistent checkpoints. RPO near zero cannot be achieved with VM replication.

Schedule HANA database backups every 5 minutes to Azure Blob Storage with geo-redundant storage (GRS), and restore in the secondary region on demand

Why wrong: This approach can only achieve an RPO of 5 minutes at best, because any transactions committed after the last backup are lost. Manual restore from blob storage to a secondary region requires provisioning a new HANA Large Instance, restoring the full backup, replaying log backups, and starting SAP HANA — a process that typically takes hours, far exceeding the 30-minute RTO. Geo-redundant storage protects against regional outages but does not automate failover or guarantee HANA transaction consistency, and backup frequency alone cannot provide near-zero RPO.

Set up HANA System Replication with synchronous mode to the secondary region

Why wrong: Synchronous HANA System Replication forces every commit on the primary to wait for acknowledgment from the secondary before completing. Over a WAN link between Azure regions (e.g., West US to East US) this adds round-trip latency to every database transaction, severely degrading production performance and potentially exceeding SAP latency tolerances. Asynchronous replication decouples commit latency while still providing a very low RPO, so it is the appropriate mode for long-distance DR; synchronous mode is only viable on low-latency, typically in-region links.

Single-master write region with Strong consistency and multiple read regions

Why wrong: A single-master write region with strong consistency requires every write to be synchronously replicated to all read regions before acknowledging the client, so write latency scales with the distance to the farthest region and can be significantly higher than necessary. This configuration also reduces write availability because if any read region is unreachable or unhealthy, writes cannot be committed, risking availability during a partial regional outage. Since the application only needs per-user session consistency, strong consistency is an unnecessary and costly over-provisioning that does not align with the global e-commerce reading pattern, where reads dominate and writes are localized.

Multi-master write with Eventual consistency and all regions enabled for writes

Why wrong: Enabling all regions for writes (multi-master) is unjustified because the application receives writes from only one region, so a single write region avoids the need for conflict-resolution logic and reduces operational cost. Eventual consistency, without session tokens, cannot guarantee that a user reads the data they just wrote within the same session; they might see stale or conflicting data as reads are served from different regions. This directly violates the explicit session consistency requirement while adding unnecessary write-write conflict handling, higher complexity, and no tangible benefit for a workload with a single write location.

Multi-master write with Strong consistency and two regions

Why wrong: This configuration is invalid in Azure Cosmos DB because strong consistency is not supported when multiple write regions are enabled; the service only allows strong consistency with a single write region, making a multi-master strong-consistency topology technically impossible. Even if it were possible, combining strong consistency with multi-master would force every write to be synchronously replicated across all regions before acknowledgment, which eliminates the latency benefits of multi-master writes and significantly increases both write latency and RU consumption. Since writes originate from only one region and the application only requires session consistency, this approach is overkill, unsupported, and not aligned with the stated requirements.

SQL Server log shipping to a VM in the secondary region

Why wrong: SQL Server log shipping is a database-level feature that periodically copies transaction log backups to a secondary VM but requires manual recovery of the database to bring it online, and every drill would break the log chain, forcing a full backup and reseed. It does not replicate the VM's operating system or SQL Server configuration, and the combination of manual steps and log restore is unlikely to guarantee a 1-hour RTO or a clean, non-impactful DR test.

Azure Backup with cross-region restore

Why wrong: Azure Backup with cross-region restore is fundamentally a backup service, not a continuous replication engine; it takes scheduled snapshots and, for cross-region restore, uses geo-redundant storage to restore a VM in the paired region from a recovery point. Creating a restored VM from a backup typically takes hours, far exceeding the required 1-hour RTO, and performing a restoration for a drill would not be a non-disruptive failover but rather a separate, full VM recovery that doesn't test automated failover processes.

Azure SQL Database geo-replication

Why wrong: Azure SQL Database geo-replication is a PaaS feature designed for Azure SQL Database and SQL Managed Instance, providing readable secondaries and auto-failover groups, but the mission-critical workload runs on SQL Server installed on an Azure VM, which is not a supported target for this service. Since geo-replication cannot be applied to an IaaS-hosted SQL Server, this option is inapplicable; adopting it would require migrating the database to Azure SQL Database, which fundamentally changes the architecture rather than protecting the existing VM.

Azure Cosmos DB with single-master and multiple read regions

Why wrong: A single-master configuration designates one regional account as the sole writable replica; all other regions are read-only replicas. IoT telemetry ingestion is a globally distributed write-heavy workload, so every device write would have to traverse the network to that one region, adding latency and creating a throughput bottleneck. Multiple read regions only improve read scalability and geo-distribution for reads, not write ingestion performance. Consequently, this fails the requirement for low-latency writes from all regions.

Azure Cosmos DB with multi-master and default strong consistency

Why wrong: Multi-master permits writes in any region, but defaulting to strong consistency forces every write to be synchronously replicated and acknowledged by a quorum of replicas across all participating regions before the commit returns. That synchronous replication sharply increases write latency and can degrade availability during regional outages, which is particularly harmful for high-volume telemetry ingestion. Strong consistency is only required for a subset of operations, such as device command reads, not for telemetry write ingestion. Using it as the default across all operations fails the latency and availability requirements.

Azure Cosmos DB with multi-master and eventual consistency only

Why wrong: Multi-master with eventual consistency alone offers the best write latency and availability, but it cannot guarantee that a device command read will return the most recently written value. In an IoT control scenario, a stale read could cause a device to miss an updated command or act on outdated instructions, so the requirement explicitly demands strong consistency for device command reads. Eventual consistency lacks any bound on replication lag and does not offer read-your-writes guarantees for those critical reads. Therefore, eventual-only fails the stated consistency requirement.