RDS Multi AZ practice questions

A company uses Microsoft Entra ID (Microsoft Entra ID). They want to allow users to sign in to multiple SaaS applications using their Microsoft Entra ID credentials without being prompted again for each application. Which Microsoft Entra ID feature should they enable?

Trap 1: Multi-Factor Authentication (MFA)

MFA requires a second verification factor (like a TOTP code or FIDO2 key) at initial sign-in, but it does not create or propagate a shared session across multiple applications. Even after MFA succeeds, each app that doesn't participate in the same Entra ID session will still prompt for credentials or its own MFA challenge. Thus, MFA strengthens security but fails to remove the repeated authentication prompts the user wants to eliminate.

Trap 2: Conditional Access

Conditional Access evaluates signals (user, device, location, risk) to enforce access policies such as blocking or requiring MFA, but it operates at the policy layer rather than the authentication session layer. It can manage when a session is allowed or challenged, yet it does not generate a single-sign-on token stream that carries identity across apps. Therefore, it can refine SSO but cannot itself replace the need for a shared authentication session.

Trap 3: Identity Protection

Identity Protection uses machine learning to detect compromised identities and risky sign-ins, triggering automated responses like forced password resets or conditional access policies. It is a risk-assessment and remediation engine, not an authentication protocol or session manager, so it does nothing to suppress the repeated authentication prompts between applications. Its role is to mitigate threats, not to federate identity for seamless access.

A
Single Sign-On (SSO)
SSO in Microsoft Entra ID uses the primary authentication token (e.g., SAML, OAuth2/OIDC) to establish a federated session, so subsequent application requests are silently authenticated without re-prompting. This works because Entra ID acts as the trusted broker that issues session cookies or refresh tokens, eliminating per-app credential entry. For this scenario, deploying SSO directly satisfies the requirement for one authentication followed by seamless access across all integrated applications.
B
Multi-Factor Authentication (MFA)
Why it fails: MFA requires a second verification factor (like a TOTP code or FIDO2 key) at initial sign-in, but it does not create or propagate a shared session across multiple applications. Even after MFA succeeds, each app that doesn't participate in the same Entra ID session will still prompt for credentials or its own MFA challenge. Thus, MFA strengthens security but fails to remove the repeated authentication prompts the user wants to eliminate.
C
Conditional Access
Why it fails: Conditional Access evaluates signals (user, device, location, risk) to enforce access policies such as blocking or requiring MFA, but it operates at the policy layer rather than the authentication session layer. It can manage when a session is allowed or challenged, yet it does not generate a single-sign-on token stream that carries identity across apps. Therefore, it can refine SSO but cannot itself replace the need for a shared authentication session.
D
Identity Protection
Why it fails: Identity Protection uses machine learning to detect compromised identities and risky sign-ins, triggering automated responses like forced password resets or conditional access policies. It is a risk-assessment and remediation engine, not an authentication protocol or session manager, so it does nothing to suppress the repeated authentication prompts between applications. Its role is to mitigate threats, not to federate identity for seamless access.

Question 2hardmultiple choice

A company is designing a solution for a data analytics workload. The company receives streaming data from multiple sources, including IoT devices and social media feeds. The data must be ingested, processed in real-time, and stored for historical analysis. The company also wants to use Power BI to create real-time dashboards from the streaming data. You need to recommend a data pipeline architecture. What should you include?

Trap 1: Use Azure IoT Hub for ingestion, Azure Stream Analytics for…

Azure IoT Hub is purpose-built for connecting and managing IoT devices, providing device identities, twin metadata, and protocol support (MQTT, AMQPS, HTTPS) tailored to device telemetry, not for ingesting arbitrary social media feeds or public APIs. While Stream Analytics can process real-time data, using IoT Hub as the entry point for a non-IoT workload is architecturally incorrect because it lacks the native event ingestion, throughput partitioning, and ecosystem connectors (e.g., no Kafka-compatible endpoint) designed for high-volume event streaming from sources like Twitter or Facebook.

Trap 2: Use Azure Event Hubs for ingestion, Azure Data Lake Analytics for…

Azure Data Lake Analytics is a batch analytics service that uses U-SQL to run on-demand jobs over large datasets; it is not a real-time stream processing engine and introduces minutes-to-hours of inherent latency. Replacing Stream Analytics with Data Lake Analytics would make the pipeline unsuitable for a dashboard that requires up-to-the-minute social media analytics, even if Event Hubs ingests the events efficiently and Power BI can display the results. The critical flaw is the batch processing model, which cannot continuously transform streaming data with low latency.

Trap 3: Use Azure Event Hubs for ingestion, Azure Synapse Analytics for…

Azure Synapse Analytics is an enterprise analytics service that combines SQL data warehousing, Apache Spark pools, and data integration, but it is fundamentally designed for batch-oriented, interactive, and large-scale analytics over stored data, not for low-latency event-by-event processing of a live social media stream. Using Synapse in place of Stream Analytics would require either writing custom streaming logic (e.g., Spark Structured Streaming) which is not a native Synapse pipeline component, or landing Event Hubs messages into a table first—introducing latency and complexity that defeats the purpose of a real-time dashboard. The appropriate Synapse role would be store and analyze historical aggregates, not continuously transform an incoming event stream.

