Case Study 4 - Fabrikam, Inc Overview Fabrikam, Inc. is a consulting company. The company has a main office in New York City and branch offices in Amsterdam and Singapore. Existing Environment…

This question tests understanding of Azure Role-Based Access Control (RBAC) by requiring the assignment of appropriate built-in roles to an Azure Kubernetes Service (AKS) identity and another general identity for common Azure resource interactions.

Submitted by ahmad_uae· Mar 6, 2026Secure identity and access

Question

Case Study 4 - Fabrikam, Inc Overview Fabrikam, Inc. is a consulting company. The company has a main office in New York City and branch offices in Amsterdam and Singapore. Existing Environment Network Environment The on-premises network contains a datacenter in each office. Cloud Environment Fabrikam has two Azure subscriptions named Sub1 and Sub2 and a Microsoft 365 subscription that includes Microsoft 365 E5 licenses. All the subscriptions are linked to a Microsoft Entra tenant named fabrikam.com that contains the identities shown in the following table. The tenant contains the groups shown in the following table. All devices are enrolled in Microsoft Intune. Sub1 Resources Sub1 contains a resource group named RG1 that contains the resources shown in the following table. SQLServer1 uses Microsoft SQL Server authentication. Sub1 has an Azure Web Application Firewall (WAF) named WAF1 that has the following types of rule sets: Bot Manager 1.1 Azure-managed Default Rule Set (DRS) Sub1 has the following compliance standards assigned in Microsoft Defender for Cloud: NIST SP 800-53 Rev. 4 Microsoft cloud security benchmark (MCSB) System and Organization Controls (SOC) 2 Type 2 Sub2 Resources Sub2 contains a resource group named RG2. Planned Changes and Requirements Planned Changes Fabrikam plans to implement the following changes: Deploy the following key vaults to RG1: - AKV2 in the West Europe Azure region - AKV3 in the Central US Azure region - AKV4 in the East US Azure region Deploy the following key vaults to RG2: - AKV5 in the East US region Configure VM1 to read data from storage1. Create function apps that have the following hosting plans: - Fa1: Flex Consumption hosting plan - Fa2: Consumption hosting plan - Fa3: Dedicated hosting plan For WAF1, implement rate limiting rules based on the request location. Enable the NIST SP 800-53 Rev. 5 compliance standard in Defender for Cloud. Create a new storage account named storage2 that supports Azure Table storage. Enforce multifactor authentication (MFA) when database administrators access SQLdb1. Implement ExpressRoute circuits to the on-premises network as shown in the following table. For RG1, create a new Privileged Identity Management (PIM) eligible role assignment that assigns the Contributor role to supported groups. Technical Requirements Fabrikam has the following technical requirements: If VM1 is deleted, the permissions for VM1 must be removed automatically. The AKS1 managed identity must only be able to pull images from Registry1. The ID1 managed identity must be able to push images to and pull images from Registry1. All the data in the storage accounts must be encrypted by using Fabrikam-managed keys. All outbound traffic from the function apps to the on-premises network must use ExpressRoute circuits. ExpressRoute connectivity between the on-premises network and the Azure environment must be encrypted by using Layer 2 or Layer 3 encryption. Hotspot Question You need to configure the AKS1 and ID1 managed identities to meet the technical requirements. The solution must follow the principle of least privilege. Which role should you assign to each identity? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Answer:

Exhibit

Answer Area

AKS1:
AcrPullAcrPushContributorOwnerReader
ID1:
AcrPullAcrPushContributorOwnerReader

Explanation

Approach. The correct interaction is to select 'AcrPull' for AKS1 and 'Contributor' for ID1.

For AKS1: Select 'AcrPull'. An Azure Kubernetes Service (AKS) cluster, or its associated service principal/managed identity, typically needs to retrieve (pull) container images from an Azure Container Registry (ACR) to deploy applications. The 'AcrPull' role is specifically designed to grant read access to an Azure Container Registry, allowing the identity to pull images and artifacts. This adheres to the principle of least privilege, providing only the necessary permissions for image retrieval.
For ID1: Select 'Contributor'. The 'Contributor' role allows an identity (such as a developer or operations engineer represented by ID1) to manage all resources within a given scope (e.g., a resource group or subscription), but it does not allow them to manage access to those resources. This is a common and appropriate role for users who need to create, update, and delete Azure resources without having full administrative control over permissions.

Common mistakes.

common_mistake. Common mistakes include assigning overly permissive roles, roles that are too restrictive, or roles that are functionally incorrect for the implied task:

AKS1: AcrPush: This role is for pushing images to an ACR. While an AKS cluster could be involved in CI/CD that pushes images, the primary requirement for deploying applications to AKS is to pull images. Assigning 'AcrPush' when only 'AcrPull' is needed violates the principle of least privilege.
AKS1: Contributor/Owner/Reader: These are broader management roles. 'Contributor' or 'Owner' on the ACR would grant unnecessary permissions beyond just pulling, while 'Reader' on ACR would not allow pulling images.
ID1: Owner: This role grants full control, including managing access. While it would provide the necessary permissions, it often provides more access than required for a general identity managing resources, thus violating the principle of least privilege.
ID1: Reader: This role only allows viewing resources and their settings. It would be insufficient for an identity that needs to 'manage' or create resources.
ID1: AcrPull/AcrPush: These roles are specific to Azure Container Registry operations and would be inappropriate for a general identity (ID1) that likely needs to manage various types of Azure resources.

Concept tested. Azure Role-Based Access Control (RBAC), principle of least privilege, and understanding of built-in Azure roles (AcrPull, AcrPush, Contributor, Owner, Reader) in the context of Azure services like Azure Kubernetes Service (AKS) and Azure Container Registry (ACR).

Topics

#managed identity#AcrPull#AcrPush#container registry RBAC

Community Discussion

No community discussion yet for this question.

Full AZ-500 Practice