IAM Policy practice questions

You are designing a governance strategy for an Azure environment that includes multiple subscriptions. The security team requires that all storage accounts must have HTTPS traffic only. Any non-compliant storage account must be automatically remediated. What is the most efficient solution?

Trap 1: Create an Azure Blueprint that includes a policy initiative

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.

Trap 2: Assign a custom RBAC role that denies creation of storage accounts…

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.

Trap 3: Configure Azure Monitor alerts to notify the security team

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.

A
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.
B
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.
C
Use Azure Policy with a DeployIfNotExists effect to enable HTTPS-only traffic
Azure Policy with the DeployIfNotExists effect evaluates every existing resource against the definition and automatically triggers a remediation task to deploy the required configuration — in this case, setting the 'supportsHttpsTrafficOnly' property to true. This effect uses a managed identity to apply the change, and it can be run on-demand via a remediation task or on a schedule, ensuring all non-compliant storage accounts are brought into compliance without manual intervention. This is the only option that provides automated, continuous enforcement and correction for resources already in the subscription.
D
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.

Question 2mediummultiple choice

An organization wants to enforce MFA only when sign-in risk is medium or high. Which Microsoft Entra capability should be used?

Trap 1: Azure RBAC deny assignments only

Azure RBAC deny assignments are designed to enforce resource-level actions, such as blocking a user from creating virtual machines or accessing storage, by overriding role assignments. However, sign-in risk is an authentication-time signal computed by Azure AD Identity Protection before any resource authorization occurs. Deny assignments cannot inspect session risk or trigger MFA; they simply revoke permission to perform specific Azure resource operations.

Trap 2: Access reviews only

Access reviews are a governance tool that periodically audits and recertifies a user's existing entitlements, such as group membership or application access, according to a schedule defined by an owner. They are a manual or semi-automated attestation flow, not a real-time authentication check, and they cannot intercept a sign-in attempt to prompt for MFA. Since sign-in risk is a transient property of the current sign-in event, access reviews cannot enforce risk-based MFA.

Trap 3: Administrative units only

Administrative units are Azure AD containers used to scope administrative role permissions to specific groups of users, letting you delegate management of a subset of the directory. They affect who can manage user accounts or devices, but they do not evaluate authentication events or sign-in risk signals. Without a Conditional Access policy, an administrative unit cannot require MFA or change the sign-in experience.

A
Azure RBAC deny assignments only
Why wrong: Azure RBAC deny assignments are designed to enforce resource-level actions, such as blocking a user from creating virtual machines or accessing storage, by overriding role assignments. However, sign-in risk is an authentication-time signal computed by Azure AD Identity Protection before any resource authorization occurs. Deny assignments cannot inspect session risk or trigger MFA; they simply revoke permission to perform specific Azure resource operations.
B
Conditional Access with Identity Protection risk signals
Conditional Access policies can directly reference Identity Protection sign-in risk levels (low, medium, high) and evaluate them during the authentication event. Configuring a policy to require MFA when sign-in risk is medium or high achieves the exact requirement, while optionally adding a block action for high risk. This is the built-in Azure AD mechanism for dynamic, risk-based step-up authentication.
C
Access reviews only
Why wrong: Access reviews are a governance tool that periodically audits and recertifies a user's existing entitlements, such as group membership or application access, according to a schedule defined by an owner. They are a manual or semi-automated attestation flow, not a real-time authentication check, and they cannot intercept a sign-in attempt to prompt for MFA. Since sign-in risk is a transient property of the current sign-in event, access reviews cannot enforce risk-based MFA.
D
Administrative units only
Why wrong: Administrative units are Azure AD containers used to scope administrative role permissions to specific groups of users, letting you delegate management of a subset of the directory. They affect who can manage user accounts or devices, but they do not evaluate authentication events or sign-in risk signals. Without a Conditional Access policy, an administrative unit cannot require MFA or change the sign-in experience.

Question 3mediummultiple choice

You are designing a governance strategy for Azure resources. The company has multiple departments, each requiring separate cost tracking and policy enforcement. You need to organize resources to align with the departments while minimizing management overhead. What should you use?

Trap 1: Azure Blueprints

Azure Blueprints were a packaging service that bundled templates, policies, and RBAC assignments into a single deployable artifact, but they are deprecated and no longer recommended. Blueprints do not provide a persistent governance hierarchy; they simply orchestrate deployment, whereas management groups offer ongoing, inherited governance. Azure now recommends using management groups combined with policy assignments and deployment stacks as a modern replacement.

Trap 2: Resource tags

Resource tags are key-value pairs attached to resources for metadata, cost allocation, and filtering, but they are not a governance mechanism. Tags do not enforce compliance, provide hierarchical inheritance, or manage access across subscriptions. While policies can require or generate tags, tags themselves cannot organize resources for cross-subscription policy or cost management.

Trap 3: Resource groups

Resource groups are logical containers that group related resources within a single subscription, offering management and lifecycle operations like templates and access control. However, they cannot span multiple subscriptions, do not inherit policies across subscriptions, and lack the organizational hierarchy needed for enterprise-wide governance. Resource groups are operational scopes, not governance structures for the entire Azure environment.

A
Management groups
Management groups provide a hierarchical governance structure above subscriptions, allowing you to apply Azure Policy and RBAC assignments at scale, and aggregate cost data across multiple subscriptions for consolidated billing and compliance. They enable enterprise-level organization of your Azure estate, with policies and governance inherited down through child management groups and subscriptions.
B
Azure Blueprints
Why wrong: Azure Blueprints were a packaging service that bundled templates, policies, and RBAC assignments into a single deployable artifact, but they are deprecated and no longer recommended. Blueprints do not provide a persistent governance hierarchy; they simply orchestrate deployment, whereas management groups offer ongoing, inherited governance. Azure now recommends using management groups combined with policy assignments and deployment stacks as a modern replacement.
C
Resource tags
Why wrong: Resource tags are key-value pairs attached to resources for metadata, cost allocation, and filtering, but they are not a governance mechanism. Tags do not enforce compliance, provide hierarchical inheritance, or manage access across subscriptions. While policies can require or generate tags, tags themselves cannot organize resources for cross-subscription policy or cost management.
D
Resource groups
Why wrong: Resource groups are logical containers that group related resources within a single subscription, offering management and lifecycle operations like templates and access control. However, they cannot span multiple subscriptions, do not inherit policies across subscriptions, and lack the organizational hierarchy needed for enterprise-wide governance. Resource groups are operational scopes, not governance structures for the entire Azure environment.

Question 4easymulti select

Which TWO of the following are benefits of using Azure Policy? (Choose two.)

Trap 1: Manage access control for resources

Azure Policy does not manage access control because it lacks the capability to assign roles or grant user permissions; that is the responsibility of Azure RBAC, which authenticates and authorizes identities via role assignments. Azure Policy only evaluates and enforces resource configuration properties, meaning a user's ability to read, write, or delete a resource remains entirely governed by RBAC, not by policy definitions.

Trap 2: Create new Azure resources based on a template

Azure Policy is an evaluation and enforcement service, not a resource provisioning engine; it does not create virtual machines, storage accounts, or any other Azure resources. Resource creation is performed by Azure Resource Manager through templates, Bicep files, or other deployment tools, while Azure Policy only inspects resources after (or during) deployment to decide whether they comply, possibly denying the operation but never instantiating anything itself.

Trap 3: Automatically remediate non-compliant resources without manual…

While Azure Policy can remediate non-compliant resources using the 'modify' effect or via deployment tasks, this is not automatic for all policies; many policies rely on 'audit' or 'deny' effects, which either log non-compliance or block creation but never correct existing resources. When remediation does occur, it requires an explicit remediation task to be created, which uses a managed identity and is executed as an asynchronous operation, not a transparent and universal automatic process.

A
Assess compliance of resources against defined policies
Azure Policy continuously evaluates existing and newly deployed resources against policy definitions and initiatives, aggregating the results into a compliance dashboard that shows per-policy and per-resource compliance states. This assessment process covers properties like resource types, locations, and configuration settings, enabling organizations to identify drift from corporate standards even after enrollment.
B
Enforce tagging conventions on resources
Azure Policy enforces tagging conventions by defining rules that require specific tags to exist on resources, or that constrain tag values to approved sets. It can also inherit tags from resource groups or subscriptions, and use effects like deny or append to block non-compliant resource creation, while existing resources can be aligned through remediation tasks.
C
Manage access control for resources
Why wrong: Azure Policy does not manage access control because it lacks the capability to assign roles or grant user permissions; that is the responsibility of Azure RBAC, which authenticates and authorizes identities via role assignments. Azure Policy only evaluates and enforces resource configuration properties, meaning a user's ability to read, write, or delete a resource remains entirely governed by RBAC, not by policy definitions.
D
Create new Azure resources based on a template
Why wrong: Azure Policy is an evaluation and enforcement service, not a resource provisioning engine; it does not create virtual machines, storage accounts, or any other Azure resources. Resource creation is performed by Azure Resource Manager through templates, Bicep files, or other deployment tools, while Azure Policy only inspects resources after (or during) deployment to decide whether they comply, possibly denying the operation but never instantiating anything itself.
E
Automatically remediate non-compliant resources without manual intervention
Why wrong: While Azure Policy can remediate non-compliant resources using the 'modify' effect or via deployment tasks, this is not automatic for all policies; many policies rely on 'audit' or 'deny' effects, which either log non-compliance or block creation but never correct existing resources. When remediation does occur, it requires an explicit remediation task to be created, which uses a managed identity and is executed as an asynchronous operation, not a transparent and universal automatic process.