A
Use Azure IoT Hub for ingestion, Azure Stream Analytics for processing, and Power BI for dashboards.
Why it fails: Azure IoT Hub is purpose-built for connecting and managing IoT devices, providing device identities, twin metadata, and protocol support (MQTT, AMQPS, HTTPS) tailored to device telemetry, not for ingesting arbitrary social media feeds or public APIs. While Stream Analytics can process real-time data, using IoT Hub as the entry point for a non-IoT workload is architecturally incorrect because it lacks the native event ingestion, throughput partitioning, and ecosystem connectors (e.g., no Kafka-compatible endpoint) designed for high-volume event streaming from sources like Twitter or Facebook.
B
Use Azure Event Hubs for ingestion, Azure Data Lake Analytics for processing, and Power BI for dashboards.
Why it fails: Azure Data Lake Analytics is a batch analytics service that uses U-SQL to run on-demand jobs over large datasets; it is not a real-time stream processing engine and introduces minutes-to-hours of inherent latency. Replacing Stream Analytics with Data Lake Analytics would make the pipeline unsuitable for a dashboard that requires up-to-the-minute social media analytics, even if Event Hubs ingests the events efficiently and Power BI can display the results. The critical flaw is the batch processing model, which cannot continuously transform streaming data with low latency.
C
Use Azure Event Hubs for ingestion, Azure Stream Analytics for real-time processing, and Power BI for dashboards.
This option is the only one that correctly assembles a real-time analytics pipeline: Azure Event Hubs ingests high-throughput, time-ordered event streams (such as social media posts) with low latency and native support for multiple independent consumers; Azure Stream Analytics then queries that stream in-memory using SQL-like temporal windows (e.g., tumbling, hopping, sliding) to aggregate and detect patterns as events arrive; Power BI consumes the Stream Analytics output via its streaming API or pre-aggregated datasets to render live dashboards. Together these three services provide the necessary ingestion speed, continuous processing, and real-time visualization, with no batch layer in the critical path.
D
Use Azure Event Hubs for ingestion, Azure Synapse Analytics for processing, and Power BI for dashboards.
Why it fails: Azure Synapse Analytics is an enterprise analytics service that combines SQL data warehousing, Apache Spark pools, and data integration, but it is fundamentally designed for batch-oriented, interactive, and large-scale analytics over stored data, not for low-latency event-by-event processing of a live social media stream. Using Synapse in place of Stream Analytics would require either writing custom streaming logic (e.g., Spark Structured Streaming) which is not a native Synapse pipeline component, or landing Event Hubs messages into a table first—introducing latency and complexity that defeats the purpose of a real-time dashboard. The appropriate Synapse role would be store and analyze historical aggregates, not continuously transform an incoming event stream.

Question 3mediummultiple choice

A company uses Microsoft Entra ID to manage identities for employees and partners. They need to allow partners to self-service reset their passwords using a mobile app notification. Which feature should you enable?

Trap 1: Microsoft Entra ID Identity Protection

Microsoft Entra ID Identity Protection is not a password reset mechanism; its core purpose is to detect and respond to identity-based risks such as compromised accounts, impossible travel, or leaked credentials. While Identity Protection can automatically trigger actions like requiring multi-factor authentication or blocking access based on risk levels, it does not provide users a portal or workflow to reset their own passwords. Its role is protective and diagnostic, not user-initiated credential recovery, so it fails to meet the stated requirement for self-service password reset.

Trap 2: Microsoft Intune

Microsoft Intune is a cloud-based unified endpoint management service focused on managing devices and applications, not on identity credential operations like password reset. Intune enforces compliance policies, deploys software, and controls device enrollment for Windows, iOS, and Android, but it does not interact with Entra ID's authentication methods to allow a user to reset their directory password. Since the question pertains to an identity-level capability for password self-service, Intune is an incorrect and non-viable choice.

Trap 3: Microsoft Entra ID Privileged Identity Management

Microsoft Entra ID Privileged Identity Management (PIM) is designed to manage, control, and monitor access to privileged administrative roles within Entra ID and Azure resources, providing just-in-time activation and approval workflows. PIM does not include a self-service password reset function; instead, it overshadows role assignments and elevation, which is a separate concern from a user resetting their own forgotten password. Therefore, PIM is irrelevant to the scenario described and cannot fulfill the requirement for SSPR.

A
Microsoft Entra ID Self-Service Password Reset (SSPR)
Microsoft Entra ID Self-Service Password Reset (SSPR) is the correct choice because it directly addresses the requirement for users to reset their own passwords without IT intervention. SSPR works by having users pre-register authentication methods—such as the Microsoft Authenticator mobile app notification, a phone number, or security questions—and then using one of those methods to verify their identity during the reset flow. This feature is tightly integrated with Entra ID and can be configured with Conditional Access policies to enforce appropriate security controls, making it the right identity-based solution for password self-service.
B
Microsoft Entra ID Identity Protection
Why it fails: Microsoft Entra ID Identity Protection is not a password reset mechanism; its core purpose is to detect and respond to identity-based risks such as compromised accounts, impossible travel, or leaked credentials. While Identity Protection can automatically trigger actions like requiring multi-factor authentication or blocking access based on risk levels, it does not provide users a portal or workflow to reset their own passwords. Its role is protective and diagnostic, not user-initiated credential recovery, so it fails to meet the stated requirement for self-service password reset.
C
Microsoft Intune
Why it fails: Microsoft Intune is a cloud-based unified endpoint management service focused on managing devices and applications, not on identity credential operations like password reset. Intune enforces compliance policies, deploys software, and controls device enrollment for Windows, iOS, and Android, but it does not interact with Entra ID's authentication methods to allow a user to reset their directory password. Since the question pertains to an identity-level capability for password self-service, Intune is an incorrect and non-viable choice.
D
Microsoft Entra ID Privileged Identity Management
Why it fails: Microsoft Entra ID Privileged Identity Management (PIM) is designed to manage, control, and monitor access to privileged administrative roles within Entra ID and Azure resources, providing just-in-time activation and approval workflows. PIM does not include a self-service password reset function; instead, it overshadows role assignments and elevation, which is a separate concern from a user resetting their own forgotten password. Therefore, PIM is irrelevant to the scenario described and cannot fulfill the requirement for SSPR.

