Plan and Implement Workload Identities practice questions

Enable Azure AD pod-managed identity for the cluster.

Why wrong: Azure AD pod-managed identity is a deprecated legacy solution that relied on NMI and MIC components. Microsoft now mandates the use of Azure AD Workload Identity, which is a cloud-native, more secure, and performant approach that leverages the Kubernetes native OIDC identity provider capabilities instead of intercepting traffic.

Assign a system-assigned managed identity to the AKS node pool.

Why wrong: Assigning an identity to the node pool grants all pods on those nodes the same permissions. This violates the principle of least privilege, as every container running on the node inherits the identity's access rights, creating a significant security risk for lateral movement within the cluster environment.

Install the Key Vault CSI driver and store the secret as a K8s secret.

Why wrong: While the CSI driver is a valid method, the requirement specifically asks to avoid using Kubernetes secrets. Storing secrets within Kubernetes introduces risks related to etcd backup exposure and RBAC misconfigurations, which the request specifically aims to circumvent by using direct identity federation instead of intermediate storage.

Use the Azure AD portal to manually update secrets every 30 days.

Why wrong: Manual rotation is prone to human error, downtime, and operational fatigue. In high-velocity environments, manual updates cannot scale and often lead to expired credentials, causing application outages. Automated lifecycle management tools are preferred over manual processes to ensure consistent security postures across all enterprise application service principals.

Enable password writeback in Azure AD Connect to force rotation.

Why wrong: Password writeback is designed for hybrid identity scenarios where on-premises Active Directory accounts need to sync password changes back from the cloud. It is not intended for service principal management or secret rotation in Azure AD application objects, as these entities do not reside in on-premises AD.

Configure the service principal to rotate its own password every hour.

Why wrong: Service principals cannot self-manage or automatically rotate their own secrets without an external orchestration trigger. Requesting an hour-long rotation is also operationally impractical and would likely cause race conditions during the authentication process, leading to intermittent failures for applications attempting to acquire new access tokens using the secret.

The GitHub Action is attempting to authenticate with the wrong Tenant ID.

Why wrong: If the tenant ID were incorrect, the error would typically manifest as a 'Resource not found' or 'Tenant not found' error. The AADSTS70021 error specifically indicates that the identity provider is reachable, but the specific federated credential policy cannot be validated against the claims provided by the caller.

The service principal has not been granted the 'Owner' role on the subscription.

Why wrong: Role-based access control (RBAC) permissions at the subscription level determine what an identity can do *after* it has successfully authenticated. The AADSTS70021 error occurs during the token exchange phase, which happens before the identity is even successfully resolved to a principal capable of performing authorization checks.

The GitHub repository is private and cannot communicate with Azure AD.

Why wrong: Azure AD Workload Identity Federation is designed to work with public and private repositories alike. The trust relationship is based on OIDC discovery of the GitHub issuer, not the visibility of the source code repository. Communication occurs over standard HTTPS endpoints, which are publicly reachable by GitHub Actions runners.

Managed Identity

Why wrong: Managed identities are specialized service principals that Azure automatically manages. While useful, they cannot be configured with custom client secrets or certificates for general-purpose applications; they are strictly bound to Azure resources and their lifecycles are managed by the Azure platform, not by developers or administrators.

Enterprise Application

Why wrong: An enterprise application is the representation of an application within your tenant, but it is not the entity you initially create to define the app's metadata. While you configure authentication on the service principal (enterprise app), the initial definition and authentication settings start with the application registration object.

Group-based access package

Why wrong: Access packages are part of Entitlement Management in Azure AD Governance. They are used to bundle resources and roles for users, not for defining the authentication identity for an application. Using this for application identity management is conceptually incorrect and does not provide any mechanism for secret-based authentication.

Managed identities assigned to multiple virtual machines.

Why wrong: Assigning the same user-assigned managed identity to multiple virtual machines is a supported architectural pattern. It allows a farm of servers to share the same access policy to Azure resources. This is not a security risk if the machines are part of the same application tier and requirement.

Service principals that use certificate-based authentication.