Question 5mediummultiple choice

You are an Azure administrator. The above Azure Policy definition is assigned to a subscription. A developer tries to deploy a Virtual Machine with SKU Standard_DS2_v2. What will happen?

Exhibit

Refer to the exhibit.

```json
{
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Compute/virtualMachines"
        },
        {
          "field": "Microsoft.Compute/virtualMachines/sku.name",
          "like": "Standard_DS*"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Trap 1: The deployment succeeds with a warning logged.

When the Deny effect is triggered, Azure Policy injects a conflict error into the deployment response, so the result is a failed deployment, not a successful one with a warning. Azure Resource Manager doesn't have a 'succeeded with policy warning' outcome for a deny; any policy that blocks a required property is a hard failure. A warning could only appear in compliance reports or activity logs, never as the deployment status.

Trap 2: The VM is created but the SKU is changed to a different series.

Deny effect never alters the requested resource; it only rejects the request if the SKU doesn't match the allowed condition. The resource provider receives the original SKU value, and since the request is denied, there is no VM to resize or change. To automatically replace a denied SKU, you would need a separate Modify or DeployIfNotExists policy with a remediation task, which is not part of the Deny effect.

Trap 3: The deployment succeeds because the policy only audits.

The effect in the policy is Deny, not Audit, so the deployment is blocked, not merely flagged. AuditEffect records the resource as non-compliant after (or while) it is created, but DenyEffect prevents the resource from being created in the first place. The behavior the answer describes would only happen if the assignment had been built with the audit effect.

A
The deployment is denied and an error message is returned.
The policy definition's effect is Deny, so Azure Resource Manager evaluates the VM SKU against the condition before the resource provider accepts the request. When the condition matches, the create or update call is blocked, the deployment status is Failed, and the response contains the policy violation, including the policy name and assignment ID. Because evaluation happens during the PUT request, no VM is ever created or partially provisioned.
B
The deployment succeeds with a warning logged.
Why wrong: When the Deny effect is triggered, Azure Policy injects a conflict error into the deployment response, so the result is a failed deployment, not a successful one with a warning. Azure Resource Manager doesn't have a 'succeeded with policy warning' outcome for a deny; any policy that blocks a required property is a hard failure. A warning could only appear in compliance reports or activity logs, never as the deployment status.
C
The VM is created but the SKU is changed to a different series.
Why wrong: Deny effect never alters the requested resource; it only rejects the request if the SKU doesn't match the allowed condition. The resource provider receives the original SKU value, and since the request is denied, there is no VM to resize or change. To automatically replace a denied SKU, you would need a separate Modify or DeployIfNotExists policy with a remediation task, which is not part of the Deny effect.
D
The deployment succeeds because the policy only audits.
Why wrong: The effect in the policy is Deny, not Audit, so the deployment is blocked, not merely flagged. AuditEffect records the resource as non-compliant after (or while) it is created, but DenyEffect prevents the resource from being created in the first place. The behavior the answer describes would only happen if the assignment had been built with the audit effect.

Question 6mediummultiple choice

Your company has a Microsoft Entra ID tenant with 10,000 users. You are designing an identity governance solution to automate user access reviews for critical applications. The compliance team requires that access reviews be conducted quarterly and that any reviewer who does not respond within 7 days have their decisions auto-approved. You need to implement the solution using Microsoft Entra ID Governance. What should you do?

Trap 1: Use Microsoft Entra Privileged Identity Management (PIM) to require…

PIM is a privileged access management service that provides just-in-time activation for high-privilege roles such as Global Administrator, requiring approval or MFA at the time of activation. It does not perform recurring certifications of standard user access to business applications, nor does it support a 7-day auto-approve fallback for non-responsive reviewers. Since the requirement is about periodic access reviews with automatic approval, PIM cannot fulfill it.

Trap 2: Create an access review with 'Auto deny' after 7 days of no…

Within Entra ID access reviews, you can specify a default action for reviewers who do not respond; choosing 'auto deny' would automatically remove access after the review deadline if the manager does not respond. However, the requirement explicitly states that access should be approved if no response within 7 days, so auto-deny is the opposite of what's needed. It would cause users to lose access and is therefore incorrect, even though it is a valid configuration option in access reviews.

Trap 3: Create a recurring campaign in Microsoft Purview Compliance Manager.

Microsoft Purview Compliance Manager is a compliance management console that tracks regulatory controls, calculates compliance scores, and provides improvement actions; it is not an access governance tool. It cannot create user access review workflows, assign managers as reviewers, or configure an automatic approve/deny decision based on reviewer inactivity. Access reviews are implemented in Microsoft Entra ID governance, so this option does not meet the requirement.

A
Use Microsoft Entra Privileged Identity Management (PIM) to require activation for access to critical applications.
Why wrong: PIM is a privileged access management service that provides just-in-time activation for high-privilege roles such as Global Administrator, requiring approval or MFA at the time of activation. It does not perform recurring certifications of standard user access to business applications, nor does it support a 7-day auto-approve fallback for non-responsive reviewers. Since the requirement is about periodic access reviews with automatic approval, PIM cannot fulfill it.
B
Create an access review with 'Auto deny' after 7 days of no response.
Why wrong: Within Entra ID access reviews, you can specify a default action for reviewers who do not respond; choosing 'auto deny' would automatically remove access after the review deadline if the manager does not respond. However, the requirement explicitly states that access should be approved if no response within 7 days, so auto-deny is the opposite of what's needed. It would cause users to lose access and is therefore incorrect, even though it is a valid configuration option in access reviews.
C
Create a recurring campaign in Microsoft Purview Compliance Manager.
Why wrong: Microsoft Purview Compliance Manager is a compliance management console that tracks regulatory controls, calculates compliance scores, and provides improvement actions; it is not an access governance tool. It cannot create user access review workflows, assign managers as reviewers, or configure an automatic approve/deny decision based on reviewer inactivity. Access reviews are implemented in Microsoft Entra ID governance, so this option does not meet the requirement.
D
Create an access review with 'Auto approve' after 7 days of no response.
Configuring an access review with the auto-approve fallback directly aligns with the business rule: the review is created in Microsoft Entra ID, managers are assigned as reviewers, and a recurrence schedule is set. When the 7-day response window lapses, the system automatically applies an 'approve' decision for each pending access, preserving user access. This ensures that access is recertified periodically without being disrupted by manager delays, satisfying the requirement precisely.

Question 7mediummultiple choice

A company uses Microsoft Entra ID and wants to enforce that all users must use multi-factor authentication (MFA) when accessing sensitive applications. However, they want to exclude users when connecting from the corporate office IP range and only allow access from devices that are compliant with Intune policies. Which Microsoft Entra ID feature should they use to create this policy?

Trap 1: Microsoft Entra ID Identity Protection

Microsoft Entra ID Identity Protection is a risk-based detection engine that evaluates sign-in risk and user risk using signals like anonymous IP addresses, atypical travel, or leaked credentials. While it can automatically require MFA in response to detected risk, it cannot enforce MFA based on static, administratively defined conditions such as excluding your corporate IP range or requiring a specific device compliance status. The described scenario is a deterministic access policy, not a risk-based response, so Identity Protection is not the correct tool.

Trap 2: Microsoft Entra ID Privileged Identity Management

Microsoft Entra ID Privileged Identity Management (PIM) is designed for just-in-time, time-bound, and approval-based activation of elevated roles such as Global Administrator or Role-Based Access Control assignments. It manages the lifecycle of privileged role assignments and provides alerts and access reviews for those roles, but it does not apply authentication requirements to end-user access of applications. Requiring MFA for general sensitive app access while excluding certain networks is strictly an authentication policy, which falls outside PIM's scope.

Trap 3: Microsoft Entra ID Identity Governance

Microsoft Entra ID Identity Governance focuses on access lifecycle management through entitlement management, access certifications, and access reviews to answer 'who should have access and for how long.' It does not evaluate authentication context in real time; it is not an authentication policy enforcement point. The scenario mandates MFA and device compliance at sign-in time, which is a session control condition, not an access-governance decision about resource membership or ongoing access eligibility.

A
Microsoft Entra ID Identity Protection
Why wrong: Microsoft Entra ID Identity Protection is a risk-based detection engine that evaluates sign-in risk and user risk using signals like anonymous IP addresses, atypical travel, or leaked credentials. While it can automatically require MFA in response to detected risk, it cannot enforce MFA based on static, administratively defined conditions such as excluding your corporate IP range or requiring a specific device compliance status. The described scenario is a deterministic access policy, not a risk-based response, so Identity Protection is not the correct tool.
B
Microsoft Entra ID Privileged Identity Management
Why wrong: Microsoft Entra ID Privileged Identity Management (PIM) is designed for just-in-time, time-bound, and approval-based activation of elevated roles such as Global Administrator or Role-Based Access Control assignments. It manages the lifecycle of privileged role assignments and provides alerts and access reviews for those roles, but it does not apply authentication requirements to end-user access of applications. Requiring MFA for general sensitive app access while excluding certain networks is strictly an authentication policy, which falls outside PIM's scope.
C
Microsoft Entra ID Conditional Access
Conditional Access policies allow you to specify conditions (e.g., IP location, device compliance) and controls (e.g., require MFA, block access). This enables the described scenario: require MFA for sensitive apps, but exclude corporate IP range and require compliant device.
D
Microsoft Entra ID Identity Governance
Why wrong: Microsoft Entra ID Identity Governance focuses on access lifecycle management through entitlement management, access certifications, and access reviews to answer 'who should have access and for how long.' It does not evaluate authentication context in real time; it is not an authentication policy enforcement point. The scenario mandates MFA and device compliance at sign-in time, which is a session control condition, not an access-governance decision about resource membership or ongoing access eligibility.

Question 8mediummultiple choice

A company stores large amounts of log data in Azure Blob Storage. Logs are accessed frequently for the first 30 days, then rarely accessed afterward, but must be retained for 7 years for compliance. The company wants to minimize storage costs. They need to configure automatic data movement and retention policies. Which combination of Azure Blob Storage access tiers and lifecycle management policy should they use?

Trap 1: Use Hot tier for 30 days, then use Cool tier for 7 years, with a…

Using the Cool tier for a seven-year retention period overlooks that Archive tier provides a substantially lower storage price for data that is no longer actively accessed. While the lifecycle rule correctly automates deletion after 7 years, the Cool tier's storage rate is significantly higher than Archive for long-lived, rarely read data, making this solution unnecessarily expensive over the retention period. Since the data is only frequently accessed for the first 30 days, Cool tier is an economically suboptimal middle ground for the remaining 6+ years.

Trap 2: Use Cool tier for 30 days, then use Archive tier for 7 years, no…

Choosing Cool tier for the initial 30 days is cost-inefficient because Cool tier has higher per-GB read and retrieval costs than Hot tier, which already offers the lowest access costs for frequently used data. Additionally, without a lifecycle rule, the data will never be automatically deleted after 7 years, resulting in ongoing storage charges indefinitely. The correct pattern pairs a Hot tier for frequent reads with an Archive tier for infrequent, long-term retention, coupled with a lifecycle policy that deletes the blob at a specific age.

Trap 3: Use Archive tier immediately, with a lifecycle rule to delete after…

Placing data directly into Archive tier fails to account for the high frequency of access during the first 30 days; Archive tier's retrieval latency (typically minutes to hours) and per-GB read charges make it inappropriate for active use. Although the lifecycle rule handles the eventual deletion correctly, immediate archiving would force repeated expensive rehydration operations for the very data users need most often. A tiering strategy must match early access patterns with Hot tier, then transition to Archive only once the data becomes rarely accessed.

A
Use Hot tier for 30 days, then use Cool tier for 7 years, with a lifecycle rule to delete after 7 years.
Why wrong: Using the Cool tier for a seven-year retention period overlooks that Archive tier provides a substantially lower storage price for data that is no longer actively accessed. While the lifecycle rule correctly automates deletion after 7 years, the Cool tier's storage rate is significantly higher than Archive for long-lived, rarely read data, making this solution unnecessarily expensive over the retention period. Since the data is only frequently accessed for the first 30 days, Cool tier is an economically suboptimal middle ground for the remaining 6+ years.
B
Use Hot tier for 30 days, then use Archive tier for the remaining period, with a lifecycle rule to delete after 7 years.
Hot tier provides low-latency access during the frequent access period. Archive tier provides the lowest storage cost for data that is rarely accessed. A lifecycle policy can automatically move data from Hot to Archive after 30 days and delete it after 7 years.
C
Use Cool tier for 30 days, then use Archive tier for 7 years, no lifecycle rule needed.
Why wrong: Choosing Cool tier for the initial 30 days is cost-inefficient because Cool tier has higher per-GB read and retrieval costs than Hot tier, which already offers the lowest access costs for frequently used data. Additionally, without a lifecycle rule, the data will never be automatically deleted after 7 years, resulting in ongoing storage charges indefinitely. The correct pattern pairs a Hot tier for frequent reads with an Archive tier for infrequent, long-term retention, coupled with a lifecycle policy that deletes the blob at a specific age.
D
Use Archive tier immediately, with a lifecycle rule to delete after 7 years.
Why wrong: Placing data directly into Archive tier fails to account for the high frequency of access during the first 30 days; Archive tier's retrieval latency (typically minutes to hours) and per-GB read charges make it inappropriate for active use. Although the lifecycle rule handles the eventual deletion correctly, immediate archiving would force repeated expensive rehydration operations for the very data users need most often. A tiering strategy must match early access patterns with Hot tier, then transition to Archive only once the data becomes rarely accessed.

Question 9mediummultiple choice

A company runs a SQL Server database on an Azure VM in West Europe. They need to back up the database daily and retain backups for 7 years for compliance. They also require the ability to restore the database to a secondary Azure region (North Europe) if the primary region fails. They want to minimize operational overhead and costs. Which Azure Backup configuration should they use?

Trap 1: B

Creating a second Recovery Services vault in North Europe and backing up to both vaults substantially increases operational overhead and storage cost because the same SQL Server databases would be protected twice. The SQL IaaS Agent extension registers the VM with a single vault; backing up to a second vault requires a second backup schedule and duplicate metadata, and you still need to enable cross-region restore anyway to meet the DR objective. Azure Backup's built-in CRR already replicates the same vault data to North Europe, so a separate vault adds unnecessary complexity with no additional resilience benefit.

Trap 2: C

Manually copying .bak files (or using SQL Server Managed Backup to a storage account) to a North Europe storage account is a fragile, labor-intensive process that requires custom scripts, scheduling, and monitoring to stay current with the transaction log chain. Unlike Azure Backup, which orchestrates backups, verifies consistency, and manages retention automatically, a manual copy introduces a significant window of data loss between copies, risks corruption or incomplete file sets, and does not provide a native restore experience. This approach is not scalable for production SQL Server workloads and lacks the built-in cross-region restore capabilities that are available with a Recovery Services vault.

Trap 3: D

Azure Site Recovery (ASR) is a disaster-recovery service that replicates entire VMs for failover, not a backup service for SQL Server databases. ASR recovery points are snapshots of the entire VM with limited retention (typically up to 72 hours), and it does not support SQL Server–consistent point-in-time restore or long-term retention of transaction log backups. While ASR could be used alongside Azure Backup, it cannot replace it, and mixing the two does not address the requirement for long-term backup retention with cross-region restore. The correct service for database-level backup, log chains, and retention is Azure Backup, not ASR.

A
A
Azure Backup for SQL Server in an Azure VM securely stores full, differential, and transaction log backups in a Recovery Services vault. You can configure the vault in West Europe as the primary region and enable the Cross-Region Restore (CRR) feature, which replicates the backup data to the paired North Europe region using geo-redundant storage (GRS). This design provides automated SQL-aware backup management, point-in-time restore capability, and the ability to restore databases in North Europe without deploying any additional backup infrastructure or vaults, making it the optimized, cost-effective approach.
B
B
Why wrong: Creating a second Recovery Services vault in North Europe and backing up to both vaults substantially increases operational overhead and storage cost because the same SQL Server databases would be protected twice. The SQL IaaS Agent extension registers the VM with a single vault; backing up to a second vault requires a second backup schedule and duplicate metadata, and you still need to enable cross-region restore anyway to meet the DR objective. Azure Backup's built-in CRR already replicates the same vault data to North Europe, so a separate vault adds unnecessary complexity with no additional resilience benefit.
C
C
Why wrong: Manually copying .bak files (or using SQL Server Managed Backup to a storage account) to a North Europe storage account is a fragile, labor-intensive process that requires custom scripts, scheduling, and monitoring to stay current with the transaction log chain. Unlike Azure Backup, which orchestrates backups, verifies consistency, and manages retention automatically, a manual copy introduces a significant window of data loss between copies, risks corruption or incomplete file sets, and does not provide a native restore experience. This approach is not scalable for production SQL Server workloads and lacks the built-in cross-region restore capabilities that are available with a Recovery Services vault.
D
D
Why wrong: Azure Site Recovery (ASR) is a disaster-recovery service that replicates entire VMs for failover, not a backup service for SQL Server databases. ASR recovery points are snapshots of the entire VM with limited retention (typically up to 72 hours), and it does not support SQL Server–consistent point-in-time restore or long-term retention of transaction log backups. While ASR could be used alongside Azure Backup, it cannot replace it, and mixing the two does not address the requirement for long-term backup retention with cross-region restore. The correct service for database-level backup, log chains, and retention is Azure Backup, not ASR.

Question 10mediummultiple choice

A company stores log data in Azure Blob Storage. The logs are accessed frequently for the first 30 days, then only occasionally for up to 1 year, and after that must be retained for 7 years for compliance purposes. The company wants to minimize storage costs by automatically moving data to cheaper tiers. Which Azure Blob Storage lifecycle management policy should they implement?

Trap 1: Move to Cool tier after 30 days, move to Archive tier after 365…

The flaw is not the tier transitions but the deletion expression: '7 years' is not a valid Azure lifecycle numeric value. Azure lifecycle management rules only accept integers for 'days after creation' or 'days after last modification', so the policy would be rejected at validation time. Using '2555 days' is the correct equivalent for 7 years and removes ambiguity around leap-year intervals; therefore this option fails because the rule cannot be executed as written.

Trap 2: Move to Cool tier after 30 days, move to Archive tier after 30…

Moving to Archive after only 30 days violates the intended access pattern: for the first year logs are accessed occasionally, and Cool tier is designed for that exactly—it offers lower storage cost than Hot while still allowing near-real-time reads. Archive, by contrast, requires rehydration and can add minutes to hours of latency before access. If you transition to Archive at day 30, you'll incur unnecessary retrieval and rehydration costs for every one of the occasional accesses during the remaining 335 days, which is more expensive than leaving the data in Cool.

Trap 3: Move to Archive tier after 30 days, keep in Archive until deletion…

Skipping Cool and placing logs into Archive at day 30 means the most frequently used period (the first 30 days) remains Hot, but from day 31 through day 365, when logs are still occasionally queried, you're hit with Archive's rehydration latency and per-GB retrieval charges. Also, once a blob is in Archive it cannot be read directly; you must 'rehydrate' it, adding operational complexity and cost for each access. The correct sequence is Hot→Cool→Archive, so this option misplaces the first-year data and penalizes normal operational workflows.

A
Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 2555 days
This policy correctly matches the log usage lifecycle: for the first 30 days data remains Hot for frequent queries; from day 30 to day 365 it is moved to Cool because access becomes occasional but still needed; after 365 days it is moved to Archive for long-term compliance while deletion occurs after 2555 days (exactly 7 years). That transition sequence minimizes cost: Hot for active use, Cool for sporadic retrieval with no rehydration fee, and Archive for rarely accessed records, with deletion eliminating any further storage charges. The rule uses numeric day values as Azure requires.
B
Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 7 years
Why wrong: The flaw is not the tier transitions but the deletion expression: '7 years' is not a valid Azure lifecycle numeric value. Azure lifecycle management rules only accept integers for 'days after creation' or 'days after last modification', so the policy would be rejected at validation time. Using '2555 days' is the correct equivalent for 7 years and removes ambiguity around leap-year intervals; therefore this option fails because the rule cannot be executed as written.
C
Move to Cool tier after 30 days, move to Archive tier after 30 days, delete after 2555 days
Why wrong: Moving to Archive after only 30 days violates the intended access pattern: for the first year logs are accessed occasionally, and Cool tier is designed for that exactly—it offers lower storage cost than Hot while still allowing near-real-time reads. Archive, by contrast, requires rehydration and can add minutes to hours of latency before access. If you transition to Archive at day 30, you'll incur unnecessary retrieval and rehydration costs for every one of the occasional accesses during the remaining 335 days, which is more expensive than leaving the data in Cool.
D
Move to Archive tier after 30 days, keep in Archive until deletion after 2555 days
Why wrong: Skipping Cool and placing logs into Archive at day 30 means the most frequently used period (the first 30 days) remains Hot, but from day 31 through day 365, when logs are still occasionally queried, you're hit with Archive's rehydration latency and per-GB retrieval charges. Also, once a blob is in Archive it cannot be read directly; you must 'rehydrate' it, adding operational complexity and cost for each access. The correct sequence is Hot→Cool→Archive, so this option misplaces the first-year data and penalizes normal operational workflows.

Question 11easymultiple choice

A company uses Microsoft Entra ID (Microsoft Entra ID). They want to require multi-factor authentication (MFA) for all users accessing the Azure portal, but do not want MFA to be required for other applications like Office 365. Which Microsoft Entra ID feature should they configure?

Trap 1: Microsoft Entra ID Security defaults

Security defaults enable a tenant-wide baseline that forces MFA for every user and every cloud application, including the Azure portal but also all other apps. There is no way to scope or exclude specific applications, so it fails the requirement of limiting MFA to only the Azure portal. Moreover, enabling Security defaults is mutually exclusive with custom Conditional Access policies, so an organization needing granular per-app control would not use this option.

Trap 2: Microsoft Entra ID Identity Protection

Microsoft Entra ID Identity Protection is a risk-detection engine that evaluates sign-in anomalies (e.g., anonymous IP addresses, atypical travel, or leaked credentials) and assigns a user or sign-in risk level. It cannot itself require MFA for a specific application; instead, its risk signals must be fed into a Conditional Access policy to trigger MFA as a grant control. Because the requirement is to enforce MFA for all Azure portal sign-ins regardless of risk, Identity Protection is too granular and conditional rather than a direct enforcement mechanism.

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

Privileged Identity Management is designed for role-based access governance, offering just-in-time activation of Azure AD and Azure resource roles with the option to require MFA at activation time. It does not apply to all users — only users who have been assigned an eligible privileged role, and it does not protect the initial sign-in to the Azure portal outside of role activation. Thus, it cannot enforce MFA for every user accessing the portal as requested.

A
Microsoft Entra ID Security defaults
Why wrong: Security defaults enable a tenant-wide baseline that forces MFA for every user and every cloud application, including the Azure portal but also all other apps. There is no way to scope or exclude specific applications, so it fails the requirement of limiting MFA to only the Azure portal. Moreover, enabling Security defaults is mutually exclusive with custom Conditional Access policies, so an organization needing granular per-app control would not use this option.
B
Microsoft Entra ID Conditional Access
Conditional Access lets an administrator create a policy that targets the 'Microsoft Azure Management' cloud app, which is the service principal behind the Azure portal, and applies the 'Require MFA' grant control to assigned users or groups. This scopes MFA enforcement to Azure portal sign-ins only, leaving other applications with their own separate access policies. It is the appropriate mechanism because it directly maps the exact resource (Azure portal) to the required control (MFA) while allowing granular exclusions and conditions.
C
Microsoft Entra ID Identity Protection
Why wrong: Microsoft Entra ID Identity Protection is a risk-detection engine that evaluates sign-in anomalies (e.g., anonymous IP addresses, atypical travel, or leaked credentials) and assigns a user or sign-in risk level. It cannot itself require MFA for a specific application; instead, its risk signals must be fed into a Conditional Access policy to trigger MFA as a grant control. Because the requirement is to enforce MFA for all Azure portal sign-ins regardless of risk, Identity Protection is too granular and conditional rather than a direct enforcement mechanism.
D
Microsoft Entra ID Privileged Identity Management (PIM)
Why wrong: Privileged Identity Management is designed for role-based access governance, offering just-in-time activation of Azure AD and Azure resource roles with the option to require MFA at activation time. It does not apply to all users — only users who have been assigned an eligible privileged role, and it does not protect the initial sign-in to the Azure portal outside of role activation. Thus, it cannot enforce MFA for every user accessing the portal as requested.

Question 12mediummultiple choice

A company uses Microsoft Entra ID (Microsoft Entra ID) Premium P2. They need to automatically block sign-ins from anonymous IP addresses (e.g., Tor) and force users from risky sign-ins to reset their password. They want to minimize administrative effort and use built-in features. Which Microsoft Entra ID feature should they enable?

Trap 1: Conditional Access policies with locations and grant controls.

Conditional Access can block specific IP ranges but cannot automatically detect anonymous proxies like Tor as a built-in risk. It would require custom IP lists and does not trigger password reset based on user risk. Identity Protection is needed for risk detection.

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

Microsoft Entra ID Privileged Identity Management (PIM) provides just-in-time activation, approval workflows, and MFA enforcement for Azure AD roles and Azure resources, but it is fundamentally an identity governance tool, not a risk detection engine. It does not evaluate sign-in risk signals such as anonymous IP addresses or leaked credentials, nor does it automatically block a sign-in or force a password reset. In this scenario, the required capabilities are precisely those of Identity Protection risk policies—not PIM's role-activation lifecycle.

Trap 3: Microsoft Entra ID Access Reviews.

Access Reviews are periodic, scheduling-based attestations where owners confirm whether users still need access to groups, applications, or roles; they are designed for compliance and certification, not for real-time security enforcement. They do not inspect risk signals like an anonymous IP (e.g., a Tor exit node) at sign-in time, and they cannot automatically revoke a session or request a password change when leaked credentials are detected. Because the company needs immediate, automatic response to detected risks, Access Reviews are irrelevant here.

A
Microsoft Entra ID Identity Protection risk policies (sign-in risk and user risk).
Identity Protection includes built-in policies that automatically detect sign-in risks (including anonymous IP addresses) and user risks (e.g., leaked credentials). The sign-in risk policy can block the sign-in, and the user risk policy can require a password reset. This minimizes manual configuration.
B
Conditional Access policies with locations and grant controls.
Why wrong: Conditional Access can block specific IP ranges but cannot automatically detect anonymous proxies like Tor as a built-in risk. It would require custom IP lists and does not trigger password reset based on user risk. Identity Protection is needed for risk detection.
C
Microsoft Entra ID Privileged Identity Management (PIM).
Why wrong: Microsoft Entra ID Privileged Identity Management (PIM) provides just-in-time activation, approval workflows, and MFA enforcement for Azure AD roles and Azure resources, but it is fundamentally an identity governance tool, not a risk detection engine. It does not evaluate sign-in risk signals such as anonymous IP addresses or leaked credentials, nor does it automatically block a sign-in or force a password reset. In this scenario, the required capabilities are precisely those of Identity Protection risk policies—not PIM's role-activation lifecycle.
D
Microsoft Entra ID Access Reviews.
Why wrong: Access Reviews are periodic, scheduling-based attestations where owners confirm whether users still need access to groups, applications, or roles; they are designed for compliance and certification, not for real-time security enforcement. They do not inspect risk signals like an anonymous IP (e.g., a Tor exit node) at sign-in time, and they cannot automatically revoke a session or request a password change when leaked credentials are detected. Because the company needs immediate, automatic response to detected risks, Access Reviews are irrelevant here.

Question 13easymultiple choice

A company uses Microsoft Entra ID and wants to allow users to sign in using their existing personal Microsoft accounts, Google, and Facebook identities. They also need custom sign-up and sign-in flows with collection of specific user attributes. Which Microsoft Entra ID feature should they use?

Trap 1: Microsoft Entra ID B2B

Microsoft Entra ID B2B is designed for B2B collaboration, allowing you to share your enterprise applications with external business partners as guest users. While it can accept identity providers like Google or Facebook as guest identities, that is a secondary capability for enabling partner access, not for building a consumer-facing sign-up/sign-in experience. B2B does not provide customizable user journeys, custom attributes on self-service sign-up, or the Identity Experience Framework policies that B2C offers, making it the wrong choice for allowing external customers to register with their own social credentials.

Trap 2: Microsoft Entra ID Identity Protection

Microsoft Entra ID Identity Protection is a risk-assessment engine that monitors sign-ins and identity usage for suspicious patterns such as impossible travel, leaked credentials, and unfamiliar sign-in properties. It is designed to trigger adaptive responses like requiring MFA or password changes, not to federate external identity providers. Identity Protection operates on identities that already exist in Entra ID; it cannot process a consumer's sign-up flow or accept a social identity provider like Google or Facebook as a catalog of customer identities.

Trap 3: Microsoft Entra ID Conditional Access

Microsoft Entra ID Conditional Access is a policy-based control plane that evaluates conditions such as user location, group membership, device compliance, and sign-in risk to enforce access decisions like block or allow with MFA. It is an authorization tool that works after an identity is established; it does not create, manage, or integrate external identity providers. While you could apply Conditional Access policies to B2C custom policies later, it is not a mechanism for allowing users to sign up via social identity providers, so it cannot satisfy the stated requirement.

A
Microsoft Entra ID B2B
Why wrong: Microsoft Entra ID B2B is designed for B2B collaboration, allowing you to share your enterprise applications with external business partners as guest users. While it can accept identity providers like Google or Facebook as guest identities, that is a secondary capability for enabling partner access, not for building a consumer-facing sign-up/sign-in experience. B2B does not provide customizable user journeys, custom attributes on self-service sign-up, or the Identity Experience Framework policies that B2C offers, making it the wrong choice for allowing external customers to register with their own social credentials.
B
Microsoft Entra ID B2C
Microsoft Entra ID B2C is the correct solution because it is a Customer Identity and Access Management (CIAM) service built specifically to handle consumer identities at scale. It natively supports multiple identity providers, including Microsoft, Google, and Facebook, and provides self-service sign-up/sign-in user flows. With the Identity Experience Framework, you can define custom policies that collect custom attributes, perform API-based validation, and create fully branded, tailored registration journeys for customers, which is exactly what this company needs.
C
Microsoft Entra ID Identity Protection
Why wrong: Microsoft Entra ID Identity Protection is a risk-assessment engine that monitors sign-ins and identity usage for suspicious patterns such as impossible travel, leaked credentials, and unfamiliar sign-in properties. It is designed to trigger adaptive responses like requiring MFA or password changes, not to federate external identity providers. Identity Protection operates on identities that already exist in Entra ID; it cannot process a consumer's sign-up flow or accept a social identity provider like Google or Facebook as a catalog of customer identities.
D
Microsoft Entra ID Conditional Access
Why wrong: Microsoft Entra ID Conditional Access is a policy-based control plane that evaluates conditions such as user location, group membership, device compliance, and sign-in risk to enforce access decisions like block or allow with MFA. It is an authorization tool that works after an identity is established; it does not create, manage, or integrate external identity providers. While you could apply Conditional Access policies to B2C custom policies later, it is not a mechanism for allowing users to sign up via social identity providers, so it cannot satisfy the stated requirement.

Question 14hardmultiple choice

Refer to the exhibit. An administrator runs the PowerShell script to enable replication for a VM. The script fails with an error that the VM is not found. What is the most likely cause?

Exhibit

Refer to the exhibit.

$rg = Get-AzResourceGroup -Name "DR-RG"
$vault = Get-AzRecoveryServicesVault -ResourceGroupName $rg.ResourceGroupName -Name "ContosoVault"
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
$fabric = Get-AzRecoveryServicesAsrFabric -Name "ContosoFabric"
$protectionContainer = Get-AzRecoveryServicesAsrProtectionContainer -Fabric $fabric
$policy = Get-AzRecoveryServicesAsrPolicy -Name "ContosoReplicationPolicy"
$vm = Get-AzVM -ResourceGroupName "PROD-RG" -Name "WebVM01"
New-AzRecoveryServicesAsrReplicationProtectedItem -VM $vm -ProtectionContainer $protectionContainer -Policy $policy

Trap 1: The Recovery Services vault does not exist.

The script's first operation, Get-AzRecoveryServicesVault, successfully returns a vault object; therefore, the vault clearly exists in the current Azure environment. If the vault were missing, this cmdlet would return nothing or terminate with a 'ResourceNotFound' error, halting the script before any backup or replication commands run. Since the script continues to retrieve containers and policies, the nonexistence of the vault cannot be the source of the failure.

Trap 2: The protection container is not available.

Get-AzRecoveryServicesBackupContainer yields a valid protection container, such as an AzureVM container, which means the container is registered and enabled within the vault. An unavailable container would produce an empty result or an exception, and New-AzRecoveryServicesBackupProtection would fail immediately at that stage with a container-specific error. Because the container is successfully retrieved and all subsequent commands execute, this option is not a plausible cause.

Trap 3: The replication policy is not valid.

The cmdlet Get-AzRecoveryServicesBackupPolicy retrieves a specific policy object successfully, confirming that the policy exists and is well-formed. An invalid policy would either be absent from the results or trigger a validation error when applied by New-AzRecoveryServicesBackupProtection, but no such policy-related failure is indicated here. The error arises after these resources are fetched, so the policy's validity is not the problem.

A
The Recovery Services vault does not exist.
Why wrong: The script's first operation, Get-AzRecoveryServicesVault, successfully returns a vault object; therefore, the vault clearly exists in the current Azure environment. If the vault were missing, this cmdlet would return nothing or terminate with a 'ResourceNotFound' error, halting the script before any backup or replication commands run. Since the script continues to retrieve containers and policies, the nonexistence of the vault cannot be the source of the failure.
B
The protection container is not available.
Why wrong: Get-AzRecoveryServicesBackupContainer yields a valid protection container, such as an AzureVM container, which means the container is registered and enabled within the vault. An unavailable container would produce an empty result or an exception, and New-AzRecoveryServicesBackupProtection would fail immediately at that stage with a container-specific error. Because the container is successfully retrieved and all subsequent commands execute, this option is not a plausible cause.
C
The replication policy is not valid.
Why wrong: The cmdlet Get-AzRecoveryServicesBackupPolicy retrieves a specific policy object successfully, confirming that the policy exists and is well-formed. An invalid policy would either be absent from the results or trigger a validation error when applied by New-AzRecoveryServicesBackupProtection, but no such policy-related failure is indicated here. The error arises after these resources are fetched, so the policy's validity is not the problem.
D
The Azure PowerShell context is not set to the subscription that contains the VM.
The script uses Get-AzVM to locate the virtual machine, and this cmdlet depends on the active Azure context — the subscription set by Set-AzContext or Select-AzSubscription. If the context points to a different subscription than the one holding the target VM, Get-AzVM returns no matching VM, causing the backup protection command to fail with 'VM not found' even though the vault, container, and policy are all visible in the current context. The solution is to explicitly set the context (e.g., Set-AzContext -SubscriptionId '...') before running the script.

Question 15mediummultiple choice

You are a solutions architect for a large healthcare organization that uses Microsoft 365 and Azure. The organization has a Microsoft Entra ID tenant with 15,000 users. The security team requires that all users use multi-factor authentication (MFA) when accessing cloud applications. Currently, only 60% of users have registered for MFA. The organization wants to enforce MFA registration for all users within 30 days. The solution must minimize user disruption and allow users to register their MFA methods during their normal work hours. The organization uses Microsoft Intune for mobile device management and has a conditional access policy that requires MFA for all cloud apps. You need to design a solution to enforce MFA registration. What should you do?

Trap 1: Modify the existing conditional access policy to require MFA for…

Modifying the conditional access policy to require MFA for all cloud apps does not itself trigger MFA registration; it only enforces MFA at sign-in after a user has already registered. Adding a 'block access if MFA is not registered' condition would lock out unregistered users entirely, causing a disruptive denial of service rather than guiding them through the registration process. The correct approach is to use a registration campaign, which nudges users to register before strict MFA enforcement is applied.

Trap 2: Deploy an Intune compliance policy that requires MFA enrollment on…

Intune compliance policies evaluate device health and configuration settings—such as OS version, encryption, or jailbreak status—and do not have a setting to enforce user MFA registration. While a compliance policy can require device-level controls like a PIN or biometric, MFA registration is a user-level authentication method property stored in Microsoft Entra ID, not a device compliance attribute. Deploying such a policy would leave user MFA registration untouched and could fail device compliance checks for unrelated reasons.

Trap 3: Use Microsoft Entra ID password reset policy to force users to…

A Microsoft Entra ID password reset policy governs self-service password reset (SSPR) and may require users to verify identity using existing authentication methods, but it does not force or track MFA registration for later sign-in. Users could reset their password using an email or security question without ever registering a phone or authenticator app, leaving them unregistered for MFA. SSPR registration and MFA registration are separate lifecycle events, so this approach would not reliably fulfill a tenant-wide MFA enrollment requirement.

A
Modify the existing conditional access policy to require MFA for all cloud apps and block access if MFA is not registered.
Why wrong: Modifying the conditional access policy to require MFA for all cloud apps does not itself trigger MFA registration; it only enforces MFA at sign-in after a user has already registered. Adding a 'block access if MFA is not registered' condition would lock out unregistered users entirely, causing a disruptive denial of service rather than guiding them through the registration process. The correct approach is to use a registration campaign, which nudges users to register before strict MFA enforcement is applied.
B
Deploy an Intune compliance policy that requires MFA enrollment on mobile devices.
Why wrong: Intune compliance policies evaluate device health and configuration settings—such as OS version, encryption, or jailbreak status—and do not have a setting to enforce user MFA registration. While a compliance policy can require device-level controls like a PIN or biometric, MFA registration is a user-level authentication method property stored in Microsoft Entra ID, not a device compliance attribute. Deploying such a policy would leave user MFA registration untouched and could fail device compliance checks for unrelated reasons.
C
Configure a Microsoft Entra ID MFA registration campaign to target all users and require registration within 14 days.
The Microsoft Entra ID MFA registration campaign is the purpose-built feature to drive adoption by targeting all users, setting a required registration deadline (e.g., 14 days), and gradually reminding them to register without immediately blocking access. Users can snooze or delay the prompt for a limited time, which avoids disruption while still moving the entire tenant toward MFA readiness. This campaign works alongside conditional access policies and is the recommended first step before enforcing MFA for all cloud apps.
D
Use Microsoft Entra ID password reset policy to force users to register MFA during password reset.
Why wrong: A Microsoft Entra ID password reset policy governs self-service password reset (SSPR) and may require users to verify identity using existing authentication methods, but it does not force or track MFA registration for later sign-in. Users could reset their password using an email or security question without ever registering a phone or authenticator app, leaving them unregistered for MFA. SSPR registration and MFA registration are separate lifecycle events, so this approach would not reliably fulfill a tenant-wide MFA enrollment requirement.

Question 16hardmultiple choice

Your company has multiple Azure subscriptions managed by different teams. You need to design a governance solution that ensures: 1) All subscriptions must have a consistent set of policies (e.g., allowed locations, allowed VM SKUs). 2) Compliance reports must be generated daily for each subscription. 3) Non-compliant resources must be automatically remediated where possible (e.g., add tags). 4) The solution must use a single management group hierarchy. What should you include in the design?

Trap 1: Create a management group hierarchy and use Azure Blueprints to…

Azure Blueprints has been deprecated and is no longer recommended for new deployments; its capabilities have been superseded by native Azure Policy, management groups, and role assignments. While Blueprints could assign policies and roles, doing so per subscription is an outdated and less flexible approach. Even if the hierarchy is correct, relying on a deprecated service risks future support and feature stagnation, making this a poor architectural choice for ongoing governance.

Trap 2: Use Azure DevOps to deploy a pipeline that runs PowerShell scripts…

Using Azure DevOps pipelines with PowerShell scripts is an imperative, ad-hoc approach that does not provide continuous, platform-native compliance enforcement. Azure Policy is declarative and automatically evaluates resources during creation and throughout their lifecycle, whereas scripts must be manually run or scheduled and do not integrate with Azure's compliance dashboard or remediation capabilities. This approach also lacks centralized reporting and can drift, as scripts require constant maintenance to keep up with resource changes.

Trap 3: Create a custom Azure Policy initiative with all required policies…

Assigning a custom Azure Policy initiative to each subscription individually is operationally inefficient and creates a fragmentation point, as each subscription's assignment must be managed and updated separately. This approach is prone to inconsistency and human error, and it does not scale as subscriptions are added or removed. Assigning the initiative at the root management group ensures inheritance to all child subscriptions, enabling centralized policy management and streamlined compliance monitoring.

A
Create a management group hierarchy, assign Azure Policy at the root management group level with both 'audit' and 'deployIfNotExists' effects, and use a daily Logic App to query compliance via Azure Resource Graph and send reports.
Assigning Azure Policy at the root management group scopes the policy to all nested subscriptions, ensuring uniform governance across the entire tenant. Using both audit and deployIfNotExists effects allows you to first assess non-compliant resources and then automatically trigger remediation tasks to fix them without manual intervention. A daily Logic App calling Azure Resource Graph to query compliance aggregates results across subscriptions and can automatically email a report, providing a scalable, native reporting mechanism.
B
Create a management group hierarchy and use Azure Blueprints to assign policies and role assignments per subscription.
Why wrong: Azure Blueprints has been deprecated and is no longer recommended for new deployments; its capabilities have been superseded by native Azure Policy, management groups, and role assignments. While Blueprints could assign policies and roles, doing so per subscription is an outdated and less flexible approach. Even if the hierarchy is correct, relying on a deprecated service risks future support and feature stagnation, making this a poor architectural choice for ongoing governance.
C
Use Azure DevOps to deploy a pipeline that runs PowerShell scripts to enforce policies and generate reports.
Why wrong: Using Azure DevOps pipelines with PowerShell scripts is an imperative, ad-hoc approach that does not provide continuous, platform-native compliance enforcement. Azure Policy is declarative and automatically evaluates resources during creation and throughout their lifecycle, whereas scripts must be manually run or scheduled and do not integrate with Azure's compliance dashboard or remediation capabilities. This approach also lacks centralized reporting and can drift, as scripts require constant maintenance to keep up with resource changes.
D
Create a custom Azure Policy initiative with all required policies and assign it to each subscription individually.
Why wrong: Assigning a custom Azure Policy initiative to each subscription individually is operationally inefficient and creates a fragmentation point, as each subscription's assignment must be managed and updated separately. This approach is prone to inconsistency and human error, and it does not scale as subscriptions are added or removed. Assigning the initiative at the root management group ensures inheritance to all child subscriptions, enabling centralized policy management and streamlined compliance monitoring.

Question 17mediummultiple choice

You are reviewing a PowerShell script for Azure SQL Database. The exhibit shows the script that sets backup retention. What is the effect of running this script?

Exhibit

Refer to the exhibit.

```
$rg = Get-AzResourceGroup -Name "myRG"
$server = Get-AzSqlServer -ResourceGroupName $rg.ResourceGroupName -ServerName "myserver"
$database = Get-AzSqlDatabase -ResourceGroupName $rg.ResourceGroupName -ServerName $server.ServerName -DatabaseName "mydb"
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName $rg.ResourceGroupName -ServerName $server.ServerName -DatabaseName $database.DatabaseName -RetentionDays 7
```

Trap 1: It enables geo-redundant backups for the database.

This is incorrect because the cmdlet shown operates on the backup retention period in days, not on the storage redundancy or geo-replication configuration of backups. Geo-redundant backups are controlled at the server level via the BackupStorageRedundancy property (e.g., Geo, Zone, Local) or by choosing Geo-redundant storage (RA-GRS) when creating the server; a database-level retention policy does not affect whether backups are copied to a paired region. Simply changing retention from 7 to 7 or any number of days cannot enable geo-redundancy; that would require an explicit storage redundancy setting or a server-level configuration change. Therefore, this option misattributes a storage/deplyment setting to a retention setting.

Trap 2: It sets the long-term retention (LTR) backup policy to 7 days.

This is wrong because the cmdlet in question configures short-term retention (STR) for point-in-time restore, not long-term retention (LTR). LTR is a separate policy that retains full database backups for years, often configured via Set-AzSqlDatabaseBackupLongTermRetentionPolicy or the LTR backup APIs, and it typically involves weekly, monthly, or yearly backup cycles (with retention ranges like 1–10 years). A value of 7 days is within the STR recommended range (1–35 days) and is far too short for LTR, which is not expressed in days but in weeks, months, or years. Thus, interpreting a 7-day setting as LTR is a category error and does not reflect what the script does.

Trap 3: It increases the backup retention from 7 to 35 days.

This is incorrect because the script sets the short-term backup retention to exactly 7 days; it is not an incremental increase from 7 to 35 days. The Set-AzSqlDatabaseBackupShortTermRetentionPolicy cmdlet overwrites the current retention period with the specified value, so if the current setting were already 7, the command is effectively a no-op; it never multiplies or extends the period. A change to 35 days would require explicitly passing -RetentionDays 35, which is not present in this script. Moreover, the phrase 'increase' assumes an existing value lower than 7, but the default is 7, so this is a restatement, not an increase.

A
It sets the short-term backup retention to 7 days, enabling point-in-time restore within that period.
This is the correct interpretation: the cmdlet being reviewed is Set-AzSqlDatabaseBackupShortTermRetentionPolicy (or equivalent), which explicitly configures the short-term backup retention policy for an Azure SQL database. Setting the property to 7 days means automated backups (full, differential, and transactional log backups) are retained for 7 days, and point-in-time restore (PITR) can be performed to any point within that window. The default is 7 days, so this is a direct, deliberate setting of the PITR window. The parameter range for short-term retention is 1–35 days, and 7 is within that range.
B
It enables geo-redundant backups for the database.
Why wrong: This is incorrect because the cmdlet shown operates on the backup retention period in days, not on the storage redundancy or geo-replication configuration of backups. Geo-redundant backups are controlled at the server level via the BackupStorageRedundancy property (e.g., Geo, Zone, Local) or by choosing Geo-redundant storage (RA-GRS) when creating the server; a database-level retention policy does not affect whether backups are copied to a paired region. Simply changing retention from 7 to 7 or any number of days cannot enable geo-redundancy; that would require an explicit storage redundancy setting or a server-level configuration change. Therefore, this option misattributes a storage/deplyment setting to a retention setting.
C
It sets the long-term retention (LTR) backup policy to 7 days.
Why wrong: This is wrong because the cmdlet in question configures short-term retention (STR) for point-in-time restore, not long-term retention (LTR). LTR is a separate policy that retains full database backups for years, often configured via Set-AzSqlDatabaseBackupLongTermRetentionPolicy or the LTR backup APIs, and it typically involves weekly, monthly, or yearly backup cycles (with retention ranges like 1–10 years). A value of 7 days is within the STR recommended range (1–35 days) and is far too short for LTR, which is not expressed in days but in weeks, months, or years. Thus, interpreting a 7-day setting as LTR is a category error and does not reflect what the script does.
D
It increases the backup retention from 7 to 35 days.
Why wrong: This is incorrect because the script sets the short-term backup retention to exactly 7 days; it is not an incremental increase from 7 to 35 days. The Set-AzSqlDatabaseBackupShortTermRetentionPolicy cmdlet overwrites the current retention period with the specified value, so if the current setting were already 7, the command is effectively a no-op; it never multiplies or extends the period. A change to 35 days would require explicitly passing -RetentionDays 35, which is not present in this script. Moreover, the phrase 'increase' assumes an existing value lower than 7, but the default is 7, so this is a restatement, not an increase.

Question 18mediummultiple choice

A company uses Microsoft Entra ID B2B collaboration for external partners. They want to enforce that external users must use multi-factor authentication (MFA) and access company resources only from devices that are compliant with Intune policies. Additionally, they need to require a session timeout of 1 hour. Which combination of Microsoft Entra ID features should they use?

Trap 1: Create a Conditional Access policy for external users that requires…

This option incorrectly assumes that MFA and device compliance claims from an external tenant are trusted by the resource tenant by default. In reality, cross-tenant access settings must be explicitly configured to trust those inbound claims; otherwise, the resource tenant does not honor the home tenant's MFA or device compliance state. Simply creating a Conditional Access policy with MFA, compliant device, and sign-in frequency controls will not work if the device compliance claim is absent or untrusted, and it will likely force external users to re-register or re-authenticate rather than leveraging their home tenant's already completed MFA.

Trap 2: Use Microsoft Entra ID Identity Protection to detect risky sessions…

Microsoft Entra ID Identity Protection can evaluate risk for sign-ins, including those from external users, and a Conditional Access policy can use that risk as a condition to require MFA. However, Identity Protection does not enforce device compliance as a grant control; device compliance must be enforced separately through Conditional Access with the 'Require device to be marked as compliant' control, which in turn requires the device compliance claim to be trusted via cross-tenant access settings. The option also omits the required one-hour sign-in frequency session control, so it fails to fully satisfy the stated requirements.

Trap 3: Configure Microsoft Entra ID Privileged Identity Management (PIM)…

Microsoft Entra ID Privileged Identity Management (PIM) is designed for just-in-time, time-bound activation of privileged roles like Global Administrator, not for enforcing authentication policies on external users. PIM's MFA requirement applies only during the role activation process, and it provides no mechanism to set a general session sign-in frequency or enforce device compliance for B2B collaboration users. Therefore, using PIM in this scenario would not deliver the required MFA, compliant device, or one-hour session controls for external access to the company's resources.

A
Configure cross-tenant access settings to trust MFA and device compliance from external organizations, and then create a Conditional Access policy that requires MFA, compliant device, and a session sign-in frequency of 1 hour.
Cross-tenant access settings in Microsoft Entra ID let you explicitly trust MFA, compliant device, and hybrid Azure AD joined device claims that external organizations assert about their own users. After configuring that inbound trust for the partner tenant, you must create a Conditional Access policy that targets external users and grants access only when MFA is satisfied, a compliant device is reported, and the session sign-in frequency does not exceed one hour. This two-step approach is mandatory because the trust settings establish which claims are honored, while the Conditional Access policy defines the conditions and session controls that are actually enforced at the resource tenant.
B
Create a Conditional Access policy for external users that requires MFA and compliant device, and set session controls for sign-in frequency. Trusting MFA from external tenants is automatic.
Why wrong: This option incorrectly assumes that MFA and device compliance claims from an external tenant are trusted by the resource tenant by default. In reality, cross-tenant access settings must be explicitly configured to trust those inbound claims; otherwise, the resource tenant does not honor the home tenant's MFA or device compliance state. Simply creating a Conditional Access policy with MFA, compliant device, and sign-in frequency controls will not work if the device compliance claim is absent or untrusted, and it will likely force external users to re-register or re-authenticate rather than leveraging their home tenant's already completed MFA.
C
Use Microsoft Entra ID Identity Protection to detect risky sessions for external users and require MFA only when risk is high. This will also enforce device compliance automatically.
Why wrong: Microsoft Entra ID Identity Protection can evaluate risk for sign-ins, including those from external users, and a Conditional Access policy can use that risk as a condition to require MFA. However, Identity Protection does not enforce device compliance as a grant control; device compliance must be enforced separately through Conditional Access with the 'Require device to be marked as compliant' control, which in turn requires the device compliance claim to be trusted via cross-tenant access settings. The option also omits the required one-hour sign-in frequency session control, so it fails to fully satisfy the stated requirements.
D
Configure Microsoft Entra ID Privileged Identity Management (PIM) for external users to activate MFA and require compliant device. PIM is for role activation, not for external user access policies.
Why wrong: Microsoft Entra ID Privileged Identity Management (PIM) is designed for just-in-time, time-bound activation of privileged roles like Global Administrator, not for enforcing authentication policies on external users. PIM's MFA requirement applies only during the role activation process, and it provides no mechanism to set a general session sign-in frequency or enforce device compliance for B2B collaboration users. Therefore, using PIM in this scenario would not deliver the required MFA, compliant device, or one-hour session controls for external access to the company's resources.

Question 19mediummultiple choice

A company ingests IoT sensor data into Azure Blob Storage. Data is written frequently and is accessed rarely after the first 24 hours. The company must retain the data for exactly 90 days for compliance. They want to minimize storage costs by automatically moving data to the cheapest possible storage tier as soon as possible. Which Azure Blob Storage lifecycle management policy should they implement?

Trap 1: Move to Archive tier after 1 day, delete after 90 days

Selecting Archive after one day seems tempting for cost savings, but the Archive tier imposes a 180-day minimum retention period, so deleting after 90 days triggers an early deletion fee proportional to the remaining 90 days. While Archive has the lowest storage price, that price advantage is erased by this penalty, plus retrieval operations are more expensive and slower than Cool. The data does not need archival-grade long-term storage; it must simply be retained for 90 days, so Cool is the appropriate and cheaper choice.

Trap 2: Move to Cool tier after 30 days, delete after 90 days

Keeping data in the Hot tier for the first 30 days is unnecessary because data is rarely accessed after 24 hours. This results in higher costs for those 29 days compared to moving to Cool after 1 day.

Trap 3: Move to Archive tier after 30 days, delete after 90 days

Keeping the data in Hot for the first 30 days creates unnecessary cost, since the sensor readings are rarely accessed after the first day; this wastes approximately 29 days of Hot-tier pricing. Then moving to Archive for only 60 days still falls short of the 180-day minimum retention requirement, causing an early deletion charge that makes the total cost higher than a straightforward Cool-tier lifecycle. The combination of a Hot wait and an Archive penalty maximizes cost rather than minimizing it.

A
Move to Cool tier after 1 day, delete after 90 days
Moving the sensor data to the Cool tier after just one day aligns lifecycle costs with actual access patterns, since IoT telemetry is typically queried only briefly after ingestion. Cool tier provides significantly lower per-GB storage costs than Hot, and because the retention period of 90 days exceeds Cool's 30-day minimum commitment, no early deletion penalty is incurred. This policy satisfies the compliance requirement to delete after 90 days while minimizing the cost of storing data that is rarely read after the first 24 hours.
B
Move to Archive tier after 1 day, delete after 90 days
Why wrong: Selecting Archive after one day seems tempting for cost savings, but the Archive tier imposes a 180-day minimum retention period, so deleting after 90 days triggers an early deletion fee proportional to the remaining 90 days. While Archive has the lowest storage price, that price advantage is erased by this penalty, plus retrieval operations are more expensive and slower than Cool. The data does not need archival-grade long-term storage; it must simply be retained for 90 days, so Cool is the appropriate and cheaper choice.
C
Move to Cool tier after 30 days, delete after 90 days
Why wrong: Keeping data in the Hot tier for the first 30 days is unnecessary because data is rarely accessed after 24 hours. This results in higher costs for those 29 days compared to moving to Cool after 1 day.
D
Move to Archive tier after 30 days, delete after 90 days
Why wrong: Keeping the data in Hot for the first 30 days creates unnecessary cost, since the sensor readings are rarely accessed after the first day; this wastes approximately 29 days of Hot-tier pricing. Then moving to Archive for only 60 days still falls short of the 180-day minimum retention requirement, causing an early deletion charge that makes the total cost higher than a straightforward Cool-tier lifecycle. The combination of a Hot wait and an Archive penalty maximizes cost rather than minimizing it.

Question 20hardmultiple choice

A company needs to store large amounts of unstructured data (log files) for analytics. The data is accessed frequently for the first 30 days, then occasionally for the next 90 days, and rarely after that but must be retained for 7 years for compliance. The data must not be modified or deleted during the retention period, and administrative access must not be able to bypass this restriction. They want to minimize storage costs. Which combination of Azure Blob Storage features should they configure?

Trap 1: Enable soft delete and versioning on the storage account, and use a…

Soft delete and versioning protect against accidental or malicious deletion only within the configured retention window and do not guarantee immutability—an administrator with delete or overwrite permissions can still purge versions or disable the protection. A custom script that deletes blobs after 7 years is an out-of-band process that can fail due to permissions, service principal expiry, or throttling, and manual tier moves via PowerShell are neither automated nor reliably scheduled, leaving cost management and compliance enforcement to human intervention. In contrast, a locked time-based retention policy prohibits both deletion and overwrites for the entire 7-year period at the container level, and lifecycle management transitions tiers deterministically.

Trap 2: Set each blob's access tier to Cool on upload, then manually change…

Setting the access tier to Cool on upload only affects storage pricing, not data retention or immutability; blobs in the Cool tier can still be overwritten or deleted at any time by an authorized user. Manually changing each blob to Archive after 30 days is not scalable and is prone to mistakes, missed jobs, or incomplete transitions, especially at enterprise scale, whereas lifecycle management applies rules automatically and idempotently. Azure Backup on the storage account creates recovery point snapshots but does not prevent ongoing writes or deletions, nor does it enforce a required retention period—it simply provides point-in-time restore capabilities, so it fails the core compliance requirement of prohibiting any modification for 2,555 days.

Trap 3: Apply a legal hold on the container to prevent deletion, and…

A legal hold prevents deletion of blobs in the container, but it does not block overwrites or modifications—an authorized user can still change the content of an existing blob, which is insufficient for a strict time-based retention requirement. Additionally, legal hold is a manual, discretionary control that must be explicitly removed after the retention period, and nothing enforces that removal at exactly 7 years; it also lacks the automatic, permanent enforcement of a locked time-based retention policy. Configuring a lifecycle policy to move blobs to Archive after 30 days is valid from a cost perspective, but because the legal hold cannot protect against overwrite, the overall solution does not meet the stated need for both deletion and modification protection for 2,555 days.

A
Configure a lifecycle management policy to move blobs to Cool tier after 30 days and to Archive tier after 120 days. Apply a time-based retention policy with a retention period of 2,555 days and lock it.
A locked time-based retention policy on the container ensures that blobs cannot be deleted or overwritten for the specified duration (7 years = 2555 days). Lifecycle management moves blobs to cost-efficient tiers. Locking prevents bypass.
B
Enable soft delete and versioning on the storage account, and use a custom script to delete blobs after 7 years. Manually move blobs to Cool and Archive tiers using Azure PowerShell.
Why wrong: Soft delete and versioning protect against accidental or malicious deletion only within the configured retention window and do not guarantee immutability—an administrator with delete or overwrite permissions can still purge versions or disable the protection. A custom script that deletes blobs after 7 years is an out-of-band process that can fail due to permissions, service principal expiry, or throttling, and manual tier moves via PowerShell are neither automated nor reliably scheduled, leaving cost management and compliance enforcement to human intervention. In contrast, a locked time-based retention policy prohibits both deletion and overwrites for the entire 7-year period at the container level, and lifecycle management transitions tiers deterministically.
C
Set each blob's access tier to Cool on upload, then manually change to Archive after 30 days. Enable Azure Backup on the storage account for retention.
Why wrong: Setting the access tier to Cool on upload only affects storage pricing, not data retention or immutability; blobs in the Cool tier can still be overwritten or deleted at any time by an authorized user. Manually changing each blob to Archive after 30 days is not scalable and is prone to mistakes, missed jobs, or incomplete transitions, especially at enterprise scale, whereas lifecycle management applies rules automatically and idempotently. Azure Backup on the storage account creates recovery point snapshots but does not prevent ongoing writes or deletions, nor does it enforce a required retention period—it simply provides point-in-time restore capabilities, so it fails the core compliance requirement of prohibiting any modification for 2,555 days.
D
Apply a legal hold on the container to prevent deletion, and configure a lifecycle policy to move blobs to Archive after 30 days.
Why wrong: A legal hold prevents deletion of blobs in the container, but it does not block overwrites or modifications—an authorized user can still change the content of an existing blob, which is insufficient for a strict time-based retention requirement. Additionally, legal hold is a manual, discretionary control that must be explicitly removed after the retention period, and nothing enforces that removal at exactly 7 years; it also lacks the automatic, permanent enforcement of a locked time-based retention policy. Configuring a lifecycle policy to move blobs to Archive after 30 days is valid from a cost perspective, but because the legal hold cannot protect against overwrite, the overall solution does not meet the stated need for both deletion and modification protection for 2,555 days.