Question 4easymultiple choice

Your company has a Azure subscription with multiple resource groups. You need to ensure that all resources are tagged with a 'CostCenter' tag. What should you use?

Trap 1: Azure Blueprints

Azure Blueprints is a deprecated orchestration service that bundled Azure Resource Manager templates, policies, role assignments, and other artifacts into a single package. While a blueprint could include a policy definition that enforces tagging rules, the enforcement mechanism itself is still Azure Policy; Blueprints only declared the intended state and assigned the policy. Since Blueprints is now retired, using Azure Policy directly is the correct, current method.

Trap 2: Management Groups

Management Groups provide a hierarchical structure above subscriptions for organizing governance, where you can assign Azure Policies and RBAC roles at scale. However, Management Groups do not themselves enforce tagging rules; they are simply containers. Even if you assign a tag-enforcing policy to a Management Group, it is that policy, not the Management Group, that performs the actual denial or remediation—so this option is incorrect.

Trap 3: Azure RBAC

Azure RBAC (Role-Based Access Control) governs who can perform actions on resources, such as create, modify, or delete them, via role assignments and the control plane. It does not evaluate or enforce resource-level attributes like tags; tags are purely metadata managed by the resource provider. Attempting to enforce tag rules through RBAC is fundamentally a misuse because RBAC lacks the ability to inspect or alter resource properties automatically—it only gates access.

A
Azure Policy
Azure Policy is the correct answer because it is a native governance service that can evaluate and enforce resource properties such as tags at scale. You can define a policy with an effect like 'deny' or 'modify' to either reject non-compliant tags or automatically append missing ones via a remediation task. Unlike RBAC, the policy engine runs independently of access control, directly inspecting each resource for compliance.
B
Azure Blueprints
Why it fails: Azure Blueprints is a deprecated orchestration service that bundled Azure Resource Manager templates, policies, role assignments, and other artifacts into a single package. While a blueprint could include a policy definition that enforces tagging rules, the enforcement mechanism itself is still Azure Policy; Blueprints only declared the intended state and assigned the policy. Since Blueprints is now retired, using Azure Policy directly is the correct, current method.
C
Management Groups
Why it fails: Management Groups provide a hierarchical structure above subscriptions for organizing governance, where you can assign Azure Policies and RBAC roles at scale. However, Management Groups do not themselves enforce tagging rules; they are simply containers. Even if you assign a tag-enforcing policy to a Management Group, it is that policy, not the Management Group, that performs the actual denial or remediation—so this option is incorrect.
D
Azure RBAC
Why it fails: Azure RBAC (Role-Based Access Control) governs who can perform actions on resources, such as create, modify, or delete them, via role assignments and the control plane. It does not evaluate or enforce resource-level attributes like tags; tags are purely metadata managed by the resource provider. Attempting to enforce tag rules through RBAC is fundamentally a misuse because RBAC lacks the ability to inspect or alter resource properties automatically—it only gates access.

Question 5hardmulti select

Your organization has multiple Azure subscriptions and uses Azure Blueprints to enforce governance. You need to design a blueprint that includes role assignments, policy assignments, and resource groups. Which THREE components can be included in an Azure Blueprint? (Choose three.)

Trap 1: Management group

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.

Trap 2: Subscription

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.

A
Management group
Why it fails: 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.
B
Role assignments
Role assignments in Azure Blueprints are artifacts that specify which Azure RBAC role (e.g., Contributor, Reader, Owner) is granted to a named user, group, or service principal at the blueprint's assigned scope. When the blueprint is assigned, these assignments are created automatically, enabling consistent identity-based access control across multiple subscriptions. For example, a blueprint can assign the 'Security Reader' role to a central security team in every subscription, ensuring uniform visibility without manual configuration.
C
Policy assignment
Policy assignments are blueprint artifacts that attach an Azure Policy definition to the scope, enforcing compliance requirements such as allowed resource locations, tagging rules, or resource SKU restrictions. They enable an organization to guarantee that all resources created under an assigned subscription adhere to the same governance standards. Unlike role assignments, which control who can act, policy assignments control what actions and resources are permitted, providing a non-identity-based layer of guardrails.
D
Subscription
Why it fails: 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.
E
ARM template
ARM templates are declarative JSON or Bicep files that define Azure resources and their configurations, and they can be embedded into a blueprint definition as artifacts to provision infrastructure like storage accounts, VMs, or virtual networks. Blueprints orchestrate the deployment of these templates in a defined order, often alongside RBAC and policy artifacts, to deliver a complete, repeatable environment. This makes ARM template artifacts a powerful way to ensure that the same infrastructure is rolled out identically across all subscriptions without relying on manual deployment scripts.

Question 6easymultiple choice

