Exam AZ-301 topic 17 question 3 discussion

Should be D: It's typically possible for someone with appropriate role-based access control (RBAC) on the subscription, such as the 'Owner' role, to be allowed to alter or delete any resource. This access isn't the case when Azure Blueprints applies locking as part of a deployed assignment. If the assignment was set with the Read Only or Do Not Delete option, not even the subscription owner can perform the blocked action on the protected resource. https://docs.microsoft.com/en-us/azure/governance/blueprints/concepts/resource-locking

Is D. Checked with lap. When you go to IAM of a given rg click on deny assignment. You will see below note Deny assignments block users from performing specific actions even if a role assignment grants them access. At this time, the only way you can add your own deny assignments is by using Azure Blueprints. Learn more https://docs.microsoft.com/en-us/azure/role-based-access-control/deny-assignments-portal

Azure Blueprint does not block by itself, it will enforce Azure policy. Blueprint are templates, nothing more ... I would go for Azure policy

Resource locks deployed by Azure Blueprints are only applied to resources deployed by the blueprint assignment. Existing resources, such as those in resource groups that already exist, don't have locks added to them.

C seems right ans as Azure Blueprints doesn't works on pre-existed resources.

D is correct answer.

https://docs.microsoft.com/en-us/azure/role-based-access-control/deny-assignments Answer is D Blueprints as stated in this article, Blueprints and managed apps are the only 2 ways to create den assignments to protect system-managed resources

Should be D

Should be D

The only possibility to achieve this is by using Azure Blueprints, the correct answer is D

I can fulfill the requirement with Blueprint not only for the new resources but for the already existing one. I wonder whoever defends the Custom Role how you can make this happen. You can exclude RG1 from AssignableScopes but this time it will loose all its access to RG1. As I know there is no such thing like give Owner role to these RGs and give Reader role to those RGs. So I would go for Blueprint which I already applied and working as expected.

The answer C: Custom role, is correct from my point of view, because, the described case states: ... a user admin1 ..., this is a very specific case which we should handle and solve. We do not need a gereral solution, which can be applied multiple times. We just need a solution for this specific user. The Blue print is more general: D: 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. Reference: https://docs.microsoft.com/en-us/azure/role-based-access-control/overview

A. a management group - doesn't make sense in this context B. an Azure policy - doesn't take individual users into account C. a custom role - Seems the correct answer D. an Azure blueprint - doesn't work on preexisting resources References: https://docs.microsoft.com/en-us/azure/governance/blueprints/concepts/resource-locking https://docs.microsoft.com/en-us/azure/azure-australia/azure-policy

cannot be blueprint. The reason is RG1 already exist, assuming it is not created by blueprint. "Resource locks deployed by Azure Blueprints are only applied to resources deployed by the blueprint assignment. Existing resources, such as those in resource groups that already exist, don't have locks added to them."

My choice would still be option C. For answer C to work the admin should be given a custom role at the subscription level (interesting note: if the admin gets e.g. a contributor role at the resource group level, that admin will still have an owner role inherited from the subscription and will also at the same time have a contributor role for that resource group; so adding a custom role for an admin to a resource group itself won't do any good due to inheritance). First off, you should the admin the required access he needs on resource group level. Then, you simply go into your subscription, click on 'create a custom role' and identify your role assignment details and you basically identify to which scope(s) you give that person access. In this case, you are giving yourself Owner rights on all the subscription except for that one resource group for which you just assigned that owner a lower permission level. Nobody denies blueprints won't work, but what I'm writing more is potentially a more fail-proof solution for reasons already mentioned in various comments here.

The answer should be D) Azure Blueprints. Have a look at the tutorial in the link below. Quote: "With Azure Blueprints resource locks, you can protect newly deployed resources from being tampered with, even by an account with the Owner role." https://docs.microsoft.com/en-us/azure/governance/blueprints/tutorials/protect-new-resources

I guess the question is outdated. C and D are valid. RBAC feature update supports deny assignments that take precedence over role assignments.