Question
Case Study 1 - Litware Existing Environment Azure Environment Litware has 10 Azure subscriptions that are linked to the Litware.com tenant and five Azure subscriptions that are linked to the dev.litware.com tenant. All the subscriptions are in an Enterprise Agreement (EA). The litware.com tenant contains a custom Azure role-based access control (Azure RBAC) role named Role1 that grants the DataActions read permission to the blobs and files in Azure Storage. On-Premises Environment The on-premises network of Litware contains the resources shown in the following table. Network Environment Litware has ExpressRoute connectivity to Azure. Planned Changes and Requirements Litware plans to implement the following changes: Migrate DB1 and DB2 to Azure. Migrate App1 to Azure virtual machines. Migrate the external storage used by App1 to Azure Storage. Deploy the Azure virtual machines that will host App1 to Azure dedicated hosts. Authentication and Authorization Requirements Litware identifies the following authentication and authorization requirements: Only users that manage the production environment by using the Azure portal must connect from a hybrid Azure AD-joined device and authenticate by using Azure Multi-Factor Authentication (MFA). The Network Contributor built-in RBAC role must be used to grant permissions to the network administrators for all the virtual networks in all the Azure subscriptions. To access the resources in Azure, App1 must use the managed identity of the virtual machines that will host the app. RBAC roles must be applied at the highest level possible. Resiliency Requirements Litware identifies the following resiliency requirements: Once migrated to Azure, DB1 and DB2 must meet the following requirements: - Maintain availability if two availability zones in the local Azure region fail. - Fail over automatically. - Minimize I/O latency. App1 must meet the following requirements: - Be hosted in an Azure region that supports availability zones. - Be hosted on Azure virtual machines that support automatic scaling. - Maintain availability if two availability zones in the local Azure region fail. Security and Compliance Requirements Litware identifies the following security and compliance requirements: Once App1 is migrated to Azure, you must ensure that new data can be written to the app, and the modification of new and existing data is prevented for a period of three years. On-premises users and services must be able to access the Azure Storage account that will host the data in App1. Access to the public endpoint of the Azure Storage account that will host the App1 data must be prevented. All Azure SQL databases in the production environment must have Transparent Data Encryption (TDE) enabled. App1 must NOT share physical hardware with other workloads. Business Requirements Litware identifies the following business requirements: Minimize administrative effort. Minimize costs. Drag and Drop Question You need to configure an Azure policy to ensure that the Azure SQL databases have Transparent Data Encryption (TDE) enabled. The solution must meet the security and compliance requirements. Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. Answer:
Explanation
Correct Sequence
- Create an Azure policy definition that uses the
deployIfNotExists effect
- Create an Azure policy assignment
- Invoke a remediation task
Why This Order
Step 1 - deployIfNotExists policy definition
TDE is a child resource on a SQL database (transparentDataEncryption), not a simple property. Enabling it requires deploying that child resource - which is exactly what deployIfNotExists does: it triggers a deployment when a compliant resource (the TDE child) is absent.
Why not Modify? The Modify effect is for adding/changing tags or simple properties on a resource itself. It cannot deploy sub-resources. Using Modify here would be technically incorrect and wouldn't enable TDE.
You must define the policy before you can assign it - hence Step 1.
Step 2 - Create a policy assignment
A policy definition has no effect until it is assigned to a scope. During assignment, Azure automatically provisions a system-assigned managed identity for the policy (required for deployIfNotExists to perform deployments).
This is why "Create a user-assigned managed identity" is a distractor - it's optional and unnecessary; the system-assigned identity is created automatically at assignment time.
Step 3 - Invoke a remediation task
The deployIfNotExists effect only acts on new or updated resources going forward. Existing non-compliant SQL databases (those already without TDE) are not automatically fixed. A remediation task explicitly triggers the policy logic against already-existing non-compliant resources.
Order matters: you cannot remediate before the policy is assigned, and you cannot assign before the definition exists.
Common Mistakes
| Mistake | Why it's wrong |
|---|
Choosing Modify instead of deployIfNotExists | Modify can't deploy child resources like TDE |
| Including "Create user-assigned managed identity" | Redundant - system-assigned identity is auto-created at assignment |
| Skipping the remediation task | Existing databases stay non-compliant without it |
| Reversing steps 1 and 2 | You cannot assign a policy that doesn't exist yet |