A company uses Microsoft Entra ID (Microsoft Entra ID). They want to enable users to reset their own passwords without contacting the help desk. They also want to enforce multi-factor authentication (MFA) during the password reset process. Which Microsoft Entra ID feature should they enable?

Trap 1: Microsoft Entra ID Identity Protection

Microsoft Entra ID Identity Protection is a risk-detection service that analyzes sign-in events and user behavior for signals such as leaked credentials, impossible travel, and anonymous IP addresses. While it can trigger a Conditional Access policy that forces a password change for users flagged with high risk, the actual reset is performed by SSPR after the user authenticates—Identity Protection does not provide a self-service portal or manage the authentication-method verification. Thus, enabling Identity Protection alone cannot satisfy a requirement for users to reset their own passwords; it only identifies risk and triggers remediation that depends on a different feature.

Trap 2: Microsoft Entra ID Privileged Identity Management (PIM)

Privileged Identity Management (PIM) provides just-in-time privileged role activation and access reviews, not self-service password reset or MFA enforcement during that reset. It is tempting because PIM does enforce MFA for activating elevated roles, which might appear to satisfy the MFA requirement. However, the scenario demands MFA specifically during the password reset flow, which PIM does not control; that function belongs to Microsoft Entra ID’s combined registration and self-service password reset (SSPR) policy.

Trap 3: Microsoft Entra ID Conditional Access

Conditional Access is a policy engine in Microsoft Entra ID that applies real-time conditions—such as user location, device compliance, application, and sign-in risk—to allow or deny access to cloud apps. It can be used to require MFA when a user opens the password-reset portal, but it does not contain the password-reset workflow or the logic that verifies a user's registered authentication methods. Since the scenario is about enabling users to reset their own passwords, not just wrapping an additional policy around an existing sign-in, Conditional Access lacks the actual reset capability and is therefore not the correct answer.

A
Microsoft Entra ID Identity Protection
Why it fails: Microsoft Entra ID Identity Protection is a risk-detection service that analyzes sign-in events and user behavior for signals such as leaked credentials, impossible travel, and anonymous IP addresses. While it can trigger a Conditional Access policy that forces a password change for users flagged with high risk, the actual reset is performed by SSPR after the user authenticates—Identity Protection does not provide a self-service portal or manage the authentication-method verification. Thus, enabling Identity Protection alone cannot satisfy a requirement for users to reset their own passwords; it only identifies risk and triggers remediation that depends on a different feature.
B
Microsoft Entra ID Privileged Identity Management (PIM)
Why it fails: Privileged Identity Management (PIM) provides just-in-time privileged role activation and access reviews, not self-service password reset or MFA enforcement during that reset. It is tempting because PIM does enforce MFA for activating elevated roles, which might appear to satisfy the MFA requirement. However, the scenario demands MFA specifically during the password reset flow, which PIM does not control; that function belongs to Microsoft Entra ID’s combined registration and self-service password reset (SSPR) policy.
C
Microsoft Entra ID Self-Service Password Reset (SSPR)
SSPR is the Microsoft Entra ID feature purpose-built for end users to unlock or reset their own passwords without helpdesk intervention, and it can enforce multi-factor authentication as part of the reset flow. When combined with the combined registration experience, users register their MFA methods once, and administrators can require two or more verification methods in the SSPR policy, meaning the user must prove possession of multiple factors before the password is changed. This directly satisfies both the need for self-service reset and the need to enforce MFA during that reset, because the verification gate is an integral part of SSPR itself.
D
Microsoft Entra ID Conditional Access
Why it fails: Conditional Access is a policy engine in Microsoft Entra ID that applies real-time conditions—such as user location, device compliance, application, and sign-in risk—to allow or deny access to cloud apps. It can be used to require MFA when a user opens the password-reset portal, but it does not contain the password-reset workflow or the logic that verifies a user's registered authentication methods. Since the scenario is about enabling users to reset their own passwords, not just wrapping an additional policy around an existing sign-in, Conditional Access lacks the actual reset capability and is therefore not the correct answer.

Question 7mediummultiple choice

You are designing a governance strategy for Azure resources. Your organization has multiple departments, each with its own set of Azure subscriptions. You need to enforce consistent policies across all subscriptions, such as allowed resource locations and required tags, while allowing departments to manage their own resources within those constraints. Which Azure service should you use?

Trap 1: Azure Blueprints

Azure Blueprints was a declarative orchestration service that packaged resource groups, ARM templates, policies, and role assignments into a single blueprint artifact. However, Microsoft deprecated Azure Blueprints in July 2024, directing customers to adopt Azure Policy for compliance enforcement and Deployment Stacks/ARM templates for repeatable deployments. Because Blueprints could only assign policies at creation time and did not itself evaluate ongoing compliance, it is not the correct tool for a continuous resource governance strategy.

Trap 2: Azure Management Groups

Azure Management Groups are hierarchical containers for organizing subscriptions, allowing you to cascade RBAC role assignments and policy definitions down to child subscriptions. While they are a necessary component of a governance architecture, they do not themselves evaluate or enforce any rule—they only act as a scope where policies and roles can be placed. Therefore, a management group alone cannot govern resource configuration; it merely provides the organizational structure.

Trap 3: Azure Role-Based Access Control (RBAC)

Azure Role-Based Access Control (RBAC) controls which security principals can perform specific actions on Azure resources through role assignments in a 'who can do what' model. It does not inspect, validate, or enforce the actual configuration of a resource, such as its public network access, encryption settings, or tagging. RBAC is essential for least-privilege access, but it complements Azure Policy rather than replacing it, because it cannot detect or block a mis-configured resource if the user has permission to deploy it.

