Microsoft Certified: Azure Security Engineer AssociateManage identity and accessHard
A software development company uses Azure DevOps for its source code repositories and CI/CD pipelines. They want to ensure that all service connections from Azure DevOps to Azure subscriptions for deploying resources use the principle of least privilege and are automatically managed. The security team explicitly wants to avoid using traditional service principal client secrets for these connections due to the management overhead and potential for compromise. Which authentication method should be configured for the Azure DevOps service connection?
- AAzure Resource Manager service connection using Managed Identity
- BAzure Resource Manager service connection using Workload Identity Federation
- CAzure Resource Manager service connection using a Service Principal (manual)
- DAzure Resource Manager service connection using a Personal Access Token (PAT)
Show answer & explanationAnswer & explanation
Correct answer: B. Azure Resource Manager service connection using Workload Identity Federation
Workload Identity Federation allows Azure DevOps to authenticate to Azure AD without needing client secrets. Instead, it uses a federated credential with Azure AD, eliminating the management overhead and security risks associated with secrets.
Why the other options are wrong
- A. Managed Identities are for Azure resources (like VMs, App Services) authenticating to other Azure services, not directly for Azure DevOps service connections to Azure subscriptions.
- C. This option uses client secrets, which the requirement explicitly aims to avoid.
- D. Personal Access Tokens (PATs) are user-based and not suitable for service-to-service authentication in CI/CD pipelines, nor do they align with the principle of least privilege for automated deployments.
Workload Identity Federation
Workload Identity Federation allows workloads (like Azure DevOps pipelines, Kubernetes pods) to authenticate with Azure AD and access Azure resources without needing to manage secrets or certificates. It uses an OpenID Connect (OIDC) federation between the workload and Azure AD.
- Eliminates the need for client secrets.
- Enhances security by removing long-lived credentials.
- Leverages OpenID Connect (OIDC) for trust establishment.
- Suitable for CI/CD pipelines and external platforms.
Memory trick: Federated Workloads: No Secrets, Just Trust.