AZ-500 Microsoft Certified: Azure Security Engineer Associate

1. Rule Type: To create an analytic rule based on a custom Log Analytics query (Query1) that runs periodically, you must choose the Scheduled rule type. This allows you to define your KQL query and set a schedule for how often it runs to detect potential threats. 2. Playbook Configuration: A playbook (which is an Azure Logic App) is an automated workflow. For an Azure Sentinel analytic rule to be able to trigger this playbook, the playbook itself must be built with a trigger. Specifically, it needs the “When a response to an Azure Sentinel alert is triggered” trigger. This trigger allows Sentinel to invoke the playbook and pass it the alert/incident details when the analytic rule’s conditions are met.

There are no options available for this question. To view the solution and explanation, click Confirm and then click Show Explanation.

Azure Sentinel collects data from sources via a Log Analytics workspace. A Sentinel instance is attached to a single workspace, but a virtual machine can send its logs to any Log Analytics workspace, regardless of the VM’s region. To connect a VM to Sentinel, you connect it to the Log Analytics workspace that Sentinel is using. In this case, Sentinel uses Workspace1. Although some VMs are already connected to Workspace2, and some are not connected to any workspace, all four VMs (VM1, VM2, VM3, and VM4) can be configured to send their logs to Workspace1 to be monitored by Azure Sentinel.

Based on the provided answers, the Azure Monitor alert state workflow being tested is specific. For Alert1, which is currently Acknowledged, the only valid next step is to resolve it by moving it to the Closed state. For Alert2, which is currently Closed, the system allows it to be reopened by changing the state back to either New or Acknowledged. This indicates that “Closed” is not a terminal state in this context and alerts can be reactivated if the issue reoccurs or was closed prematurely.

When deploying the Microsoft Monitoring Agent (also known as the Log Analytics agent or OMS extension) using an ARM template, you must provide two essential pieces of information for it to connect to the correct Log Analytics workspace. 1. WorkspaceID: This is the unique identifier for your Log Analytics workspace. It is considered public information and is placed in the settings section of the extension’s properties. 2. WorkspaceKey: This is the primary or secondary key for the workspace, acting as a password. Because it is sensitive information, it must be placed in the protectedSettings section, which ensures it is encrypted during deployment and not exposed in logs or the portal.

Create an alert rule on a metric with the Azure portal. 1. In the portal, locate the resource, here VM1, you are interested in monitoring and select it. 2. Select Alerts (Classic) under the MONITORING section. The text and icon may vary slightly for different resources. 3. Select the Add metric alert (classic) button and fill in the fields as per below, and click OK. – Metric: CPU Percentage – Condition: Greater than -Threshold: 70 – Period: Over last 15 minutes – Notify via email – Additional administrator email(s): admin1@contoso.com

When automatic provisioning is On, Security Center provisions the Log Analytics Agent on all supported Azure VMs and any new ones that are created. Supported Operating systems include: Ubuntu 14.04 LTS (x86/x64), 16.04 LTS (x86/x64), and 18.04 LTS (x64) and Windows Server 2008 R2, 2012, 2012 R2, 2016, version 1709 and 1803 Since both Windows Server 2016 and Ubuntu 18.04 LTS are supported operating systems, the agent will be installed on all four virtual machines (the existing VMs VM1 and VM2, and the newly deployed VMs VM3 and VM4).

For ASG1: The rule for Application Security Groups (ASGs) is that all member network interfaces must belong to the same virtual network. Since VM1’s network interface has already been added to ASG1, and VM1 is in VNET1, only other VMs in VNET1 can be added. Looking at the table, only VM2 is also in VNET1. For ASG2: The selected answer is VM1, VM2, VM3, and VM4. Note: This answer contradicts the fundamental rule of ASGs. An ASG can only contain network interfaces from a single virtual network. The listed VMs are in VNET1, VNET2, and VNET3. Furthermore, an ASG and its members must be in the same region, and VM3 is in a different region (Central US) than ASG2 (West US). The provided answer for ASG2 appears to be incorrect based on Azure’s documented constraints. VNet peering does not affect ASG membership rules.

To allow RDP connections from the internet to a VM with only a private IP, you need a service that can perform Network Address Translation (NAT). Azure Firewall is a suitable service for this. The process is as follows: 1. Create a new subnet: Azure Firewall requires its own dedicated subnet within the virtual network. This subnet is typically named AzureFirewallSubnet. This must be done before deploying the firewall. 2. Deploy Azure Firewall: After the dedicated subnet is created, you can deploy the Azure Firewall instance into it. The firewall will have a public IP address to receive traffic from the internet. 3. Create a NAT rule collection: To forward the RDP traffic (TCP port 3389) from the firewall’s public IP to the private IP of VM1, you must create a DNAT (Destination NAT) rule in a NAT rule collection on the Azure Firewall. This rule will translate the destination address and port for incoming RDP connections to VM1.

To grant specific permissions using the principle of least privilege, you need to create a custom RBAC role and then assign it. The process is as follows: Create a JSON file: First, you define the custom role in a JSON file. This file will specify the exact actions required (e.g., Microsoft.Compute/virtualMachines/start/action, Microsoft.Compute/virtualMachines/stop/action, Microsoft.Compute/virtualMachines/restart/action) and the scope at which the role can be assigned (Subscription1). Run the New-AzureRmRoleDefinition cmdlet: Next, you use this PowerShell cmdlet to create the custom role in Azure, using the JSON file as input. This makes the new role available for assignment. Run the New-AzureRmRoleAssignment cmdlet: Finally, you assign the newly created custom role to the security principal (Group1) at the specified scope (Subscription1) using this cmdlet. This grants the members of Group1 the intended permissions.

Azure Update Management can be enabled on virtual machines that are running. In this scenario, VM1, VM2, and VM4 are in a “Running” state. VM3 is in a “Stopped” state, which means the Log Analytics agent required for Update Management cannot be installed or communicate with the service. Therefore, you can only enable Update Management for the running virtual machines: VM1, VM2, and VM4.

To integrate Azure Kubernetes Service (AKS) with Azure Active Directory for role-based access control (RBAC), you often need to authorize users based on their group memberships. To achieve this, the access tokens issued by Azure AD must contain information about the user’s groups. The groupMembershipClaims property in the application manifest controls this behavior. By modifying this property from null to a value such as “All” or “SecurityGroup”, you configure Azure AD to include the user’s group claims in the token, which can then be used by Kubernetes RBAC for authorization.

Box 1: able to connect to East US 2 The rule StorageEA2Allow has a higher priority (104) than the DenyStorageAccess rule (105). This rule specifically allows outbound traffic to the Storage/EastUS2 service tag on port 443. Therefore, connections to storage accounts in the East US 2 region are permitted. All other storage traffic is blocked by the lower-priority deny rule. Box 2: allowed TCP Port 21 controls the FTP session. The Contoso_FTP rule is an inbound rule that explicitly allows TCP traffic on port 21 from the source IP address 1.2.3.4 to the destination IP 10.0.0.5. Since the question asks about a destination in the 10.0.0.10/32 range, it appears there is a typo in the question or the provided explanation. Assuming the rule Contoso_FTP correctly allows FTP traffic, this would be the controlling rule.

An ingress controller is a piece of software that provides reverse proxy, configurable traffic routing, and TLS termination for Kubernetes services.

Note: Create a workspace In the Azure portal, click All services. In the list of resources, type Log Analytics. As you begin typing, the list filters based on your input. Select Log Analytics. Click Create, and then select choices for the following items: Provide a name for the new Log Analytics workspace, such as DefaultLAWorkspace. OMS workspaces are now referred to as Log Analytics workspaces. Select a Subscription to link to by selecting from the drop-down list if the default selected is not appropriate. For Resource Group, select an existing resource group that contains one or more Azure virtual machines. Select the Location your VMs are deployed to. For additional information, see which regions Log Analytics is available in. Incorrect Answers: B, C: A Log Analytics workspace provides a geographic location for data storage. VM2 and VM3 are at a different location. D: VM4 is a different resource group.

You need to configure the Network Security Group that is associated with subnet0. 1. In the Azure portal, type Virtual Networks in the search box, select Virtual Networks from the search results then select VNET1. Alternatively, browse to Virtual Networks in the left navigation pane. 2. In the properties of VNET1, click on Subnets. This will display the subnets in VNET1 and the Network Security Group associated to each subnet. Note the name of the Network Security Group associated to Subnet0. 3. Type Network Security Groups into the search box and select the Network Security Group associated with Subnet0. 4. In the properties of the Network Security Group, click on Inbound Security Rules. 5. Click the Add button to add a new rule. 6. In the Source field, select Service Tag. 7. In the Source Service Tag field, select Internet. 8. Leave the Source port ranges and Destination field as the default values (* and All). 9. In the Destination port ranges field, enter 7777. 10. Change the Protocol to TCP. 11. Leave the Action option as Allow. 12. Change the Priority to 100. 13. Change the Name from the default Port_8080 to something more descriptive such as Allow_TCP_7777_from_Internet. The name cannot contain spaces. 14. Click the Add button to save the new rule.

1. Effect: The goal is to automatically install a missing antimalware extension on existing and new VMs. The DeployIfNotExists effect is specifically designed for this purpose. It evaluates if a specified related resource exists, and if it doesn’t, it runs an ARM template deployment to create it. Deny would only block non-compliant VMs, and Append is used for adding fields to a resource, not deploying a separate one. 2. Property: The deployment block within a DeployIfNotExists policy effect defines the deployment that will be executed if the resource is missing. This deployment is specified using an ARM template. The existenceCondition is a separate property within the details block (at the same level as deployment) used to check if the resource already exists.

Box 1: Yes. The storage account’s firewall configuration explicitly has a VirtualNetworkRules entry that allows access from Subnet1. Box 2: No. The DefaultAction for the firewall is Deny. Since there is no specific rule allowing access from Subnet2, it is denied access by default. Box 3: Yes. The IpRules contain an Allow rule for the IP range 193.77.0.0/16. The IP address 193.77.10.2 falls within this range and is therefore allowed.