A
Azure Blueprints
Why it fails: Azure Blueprints was a declarative orchestration service that packaged resource groups, ARM templates, policies, and role assignments into a single blueprint artifact. However, Microsoft deprecated Azure Blueprints in July 2024, directing customers to adopt Azure Policy for compliance enforcement and Deployment Stacks/ARM templates for repeatable deployments. Because Blueprints could only assign policies at creation time and did not itself evaluate ongoing compliance, it is not the correct tool for a continuous resource governance strategy.
B
Azure Policy
Azure Policy is the correct choice because it centralizes enforcement of resource governance rules across management groups, subscriptions, and resource groups. It evaluates resources against policy definitions using effects such as Deny, Audit, Modify, and DeployIfNotExists, and it continuously scans for drift, not just at deployment time. This lets you enforce tagging standards, restrict resource types and locations, and auto-remediate non-compliant configurations with managed identities.
C
Azure Management Groups
Why it fails: Azure Management Groups are hierarchical containers for organizing subscriptions, allowing you to cascade RBAC role assignments and policy definitions down to child subscriptions. While they are a necessary component of a governance architecture, they do not themselves evaluate or enforce any rule—they only act as a scope where policies and roles can be placed. Therefore, a management group alone cannot govern resource configuration; it merely provides the organizational structure.
D
Azure Role-Based Access Control (RBAC)
Why it fails: Azure Role-Based Access Control (RBAC) controls which security principals can perform specific actions on Azure resources through role assignments in a 'who can do what' model. It does not inspect, validate, or enforce the actual configuration of a resource, such as its public network access, encryption settings, or tagging. RBAC is essential for least-privilege access, but it complements Azure Policy rather than replacing it, because it cannot detect or block a mis-configured resource if the user has permission to deploy it.

Question 8hardmultiple choice

You are designing a storage solution for a healthcare application that stores patient records. The solution must meet the following requirements: - Support for both structured and unstructured data. - Provide low-latency access to frequently accessed data. - Automatically move cold data to a lower-cost tier. - Encrypt data at rest using customer-managed keys. Which combination of Azure services should you recommend?

Trap 1: Azure Table Storage for structured data and Azure Blob Storage for…

While Blob Storage adequately handles unstructured data with lifecycle management and tiering, Azure Table Storage lacks automatic tiering capabilities, meaning structured data cannot be cost-effectively moved between hot and cool tiers without custom solutions. Additionally, Table Storage offers limited query flexibility and secondary indexes compared to other Azure data services, making it a suboptimal fit for healthcare structured data that may require complex queries. This combination fails to fully leverage Azure's built-in cost management features for structured data.

Trap 2: Azure Files for unstructured data and Azure SQL Database for…

Azure Files lacks lifecycle management for automatic tiering, so unstructured data would remain on hot storage and increase costs; it is designed for file shares, not large-scale analytical data, and has slower access latency than Blob Storage for similar media. Although Azure SQL Database offers robust relational capabilities, it does not support automatic tiering to cold storage for structured healthcare data, requiring manual scaling or custom archiving. This pairing addresses the data types but fails to deliver the cost-optimizing lifecycle policies that the healthcare solution needs.

Trap 3: Azure Blob Storage for unstructured data and Azure SQL Database for…

While Blob Storage offers lifecycle tiering for unstructured data, Azure SQL Database does not support automatic tiering to cold storage—it lacks built-in lifecycle policies to move older structured data to a lower-cost tier without custom scripting or offloading data to Blob Storage. For a healthcare application, structured data volumes can grow quickly, and without automatic tiering, you will incur higher storage costs on premium SQL storage. Azure SQL Database also has limited elastic scaling for mixed workloads compared with a purpose-built NoSQL service, making Cosmos DB a better fit for low-latency structured data.

A
Azure Table Storage for structured data and Azure Blob Storage for unstructured data
Why it fails: While Blob Storage adequately handles unstructured data with lifecycle management and tiering, Azure Table Storage lacks automatic tiering capabilities, meaning structured data cannot be cost-effectively moved between hot and cool tiers without custom solutions. Additionally, Table Storage offers limited query flexibility and secondary indexes compared to other Azure data services, making it a suboptimal fit for healthcare structured data that may require complex queries. This combination fails to fully leverage Azure's built-in cost management features for structured data.
B
Azure Files for unstructured data and Azure SQL Database for structured data
Why it fails: Azure Files lacks lifecycle management for automatic tiering, so unstructured data would remain on hot storage and increase costs; it is designed for file shares, not large-scale analytical data, and has slower access latency than Blob Storage for similar media. Although Azure SQL Database offers robust relational capabilities, it does not support automatic tiering to cold storage for structured healthcare data, requiring manual scaling or custom archiving. This pairing addresses the data types but fails to deliver the cost-optimizing lifecycle policies that the healthcare solution needs.
C
Azure Blob Storage for unstructured data and Azure Cosmos DB for structured data
Azure Blob Storage provides multiple access tiers and lifecycle management policies, enabling automated movement of unstructured data (e.g., medical images, text reports) to cool or archive storage based on age, significantly reducing costs. Azure Cosmos DB offers single-digit millisecond read/write latency for structured healthcare data, with guaranteed throughput and global distribution, which is essential for electronic health records and real-time patient monitoring. Both services support customer-managed keys (CMK) for encryption at rest, meeting the healthcare industry's strict compliance and security requirements.
D
Azure Blob Storage for unstructured data and Azure SQL Database for structured data
Why it fails: While Blob Storage offers lifecycle tiering for unstructured data, Azure SQL Database does not support automatic tiering to cold storage—it lacks built-in lifecycle policies to move older structured data to a lower-cost tier without custom scripting or offloading data to Blob Storage. For a healthcare application, structured data volumes can grow quickly, and without automatic tiering, you will incur higher storage costs on premium SQL storage. Azure SQL Database also has limited elastic scaling for mixed workloads compared with a purpose-built NoSQL service, making Cosmos DB a better fit for low-latency structured data.

