HOTSPOT -
You have an Azure subscription named Subscription1 that contains the resources shown in the following table.
The status of VM1 is Running.
You assign an Azure policy as shown in the exhibit. (Click the Exhibit tab.)
You assign the policy by using the following parameters:
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:
tested out and found that indeed after policy, the VM goes into a deallocated state.
Good Job, that would mean these answers are correct
I didn't believe you so I tested this myself. I created the policy to not allow resource types virtual machines and when it took effect, it said that the virtual machine was non-compliant but it was STILL RUNNING. Please check your lab again because you are wrong.
I also didn't believe both of you, so checked myself. Diggity801 is right. Period.
I didn't believe any of you, so i skipped the question. Just kidding...The VM will keep running.
no, no, no. believe in me. Giggity
no, no, no. believe in me. Giggity
I didn't believe any of you, so i skipped the question. Just kidding...The VM will keep running.
no, no, no. believe in me. Giggity
no, no, no. believe in me. Giggity
I also didn't believe both of you, so checked myself. Diggity801 is right. Period.
I didn't believe any of you, so i skipped the question. Just kidding...The VM will keep running.
no, no, no. believe in me. Giggity
no, no, no. believe in me. Giggity
I didn't believe any of you, so i skipped the question. Just kidding...The VM will keep running.
no, no, no. believe in me. Giggity
Wrong. Policies typically don't affect resources that are already existent.
no, no, no. believe in me. Giggity
Shouldn't it be Yes, No, No? I've tried this in my Azure account and I was surprised that I was able to move Vnet1 from RG1 to RG2 despite RG2 having the policy enforced.
I tested this and found the same result. the VNET can be moved to RG2
Maybe its because policies prevents you from "deploying" new resources, but if the resource already exists, it just marks it as non-compliant.
Yup - i was able to move the VNET to RG2 - No issues. VM just reflected as Non-Compliant but running I was NOT Able to modify the address space - it gave me a policy error So basically answer should be Y Y N
****Correction Y N N
****Correction Y N N
As per Microsoft https://docs.microsoft.com/en-us/azure/governance/policy/overview#azure-policy-objects "Not allowed resource types (Deny): Prevents a list of resource types from being deployed." Prevents a list of resource types from being deployed it says...which means that move or start/stop operations and others than deployments are not prevented. Only deployments are. Not quite true though. So also tested the policy myself and the outcome was the following: Started VM stayed on, was able to stop and start again. Could not create Vnet or VM. Could not change VM size. Could not change the address space. Could move Vnet and VM. So basically the correct answer is Yes - No - No
its a Yes,Yes, No...its clear from your explanation also
I got also same result. Yes-No-No
Should be no, no, no... The rg is non compliant, but existing VM still run... you can't add subsequent vm to the rg after the policy is applied
Why last one would be "No"? Should still be able to update resources that are flagged as not compliant, no?
The state of the VM remains running, not deallocated. The policy will mark the VM as non-compliant but it will still be running, not deallocated. I tested this myself.
tested this, was allowed to move vnet, vm did not get de-allocated - kept on running, could not add address space. So yes no no
Phantastic! 41 threads and all different answers. So the answer is Maybe - Maybe - Maybe !
in that case ..go with answers given by examtopic.:_-)
I was wrong in my last post: I did not wait/check that the policycompliancescan had actually been run. RG2 -> Policies Ensure status is not "NOT STARTED" Would guess this is the reason for all the confusing in this thread. After the Policy was actually started, I got the following answer YES - I could move the VNET (does not make sense in my oppinion, but thats how it is) NO - The status of the VM did not change NO - I could not change Address-space of the existing VNET
Can verify, came to make the same comment. Took a solid 30 minutes for the policy to completely take effect. Upon first applying it, I couldn't create a new VNET, but I could update the existing one. Once it changed to Non-Compliant from Not Started, it seems the rules were applied to the existing resources and I could no longer update VNETs within the RG, but I could move an existing VNET into the RG. No impact on the VM.
I've just made a try, and to my surprise I got YES, NO, NO: - I've successfully moved VNET from one RG to RG2(with applied policy) - VM was not deallocated, and I could do start/stop - I could not change adrress space of VNET in RG2 and got policy violation error
I got the same results as you with my test, Y,N,N
Agree with suineglive13. Answers are 1. Yes - I have tested in my tenant and even I am surprised to see that I can move VNet from one resource group to another resource group which has the Azure Policy applied. 2. No - This policy is applicable only to the new & changed resources. It will not impact the existing resources. So, VM will still be running on RG2. 3. No - Azure Policy will not allow changes to the VNet in RG2.
Hi All, I was able to move a VNet from another Resource Group to the Resource Group with the policy The VM did not get deallocated Also the was not able to change the address space of the existing VNet
I just tried this. After creating the policy, I could not create a new VM and the reason given was that I had a policy that prevented it. However, my existing VM continued to run and was (eventually) marked as non-complaint. It wasn't marked as deallocated and I was able to both stop it and start it. I'm pretty sure that existing resources aren't forced to be complaint. If they were then the answer to an earlier question about a policy that automatically adds tags to new resources would be wrong (the right answer says that existing resources wouldn't have the new tag required by the policy retroactively added). Besides, if new resources weren't permitted and existing resources were automatically brought in line with the policy what could ever end up in the non-complaint status? So I'm wondering if the VM that SMat used was already deallocated before the policy was applied?
Yes there is so much confusion if policy affects existing resources. And contradictory answers on website
From my tests, Created: - RG1 and RG2 - one WIndows VM1 and one Linux VM in RG2 - RG1VNET1 in RG1 and - RG2VNET1 in RG2 - applying the policy to RG2 (not allow resource types: microsoft.classicnetwork/virtualnetworks microsoft/virtualnetworks microsoft.compute/virtualmachine) - ensured policy is 100% compliant Tests: - move RG1VNET1 to RG2 (gave an inital error... validating, but eventually moved to VNET2 fine) so YES - both Windows VM and Linux VM are still running (not deallocated) - so No - modify Address space for VNET2 - gave an error "Failed to save address space changes to virtual network 'RG2VNET1'. Error: Resource 'RG2VNET1' was disallowed by policy." - so NO
Wondering if "Resource 'RG2VNET1' was disallowed by policy." then how movement of RG1VNET1 to RG2 completed successfully.
NO NO NO
So what is correct final answer here ? Confused with the comments here.
Yes, you can move VNet to another RG No, policy does not change the state of running VM No, you cannot make changes to VNet in RG2
Y, N, N
Test in Lab, not able to move Vnet1 to RG2, showing error : Moving resources failed There was an error moving resources. Resource move policy validation failed. Please see details. Diagnostic information: subscription id 'XXXXXXXXXXXXXXXXX', request correlation id 'XXXXXXXXXXXXXXXXXXXXXXXX'. (Code: ResourceMovePolicyValidationFailed) Resource 'Vnet1' was disallowed by policy. Policy identifiers: '[{"policyAssignment":{"name":"Not allowed resource types","id":"/subscriptions/XXXXXXX/resourceGroups/RG2/providers/Microsoft.Authorization/policyAssignments/XXXXXXXX"},"policyDefinition":{"name":"Not allowed resource types","id":"/providers/Microsoft.Authorization/policyDefinitions/XXXXXXX"}}]'. (Code: RequestDisallowedByPolicy, Target: Vnet1) Related events
How the answer to second question is "Yes
I believe this is due to the policy not allowing virtual machines within that RG. I'm not positive on if by applying the policy, it automatically deallocates the VM though.
Yes, this question leaves a lot to be desired. Yes, the policy will flag the VM as not compliant, but without seeing the detail of policy action, we can't for sure say what happens to existing resources. I have No, No, No. :)
Yes, this question leaves a lot to be desired. Yes, the policy will flag the VM as not compliant, but without seeing the detail of policy action, we can't for sure say what happens to existing resources. I have No, No, No. :)
second one should be no since the existing vm's won't be impacted
Policy enforces on existing resources. It will delete or shutdown or whatever is needed to make policy compliance. Vnet2 does not exist anymore to make changes
just tested this in my lab and confirm that the answers are Y, N, N Y - i was able to move VNET1 to RG2 N - the VMs status did not change to deallocated N - with the policy in place i was not able to modify the VNET2 address space. as a further test i removed the policy waited a few minutes and was then able to make changes to VNET2 address space.
just tested this in my lab and the answers are Y N N
guess all possible combination of answers is here.
hahahhahaaahaahha
Yes Admin can move VNET1, the state of Vm1 no change, the admin can not modify the addrees space
The answers are Correct. I applied the policy as shown in the question. Basically you can dellocated the VM and stopped it But you cannot start it.
I tested it on my lab and 3xYES. Because this policy is applied only the NEW VMs and VNETs in RG2! -You can move VNET1 to RG2 because VNET1 isn't created but moved and operation was successfully (yes I was surprised too). -VM1 was created before apply policy to RG2 so I can start/stop/restart VM1 too. -And VNET2 was created before apply policy to RG2 so I can move and modify too (address space can bee added/ remove/ change). 3xYES
i dont believe in you. u are only confusing people here
Guess you forgot to check if the policycompliancescan had been run... RG -> Policy, you will see that the status of your new policy is "Not Started" The correct answer is YES - NO - NO
NO, CANNOT add or create new VNETS in RG2 NO, Current resources are not changed by policy unless specifically told to do so, they are just marked as non-compliant. Yes, Current resources are not effected unless specifically stated and can be edited as the policy is only in effect for new resources not the editing of current one.
The correct answer is: No - Yes - No It's simple, just simulate the Azure environment. 1. I can't move VNET1 to RG2 due to the Policy. 2. I can't make the size of the VM, but stop (deallocate) yes. 3. I cannot change the Address Space In this way I leave my contribution.
1) Move from another RG to this RG is possible . 2) State of VM does not become unhealthy. In fact it can be retasrted as well. 3) But you cant modify the address space of Vnet in the RG where policy is applied
I think Final Correct Answer is - YES-NO-NO , is it true ???
I just labbed this. Waited 30mins for policy to apply just to be sure. The answer is Yes, No, No
I don't know how you guys tested this, but after testing my self i found: Yes - I could move the VNET. No - No the status of the existing virtual machine did not change Yes - I could change address-space of existing VNET. (Tested this by adding a range) I waited approximately 5min to make sure the policy was enforced (I have not been able to find any information regarding the need of this)
Yes, No and No
I just did a lab. It is Yes, No, Yes. The mirror of what is shown :)
Exam Question 12/23/2020
answers are Y N N we can move resources when the policy is applied you can infact deallocate the VM or restart it but the VM won't be deallocated when the policy is applied , wording of the question isn't good when try to change the address space you will get error due to the policy tried it in the lab
how this second policy was no but they wont mention vm1 is set to dellocated if dellocated its rerady to stop vm then apps were stopped
No No Yes
u need to do more labs sir.. don't just guess
no,no,no
The correct answer is: No - Yes - No It's simple, just simulate the Azure environment. 1. I can't move VNET1 to RG2 due to the Policy. 2. I can make the size of the VM, but stop (deallocate) yes. 3. I cannot change the Address Space In this way I leave my contribution.
I do not believe you have tested this, as you would find that you can move the vnet
Did this lab on my environment. After creating the policy I could edit the address space of VNET successfully. To other guys in Whizalbs happened the same thing. After reading all coments here I´m really confused!
Just tested - You can move vnet into the RG but cannot modify Address Range
The policy applies to resources in RG2 only and this will effect only resources created after the new policy is implemented. Therefore answers are No-No-No 1. No – as no vnet activity allowed 2. No – the VM already exists and policy will not change it merely flag no compliance 3. No – no vnet activity permitted
Even my answer is No,No,No
which means "Azure pass / RG2"?
NO, NO NO.
all the options are no checked in lab environment
y n n is correct