Step 1: 1. In Azure portal go to the storage account you want to secure. Here: rg1lod10598168 2. Click on the settings menu called Firewalls and virtual networks. 3. To deny access by default, choose to allow access from Selected networks. To allow traffic from all networks, choose to allow access from All networks. 4. Click Save to apply your changes. Step 2: 1. Go to the storage account you want to secure. Here: rg1lod10598168 2. Click on the settings menu called Firewalls and virtual networks. 3. Check that you’ve selected to allow access from Selected networks. 4. To grant access to a virtual network with a new network rule, under Virtual networks, click Add existing virtual network, select Virtual networks and Subnets options. Enter the 131.107.0.0/16 subnet and then click Add. Note: When network rules are configured, only applications requesting data over the specified set of networks can access a storage account. You can limit access to your storage account to requests originating from specified IP addresses, IP ranges or from a list of subnets in an Azure Virtual Network (VNet).

1. In Azure portal, locate and select the RG1lod10598168 resource group. 2. Click Access control (IAM). 3. Click the Role assignments tab to view all the role assignments at this scope. 4. Click Add > Add role assignment to open the Add role assignment pane. 5. In the Role drop-down list, select the role Virtual Machine Contributor. Virtual Machine Contributor lets you manage virtual machines, but not access to them, and not the virtual network or storage account they’re connected to. 6. In the Select list, select user user21059868. 7. Click Save to assign the role.

This outcome is determined by a combination of RBAC role assignments and resource locks. The specific details are likely in a larger scenario not shown in the image, but we can infer the configuration: Modification Permissions: User2 can modify VNET4 and VNET1. This indicates that User2 has a role like “Contributor” or “Network Contributor” on both of these virtual networks. It also implies that VNET2 and VNET3 have either different permissions or a ReadOnly resource lock preventing modifications. Deletion Permissions: User2 can only delete VNET4. This means that even though User2 has modify permissions on VNET1, VNET1 must have a CanNotDelete resource lock applied to it. This type of lock allows modification but specifically prevents deletion. VNET4 has no such lock, so User2’s role permissions allow its deletion. VNET2 and VNET3 cannot be deleted because User2 lacks the necessary permissions, possibly combined with locks.

1. In the Search resources, services, and docs box at the top of the portal, begin typing the name of a virtual machine, VM1 that has a network interface that you want to add to, or remove from, an application security group. 2. When the name of your VM appears in the search results, select it. 3. Under SETTINGS, select Networking. Select Configure the application security groups, select the application security groups that you want to add the network interface to, or unselect the application security groups that you want to remove the network interface from, and then select Save.

Microsoft Sentinel notebooks are Jupyter notebooks that run on an Azure Machine Learning (AML) platform. To use this feature, you must first create an Azure Machine Learning workspace. Therefore, the minimum number of required workspaces is 1. While an AML workspace can integrate with an Azure Container Registry to store Docker images for environments, it is not a mandatory prerequisite for creating the workspace or running a basic Sentinel notebook. The necessary compute and environment can be set up without you explicitly creating a container registry first. Therefore, the minimum number of Azure container registries required is 0.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

This question relies on information from a broader scenario that is not fully visible in the image. However, the answers imply a set of Azure Policies are in place that restrict resource creation. Virtual Networks: The answer RG6 only suggests that there is an Azure Policy assigned to resource groups RG4 and RG5 that has a deny effect on the creation of Microsoft.Network/virtualNetworks resources. RG6 does not have this restrictive policy, so User8, having the Owner role, is permitted to create virtual networks there. NSGs: The answer RG4 and RG6 only indicates a similar policy is in place, but it only restricts the creation of Microsoft.Network/networkSecurityGroups in RG5. Therefore, User8 can create NSGs in both RG4 and RG6, where no such deny policy exists. The Owner role provides the necessary permissions, and the action is only blocked by the policy on RG5.

VM1: Yes. NSG2 applies to VM1 and this allows inbound traffic on port 80. VM2: No. NSG2 and NSG1 apply to VM2. NSG2 allows the inbound traffic on port 80 but NSG1 does not allow it. VM3: Yes. There are no NSGs applying to VM3 so all ports will be open.

This outcome is determined by Network Security Group (NSG) rules that use Application Security Groups (ASGs) as sources and destinations. Based on the answers, the rules are configured as follows: VM1 cannot ping VM4: This indicates there is no NSG rule that allows ICMP traffic (ping) from the ASG of VM1 to the ASG of VM4. VM2 can ping VM4: This means an NSG rule exists that explicitly allows ICMP traffic from the ASG of VM2 to the ASG of VM4. VM1 can connect to the web server on VM4: This implies that an NSG rule exists allowing web traffic (e.g., on TCP ports 80 or 443) from the ASG of VM1 to the ASG of VM4, even though ping traffic is blocked.

This question requires context from a larger scenario describing the network configuration (VNets, subnets, NSG rules) of VM1, VM2, VM3, and VM5. Based on the correct answers, we can infer the following: VM1 to VM2 (Public IP): The connection is allowed. This implies that the Network Security Group (NSG) associated with VM1’s subnet has an outbound rule that allows ICMP (ping) traffic to the internet, and the NSG for VM2’s subnet has an inbound rule allowing ICMP from the internet or specifically from VM1’s public IP. VM1 to VM3 (Private IP): The connection is allowed. This suggests that VM1 and VM3 are within the same Virtual Network (or peered VNets), and the NSG rules allow ICMP traffic between their respective subnets. VM1 to VM5 (Public IP): The connection is blocked. This indicates that there is a restrictive NSG rule on either VM1’s outbound traffic or VM5’s inbound traffic that is blocking the ICMP protocol from reaching VM5’s public IP address.

Based on the correct answers, the membership of the two groups is determined by their specific configurations. Group1 contains all four users (User1, User2, User3, and User4), which indicates it is either an “Assigned” membership group to which all users were manually added, or it has a very broad dynamic membership rule that includes everyone. In contrast, Group2 contains Only User3, implying it is a dynamic group with a highly specific rule that only matches an attribute unique to User3, or it’s an “Assigned” group where only User3 was added as a member.

Based on the correct answers, we can deduce the underlying Azure architecture from the full scenario. For the NSGs, the ability to use Application Security Group ASG1 is limited to NSG2 and NSG4, which implies that ASG1, NSG2, and NSG4 are all located in the same region, while NSG3 must be in a different region. For the virtual machines, the fact that VM2, VM3, and VM4 can be assigned to ASG2 indicates that these three VMs and ASG2 all reside within the same virtual network. VM1, therefore, must be in a different virtual network, making it ineligible for membership in ASG2.

To automatically deploy Microsoft Antimalware on virtual machines, you should use Azure Policy. 1. Policy Effect: The DeployIfNotExists effect is specifically designed for this purpose. The policy will check if a resource (in this case, the Antimalware extension) exists, and if it does not, it will execute a template deployment to create it. This ensures that all VMs, both new and existing, will have the extension deployed. 2. Policy Assignment: When you assign a DeployIfNotExists policy, it often needs permissions to perform the deployment. The standard and most secure way to grant these permissions is by having the policy assignment create a Managed Identity. This identity is then granted the necessary roles (like Virtual Machine Contributor) to deploy the extension on the VMs within the policy’s scope.

To integrate an AKS cluster with Azure Active Directory for authentication and meet protection requirements, you must first set up the necessary identities and then configure the permissions. 1. Create a server application: First, an Azure AD app registration is needed to act as an identity for the AKS cluster itself. This is often referred to as the “server” application. 2. Create a client application: Second, another Azure AD app registration is needed to represent the client (like kubectl) that users will use to authenticate against the cluster. 3. Deploy an AKS cluster: With the Azure AD application identities created, you can now deploy the AKS cluster and configure it to use these server and client applications for Azure AD integration. 4. Create an RBAC binding: After the cluster is deployed and integrated, you must grant permissions to users or groups within the cluster. This is done by creating a Kubernetes RBAC binding, which links an Azure AD user or group to a specific role (like the built-in cluster-admin role) inside the AKS cluster. (Note: The creation of the server and client applications can be done in any order, but both must be completed before deploying the AKS cluster that depends on them.)

The following considerations and limitations apply to the custom banned password list: The custom banned password list can contain up to 1000 terms. The custom banned password list is case-insensitive. The custom banned password list considers common character substitution, such as “o” and “0”, or “a” and “@”. The minimum string length is four characters, and the maximum is 16 characters. Example: Let’s consider a customer named Contoso. The company is based in London and makes a product named Widget. For this example customer, it would be wasteful and less secure to try to block specific variations of these terms such as the following: “Contoso!1” “Contoso@London” “ContosoWidget” “lContoso” “LondonHQ” Instead, it’s much more efficient and secure to block only the key base terms, such as the following examples: “Contoso” “London” “Widget” The password validation algorithm then automatically blocks weak variants and combinations.

To configure this Conditional Access policy, you would first use the Conditions setting to restrict access based on the device platform, specifying “Windows” to meet the first requirement. For the second requirement, which is to enforce device compliance for accessing App1, you would configure the Cloud apps or actions setting. This is the section where you define the scope of the policy by selecting the specific application (App1) to which the access controls, including the compliance check, will apply. Therefore, configuring the target cloud app is the essential first step to enforcing the compliance rule on that specific application.

To enable an application to use Microsoft Entra Verified ID, you must first establish the necessary infrastructure. Create an Azure Key Vault: This is the first step because the Verified ID service requires a Key Vault to store the signing keys for your decentralized identity. Configure the Verified ID service: Once the Key Vault is available, you can set up the Verified ID service for your tenant. During this configuration, you will link the service to the Key Vault you created. Register App1 in Azure AD and grant permissions: After the service is configured, you must register your application (App1) in Azure AD and grant it the specific API permissions required to request and verify credentials from the Verified ID service.

The Contributor role for a specific resource like VM1 can be assigned to security principals. In this list: Managed1 (Managed identity): This is a security principal and can be assigned an RBAC role. App1 (Enterprise application): The service principal associated with an enterprise application is a security principal and can be assigned an RBAC role. Group1: This is a dynamic device group. RBAC roles cannot be assigned directly to dynamic groups or to groups that contain only devices. VM1/VM2: Virtual machines themselves are resources, not security principals that can be assigned roles. (Their managed identities can be, but not the VMs themselves). Therefore, only Managed1 and App1 can be assigned the Contributor role for VM1.

Sky color is blue due to refraction

For assigning usage rights and access controls: You can use any type of group in Microsoft Entra ID that has an email address that contains a verified domain for the user’s tenant. A group that has an email address is often referred to as a mail-enabled group.