Why wrong: Certificate-based authentication is a best practice for workload identities. Unlike client secrets, which are strings that can be easily leaked, certificates are cryptographically secure and significantly harder to compromise. Promoting certificate use is a security improvement, not a risk, and is standard practice for production-grade enterprise applications.

The command fails because the scope is too narrow.

Why wrong: The scope provided (/subscriptions/.../resourceGroups/MyRG) is a perfectly valid and common target for RBAC assignments. There is no requirement that a service principal must be scoped to a full subscription or an entire tenant; in fact, scoping to a resource group is a recommended security practice.

The service principal is not assigned any authentication method by default.

Why wrong: The 'az ad sp create-for-rbac' command automatically generates a password-based credential (client secret) by default if no other authentication method is specified. Therefore, the service principal is fully functional and ready for use immediately upon successful command execution, which is the intended behavior for this specific CLI utility.

The service principal is created with Owner permissions instead of Contributor.

Why wrong: The command explicitly specifies '--role Contributor'. The Azure CLI honors this parameter and assigns the Contributor role, which allows the principal to manage resources but does not allow it to manage user access (RBAC assignments), unlike the Owner role which would allow full control over identity management.

Azure Storage Account

Why wrong: Storage accounts are not designed for cryptographic key management or certificate lifecycle automation. They lack the built-in integration with Azure AD for service principal authentication rotation and do not provide the specialized hardware security module (HSM) backing required to securely handle sensitive private keys in production scenarios.

Azure App Configuration

Why wrong: Azure App Configuration is intended for managing application settings and feature flags, not for storing sensitive cryptographic material or managing certificate lifecycles. It lacks the security controls and HSM integration necessary to protect private keys, making it an inappropriate choice for securing service principal credentials.

Azure DevOps Secret Variables

Why wrong: While DevOps secret variables can hold secrets, they are limited to the scope of an Azure DevOps pipeline. They do not provide a centralized, tenant-wide management system for certificate renewal, rotation, or auditing, and they do not allow the Azure AD application to automatically pull the updated certificate.

Create an Azure AD user and store their credentials in the VM config.

Why wrong: Storing user credentials on a VM is a major security violation. It exposes credentials to any user with access to the VM's file system or environment variables, and it forces you to manage password rotation for a human user account, which is not designed for programmatic application authentication.

Use a service principal with a client secret stored in a local file.

Why wrong: Storing client secrets in local files is insecure. If the file is accessed or backed up, the secret is compromised. Furthermore, this requires manual management of the secret lifecycle, including rotation and secure distribution, which is precisely the operational burden that managed identities are intended to eliminate.

Enable SQL Server Authentication and use a firewall rule to restrict IPs.

Why wrong: SQL Authentication relies on static passwords, which are prone to brute-force attacks and credential leakage. Even with IP restrictions, the underlying security depends on the secrecy of the password. Azure AD-based authentication via managed identity is significantly more robust and aligns with modern zero-trust security architecture principles.

When the application runs on an Azure Virtual Machine.

Why wrong: Managed identities are the preferred choice for applications running on Azure VMs. They eliminate the need for credential management, rotation, and storage, making them a much more secure and operational-friendly alternative to traditional service principals that require external secret management and rotation logic.

When the application requires access to multiple Azure subscriptions.

Why wrong: Managed identities can be granted permissions across multiple subscriptions just like any other service principal. There is no limitation preventing a managed identity from accessing resources in different subscriptions, provided the identity is added to the relevant roles in each subscription scope as required by your architecture.

When you need to provide administrative access to the entire tenant.

Why wrong: Granting tenant-wide administrative access should be avoided for any identity, whether a managed identity or a service principal. If such access is strictly necessary, either option can be used; the difference between them is the hosting environment, not the scope of permissions that can be assigned to them.

The Client Secret of the service principal.

Why wrong: Workload Identity Federation is designed specifically to remove the need for client secrets. By configuring a federated credential, the external workload performs an OIDC exchange to obtain an access token without ever having, storing, or using a client secret, effectively mitigating the risk of credential leakage.

The Tenant ID of the external provider.

Why wrong: The external OIDC provider, such as GitHub or GitLab, does not have an Azure AD Tenant ID. They operate as independent OIDC identity providers. Requiring a tenant ID is a confusion between Azure-to-Azure authentication and cross-provider identity federation, which does not rely on tenant-based trust boundaries.