Read the full DNS explanation →

Question 9mediummultiple choice

A company runs a multi-tier application on Azure VMs. The application has front-end and back-end VMs that must be started in a specific order during failover (front-end first, then back-end). The company uses Azure Site Recovery to replicate to a secondary region. After failover, they also need to run custom PowerShell scripts to update DNS records. Which Azure Site Recovery feature should they configure?

Trap 1: Recovery plan with manual steps

A recovery plan with only manual steps depends on a human operator to remember and execute the exact startup order for the web, app, and data tiers and to run custom scripts by hand during a live disaster. This human intervention lengthens RTO, is prone to errors or skipped dependencies, and cannot guarantee that scripts are executed at the correct moment in the failover sequence. In contrast, a recovery plan with automation runbooks executes the same steps automatically the instant failover occurs, so this option fails both the ordering and scripting requirements.

Trap 2: Failover with network mapping

Failover with network mapping only lets you specify which Azure virtual network each VM's NIC should connect to after failover; it does not influence the order in which tiers start or run any custom preparation scripts. While mapping to the correct VNet is necessary for connectivity, it is completely orthogonal to sequencing and script execution. A VM can have the correct network mapping yet still come up before its database dependency is ready, so this option does not meet the requirements.

Trap 3: Test failover with isolation

Test failover with isolation is designed for disaster-recovery drills: it creates a network-isolated copy of the replicated VMs so the test does not affect the production site or the actual recovery plan. It validates that the replicated images and settings are healthy, but it does not define the production failover startup sequence, nor does it execute custom scripts in the real failover workflow. Relying only on test failover as the recovery strategy would still require manual steps and incorrect dependency start order in a genuine outage.

A
Recovery plan with manual steps
Why it fails: A recovery plan with only manual steps depends on a human operator to remember and execute the exact startup order for the web, app, and data tiers and to run custom scripts by hand during a live disaster. This human intervention lengthens RTO, is prone to errors or skipped dependencies, and cannot guarantee that scripts are executed at the correct moment in the failover sequence. In contrast, a recovery plan with automation runbooks executes the same steps automatically the instant failover occurs, so this option fails both the ordering and scripting requirements.
B
Recovery plan with automation runbooks and order groups
Recovery plans support order groups, so the web tier, application tier, and database tier can be assigned to separate groups that start strictly in the specified sequence. Automation runbooks can be attached as pre-action or post-action steps for each group, which lets you run custom scripts to reconfigure connections, update DNS, or mount storage right after each dependency is available. This combined capability not only satisfies the stated startup-order and script requirements but also makes failover predictable and fully automated.
C
Failover with network mapping
Why it fails: Failover with network mapping only lets you specify which Azure virtual network each VM's NIC should connect to after failover; it does not influence the order in which tiers start or run any custom preparation scripts. While mapping to the correct VNet is necessary for connectivity, it is completely orthogonal to sequencing and script execution. A VM can have the correct network mapping yet still come up before its database dependency is ready, so this option does not meet the requirements.
D
Test failover with isolation
Why it fails: Test failover with isolation is designed for disaster-recovery drills: it creates a network-isolated copy of the replicated VMs so the test does not affect the production site or the actual recovery plan. It validates that the replicated images and settings are healthy, but it does not define the production failover startup sequence, nor does it execute custom scripts in the real failover workflow. Relying only on test failover as the recovery strategy would still require manual steps and incorrect dependency start order in a genuine outage.

Question 10hardmulti select

You are designing a governance and compliance solution for a large Azure environment with multiple subscriptions. The solution must enforce tagging policies, restrict resource types, and ensure compliance with regulatory standards. Which THREE Azure services or features should you use? (Choose three.)

Trap 1: Azure Resource Graph

Azure Resource Graph is a query engine that enables efficient exploration of resource properties across subscriptions, but it performs no enforcement or mutation. While it can be used to audit current state (e.g., find un-tagged VMs), it cannot assign policies, deny deployments, or apply compliance remediations. Its role is discovery and inventory, not governance enforcement.

Trap 2: Azure Cost Management

Azure Cost Management is a financial operations service centered on monitoring, analyzing, and optimizing cloud spending, with capabilities such as budgets, anomaly detection, and cost allocation. Although it can trigger alerts or budgets, it operates entirely in the cost domain and cannot define or enforce resource configuration rules, tagging standards, or allowed resource types. Thus it does not address governance/compliance enforcement.

