HOTSPOT -
You have the Azure management groups shown in the following table:
You add Azure subscriptions to the management groups as shown in the following table:
You create the Azure policies shown in the following table:
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
NOTE: Each correct selection is worth one point.
Hot Area:
Answer is Wrong : It should Be NO NO NO - subscription should be moved by can't be added to 2 groups.
Agree. - NO: Subscription 1: is not allowed to create a VNET. - NO: Subscription 2: Allowed to create a VNET which restricts anything else. - NO: Subscription 1: already in one Management group called 21, so cannot add into another. A Subscription can be assigned to 1 Management Group.
I think this is wrong, it should be No YES NO. The first policy only restrict to create VNets not VMs, So VMs are allowed to be created if you can attach a VNET and the 2nd policy allows you to create the VNET, So.. yes
That's not correct...If you read this definition, then answer #2 is No. So It's still No, No, No Allowed Resource Type (Deny): Defines the resource types that you can deploy. Its effect is to deny all resources that aren't part of this defined list.
Allowed Resource Type (Deny): Defines the resource types that you can deploy. Its effect is to deny all resources that aren't part of this defined list.
Azure Policy is an explicit deny. So the root management group deny the virtual network resource type to the child management groups/subscriptions/resources groups and the policy in the question does not have any thing excluded so it will deny
@Bon_: #2 is still a YES. You have 5 definition types, these two makes the magic about what can be deployed: Not allowed resource types (Deny): Prevents a list of resource types from being deployed. Allowed Resource Type (Deny): Defines the resource types that you CAN deploy, which means that all the resources in this list are allowed, and those which are not part, doesn't. Think on this a whitelist for resources
It's because of the "Allowed Resources Policy". You can only create resources of the allowed type and the ones which cannot be assigned tags. TR ->MG11 -> MG21 - Sub1 ->MG12 - sub2
you can't create a vm without a vnet
Best explanation
Who told you there is an existing VNET?
ms exams usually tell what resources are already available, or what will be deployed. if it requires presuming that it just exists out of the nether, then it means it's not there. A VM in azure cannot be created without VNET, meaning that avidlearner is correct
overrides property allows you to change the effect of a policy definition without modifying the underlying policy definition
Same question for you. Who told you there is NO existing VNet? We have no info about it (or any other resources) but we have a Q about VM's. VM's COULD be created because it's required an VNet and VNet could already exist, and there is no restriction about VM creation. So potentially you have a chance create VM (cuz it's not prohibited) by using existing VNet.
ms exams usually tell what resources are already available, or what will be deployed. if it requires presuming that it just exists out of the nether, then it means it's not there. A VM in azure cannot be created without VNET, meaning that avidlearner is correct
Who told you there isn't? - Actually, who would make policies like this, if there weren't any VNets available already? (I know, it's a Microsoft scenario, but still...)
no one in their right mind would make policies like these, but this is not a real world tenant in a company. this is an exam question to test if you know how allows and denies trickle down through management groups. No need to get philosophical on this
Allowed Resource Type (Deny): Defines the resource types that you can deploy. Its effect is to deny all resources that aren't part of this defined list. Not allowed resource types (Deny): Prevents a list of resource types from being deployed. Based on the Policies, VNETs are not allowed in the Tenant Root Group scope, so you cannot deploy VNETs. Also, VNETs only allowed in ManagementGroup12 scope, but you cannot deploy any other resource. Box 1: No Subscription1 is a member of ManagementGroup21, ManagementGroup21 is a member of ManagementGroup11, ManagementGroup11 is a member of the Tenant Root Group, The Tenant Root group has ‘Not allowed resource types for virtual network’. Box 2: No: You cannot create a VM, because based on the Policy you can only create VNETs in Sybscription2 (ManagementGroup12). Box 3: No You cannot ADD Subscription1 to ManagementGroup11, but you can MOVE Subscription1 from ManagementGroup21 to ManagmentGroup11. Subscriptions can only be a member of ONE ManagementGroup at a time.
Policy doesnt restrict you to create a VM anywhere. It restricts you to create VNet only which is overridden at Management12 and it will be inherited by Subscription 2. So you can create Vnet hence VM in subscription 2
OLD Question : - NO: Subscription 1: is not allowed to create a VNET. - NO: Subscription 2: Allowed to create a VNET which restricts anything else. - NO: Subscription 1: already in one Management group called 21, so cannot add into another. A Subscription can be assigned to 1 Management Group. NEW Question : 1. NO - I had subscription under MG with allowed virtualNetworks but got blocked by not allowed virtualNetworks policy from root MG https://imgur.com/a/vLnpRdX 2. NO - Screenshot of policy that blocked my deployment of VM in my subscription https://imgur.com/a/BOUyWe4 3. YES - I could MOVE it to higher tier MG which was called "add" in notification pane https://imgur.com/a/qX7WS6w
This is correct. 1. This is obviously no. 2. Yes, VM can be created as long as you have an existing VNET. It's reasonable to assume a VNET already exist. You'll only be prevented to create a VM is you try to create a new VNET while creating the VM. This is not specified so assume a VNET exists. 3. Yes. I also tried this in lab. "Add to subscription" really means move, not add it again. The "Add to subscription" is misleading but this is how it is in the lab. It will move the subscription.
NO NO YES
These questions will be a lot easier if they are represented diagrammatically like you would do in real life but MS is too lazy to do something like that...
#3 is should be "move" in the current version of the question (which is what I got on my exam), resulting in N/N/Y as the answer. It will be N/N/N otherwise. For #2, it is "No" for two reasons. The first being the "allowed" policy inherited on subscription 2 does not allow anything except virtual networks to be created, denying virtual machines. The second reason is that the "not allowed" policy inherited from the root management group does not allow virtual networks to be created, and you cannot create a virtual machine without a virtual network. As a result of the two policies, you in fact should not be able to create any resource at all in subscription 2. https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effects#layering-policy-definitions The link above describes the net effect of layering multiple policies.
NO NO YES
NO, NO, YES
I agree that the first two are "no", third definitely 'yes', the terminology 'add subscription' is used everywhere in the portal instead of 'move'
1) No - Policy at root level prevents the creation of vnets in any child management group (tested) 2) No - Policy only allows vnets to be created, nothing else (tested) 3) Yes - Click the elipsis in the selected management group and click "Add subscriptio here". This will move the subscription. In this case Add=Move.
Is it possible to have a VN without VMS?
there is explicit deny on root. So answer should be NO, NO, YES
Moderator please remove my previous answer. I go for N -N- N - can't add but can move
We can add using Add subscription option from management group. However it finally moves the subscription and doesn't duplicates it in multiple management groups.
1. No 2. Yes (VM not Vnet) 3. No (add -> No if move -> YES)
Correct Answer is No, Yes, No.
Box1: No -> because VNets are only allowed for MG12. (here the question in principle whether the allowed VNet for MG12 overrides the previous rule that VNets are forbidden on Tenant root level, which will then mean that such a rule forbids totally the creation of new VNets). Box 2: Yes -> because forbidding VNets creation does not automatically forbit VMs creation, we can still create new VNs within the already existing Vnets. Box 3: Yes -> we can move subscriptions from one MG to another, and here we have MG21 under MG11 https://docs.microsoft.com/en-us/learn/modules/create-windows-virtual-machine-in-azure/2-create-a-windows-virtual-machine https://docs.microsoft.com/en-us/azure/governance/management-groups/manage
2 - NO "In another example, you might want to assign a resource type allow list definition at the management group level. Then you assign a more permissive policy (allowing more resource types) on a child management group or even directly on subscriptions. However, this example wouldn't work because Azure Policy is an explicit deny system. Instead, you need to exclude the child management group or subscription from the management group-level assignment. Then, assign the more permissive definition on the child management group or subscription level. If any assignment results in a resource getting denied, then the only way to allow the resource is to modify the denying assignment."
NO,NO,YES
No , Yes , Yes
Vote: No, Yes, No Not sure for 2nd is Yes.
NNY is the correct ans
Answer is correct - The scope is set to GUEST users only. So User3 cannot perform an access review of User1 and UserA as they are Members. Group2 is a member of Group1 so the access review is inherited.
Clicked on the wrong discussion box - Moderator please delete this as it was meant to reply to another question, thanks.
2 - Yes "At the subscription scope, you can assign a definition that prevents the creation of networking resources. You could exclude a resource group in that subscription that is intended for networking infrastructure. You then grant access to this networking resource group to users that you trust with creating networking resources." https://docs.microsoft.com/en-us/azure/governance/policy/overview
The Tenant Root Group is a predefined management group; you can modify but not delete it. By default, any RBAC or Azure Policy you define at this level cascades by inheritance to administrator-defined management groups. As you can do with, say, NTFS permissions, you can override inheritance by setting explicit Azure or RBAC policy at the child management group
NO yes NO
NO NO NO
One reason to create a management group is to bundle subscriptions together. Only management groups and subscriptions can be made children of another management group. A subscription that moves to a management group inherits all user access and policies from the parent management group When moving a management group or subscription to be a child of another management group, three rules need to be evaluated as true. https://docs.microsoft.com/en-us/azure/governance/management-groups/manage#moving-management-groups-and-subscriptions
NO - There is deny policy for virtual network resource on root level. NO - There is deny policy for virtual network resource on root level which means only virtual network resources are denied to be created and users are allowed to create rest all resources. But than there is another allowed policy applied on Sub2 to allow resource type is vnet which means rest of resources not allowed. So VM can't be created. Refer (Policy Definition) - https://docs.microsoft.com/en-us/azure/governance/policy/overview N - You can move subscription to another management group but can't add. Subscription can be part of single management group only.
NO NO NO
Correct answer is NO NO YES right?
Answer should be No No No
Answer is Wrong : It should Be NO NO NO
This question is explained in the below video with the concept. https://youtu.be/ajrGaguGg90
During a VM creation, a VNet and NIC creation are mandatory. Because of the Policy, VM creation would be stopped if a new VNet needs to be created. But if there is any existing VNet available in the resource group already, that can be used to create the VM. In that way, the VM creation shouldn't fail. So, yes, you can create a VM.
Going to go with NYN - will report back
NYN. In general, polices are inherited through a hierarchical structure consisting of Management Groups > Subscriptions > Resource Groups > and Resources. However policies, even more restrictive policies, can be over-ridden at those lower levels. The first answer is No because it inherits the restrictive policy from the root group and there is nothing to over-ride that policy. The second answer is Yes because even though it inherits a restrictive policy from the root group, it explicitly allows VNETs to be created at a lower, more granular, management level. I know the question is asking about VM creation, but you need VNETs to create VMs and there is no policy specifically about allowing or disallowing VM creation. The third answer is No because, as other have said, you cannot have a subscription in 2 management groups. It cannot be added, but it can be moved.