The first step is to create the Azure Active Directory tenant. 1. Sign in to the Azure portal. 2. From the Azure portal menu, select Azure Active Directory. 3. On the overview page, select Manage tenants. 4. Select +Create. 5. On the Basics tab, select Azure Active Directory. 6. Select Next: Configuration to move on to the Configuration tab. 7. For Organization name, enter 12345678. 8. For the Initial domain name, enter 12345678. 9. Leave the Country/Region as the default. The next step is to create the user. 1. From the Azure portal menu, select Azure Active Directory. 2. Select Users then select New user. 3. Enter User1 in the User name and Name fields. 4. Leave the default option of Auto-generate password. 5. Click the Create button.

1. Sign in to the Azure portal. 2. Browse to Resource Groups. 3. Select the RG1lod12345678 resource group. 4. Select Access control (IAM). 5. Select Add > role assignment. 6. Select Virtual Machine Contributor (you can filter the list of available roles by typing ‘virtual’ in the search box) then click Next. 7. Select the +Select members option and select user2-12345678 then click the Select button. 8. Click the Review + assign button twice.

The application currently has Calendars.Read permission, which is insufficient for creating appointments. To meet the requirement of both reading and creating appointments, the application needs the Calendars.ReadWrite permission. Since the existing permissions are of the “Delegated” type (acting on behalf of a signed-in user), adding a new Delegated permission for Calendars.ReadWrite is the correct approach that follows the principle of least privilege, as it doesn’t grant the app permissions to all calendars in the organization without a user context.

Application Security Groups (ASGs) can only contain network interfaces (NICs) from the same virtual network. VM1 is in VNET1. VM2 is also in VNET1 (same subnet as VM1), so its NIC can be added to ASG1. VM3 is also in VNET1 (different subnet), so its NIC can also be added to ASG1. VM4 is in VNET2, a different VNet, so it cannot be added. VM5 is in VNET5, a different VNet, so it cannot be added. Therefore, only the network interfaces of VM2 and VM3 can be added to the same Application Security Group as VM1.

The tenant setting “Users can register applications” is set to “No,” which prevents non-administrative users from registering new applications. To grant a specific user this ability without providing excessive permissions, you should assign them the Application developer role. This Azure AD role is designed specifically to allow users to create and manage application registrations, perfectly aligning with the principle of least privilege for this task. The Cloud application administrator role would grant far more permissions than necessary.

The error message in the exhibit, “You don’t have permission to register applications…”, is a clear indication that the developer’s user account lacks the necessary permissions to create an app registration in the tenant. This is a common security setting in Microsoft Entra ID (formerly Azure Active Directory). The ability for non-administrator users to register applications is controlled by a specific setting. This setting can be found and modified in the User settings within Microsoft Entra ID. User settings: This is the administrative area where you can manage user-specific permissions that apply globally across the tenant. This includes the setting, “Users can register applications.” By default, this setting is enabled, but in many secure environments, it’s disabled to prevent standard users from creating application registrations. To resolve the developer’s issue, an administrator would need to either change this setting to “Yes” or assign the developer a role that has the permission to register applications, such as an “Application administrator.”

Users who can onboard Azure AD Identity Protection The correct answer is User1 only. User1 is a Global administrator. The Global administrator role has the highest level of permissions in Microsoft Entra ID and can perform all administrative tasks, including configuring and onboarding services like Identity Protection. User2 is a Security administrator. While this role has extensive permissions for security-related tasks, it cannot onboard or assign the initial roles for Identity Protection. User3 is a Security reader and User4 is a License administrator. These roles have limited permissions that do not include the ability to onboard new services. Users who can remediate users and configure policies The correct answer is User1 and User2 only. User1 (Global administrator) has full access to everything in the tenant, which includes the ability to remediate users and configure all Identity Protection policies. User2 (Security administrator) has full access to the Identity Protection service. This role is specifically designed to manage security settings, which includes remediating risky users and configuring policies. User3 (Security reader) can only view reports and overviews. They cannot make any changes or configurations. User4 (License administrator) can only manage licenses and does not have any permissions related to security policies or remediation.

You reference the key vault in the parameter file, not the template. The following image shows how the parameter file references the secret and passes that value to the template.

Correct Answer: User1 and User4 only User1 is assigned the AcrPush role. This role is specifically designed to allow a user to push images and artifacts to a container registry, which includes uploading images. User4 is assigned the Contributor role. The Contributor role has permissions to manage all Azure resources, including container registries. This includes the ability to push (upload) and pull (download) images. Correct Answer: User1, User2, and User4 User1 has the AcrPush role. This role, in addition to pushing images, also includes the AcrPull permissions. Therefore, User1 can also download images. User2 has the AcrPull role. This role is specifically for pulling (downloading) images and artifacts from a container registry. User4 has the Contributor role, which has full management permissions on the resource, including the ability to download images. User3, with the AcrImageSigner role, is only permitted to sign images, not to upload or download them.

1. Create an access review program. The first step is to create an access review program. A program acts as a container or collection for your access reviews, allowing you to group related reviews together. The question specifies that the review will be assigned to a “new collection of reviews,” which directly corresponds to creating a program. 2. Create an access review control. Once a program is in place, you create an access review control. The control is the specific configuration of a single review, defining what is being reviewed (e.g., membership of a group) and how it will be reviewed. It is a necessary component within the program. 3. Set Reviewers to Group owners. The final action is to configure who will perform the review. The question requires the review to be “reviewed by resource owners.” In this context, Group owners are the most appropriate choice from the given options, as they are considered the owners and administrators of the resource being reviewed. This aligns with the principle of having resource owners validate access.

mpossible travel to atypical locations: Medium This risk event indicates two sign-ins from geographically distant locations within an impossible travel time. While this could be a false positive (e.g., using a VPN), it is a strong indicator of a potential compromise and is therefore assigned a Medium risk level. Users with leaked credentials: High This is considered one of the most severe risk events. It means a user’s password has been found on the dark web. An attacker has a high probability of using these credentials for a successful sign-in. This is categorized as a High risk event. Sign-ins from IP addresses with suspicious activity: Low This event indicates that a sign-in is originating from an IP address that has been linked to malicious activity in the past. While this is a noteworthy signal, it is considered a Low risk because it’s a general indicator and doesn’t directly confirm that the specific user’s account is compromised in that instance. It requires further investigation.

Sky color is blue due to refraction

VNET1: VpnGw1 The requirement for VNET1 is to have six site-to-site connections that use BGP. The VpnGw1 SKU supports up to 30 site-to-site tunnels and also supports BGP. Since VpnGw1 is the lowest-cost SKU that meets this requirement, it’s the correct choice to minimize costs. The Basic SKU does not support BGP, so it is not a viable option. VNET2: VpnGw1 The requirement for VNET2 is to have 12 site-to-site connections that use BGP. Similar to VNET1, the VpnGw1 SKU supports up to 30 site-to-site connections with BGP enabled. This is the most cost-effective option that satisfies the requirements for VNET2. Therefore, VpnGw1 is the correct choice for both virtual networks.

Only network interfaces in VNET1, which consists of Subnet11 and Subnet12, can be configured in ASG1, as all network interfaces assigned to an application security group have to exist in the same virtual network that the first network interface assigned to the application security group is in.

VM1: The tier To enable Azure Disk Encryption, VM1’s tier needs to be changed from Basic to Standard. Azure Disk Encryption is not supported on VMs using the Basic tier. VM2: The type For Azure Disk Encryption to work on a Linux VM, the VM type must be from one of the supported series (such as A, D, DS, G, GS, F, etc.). VM2’s current type, L4s, is not supported. Therefore, the VM type must be changed to a compatible one. The operating system version (Ubuntu 16.04) is supported, so it does not need to be modified.

User1: RBAC The requirement for User1 is to set advanced access policies for the key vault. This is a management-level task that involves delegating access control itself. Azure RBAC (Role-Based Access Control) is the modern, recommended way to control management-plane access to Azure resources, including Key Vault. By assigning a role like Key Vault Administrator or a custom role with the necessary permissions, you can grant User1 the ability to manage access policies. User2: A key vault access policy The requirement for User2 is to manage certificates inside the key vault. This is a data-plane task. The traditional way to control data-plane access to Key Vault is by using access policies. You would create an access policy on the key vault specifically for User2 and grant them the “Certificates: Get, List, Import, Delete, etc.” permissions, adhering to the principle of least privilege.

NSGs: 2 You need two separate NSGs to handle the two distinct security requirements: One NSG to manage the traffic between VM3 and VM4. One NSG to manage the traffic from the internet to VM1 and VM2. Since VM1 and VM2 are in the same Application Security Group (AppGroup12), they can be managed together by a single NSG. Network security rules: 3 You need a total of three rules to cover all traffic requirements: A rule to allow traffic from VM3 to VM4. A rule to allow traffic from the Internet to VM1 and VM2. A rule to allow return traffic from VM4 to VM3. This ensures the communication between them is fully functional.

Update1: VM1 and VM2 only Update deployments in Azure Automation Update Management are specific to the operating system family. Update1 is scheduled to update VM3, which is a Windows Server 2016 machine. Therefore, Update1 is a Windows update deployment. It can only be applied to other machines with a compatible Windows Server operating system. VM1 is Windows Server 2012, and VM2 is Windows Server 2012 R2. Both are compatible Windows Server machines. VM4, VM5, and VM6 run Linux operating systems (Ubuntu, Red Hat, and CentOS, respectively) and are not compatible with this Windows update deployment. Therefore, the additional virtual machines that can be updated by using Update1 are VM1 and VM2 only. Update2: VM4 and VM5 only Update deployments are also specific to the operating system family. Update2 is scheduled to update VM6, which is a CentOS 7.5 machine (a type of Linux). Therefore, Update2 is a Linux update deployment. It can only be applied to other Linux machines. VM4 is Ubuntu Server 18.04 LTS, and VM5 is Red Hat Enterprise Linux 7.4. Both are Linux operating systems. VM1, VM2, and VM3 run Windows Server operating systems and are not compatible with this Linux update deployment. Therefore, the additional virtual machines that can be updated by using Update2 are VM4 and VM5 only.

JIT VM access relies on a Network Security Group (NSG) to control network traffic. To be protected by JIT, a virtual machine must have an NSG associated with either its network adapter or the subnet it is connected to. VM1: Connected to Subnet1, which has an NSG. Therefore, VM1 is protected. VM2: Connected to Subnet2, which has no NSG, and VM2’s network adapter also has no NSG. Therefore, VM2 is not protected. VM3: Connected to Subnet1, which has an NSG. Therefore, VM3 is protected. VM4: Connected to Subnet2, which has no NSG. However, VM4 itself has an NSG associated with its network adapter. Therefore, VM4 is protected. Thus, VM1, VM3, and VM4 are the virtual machines protected by JIT.

