AZ-400 Practice Question: Design and implement build and release pipelines

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use managed identity for GitHub Actions and assign it to the AKS cluster

  Why it's wrong here

  Azure AD managed identities are designed for Azure-hosted resources (such as VMs, App Services, or an AKS cluster) that need to authenticate to other Azure services without storing credentials. GitHub Actions runs on GitHub-hosted or self-hosted runners that are external to Azure and cannot assume an Azure resource's managed identity, because the identity is only available when the code executes on that specific Azure resource. There is no mechanism to 'assign' a managed identity to GitHub Actions; the correct, secure path for GitHub Actions to authenticate to Azure is to use OpenID Connect (OIDC) with a federated credential or to store service principal credentials as GitHub Actions secrets. Assigning a managed identity to the AKS cluster would only grant the cluster its own identity, not give the GitHub Actions workflow any authority to deploy or manage cluster resources.

• ✗

  Store the service principal credentials in a Kubernetes secret in the AKS cluster

  Why it's wrong here

  Kubernetes secrets are stored in etcd and are designed to inject sensitive data into pods running inside the AKS cluster; since the GitHub Actions workflow runs outside the cluster, it cannot directly read those secrets, and doing so would not authenticate the workflow to Azure. Exposing service principal credentials in a Kubernetes secret also fails because the workflow has no native mechanism to retrieve or use them as part of the 'azure/login' action, making this approach inappropriate for CI/CD authentication.

• ✓

  Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action

  Why this is correct

  GitHub Actions secrets are encrypted at rest, masked in logs, and injected into the workflow runtime only when explicitly referenced, making them the secure, supported way to pass service principal credentials. The 'azure/login' action accepts these credentials via secret inputs (e.g., 'client-id', 'client-secret', 'subscription-id', 'tenant-id') and uses them to establish an authenticated session with Azure, so storing them as GitHub Actions secrets and referencing them in that action is the correct, best-practice approach.

• ✗

  Store the service principal credentials as environment variables in the workflow file

  Why it's wrong here

  Environment variables defined directly in the workflow file are stored in plaintext in the repository and can be exposed in run logs or debug output, since they do not benefit from GitHub's secret encryption or automatic log masking. Putting service principal credentials in plain environment variables creates a severe security vulnerability and violates Azure DevOps best practices, which require using protected GitHub Actions secrets for any sensitive authentication material.