A
Azure Resource Graph
Why it fails: Azure Resource Graph is a query engine that enables efficient exploration of resource properties across subscriptions, but it performs no enforcement or mutation. While it can be used to audit current state (e.g., find un-tagged VMs), it cannot assign policies, deny deployments, or apply compliance remediations. Its role is discovery and inventory, not governance enforcement.
B
Azure Management Groups
Azure Management Groups provide a hierarchical structure above subscriptions, allowing you to organize and govern enterprise subscription fleets at scale. Policies and role-based access control assignments placed on a management group are inherited by all descendant subscriptions and resource groups, enabling consistent compliance baselining. They are fundamental for applying governance in a multi-subscription enterprise.
C
Azure Cost Management
Why it fails: Azure Cost Management is a financial operations service centered on monitoring, analyzing, and optimizing cloud spending, with capabilities such as budgets, anomaly detection, and cost allocation. Although it can trigger alerts or budgets, it operates entirely in the cost domain and cannot define or enforce resource configuration rules, tagging standards, or allowed resource types. Thus it does not address governance/compliance enforcement.
D
Azure Blueprints (or Policy Initiatives)
Azure Blueprints (or Policy Initiatives) support the packaging of Azure Policy definitions, RBAC role assignments, and Azure Resource Manager templates into a single deployable artifact for compliance. By orchestrating these components together, they enable repeatable, audited provisioning of governed environments. Blueprints are deprecated in favor of deployment stacks and initiative definitions, but the concept remains a valid compliance packaging tool. If referring to Policy Initiatives, they group policies to achieve a specific compliance goal.
E
Azure Policy
Azure Policy is the enforcement engine that evaluates resources for compliance with rules, applying effects such as deny, audit, append, and modify. It can enforce tagging conventions, restrict allowed resource types/locations, and automatically remediate non-compliant resources at scale. Unlike query-based or cost-based tools, Azure Policy actively governs resource state and enforces organizational standards.

Read the full DNS explanation →

Question 11mediummultiple choice

Your company has an Azure subscription with multiple virtual networks connected via VNet peering. You need to design a solution to allow VMs in different peered VNets to resolve each other's private IP addresses using custom DNS suffixes. The solution must minimize administrative overhead. What should you implement?

Trap 1: Deploy custom DNS servers on Azure VMs and configure VNets to use…

Deploying custom DNS servers on Azure VMs introduces significant administrative overhead because you must manually create and manage DNS records, implement high availability for the DNS service, and patch/update the underlying VMs. Since these servers also reside in the VNet, you need conditional forwarding and careful IP configuration, and they cannot take advantage of Azure’s automatic registration capabilities. Unlike Azure Private DNS Zones, custom DNS servers require ongoing operational effort and do not natively integrate with VNet topology or VM lifecycle events.

Trap 2: Configure Azure DNS to use a custom domain name and update each…

Azure DNS as a service is designed for hosting public DNS zones and resolving internet-facing domain names, not for resolving private IP addresses of VMs inside a VNet. Simply applying a custom domain suffix to each VM does not create any A records or enable name resolution; the VMs still rely on Azure's internal DNS or a configured DNS server. For private name resolution across peered VNets, you must use Azure Private DNS Zones with VNet links, which Azure DNS does not provide in its public zone offering.

Trap 3: Use Azure Firewall as a DNS proxy with custom DNS settings.

Azure Firewall's DNS proxy is specifically for outbound traffic—it forwards DNS queries from virtual networks to an upstream DNS server, typically for resolving internet or on-premises names. It does not act as an authoritative or caching DNS server for internal VM hostnames, nor does it generate or manage records for resources in a VNet. Because it lacks zone management, auto-registration, and VNet-link integration, it cannot resolve VM hostnames across peered VNets and therefore is not a substitute for Azure Private DNS Zones.

A
Deploy custom DNS servers on Azure VMs and configure VNets to use those servers.
Why it fails: Deploying custom DNS servers on Azure VMs introduces significant administrative overhead because you must manually create and manage DNS records, implement high availability for the DNS service, and patch/update the underlying VMs. Since these servers also reside in the VNet, you need conditional forwarding and careful IP configuration, and they cannot take advantage of Azure’s automatic registration capabilities. Unlike Azure Private DNS Zones, custom DNS servers require ongoing operational effort and do not natively integrate with VNet topology or VM lifecycle events.
B
Configure Azure DNS to use a custom domain name and update each VM's DNS suffix.
Why it fails: Azure DNS as a service is designed for hosting public DNS zones and resolving internet-facing domain names, not for resolving private IP addresses of VMs inside a VNet. Simply applying a custom domain suffix to each VM does not create any A records or enable name resolution; the VMs still rely on Azure's internal DNS or a configured DNS server. For private name resolution across peered VNets, you must use Azure Private DNS Zones with VNet links, which Azure DNS does not provide in its public zone offering.
C
Use Azure Firewall as a DNS proxy with custom DNS settings.
Why it fails: Azure Firewall's DNS proxy is specifically for outbound traffic—it forwards DNS queries from virtual networks to an upstream DNS server, typically for resolving internet or on-premises names. It does not act as an authoritative or caching DNS server for internal VM hostnames, nor does it generate or manage records for resources in a VNet. Because it lacks zone management, auto-registration, and VNet-link integration, it cannot resolve VM hostnames across peered VNets and therefore is not a substitute for Azure Private DNS Zones.
D
Create an Azure Private DNS Zone linked to each VNet with auto-registration enabled.
Creating an Azure Private DNS Zone and linking it to each VNet with auto-registration enabled provides fully managed, automatic name resolution for VMs across the entire peered network topology. When auto-registration is turned on, Azure automatically creates and maintains A records for every VM as they are generated or deleted, eliminating manual record management. By linking the zone to all VNets involved in peering, nodes in any linked VNet can resolve each other's hostnames using the same private DNS namespace, making this the correct, scalable, and administration-free solution.