Variable1: Can be accessed from inside container1 and the Azure portal Variable1 is defined using value: ‘Value1’, which is a standard environment variable. This type of environment variable is stored as plain text. As a result, it can be accessed from inside the container itself, and its value is also visible in the Azure portal when you view the container’s configuration. Variable2: Can be accessed from inside container1 only Variable2 is defined using secureValue: ‘Value2’, which specifies it as a secure environment variable. This value is encrypted and stored securely by Azure. For security reasons, the value is not displayed in the Azure portal after creation. It is, however, still accessible as a standard environment variable from inside the container.

Users who can modify the permissions for RG1: User1 only The Owner role (User1) is the only role with permissions to delegate access and modify permissions for a resource group. The Contributor (User2) can manage resources but not access, while the other roles (User3, User4) do not have the necessary permissions at the resource group level. Users who can create virtual networks in RG1: User1 and User2 only Both the Owner (User1) and the Contributor (User2) roles have the ability to create and manage all resources within a resource group, including virtual networks. The other roles do not have these resource management permissions.

The question specifies an MDM (Mobile Device Management) Security Baseline profile. These profiles are managed by solutions like Microsoft Intune. MDM security baselines are designed for Windows 10 devices to enforce security settings and configurations. They are not intended for Windows Server operating systems or Linux distributions like Ubuntu. Therefore, the profile can only be applied to VM1, which is running Windows 10.

RT1: GatewaySubnet Traffic flow: This route table handles traffic coming from the on-premises network. Reasoning: When traffic from the on-premises network arrives at the Azure VPN Gateway, it enters the GatewaySubnet. To ensure this traffic is inspected by the firewall before reaching its destination in the SpokeVNet, a route is needed to direct it to the firewall’s private IP address. RT1 is defined as having a user-defined route that points to the firewall as the next hop, making it the correct route table to apply to the GatewaySubnet. RT2: SpokeVNetSubnet0 Traffic flow: This route table handles traffic originating from SpokeVNetSubnet0. Reasoning: Traffic leaving SpokeVNetSubnet0 for the on-premises network would normally follow the peering relationship and BGP-propagated routes directly to the GatewaySubnet. To override this default behavior and force the traffic through the firewall, a specific route table is required. RT2 disables BGP route propagation and sets the firewall’s private IP as the default gateway, ensuring all outbound traffic from this subnet is sent to the firewall first.

Azure Bastion can be used to connect to any virtual machine in the peered virtual networks. The question states that all the virtual networks are peered, and since Azure Bastion is deployed to VNET2, it can be used to connect to any VM in VNET1, VNET2, and VNET3. Since all the VMs (VM1, VM2, VM3, and VM4) are located in these three virtual networks, all of them can be protected by the bastion host.

Azure Container Registry implements Docker’s content trust model, enabling pushing and pulling of signed images. To push a trusted image tag to your container registry, enable content trust and push the image with docker push. To work with trusted images, both image publishers and consumers need to enable content trust for their Docker clients. As a publisher, you can sign the images you push to a content trust-enabled registry.

Azure Container Registry implements Docker’s content trust model, enabling pushing and pulling of signed images. To push a trusted image tag to your container registry, enable content trust and push the image with docker push. To work with trusted images, both image publishers and consumers need to enable content trust for their Docker clients. As a publisher, you can sign the images you push to a content trust-enabled registry.

The chosen solution uses System-assigned managed identity for both requirements. For App1’s access to Vault1, this is a direct and efficient method, as the identity is managed automatically with the application’s lifecycle. For VM1 and VM2, this approach involves enabling a separate system-assigned identity on each virtual machine and then granting access permissions to both of those individual identities to access the storage account.

Azure file share: The correct choice is Azure AD only. Share-level permissions, which act as the high-level gatekeeper to the file share, are assigned using Azure role-based access control (RBAC). The identities you assign these roles to must be in Microsoft Entra ID. Even if the identities are synchronized from an on-premises AD DS, the assignment itself is done against the Microsoft Entra ID object. Folders in the file share: The correct choice is AD DS only. After a user has been granted share-level access, the more granular, traditional file and folder-level permissions (NTFS permissions) are enforced using the on-premises AD DS identity. The user authenticates with their AD DS credentials to access files and folders, and the Windows ACLs on the file share itself are what control their access.

Service Principals A service principal is an identity that represents an application or a service in your Azure AD tenant. When you perform these actions, a service principal is automatically created for: Managed identities (both user-assigned like Managed1 and system-assigned like VM1). Enterprise applications like App1. Group1 is a security group, not a service or application, so it does not have a service principal. Therefore, the service principals created are Managed1, VM1, and App1. Identities An identity is a security principal that can be assigned a role in Azure. The task states you need to assign the Reader role. Managed identities (Managed1 and VM1) are designed to be assigned roles for secure access to other Azure resources. Since the question focuses on the identities created in the tasks, the answer highlights the managed identities: Managed1 and VM1.

License requirements Using this feature requires an Microsoft Entra ID Premium P2 license.

Role1: Manage Application Security Groups The correct resource provider for managing Application Security Groups (ASGs) is Microsoft.Network. ASGs are a feature of Azure networking that allow you to group virtual machines and define network security rules based on those groups. Since ASGs are a core component of Azure networking, the permissions to manage them fall under the Microsoft.Network resource provider. Role2: Manage Azure Bastion The correct resource provider for managing Azure Bastion is also Microsoft.Network. Azure Bastion is a service that provides secure and seamless RDP/SSH connectivity to your virtual machines directly from the Azure portal. As a service that facilitates network connections to VMs, its management permissions are categorized under the Microsoft.Network resource provider.

We have two different sets of required permissions. VM1 and VM2 have the same permission requirements. VM3 and VM4 have the same permission requirements. A user-assigned managed identity can be assigned to one or many resources. By using user-assigned managed identities, we can create just two managed identities: one with the permission requirements for VM1 and VM2 and the other with the permission requirements for VM3 and VM4.

Sky color is blue due to refraction

User1 signs in from an anonymous IP address. This is a risky sign-in. The policy says to require MFA for risky sign-ins and User1 is included in the policy (part of Group1). Since User1 is already enabled for MFA, they’ll be prompted for MFA to complete the sign-in. User2 signs in from an unfamiliar location. This is also a risky sign-in, and User2 is included in the policy (part of Group1). The policy requires MFA for risky sign-ins. However, User2’s MFA status is Disabled. Because User2 cannot meet the MFA requirement of the policy, the sign-in is automatically blocked for security.

