AZ-204 Practice Question: Connect to and consume Azure services and third-party services
Northwind Traders is building a microservices architecture on Azure Kubernetes Service (AKS). One service needs to read messages from an Azure Service Bus queue and write them to an Azure SQL database. The solution must use managed identities for authentication. The AKS cluster is integrated with Microsoft Entra ID. The development team wants to avoid managing service principals and secrets. The team has chosen to use the Azure Identity SDK for authentication. The service will run as a pod in AKS. Which approach should the team use to authenticate to Service Bus and Azure SQL Database?
⚠ Common exam trap
Test-takers frequently confuse using Azure Key Vault for secret storage (Option C) with using managed identities for authentication, but the question explicitly requires managed identities for authentication, not just for accessing secrets.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Deploy Azure AD Pod Identity (or Workload Identity) to assign a user-assigned managed identity to the pod. Use DefaultAzureCredential in the code. Grant the identity 'Listen' on Service Bus and 'Connect' on SQL Database.
Azure AD Pod Identity (or Workload Identity) allows you to assign a user-assigned managed identity to a pod, eliminating the need to manage service principals or secrets. The DefaultAzureCredential from the Azure Identity SDK automatically uses the pod's managed identity to authenticate to Azure services. Granting the identity 'Listen' on Service Bus and 'Connect' on SQL Database provides the minimum required permissions for the service to read messages and write to the database.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Generate a self-signed certificate, upload it to AKS, and use ClientCertificateCredential in the code.
Why it's wrong here
This approach requires generating and managing a self-signed certificate, which introduces significant operational overhead for secure storage, rotation, and revocation within the AKS environment. While ClientCertificateCredential can authenticate, it does not leverage Azure AD managed identities, which are specifically designed to eliminate the need for manual credential management and enhance security by integrating with Azure AD. This method is generally less secure and more complex than using managed identities for Azure resource access.
- ✓
Deploy Azure AD Pod Identity (or Workload Identity) to assign a user-assigned managed identity to the pod. Use DefaultAzureCredential in the code. Grant the identity 'Listen' on Service Bus and 'Connect' on SQL Database.
Why this is correct
This is the most secure and recommended approach for microservices in AKS. Deploying Azure AD Pod Identity (or its successor, Workload Identity) allows assigning a user-assigned managed identity directly to the Kubernetes pod, eliminating the need for hardcoded credentials or secrets. DefaultAzureCredential then automatically discovers and uses this identity for authentication to Azure services like Service Bus and SQL Database, while granting specific permissions ('Listen', 'Connect') adheres to the principle of least privilege.
- ✗
Store Service Bus connection string and SQL connection string in Azure Key Vault. Use Key Vault SDK to retrieve them at runtime.
Why it's wrong here
While Azure Key Vault is an excellent solution for securely storing secrets, this approach still requires the application to retrieve and manage connection strings that contain sensitive credentials. The application itself would need an identity (e.g., a managed identity) to access Key Vault, but the core issue of managing and rotating the underlying connection string secrets for Service Bus and SQL Database persists. It doesn't fully eliminate credential management for the target services themselves.
- ✗
Create a service principal and store its client secret in a Kubernetes secret. Use ClientSecretCredential in the code. Assign the service principal permissions to Service Bus and SQL.
Why it's wrong here
This method involves creating a service principal and storing its client secret directly within a Kubernetes secret, which then needs to be securely mounted or injected into the pod. This reintroduces the operational burden of secret management, including secure storage, rotation, and lifecycle management of the client secret. Managed identities are designed to abstract away these complexities by providing an identity managed by Azure AD, eliminating the need for client secrets and reducing the attack surface.
Go deeper
Related to this question
Learn chapter
Azure Functions Development
Key term
Managed identity
A managed identity is an automatically managed service principal in Azure that allows your code to authenticate to any service that supports Azure AD authentication without storing credentials.
Key term
Azure Relay
Azure Relay is a cloud service that securely exposes on-premises web services to the public internet or other cloud applications without opening firewall ports.
About these practice questions
One of 881 original AZ-204 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.