AuditLogs

Why wrong: Audit logs track changes to the configuration of resources, such as creating a new service principal or updating a secret. They do not track the runtime usage of the secret for authentication. To see when an application actually logs in, you must check the specific sign-in activity logs.

AzureActivity

Why wrong: The Azure Activity log records operations performed on Azure resources, such as creating, updating, or deleting a virtual machine or a database. It does not track the authentication events of applications logging into Azure AD, as those are managed within the identity plane, not the resource management plane.

AppServiceHTTPLogs

Why wrong: App Service HTTP logs record the incoming requests to your web application, including URLs, status codes, and response times. While useful for debugging application traffic, they do not show the internal Azure AD authentication handshake that happens when your application requests an access token for an Azure resource.

The application can only be used by users within your home tenant.

Why wrong: This is the default setting for a single-tenant application. Changing the configuration to 'Accounts in any organizational directory' explicitly overrides this restriction, enabling the application to accept authentication requests from users and service principals located in any Microsoft Entra ID tenant globally.

The application becomes a public application and ignores authentication.

Why wrong: Multi-tenancy does not bypass authentication. The application still requires a valid token from the issuing authority (Azure AD). It simply changes the validation scope, allowing the application to trust identity providers from other tenants rather than restricting trust to the local tenant's identity provider only.

The application is automatically deleted and must be re-registered.

Why wrong: Changing the supported account types is a configuration change that takes effect immediately. It does not require deleting or re-registering the application object. However, you may need to update your application code to handle cross-tenant authentication scenarios appropriately, particularly regarding user consent and application permissions.

The use of ClientSecret as an authentication method.

Why wrong: While certificates are more secure, client secrets are a standard and widely used authentication method. The risk associated with a secret is primarily its lifecycle management (rotation/leakage), not its use as an authentication mechanism. The broad permissions are a more inherent security risk than the choice of secret.

The application ID is too short.

Why wrong: Application IDs are GUIDs. The value shown in the exhibit is likely a simplified placeholder for the purpose of the exam question. The length or format of the ID does not represent a security risk, as IDs are meant to be public identifiers for the application.

The expiry date is in the past.

Why wrong: While an expired secret means the application will stop working, this is an availability issue rather than a security vulnerability. Security vulnerabilities involve unauthorized access, data exposure, or privilege escalation. An expired credential prevents access, which is the desired state for a credential that should no longer be valid.

Application Registration

Why wrong: The application registration is the template. It is used to define the application's global configuration and authentication metadata. It does not provide the tenant-specific management features like user assignment, application-specific conditional access, or local provisioning management that are found in the Enterprise Application instance.

Managed Identity

Why wrong: Managed identities are a specialized subset of service principals designed to be managed by Azure for Azure resources. They do not support the same level of tenant-wide management features, such as user assignment or application-specific conditional access, because their lifecycle and purpose are tied to the host Azure resource.

Azure Policy

Why wrong: Azure Policy is used to enforce rules on Azure resources, such as preventing the creation of insecure resources or forcing tags. It is not used to manage the identity lifecycle, conditional access, or user assignments for applications. These identity-centric tasks are handled exclusively within the Azure AD management plane.

Create a service principal and store the client secret in the Function app settings.

Why wrong: Service principals require the manual creation and rotation of client secrets or certificates. This adds significant administrative overhead and introduces security risks if secrets are accidentally committed to source control or logged. While functional, it does not meet the requirement of eliminating secret management for the application.

Use a shared access signature (SAS) token with a five-year expiration date.

Why wrong: Shared access signatures are used for Azure Storage and do not provide an identity for an Azure Function to access Key Vault. Furthermore, long-lived tokens violate the principle of least privilege and increase the window of opportunity for an attacker to exploit a compromised token.

Register a new application in Microsoft Entra ID and grant it Key Vault Secrets Officer permissions.

Why wrong: Granting excessive permissions like Secrets Officer allows the identity to manage and delete secrets, which violates the principle of least privilege if only read access is needed. Additionally, a standard app registration still requires a secret or certificate, failing the requirement to avoid stored credentials.