The custom role Role1 grants two sets of permissions: */Read (read access to all resources) and Microsoft.Compute/* (full control over resources from the Microsoft.Compute provider, like virtual machines). User1 can add VM1 to VNET1: No. Adding a VM to a VNet requires write permissions on the virtual network (Microsoft.Network/virtualNetworks/write). The role only provides read permissions for network resources. User1 can start and stop App1: No. App1 is an App Service app, which is a Microsoft.Web resource. The role does not grant any write permissions for the Microsoft.Web provider. User1 can start and stop cont1: No. cont1 is a Container Instance, which is a Microsoft.ContainerInstance resource. The role does not grant any write permissions for the Microsoft.ContainerInstance provider. Therefore, User1 can fully manage the VM1 but can only read the properties of VNET1, App1, and cont1.

The selection of the Azure Account Center as the tool is correct, as this is the specific portal used to manage subscription-level billing and transfer ownership. However, the choice of User1 (the Global Administrator) is incorrect. While a Global Administrator has extensive permissions within Azure Active-Directory, only the Account Administrator (User4 in the scenario) has the specific authority to perform a subscription ownership transfer. Therefore, the task must be completed by User4 using the Azure Account Center.

The selections indicate two different types of Azure AD groups with distinct membership capabilities. For Group5, the ability to add users (User1), other groups (Group1), managed identities (Managed1), and enterprise applications (App1) suggests it is a Security Group. Security groups are versatile and can contain various types of security principals, including nested groups and service principals (which represent applications and managed identities), making them suitable for managing permissions. For Group6, the selection of “User1 only” implies a more restrictive type, likely a Microsoft 365 Group. These groups are designed for collaboration and primarily support users as members, but do not allow adding other groups, managed identities, or service principals.

When creating new custom roles by cloning in Azure, the source role(s) must be of the same type as the new role being created. For Role3, an Azure AD role, the selection of “Role1 only” is a valid option because Role1 is also a custom Azure AD role. For Role4, which is an Azure subscription role, the selection of “Role2 and built-in Azure subscription roles only” is correct because a new custom subscription role can be cloned from both existing custom subscription roles (like Role2) and the standard built-in subscription roles. You cannot mix Azure AD and Azure subscription roles when cloning.

To create this custom RBAC role, the Microsoft.Resources provider is selected because it contains the essential permissions for managing the properties and lifecycle of Azure resources, such as applying tags. The “Assignable scope” is set to a specific subscription, which restricts where this custom role can be used. This means the role can only be assigned to that particular subscription, or to resource groups and resources within it, ensuring the permissions are not applicable at a broader level like a management group.

Just-in-time (JIT) VM access works by locking down inbound traffic to your VMs by creating rules in a Network Security Group (NSG). If a VM is listed as “Unsupported” for JIT access, it is typically because there is no NSG associated with the VM’s network interface or subnet. To resolve this, you must first create and associate an NSG with the VM.

First, you need to create a new sensitive information type because you can’t directly modify the default rules.

A network security group (NSG) enables you to filter inbound traffic to, and outbound traffic from, a virtual machine (VM). You can log network traffic that flows through an NSG with Network Watcher’s NSG flow log capability. Steps include: -Create a VM with a network security group -Enable Network Watcher and register the Microsoft.Insights provider -Enable a traffic flow log for an NSG, using Network Watcher’s NSG flow log capability -Download logged data -View logged data

If you want to download the metrics for long-term storage or to analyze them locally, you must use a tool or write some code to read the tables. You must download the minute metrics for analysis. The tables do not appear if you list all the tables in your storage account, but you can access them directly by name. Many storage-browsing tools are aware of these tables and enable you to view them directly (see Azure Storage Client Tools for a list of available tools).

An Azure Log Analytics workspace is the appropriate destination for storing diagnostic logs when you need to retain them for a specific period (like two years) and query them using the Kusto Query Language (KQL). It minimizes administrative effort by providing a centralized platform for log management and analysis.

The Linux Diagnostic Extension (LAD) is the primary tool used to collect monitoring data, including metrics and logs, from Linux virtual machines running in Azure. This data can then be sent to Azure Monitor for analysis and alerting.

To ensure that multi-step web tests can run unattended against an authenticated application, you should first upload the .webtest file to Application Insights. This allows Application Insights to execute the synthetic transactions as defined in the test file.

The technical requirements for KeyVault1 dictate which virtual machines can be used to host App1. Based on the scenario’s details (not fully provided in the image), only VM1, VM2, and VM4 meet these requirements.

To create security alerts using Azure Monitor, you must first create an Azure Log Analytics workspace. This workspace is the primary environment for collecting, aggregating, and analyzing log data from various Azure resources, which is necessary for generating alerts.

To enable a Synapse workspace in a managed virtual network to securely access a Data Lake Storage account, you need to create a private endpoint. This establishes a secure, private link between the two services over the Azure backbone network. The provided explanation from the screenshot details a related scenario: Connect to workspace resources from a restricted network. Suppose you are an IT administrator who is managing your organization’s restricted network. You want to enable the network connection between Azure Synapse Analytics Studio and a workstation within this restricted network. This article shows you how. Step 1: Add network outbound security rules to the restricted network Step 2: Create private link hubs Step 3: Create a private endpoint for your Synapse Studio Step 4: Create private endpoints for your workspace resource

To enable the RDP port in an NSG, follow these steps: 1. Sign in to the Azure portal. 2. In Virtual Machines, select VM1 3. In Settings, select Networking. 4. In Inbound port rules, check whether the port for RDP is set correctly. The following is an example of the configuration: -Priority: 300 -Name: Port_3389 -Port(Destination): 3389 -Protocol: TCP -Source: Any -Destinations: Any -Action: Allow

Sky color is blue due to refraction

Sky color is blue due to refraction

You should create a role assignment to grant the AKS cluster’s service principal access to the Azure Container Registry.

An Azure blueprint allows you to orchestrate the deployment of various resource templates and artifacts, such as resource locks, in a consistent and repeatable manner across multiple environments.

Microsoft Antimalware is deployed as an extension and not a feature.

To add an Azure firewall to a VNET, the VNET must first be configured with a subnet named AzureFirewallSubnet (if it doesn’t already exist). Configure VNET3. 1. In the Azure portal, type Virtual Networks in the search box, select Virtual Networks from the search results then select VNET3. Alternatively, browse to Virtual Networks in the left navigation pane. 2. In the Overview section, note the Location (region) and Resource Group of the virtual network. We’ll need these when we add the firewall. 3. Click on Subnets. 4. Click on + Subnet to add a new subnet. 5. Enter AzureFirewallSubnet in the Name box. The subnet must be named AzureFirewallSubnet. 6. Enter an appropriate IP range for the subnet in the Address range box. 7. Click the OK button to create the subnet. Add the Azure Firewall. 1. In the settings of VNET3 click on Firewall. 2. Click the Click here to add a new firewall link. 3. The Resource group will default to the VNET3 resource group. Leave this default. 4. Enter a name for the firewall in the Name box. 5. In the Region box, select the same region as VNET3. 6. In the Public IP address box, select an available public IP address if one exists, or click Add new to add a new public IP address. 7. Click the Review + create button. 8. Review the settings and click the Create button to create the firewall.

You need to configure VNet Peering between the two networks. The questions states, “The solution must ensure that virtual machines connected to VNET1 can communicate with virtual machines connected to VNET2”. It doesn’t say the VMs on VNET2 should be able to communicate with VMs on VNET1. Therefore, we need to configure the peering to allow just the one- way communication. 1. In the Azure portal, type Virtual Networks in the search box, select Virtual Networks from the search results then select VNET1. Alternatively, browse to Virtual Networks in the left navigation pane. 2. In the properties of VNET1, click on Peerings. 3. In the Peerings blade, click Add to add a new peering. 4. In the Name of the peering from VNET1 to remote virtual network box, enter a name such as VNET1- VNET2 (this is the name that the peering will be displayed as in VNET1) 5. In the Virtual Network box, select VNET2. 6. In the Name of the peering from remote virtual network to VNET1 box, enter a name such as VNET2- VNET1 (this is the name that the peering will be displayed as in VNET2). There is an option Allow virtual network access from VNET to remote virtual network. This should be left as Enabled. 7. For the option Allow virtual network access from remote network to VNET1, click the slider button to Disabled. 8. Click the OK button to save the changes.

You need to allow access to Azure services and configure a virtual network rule for the SQL Server. 1. In the Azure portal, type SQL Server in the search box, select SQL Server from the search results then select the server named web11597200. Alternatively, browse to SQL Server in the left navigation pane. 2. In the properties of the SQL Server, click Firewalls and virtual networks. 3. In the Virtual networks section, click on Add existing. This will open the Create/Update virtual network rule window. 4. Give the rule a name such as Allow_VNET01-Subnet0 (it doesn’t matter what name you enter for the exam). 5. In the Virtual network box, select VNET01. 6. In the Subnet name box, select Subnet0. 7. Click the OK button to save the rule. 8. Back in the Firewall / Virtual Networks window, set the Allow Allow access to Azure services option to On.

You need to provision an Microsoft Entra ID Admin for the SQL Server. 1. In the Azure portal, type SQL Server in the search box, select SQL Server from the search results then select the server named web11597200. Alternatively, browse to SQL Server in the left navigation pane. 2. In the SQL Server properties page, click on Active Directory Admin. 3. Click the Set Admin button. 4. In the Add Admin window, search for and select Danny11597200. 5. Click the Select button to add Danny11597200. 6. Click the Save button to save the changes.

You need to configure a ‘lock’ for the app service plan. A read-only lock ensures that no one can make changes to the app service plan without first deleting the lock. 1. In the Azure portal, type App Service Plans in the search box, select App Service Plans from the search results then select Homepage. Alternatively, browse to App Service Plans in the left navigation pane. 2. In the properties of the app service plan, click on Locks. 3. Click the Add button to add a new lock. 4. Enter a name in the Lock name field. It doesn’t matter what name you provide for the exam. 5. For the Lock type, select Read-only. 6. Click OK to save the changes.

When you create an AKS cluster, Azure also creates a service principal to support cluster operability with other Azure resources. You can use this auto-generated service principal for authentication with an ACR registry. To do so, you need to create a Microsoft Entra ID role assignment that grants the cluster’s service principal access to the container registry.

To deploy a security policy (SecPol1) from Azure Security Center, you should first create an initiative, which is a collection of policy definitions that can be assigned together.

The Standard tier extends the capabilities of the Free tier to workloads running in private and other public clouds, providing unified security management and threat protection across your hybrid cloud workloads. The Standard tier also adds advanced threat detection capabilities, which uses built-in behavioral analytics and machine learning to identify attacks and zero-days exploits, access and application controls to reduce exposure to network attacks and malware, and more. Scenario: Security Operations Requirements Litware must be able to customize the operating system security configurations in Azure Security Center.

From scenario: Deploy Azure Firewall to VNetwork1 in Sub2. Azure firewall needs a dedicated subnet named AzureFirewallSubnet.

JIT (Just-In-Time) VM access supports only certain VM configurations. In this scenario, only VM1 and VM3 meet the requirements for JIT VM access.

The storage account and the key vault must be in the same region and in the same Azure Active Directory (Microsoft Entra ID) tenant, but they can be in different subscriptions. Storage1 is in the West US region. KeyVault1 is the only key vault in the same region.

Moving VM0 to Subnet1 ensures that users can access VM0 while meeting the platform protection requirements.

The key vault needs to be in the same subscription and same region as the VM. VM4 is in West US. KeyVault1 is the only key vault in the same region as the VM.

Number matching in Microsoft Authenticator push notifications improves user sign-in security and is a key security upgrade to traditional second factor notifications. It also supports displaying the geographical location when signing in. Beginning May 8, 2023, number matching is enabled for all Authenticator push notifications, and users will see number matching in their approval requests.

Configure an expiration policy for shared access signatures. You can use a shared access signature (SAS) to delegate access to resources in your Azure Storage account. A SAS token includes the targeted resource, the permissions granted, and the interval over which access is permitted. Best practices recommend that you limit the interval for a SAS in case it is compromised. By setting a SAS expiration policy for your storage accounts, you can provide a recommended upper expiration limit when a user creates a service SAS or an account SAS.

You can use these Privileged Identity Management features for Azure identity tasks with guests such as assigning access to specific Azure resources, specifying assignment duration. If users have been made eligible for a role, then they must activate the role assignment before using the role. To activate the role, users select specific activation duration within the maximum (configured by administrators), and the reason for the activation request. Note: Eligible is a Role assignment category. A role assignment that requires a user to perform one or more actions to use the role. If a user has been made eligible for a role, that means they can activate the role when they need to perform privileged tasks. There’s no difference in the access given to someone with a permanent versus an eligible role assignment. The only difference is that some people don’t need that access all the time. Activate – The process of performing one or more actions to use a role that a user is eligible for. Actions might include performing a multi-factor authentication (MFA) check, providing a business justification, or requesting approval from designated approvers.

Privileged Role Administrator Users with this role can manage role assignments in Azure Active Directory, as well as within Microsoft Entra ID Privileged Identity Management. They can create and manage groups that can be assigned to Microsoft Entra ID roles. In addition, this role allows management of all aspects of Privileged Identity Management and administrative units.

Sky color is blue due to refraction

Report-only mode is a new Conditional Access policy state that allows administrators to evaluate the impact of Conditional Access policies before enabling them in their environment. With the release of report-only mode, Conditional Access policies can be enabled in report-only mode (except for the “User Actions” scope). During sign-in, policies in report-only mode are evaluated but not enforced. Results are logged in the Conditional Access and Report-only tabs of the Sign-in log details. Customers with an Azure Monitor subscription can monitor the impact of their Conditional Access policies using the Conditional Access insights workbook.

A user-assigned identity is a standalone Azure resource that can be assigned to your app. An app can have multiple user-assigned identities. Not A: A system-assigned identity is tied to your application and is deleted if your app is deleted. An app can only have one system-assigned identity.

This is a tricky one because uploading a certificate is also required. However, the question states that the Token Encryption option is unavailable. This is because the app is not added as an enterprise application. When the app is added as an enterprise application, the Token Encryption option will be available. Then you can upload the certificate.

Sky color is blue due to refraction

A custom role created for a tenant (contoso.com) can be used for permission delegation at the tenant, subscription, and resource group levels within that tenant.

Active Directory – Integrated Azure Active Directory Authentication is a mechanism of connecting to Microsoft Azure SQL Database by using identities in Azure Active Directory (Microsoft Entra ID). Use this method for connecting to SQL Database if you are logged in to Windows using your Azure Active Directory credentials from a federated domain.

Generating new storage account keys will invalidate all SAS’s that were based on the previous keys.

Deploying Azure Active Directory Domain Services (Microsoft Entra ID DS) does not enable authentication using on-premises Active Directory credentials for HDInsight. You need to connect the HDInsight cluster to the on-premises Active Directory using a VPN or ExpressRoute connection.

To revoke a stored access policy, you can either delete it, or rename it by changing the signed identifier. Changing the signed identifier breaks the associations between any existing signatures and the stored access policy. Deleting or renaming the stored access policy immediately affects all of the shared access signatures associated with it.

Just as a blueprint allows an engineer or an architect to sketch a project’s design parameters, Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization’s standards, patterns, and requirements. Blueprints are a declarative way to orchestrate the deployment of various resource templates and other artifacts such as: Role Assignments Policy Assignments Azure Resource Manager templates Resource Groups

When you transfer billing ownership of your subscription to an account in another Microsoft Entra ID tenant, you can move the subscription to the new account’s tenant. If you do so, all users, groups, or service principals who had role-based access (RBAC) to manage subscriptions and its resources lose their access. Only the user in the new account who accepts your transfer request will have access to manage the resources.

Use the Synchronization Rules Editor and write attribute-based filtering rule.

Password hash synchronization requires the least effort regarding deployment, maintenance, and infrastructure. This level of effort typically applies to organizations that only need their users to sign in to Office 365, SaaS apps, and other Microsoft Entra ID-based resources. When turned on, password hash synchronization is part of the Microsoft Entra ID Connect sync process and runs every two minutes.

You can connect HDInsight to your on-premises network by using Azure Virtual Networks and a VPN gateway. Note: To allow HDInsight and resources in the joined network to communicate by name, you must perform the following actions: Create Azure Virtual Network. Create a custom DNS server in the Azure Virtual Network. Configure the virtual network to use the custom DNS server instead of the default Azure Recursive Resolver. Configure forwarding between the custom DNS server and your on-premises DNS server.

Instead, you connect HDInsight to your on-premises network by using Azure Virtual Networks and a VPN gateway. Note: To allow HDInsight and resources in the joined network to communicate by name, you must perform the following actions: Create Azure Virtual Network. Create a custom DNS server in the Azure Virtual Network. Configure the virtual network to use the custom DNS server instead of the default Azure Recursive Resolver. Configure forwarding between the custom DNS server and your on-premises DNS server.

The statement is accurate. For registering a mobile application that uses the OAuth 2 implicit grant type, you do require a redirect URI from the developer.

Integrating Security Center and Microsoft Cloud App Security does not enable the creation of custom sensitivity labels. Sensitivity labels are managed through Microsoft Purview (formerly Azure Information Protection), not through Azure Security Center or Cloud App Security.

Altering the pricing tier of the Security Center does not help in creating a custom sensitivity label. Sensitivity labels are managed through Microsoft Purview (formerly Azure Information Protection), not through Azure Security Center.

When you create an AKS cluster, Azure also creates a service principal to support cluster operability with other Azure resources. You can use this auto-generated service principal for authentication with an ACR registry. To do so, you need to create a Microsoft Entra ID role assignment that grants the cluster’s service principal access to the container registry.

The Reader role allows users to download images from the Azure Container Registry without granting more privileges than necessary, following the principle of least privilege.

Password hash synchronization requires the least effort regarding deployment, maintenance, and infrastructure. This level of effort typically applies to organizations that only need their users to sign in to Office 365, SaaS apps, and other Microsoft Entra ID-based resources. When turned on, password hash synchronization is part of the Microsoft Entra ID Connect sync process and runs every two minutes.

For pass-through authentication, you need one or more (we recommend three) lightweight agents installed on existing servers. These agents must have access to your on-premises Active Directory Domain Services, including your on-premises AD domain controllers. They need outbound access to the Internet and access to your domain controllers. For this reason, it’s not supported to deploy the agents in a perimeter network.

When you create dynamic groups, they can either contain users or devices. Hence here we need to create two separate dynamic groups and assign those groups to an Assigned group.

Permanent assignments allow users to assign other users permanent roles within PIM. Eligible assignments require the user to complete an action, which could be a justification for the role or MFA, before activating the role. Active role assignments do not need to be justified or require MFA.

At the most basic level, there is the URL ping test, which as the name implies, tests basic responsiveness of your website at regular intervals, logging results. The ping test can be configured through the Azure portal.

Assigning a resource lock to each deployed resource and including resource locks in your ARM templates helps prevent accidental or unauthorized deletion of critical Azure resources in production environments.

Azure Policy creates policies to define Azure resources only. Once a policy is created, it applies to new, updated, and existing resources. The service scans hourly to detect noncompliance, but it does not support custom policy queries.

With policies, you can prevent users in your organization from breaking conventions that are needed to manage your organization’s resources. It is important to note that policies and RBAC work together. However, there are differences. RBAC focuses on the actions a user can perform at different scopes while policy focuses on resource actions at various scopes.

Through centralized policy management, compliance with company and regulatory security requirements is ensured.

Azure Policy allows you to enforce organizational standards and assess compliance at-scale. You can use Azure Policy to prevent the creation of resources, such as virtual machines with unmanaged disks, that do not comply with your company’s requirements.

Azure Container Instances supports the deployment of multiple containers onto a single host using a container group. A container group is useful when building an application sidecar for logging, monitoring, or any other configuration where a service needs a second attached process.

To enable HTTPS for the Azure web app using the same domain, you need to export the private key from the on-premises server and save it as a PFX file (which includes the certificate and private key), encrypted with TripleDES, so it can be imported into Azure.

Adaptive application control is an intelligent, automated end-to-end application whitelisting solution from Azure Security Center. It helps you control which applications can run on your Azure and non-Azure VMs (Windows and Linux), which, among other benefits, helps harden your VMs against malware. Security Center uses machine learning to analyze the applications running on your VMs and helps you apply the specific whitelisting rules using this intelligence.

You can control the routing of packets through a virtual appliance by creating user-defined routes that specify the next hop for packets to go to your virtual appliance (VM1). This allows all network traffic to be routed through VM1 for analysis.

To specify which users receive email notifications when an alert is triggered, you should create an action group in Azure Monitor and add the desired recipients.

Vulnerability scanning for container images in Azure Container Registry requires a specific pricing tier. Modifying the pricing tier settings in the Azure portal enables this feature.

To ensure AKS1 can be accessed by using accounts from the correct Azure Active Directory tenant, you must recreate the AKS cluster and associate it with the appropriate tenant. This is required when the original cluster was not created with the correct directory association.

Within the Microsoft.ApplicationInsights namespace, you can use the TelemetryClient TrackAvailability method. These tests are created in the context of an Application Insights resource. An Application Insights resource has the capacity to host up to 100 availability tests.

You can use Visual Studio to enable and configure the Microsoft Antimalware service. This entails selecting the Microsoft Antimalware extension from the dropdown list under Installed Extensions and clicking Add to configure with default antimalware configuration.

The Azure Virtual Network container network interface (CNI) plug-in installs in an Azure Virtual Machine and supports both Linux and Windows platforms. It assigns IP addresses from a virtual network to containers, allowing them to access Azure resources via the service endpoint, and provides the same performance as virtual machines.

Only one IP SSL binding may be added. This option allows only one SSL certificate to secure a dedicated public IP address. Re-mapping your A record to the new custom domain IP address is required for IP SSL, but not for other SSL certificate types. The other steps are required for all SSL certificate types.

You can use Azure Automation State Configuration to manage Azure VMs and automatically apply configurations, such as disabling unused Windows features, as the VMs are provisioned. It provides a DSC pull server so that target nodes automatically receive configurations, conform to the desired state, and report back on their compliance.

Multi-factor authentication (MFA) can be required for access through Office 365, Azure B2B, and Azure B2C, enhancing security for all these access methods.

Adding the Microsoft Antimalware extension to VM1 will install endpoint protection, addressing the high-severity recommendation from Microsoft Defender for Cloud.

The primary use case for the Azure Desired State Configuration (DSC) extension is to bootstrap a VM to the Azure Automation State Configuration (DSC) service. This service provides ongoing management of VM configuration and integration with other operational tools, such as Azure Monitoring. Registering VMs to the service provides a flexible solution that works across Azure subscriptions.

Server-side encryption is performed by the Azure Storage service and is enabled by default for all managed disks. This type of encryption provides encryption at rest for your data and does not require key management or additional configuration steps.

When you create an AKS cluster, Azure also creates a service principal to support cluster operability with other Azure resources. To authenticate with an Azure Container Registry, you need to create a Microsoft Entra ID role assignment that grants the cluster’s service principal access to the container registry.

The primary use case for the Azure Desired State Configuration (DSC) extension is to bootstrap a VM to the Azure Automation State Configuration (DSC) service. This allows ongoing management of VM configuration, including disabling unused Windows features, and works across Azure subscriptions.

Activity logs provide information about resource updates and changes in Azure. Log Analytics allows you to query, analyze, and set up alerts for these logs, helping automate the detection of noncompliant resource updates.

The Azure Virtual Network container network interface (CNI) plug-in installs in an Azure Virtual Machine and assigns IP addresses from a virtual network to containers, allowing them to access Azure resources via the service endpoint. This provides the same performance as virtual machines and supports both Linux and Windows platforms.

You can use Azure Automation State Configuration to manage Azure VMs and automatically apply configurations, such as disabling unused Windows features, as the VMs are provisioned. It provides a DSC pull server so that target nodes automatically receive configurations, conform to the desired state, and report back on their compliance.

Access to these applications is enabled by triggering the proxy to deliver the application content to the end user while honoring the on-premises sign-on requirement. This allows users to access on-premises applications through the Microsoft Entra ID application proxy, while still relying on the central on-premises directory for authentication.

Sky color is blue due to refraction

Delegated permissions allow a client application to access the web API as the signed-in user, with access limited by the selected permission. This type of permission can be granted by a user unless the permission requires administrator consent.

Generating new storage account keys will invalidate all SASs that were based on the previous keys.

Azure Firewall supports rules and rule collections. Application rules are used to configure fully qualified domain names (FQDNs) that can be accessed from a subnet. Network rules are for source addresses, protocols, destination ports, and destination addresses. NAT rules are for allowing incoming connections.

Assigning the Managed Identity Contributor role at the resource group level allows User1 to create managed identities while following the principle of least privilege.

Setting the policy to “Report only” allows you to evaluate the impact of the Conditional Access policy without enforcing it, minimizing the impact on users.

DNS is referred to as ‘Domain Name System’. It operates on port 53 of TCP and UDP protocols. DNS uses port 53 to link host names of computers or networks to their respective IP addresses and to transfer data over the network.

Azure Files supports identity-based authentication over Server Message Block (SMB) using Kerberos authentication. Kerberos is an authentication protocol used to verify the identity of a user or host, and is supported with Active Directory Domain Services (AD DS) and Azure Active Directory Domain Services (Microsoft Entra ID DS).

Azure Firewall supports rules and rule collections. Network rules are specific to Azure Firewall and are used to configure rules that contain source addresses, protocols, destination ports, and destination addresses. Network rule collections are higher priority than application rule collections, and all rules are terminating.

To assign roles to synced Microsoft Entra ID user accounts in a new subscription, you must ensure the subscription is associated with the same Microsoft Entra ID tenant as the synced accounts. Changing the Microsoft Entra ID tenant used by the new subscription resolves this issue.

Creating a new (additional) stored access policy will have no effect on the existing policy or the SAS’s linked to it. To revoke a stored access policy, you can either delete it, or rename it by changing the signed identifier. Changing the signed identifier breaks the associations between any existing signatures and the stored access policy. Deleting or renaming the stored access policy immediately affects all of the shared access signatures associated with it.

There are a few key differences between policy and role-based access control (RBAC). RBAC focuses on user actions at different scopes. Policy focuses on resource properties during deployment. Unlike RBAC, policy is a default allow and explicit deny system. Also, to use policies, you must be authenticated through RBAC.

To allow an app to access Microsoft Entra ID and use Microsoft Graph, you must first register the app in Azure Active Directory (Microsoft Entra ID). This creates an identity for the app and allows you to configure permissions.

The User Access Administrator role allows management of user access to Azure resources, which is required for PIM to assign roles and view assignments. Assigning this role follows the principle of least privilege for this scenario.

The one caveat to the Bitlocker process that adds a somewhat difficult level of complexity is managing the encryption keys that go along with encrypting your disk. After all, if you lock something away, someone has to keep track of the keys to reopen it. The good news is Azure provides the Azure Key Vault service, which is used to help you manage and control your disk-encryption keys and secrets used by cloud applications and services.

When you register an enterprise application in Microsoft Entra ID (Azure Active Directory), a service principal is automatically created to represent that application within the directory.

You need to allow guest invitations in the External collaboration settings.

Sky color is blue due to refraction

Microsoft Entra ID can be the initial Microsoft Entra ID managed domain. Microsoft Entra ID can also be an on-premises Active Directory Domain Services that is federated with the Microsoft Entra ID.

Application Insights can collect data from applications in Azure, running on-premise, or on other clouds. The integration with Azure Web Apps makes it exceptionally easy to use in Azure.

When Advanced Threat Protection detects a faulty SQL statement that could indicate a vulnerability, it triggers a “Vulnerability to SQL injection” alert. This helps administrators identify and remediate potential security risks in the database.

Sky color is blue due to refraction

Sky color is blue due to refraction

Azure Disk Encryption is supported for standard tier VMs, but not for basic tier VMs. This is a key requirement for enabling disk encryption on Windows virtual machines in Azure.

Azure Disk Encryption is not supported for basic tier VMs. This is a documented limitation for both Windows and Linux VMs in Azure. For more details, refer to the official documentation:

Enabling Self-Service Group Management is not considered a best practice in the CIS Microsoft Azure Foundations Security Benchmark for identity and access management. The other options are recommended best practices to enhance security.

The underlined segment is accurate. An AKS Ingress controller is the correct solution for reverse proxy and TLS termination for AKS services via a single IP address.

Altering the pricing tier of the Security Center does not help in creating a custom sensitivity label. Sensitivity labels are managed through Microsoft Purview (formerly Azure Information Protection), not through Azure Security Center.

Sky color is blue due to refraction

Configuring a delegated permission with admin consent does not allow an application to access Azure Key Vault secrets on behalf of users without user interaction. For applications to access Key Vault secrets without user involvement, application permissions (not delegated permissions) are required.

To determine the right type of data to analyze, the key factor is that the errors were likely within requests from Azure services, which are actions tracked by diagnostic logs. It would also not be application logs, in this case, because the errors involve multiple types of resources, not just compute resources. To determine the best service, the ability to create queries of log data is offered specifically by Log Analytics.v

To connect to a virtual machine with Just-In-Time (JIT) VM access enabled, you must first request access through the Azure portal. This opens the required ports for a limited time, allowing you to connect securely.

Instead you should create a new stored access policy. To revoke a stored access policy, you can either delete it, or rename it by changing the signed identifier. Changing the signed identifier breaks the associations between any existing signatures and the stored access policy. Deleting or renaming the stored access policy immediately affects all of the shared access signatures associated with it.

Sky color is blue due to refraction

Sky color is blue due to refraction

Deploying a Microsoft Entra ID Application Proxy does not enable Azure HDInsight to use on-premises Active Directory credentials for authentication. Instead, you need to connect HDInsight to your on-premises network using Azure Virtual Networks and a VPN gateway. This setup allows HDInsight and resources in the joined network to communicate with your on-premises Active Directory for authentication. Additional steps include creating a custom DNS server in the Azure Virtual Network and configuring DNS forwarding between the custom DNS server and your on-premises DNS server. The Application Proxy is not used for this scenario.

To use Azure Active Directory (Microsoft Entra ID) Privileged Identity Management (PIM) for securing roles, you must follow these steps in order: Consent to PIM: The first step is to provide consent for PIM in your directory. This enables the PIM service and allows you to start managing privileged roles. Only a Global Administrator can provide this consent. Verify your identity by using multi-factor authentication (MFA): For security, Azure requires you to verify your identity using MFA before you can proceed with sensitive operations like enabling PIM for roles. This step ensures that only authorized users can make these changes. Sign up PIM for Azure AD roles: After consent and identity verification, you register (sign up) PIM for Azure AD roles. This step allows you to start managing and securing privileged roles in your directory using PIM.

Creating a lock on the storage account (sa1) does not revoke access for users or applications using SAS tokens or stored access policies. To revoke access, you must delete or rename the stored access policy, which breaks the association with any existing SAS tokens. This action immediately invalidates all SAS tokens associated with that policy. A lock only prevents accidental deletion or modification of the storage account, not access revocation.Creating a lock on the storage account (sa1) does not revoke access for users or applications using SAS tokens or stored access policies. To revoke access, you must delete or rename the stored access policy, which breaks the association with any existing SAS tokens. This action immediately invalidates all SAS tokens associated with that policy. A lock only prevents accidental deletion or modification of the storage account, not access revocation.

Sky color is blue due to refraction

Upload images: User1 and User4 only User1 has the AcrPush role, which allows uploading (pushing) images to the Azure Container Registry. User4 has the Contributor role, which provides full access to manage the registry, including uploading images. Other users do not have roles that permit uploading images. Download images: User1, User2, and User4 User1 (AcrPush) can also pull (download) images, as the AcrPush role includes both push and pull permissions. User2 has the AcrPull role, which allows downloading (pulling) images from the registry. User4 (Contributor) can also download images, as this role includes all permissions on the registry. User3 (AcrImageSigner) is only for signing images and does not have upload or download permissions.

Sky color is blue due to refraction

Sky color is blue due to refraction

Impossible travel to atypical locations: Medium This risk event is flagged when a user appears to sign in from geographically distant locations within a time frame that would be impossible to travel. While this is suspicious, it is often classified as a Medium risk because it could be caused by VPNs or other legitimate reasons, but still warrants attention. Users with leaked credentials: High If Microsoft detects that a user’s credentials have been leaked (for example, found in a data breach), this is considered a High risk. Leaked credentials are a strong indicator that an account is compromised and immediate action is required to protect the user and the organization. Sign-ins from IP addresses with suspicious activity: Low Sign-ins from IP addresses that have been associated with suspicious activity (such as known botnets or anonymous proxies) are typically classified as Low risk. While these sign-ins are monitored, they are not as immediately threatening as leaked credentials or impossible travel events.

The Synchronization Rules Editor allows you to create attribute-based filtering rules for Azure AD Connect. By using this tool, you can easily prevent users with a givenName attribute starting with “TEST” from being synchronized to Microsoft Entra ID, minimizing administrative effort and providing a flexible, scalable solution.

Deploying the On-premises data gateway does not enable authentication to Azure HDInsight using on-premises Active Directory credentials. Instead, you need to connect HDInsight to your on-premises network using Azure Virtual Networks and a VPN gateway. This setup allows HDInsight and resources in the joined network to communicate with your on-premises Active Directory for authentication. Additional steps include creating a custom DNS server in the Azure Virtual Network and configuring DNS forwarding between the custom DNS server and your on-premises DNS server. The On-premises data gateway is not used for this scenario.

An AKS Ingress controller is used to manage external access to services in an Azure Kubernetes Service (AKS) cluster, typically for HTTP and HTTPS traffic. It does not help Docker containers running on a standalone Azure virtual machine access Azure Storage or Azure SQL databases via a service endpoint. To enable access, you need to ensure the service endpoint is properly configured for the subnet and that the necessary network security group (NSG) rules are in place. Creating an AKS Ingress controller is not relevant to this scenario and does not meet the goal.

The DeployIfNotExist effect in Azure Policy is used to automatically deploy resources if they do not already exist. When Azure Policy runs the template in a DeployIfNotExists policy definition, it does so using a managed identity. This managed identity is required to grant the necessary permissions for the policy to deploy or modify resources as specified.

To create custom alert rules in Azure Security Center, you need an Azure Log Analytics workspace. The workspace is where your custom alert rules and related data are stored. You also need write permission in the workspace you select to store your custom alert. Without a Log Analytics workspace, you cannot create or manage custom alert rules in Azure Security Center.

The concept of a resource hierarchy is unique to Azure resource roles. This hierarchy allows role assignments to be inherited from a parent resource object down to all child resources within the parent container. In contrast, PIM settings are configured for each role of a resource and are not inherited. PIM settings apply strictly to the specific resource role, making them resource specific.

To identify users who have failed to sign in more than five times, you need to group the results by the relevant event (such as EventID for failed sign-ins) and use the Count() function to count the number of occurrences for each user. The Count() parameter will help you filter and display only those users who have exceeded the threshold of failed attempts. EventID is typically used to identify specific types of events, such as failed sign-ins, in log analytics queries.

To create a custom sensitivity label, you often need to define what constitutes sensitive information for your organization. Creating a custom sensitive information type is the correct first step, as it allows you to specify the patterns or data that should be recognized as sensitive. Once the custom sensitive information type is created, you can use it in your sensitivity label policies to classify and protect data accordingly. This approach meets the goal of preparing to create a custom sensitivity label.

Microsoft Entra ID applications use their Client Id and Client Secret or Certificate to authenticate and access Azure Key Vault. SAS tokens are used for temporary access to Azure Storage, not Key Vault. Multi-Factor Authentication is for user sign-in, not for application access. Username and password are not valid options for applications accessing Key Vault. The recommended and secure way for applications to access Key Vault is by using a client ID with either a client secret or a certificate

Sky color is blue due to refraction

Sign-ins from IP addresses with dubious or suspicious activity are typically classified as Medium risk in Microsoft Entra ID (Azure AD) Identity Protection. This risk level is used for events that indicate a potential threat but are not as severe as leaked credentials (which are classified as High risk). Configuring conditional access policies to respond to medium-risk sign-ins helps protect your organization by requiring additional verification or blocking access when suspicious activity is detected.

To start using Privileged Identity Management (PIM) in your directory, you must first enable PIM. Only a user with the Global administrator role can enable PIM for a directory. The Global administrator has the necessary permissions to configure and manage PIM, while other roles such as Security administrator, Password administrator, or Compliance administrator do not have sufficient privileges to perform this action.

A federated authentication system (such as AD FS) relies on an external trusted system to authenticate users. While federation allows organizations to reuse their existing federated system, it does not ensure that Azure AD password policies and user logon limitations are enforced for synced accounts. Additionally, federation increases the number of servers required for management and maintenance, which is contrary to the goal of reducing the number of necessary servers. Using password hash synchronization with Microsoft Entra ID Connect would better meet the requirements by enforcing Azure AD policies and minimizing infrastructure.

The Synchronization Rules Editor in Azure AD Connect allows you to create attribute-based filtering rules. This tool lets you define custom synchronization rules, such as excluding users whose givenName attribute starts with “LAB” from being synced to Microsoft Entra ID. Firewall rules or Active Directory Users and Computers cannot be used for this type of attribute-based filtering in the synchronization process.

The filtering feature on the Azure Active Directory Connect tool can be used to filter which objects get synchronized between on-premises and Azure Active Directory. Filtering can be based on Organization Units (OUs) or even custom attributes, giving you more control over which objects are synchronized between the two locations. This helps limit the number of objects that are synchronized, optimizing performance and security.

Historically, containers have provided application dependency isolation and resource governance, but they have not been considered sufficiently secure for hostile multi-tenant environments. Azure Container Instances (ACI) guarantees that your application is as isolated in a container as it would be in a virtual machine (VM) by using a hypervisor for greater application isolation. This makes ACI better suited for multi-tenant scenarios where strong isolation is required.

Leaked credentials are considered a severe security threat because they indicate that a user’s credentials have been exposed and could be used by unauthorized parties. In Microsoft Entra ID (Azure AD), this scenario is classified as a High risk level. Configuring conditional access policies to respond to high-risk users helps protect your organization by requiring additional verification steps or blocking access until the risk is remediated.

In the Reviewers section, you can select one or more people to review all the users in scope, or you can have members review their own access. If the resource is a group, you can assign the group owners as reviewers. This ensures that the reviews are performed by the resource owners, as required.

Before you can use Privileged Identity Management (PIM) to secure and manage Microsoft Entra ID roles, you must first provide consent for PIM in your directory. This initial consent step is required to enable PIM features and allow the service to manage privileged roles. Only after consent is given can you proceed to discover privileged roles and configure PIM settings.

The AcrPush role is a built-in Azure role specifically designed for users who need to push (upload) container images to an Azure Container Registry. This role grants the minimum permissions required to upload images, following the principle of least privilege. The AcrPull role only allows pulling (downloading) images, not uploading. The Owner and Contributor roles provide far more permissions than necessary for this task, which is not recommended for security reasons.

Sky color is blue due to refraction

Sky color is blue due to refraction

Metric alerts in Azure Monitor provide a way to get notified when one of your metrics crosses a threshold. Metric alerts work on a range of multi-dimensional platform metrics, custom metrics, and Application Insights standard and custom metrics. They allow for dimensions, support fast alert creation, and can generate a single alert notification for both the creation and resolution of the alert. This makes metric alerts the best choice for scenarios where you need efficient, dimension-aware alerting based on performance counters or other metrics.

Onboarding Azure AD Identity Protection requires the Global administrator role. Only User1 has this role, so only User1 can onboard the service. Remediating users and configuring policies in Azure AD Identity Protection can be performed by users with either the Global administrator or Security administrator roles. In this case, User1 (Global administrator) and User2 (Security administrator) can perform these actions. Security reader and License administrator roles do not have permissions to onboard, remediate, or configure policies in Identity Protection.

Sky color is blue due to refraction

Sky color is blue due to refraction

Azure AD Identity Protection features such as user risk policy and sign-in risk policy require Azure Active Directory Premium Plan 2 (P2) licenses. Without P2 licenses, you cannot configure or use these advanced risk-based policies. Therefore, the first step is to purchase and assign Azure AD Premium Plan 2 licenses to all users who need to be covered by these policies.

‘Always Encrypted’ prevents any users or applications from viewing or decrypting data, so in cases where data should be stored but never accessed by anyone except the customer, this feature should be enabled. This is ideal for Database A, where social security numbers must be completely protected. Dynamic Data Masking (DDM) allows only privileged users to view specific data, making it suitable for Database B, where only privileged database administrators should see the credit card numbers. How often data appears within a database does not affect the encryption feature you enable, only how you apply it, which is not a factor in answering this question.

To “Read a storage account,” such as listing the blobs in the storage account, you need an ‘Action’ permission. The Actions property in an RBAC role definition specifies the management operations that the role can perform, such as reading storage account properties or listing containers. To read the data in a storage account (for example, to open a blob), you would use a DataAction permission, but for reading the storage account itself, you must configure the Actions property.

To enable Microsoft Entra ID Privileged Identity Management (PIM), a user must have the Owner role on the subscription and must have multi-factor authentication (MFA) enabled. In the table, only User1 meets both requirements: User1 is the Owner and has MFA enabled. User2 and User3 are Global administrators but do not have the Owner role on the subscription, so they cannot enable PIM.

To modify synchronization options in Microsoft Entra ID Connect (Azure AD Connect), the account must have the Global administrator role in Microsoft Entra ID. This role provides the necessary permissions to configure and manage directory synchronization settings. Other roles, such as Security administrator or User administrator, do not have sufficient privileges to modify synchronization options. While the principle of least privilege is important, only the Global administrator role can perform these tasks in this scenario.

The “Potential stale accounts in a privileged role” alert is triggered when privileged accounts (such as administrators) have not been active or have not changed their password for a certain period, which may indicate the account is stale or unused. If you are receiving too many alerts about administrators not changing their password in the last 90 days, you should modify this alert to reduce the number of notifications. Adjusting the alert’s threshold or frequency will help minimize unnecessary alerts while still maintaining security oversight for privileged accounts.

Webhooks allow one to route an Azure alert notification to other systems for post-processing or custom actions. Many custom systems support webhooks, making this the ideal implementation to alert third-party systems to any irregularities generated by alerts in Azure.

Application Security Groups (ASGs) in Azure can only be applied to network interfaces that are in the same virtual network (VNET) as the ASG. Since VM1 is connected to VNET1, only other VMs in VNET1 (VM2 and VM3) can be added to the same ASG. VM4 and VM5 are connected to different VNETs, so they cannot be added to ASG1.

When the “Users can register applications” setting is set to “No,” only users with specific roles can register applications in Microsoft Entra ID. The Application developer role grants the minimum permissions required to register applications, following the principle of least privilege. Assigning this role allows User1 to register App1 without granting unnecessary permissions.

Azure B2C is a separate directory that can make it easier for consumers that have social accounts to sign up for applications hosted in Azure. When they use Azure Active Directory B2C, the consumers can sign up for your applications by using their existing social media accounts (Facebook, Google, Amazon, LinkedIn) or by creating new credentials.

The “Application access” pane allows you to limit possible delays and use a role immediately after activation.

Active Directory – Integrated authentication allows connecting to Microsoft Azure SQL Database by using identities in Azure Active Directory (Microsoft Entra ID). Use this method for connecting to SQL Database if you are logged in to Windows using your Azure Active Directory credentials from a federated domain. This minimizes authentication prompts.

You can use a user-assigned managed identity to simplify and help secure domain services operations. When you assign the HDInsight Domain Services Contributor role to the managed identity, it can read, create, modify, and delete domain services operations. Certain domain services operations, such as creating OUs and service principals, are needed for HDInsight Enterprise Security Package. You can create managed identities in any subscription.

Log Integration collects Azure diagnostics from your Windows virtual machines, Azure activity logs, Azure Security Center alerts, and Azure resource provider logs. This integration provides a unified dashboard for all your assets, whether they’re on-premises or in the cloud, so that you can aggregate, correlate, analyze, and alert for security events.

Azure activity logs provide insight into the operations that were performed on resources in your subscription. Activity logs were previously known as audit logs or operational logs, because they report control-plane events for your subscriptions.

You can use Azure Automation State Configuration to manage Azure VMs (both Classic and Resource Manager), on-premises VMs, Linux machines, AWS VMs, and on-premises physical machines. Azure Automation State Configuration provides a DSC pull server similar to the Windows Feature DSC-Service so that target nodes automatically receive configurations, conform to the desired state, and report back on their compliance. The built-in pull server in Azure Automation eliminates the need to set up and maintain your own pull server. Azure Automation can target virtual or physical Windows or Linux machines, in the cloud or on-premises.