Question 12hardmultiple choice

A large enterprise is designing a data analytics platform in Azure that will ingest terabytes of data daily from multiple sources, including IoT devices, social media feeds, and internal databases. The data must be stored in a raw format for future processing, and then transformed and aggregated for reporting. The company requires low-latency querying for real-time dashboards and the ability to run complex batch analytics using Spark. The solution must also provide a unified data governance layer for cataloging and lineage tracking. Which combination of Azure services should the company choose to meet all these requirements with minimal operational overhead?

Trap 1: Azure Cosmos DB, Azure Stream Analytics, and Azure Analysis Services

Azure Cosmos DB is a multi-model NoSQL database engineered for low-latency transactional access and global distribution, not for cost-effective landing and scanning of terabytes of raw analytics data; its request-unit pricing and per-index overhead make large-scale exploratory queries prohibitively expensive. Stream Analytics is a serverless event-processing engine that performs time-windowed streaming computations, so it has no role in batch analytics or historical data transformation. Analysis Services adds a tabular semantic model, but the stack lacks a unified data lake for raw files, a query engine that spans streaming and batch, and the automated data cataloging/lineage needed for enterprise governance.

Trap 2: Azure Blob Storage, Azure HDInsight, and Azure Data Factory

Blob Storage with a flat namespace lacks the hierarchical directory structure, POSIX permissions, and atomic rename semantics of Azure Data Lake Storage Gen2, so it is less suitable as a governed lakehouse foundation. HDInsight is a managed Hadoop/Spark cluster service that still requires you to configure and patch clusters, monitor node health, and wait for scale operations; unlike Synapse, it offers no native serverless SQL endpoint for direct interactive queries on the lake. While Data Factory can orchestrate pipelines, this trio leaves a gap in unified query--you must glue Blob, Hadoop jobs, and ADF together without the integrated data warehouse and Purview-based governance needed for a modern analytics platform.

Trap 3: Azure SQL Database, Azure Databricks, and Azure Data Catalog

Azure SQL Database is a relational OLTP system that enforces schema on write and has storage limits that make it impractical for landing raw, semi-structured files at data-lake scale; you would be forced to model unstructured data before you can explore it. Databricks gives you a strong Spark engine for batch processing and Delta Lake, but it does not by itself provide a fully managed enterprise data catalog with automated lineage scanning across multiple sources--that is the role of Microsoft Purview. Azure Data Catalog is a legacy service that Microsoft is replacing with Purview, so this stack also misses the centralized compliance, classification, and lineage capabilities required in a modern data estate.

A
Azure Cosmos DB, Azure Stream Analytics, and Azure Analysis Services
Why it fails: Azure Cosmos DB is a multi-model NoSQL database engineered for low-latency transactional access and global distribution, not for cost-effective landing and scanning of terabytes of raw analytics data; its request-unit pricing and per-index overhead make large-scale exploratory queries prohibitively expensive. Stream Analytics is a serverless event-processing engine that performs time-windowed streaming computations, so it has no role in batch analytics or historical data transformation. Analysis Services adds a tabular semantic model, but the stack lacks a unified data lake for raw files, a query engine that spans streaming and batch, and the automated data cataloging/lineage needed for enterprise governance.
B
Azure Blob Storage, Azure HDInsight, and Azure Data Factory
Why it fails: Blob Storage with a flat namespace lacks the hierarchical directory structure, POSIX permissions, and atomic rename semantics of Azure Data Lake Storage Gen2, so it is less suitable as a governed lakehouse foundation. HDInsight is a managed Hadoop/Spark cluster service that still requires you to configure and patch clusters, monitor node health, and wait for scale operations; unlike Synapse, it offers no native serverless SQL endpoint for direct interactive queries on the lake. While Data Factory can orchestrate pipelines, this trio leaves a gap in unified query--you must glue Blob, Hadoop jobs, and ADF together without the integrated data warehouse and Purview-based governance needed for a modern analytics platform.
C
Azure SQL Database, Azure Databricks, and Azure Data Catalog
Why it fails: Azure SQL Database is a relational OLTP system that enforces schema on write and has storage limits that make it impractical for landing raw, semi-structured files at data-lake scale; you would be forced to model unstructured data before you can explore it. Databricks gives you a strong Spark engine for batch processing and Delta Lake, but it does not by itself provide a fully managed enterprise data catalog with automated lineage scanning across multiple sources--that is the role of Microsoft Purview. Azure Data Catalog is a legacy service that Microsoft is replacing with Purview, so this stack also misses the centralized compliance, classification, and lineage capabilities required in a modern data estate.
D
Azure Data Lake Storage, Azure Synapse Analytics, and Microsoft Purview
Azure Data Lake Storage Gen2 supplies the required raw landing zone: it combines Blob scalability with a hierarchical namespace and granular POSIX ACLs, enabling governed storage from bytes to petabytes. Azure Synapse Analytics is the analytical core, offering serverless SQL to query raw ADLS files in place, dedicated pools for high-performance warehouse workloads, and built-in Spark for batch transformations--all without separate infrastructure to manage. Microsoft Purview completes the platform by automatically scanning these assets, classifying sensitive data, and capturing end-to-end lineage so downstream analytics can be audited and trusted. Together these services deliver storage, real-time and historical query, batch processing, and governance in one integrated solution.