A Microsoft Entra ID Protection risk-based policy for users.

Why wrong: Standard Microsoft Entra ID Protection policies target human user accounts rather than service principals. While these policies are effective for protecting employee logins, they do not evaluate the sign-in context or location for workload identities, making them ineffective for securing automated deployment pipelines and service accounts.

An Azure Virtual Network service endpoint for Microsoft Entra ID.

Why wrong: Service endpoints optimize traffic routing from a virtual network to Azure services but do not provide identity-level authentication restrictions based on IP address. They are used for network-level isolation rather than enforcing Conditional Access policies on service principals at the identity provider level during the authentication phase.

A Microsoft Entra security group containing the service principals.

Why wrong: While you can place service principals into security groups, the groups themselves do not enforce location restrictions. Groups are used for administrative organization or assigning permissions, but they lack the policy enforcement engine required to block authentication attempts originating from unauthorized IP addresses or geographic regions.

Managed identities can be used to access resources outside of Azure via SAML.

Why wrong: Managed identities are primarily designed for authenticating from Azure resources to other services that support Microsoft Entra authentication. They are not intended as a general-purpose SAML identity provider for external third-party applications, which typically requires a standard service principal or a full application registration configuration.

Managed identities support the use of client certificates for authentication.

Why wrong: While service principals can use certificates for authentication, managed identities do not expose the underlying certificate or secret to the user at all. The authentication process is abstracted away, so the developer does not choose or manage certificates, unlike the process for configuring a standard service principal identity.

Managed identities allow for the assignment of Application permissions to Microsoft Graph.

Why wrong: Both managed identities and service principals can be granted Application permissions to Microsoft Graph. This is not a unique benefit of managed identities; rather, it is a shared capability of all service principal types in Microsoft Entra ID for performing non-interactive tasks within the tenant environment.

It specifies the display name of the service principal in the Entra ID tenant.

Why wrong: The subject field is not used for naming or identifying the service principal within the Microsoft Entra ID directory. Its role is strictly for validation of the incoming claim from the external provider, ensuring that the token was issued for the correct external entity or workflow context.

It defines the URL of the GitHub repository where the workflow is hosted.

Why wrong: While the subject string contains the repository name, it is a structured claim that includes specific conditions like the branch or environment. It is not a simple URL for hosting, but a security filter used during the handshake to verify the origin and context of the request.

It lists the Azure resources that the GitHub workflow is permitted to manage.

Why wrong: The subject field does not define permissions or target resources in Azure. Permissions are managed via Role-Based Access Control (RBAC) assigned to the service principal. The subject field is strictly part of the authentication trust relationship, determining if the external caller is who they claim to be.

Microsoft Entra ID Protection alerts.

Why wrong: ID Protection alerts are designed to detect and report on suspicious activities or potential compromises of identities. They do not provide a mechanism for periodic verification or attestation of permissions, which is necessary for governance and compliance requirements regarding long-term access for service accounts.

Azure Monitor Log Analytics alerts.

Why wrong: While Log Analytics can track when permissions are used, it does not provide a built-in workflow for human or automated attestation. It is a monitoring tool rather than a governance tool, meaning it lacks the specific review and remediation lifecycle found in the Access Reviews feature.

Privileged Identity Management (PIM) for groups.

Why wrong: PIM for groups allows for just-in-time activation of group membership, but it is primarily focused on human users. While service principals can be in groups, PIM does not offer the same periodic attestation workflow for workload identities that Access Reviews provide for auditing permanent or long-standing assignments.

Create a Kubernetes Secret containing the client secret of the service principal.

Why wrong: The primary goal of Azure AD Workload Identity is to eliminate the use of secrets. Storing a client secret in a Kubernetes Secret is the old method (Azure AD Pod Identity or standard SP) and is exactly what this migration is designed to move away from for better security.

Install the Azure Key Vault secrets provider add-on for AKS.

Why wrong: While the Secrets Store CSI Driver is useful for mounting secrets as files, it is not a prerequisite for Azure AD Workload Identity itself. Workload Identity provides the authentication mechanism; the CSI driver is a consumer that might use that identity to fetch items from Key Vault.