AZ-204 Implement Azure security Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Store the connection string in a Kubernetes Secret and mount it as an environment variable

  Why it's wrong here

  Storing sensitive connection strings directly in Kubernetes Secrets and mounting them as environment variables is generally discouraged for high-security scenarios. While Secrets prevent credentials from being hardcoded in application code, they are only base64 encoded, not encrypted by default, meaning anyone with `kubectl` access to the cluster can easily decode and retrieve the sensitive information. This approach also requires managing the secret's lifecycle within Kubernetes, which can become complex and less secure than leveraging an identity-based solution.

• ✓

  Use Azure AD Pod Identity (Workload Identity) to assign a managed identity to the pod and authenticate to SQL

  Why this is correct

  Azure AD Workload Identity (formerly Pod Identity) is the most secure and recommended approach for AKS pods to authenticate to Azure services like SQL Database. It assigns an Azure Active Directory managed identity directly to a Kubernetes service account, which is then associated with the pod. The pod can then obtain an Azure AD access token by exchanging its Kubernetes service account token with Azure AD, allowing it to authenticate to Azure SQL Database without needing any stored credentials, connection strings, or client secrets within the pod or Kubernetes Secrets. This significantly reduces the attack surface and simplifies credential management.

• ✗

  Use a service principal and store its credentials in Azure Key Vault, then use the Key Vault Secrets Store CSI driver

  Why it's wrong here

  This option securely externalises credentials from the container image using Azure Key Vault and the CSI driver, preventing secrets from being hardcoded. However, it still requires the application to retrieve and use a service principal's client secret to authenticate with Azure SQL Database. This doesn't eliminate the application's direct handling of credentials. It is a valid approach for managing other types of secrets or when a service principal is required for resource management, but a more integrated identity-based solution exists for application authentication to Azure SQL Database.

• ✗

  Hardcode the credentials in the Dockerfile

  Why it's wrong here

  Hardcoding credentials directly into a Dockerfile or application code is a severe security anti-pattern and should never be done. Once embedded, these credentials become an immutable part of the container image layer, making them discoverable by anyone with access to the image, even if the image is private. This practice also makes credential rotation extremely difficult, requiring a full image rebuild and redeployment, and violates the principle of least privilege by exposing sensitive information unnecessarily.

Go deeper

Related to this question