AZ-204 Develop Azure compute solutions Practice Question
Which THREE are valid ways to authenticate an Azure Functions app to an Azure Service Bus namespace?
⚠ Common exam trap
The trap here is that candidates might think client certificates are a valid authentication method for Service Bus, but Service Bus only supports Microsoft Entra ID, SAS tokens, and connection strings—not certificate-based authentication.
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
✓
Using an Microsoft Entra ID token obtained via DefaultAzureCredential
DefaultAzureCredential from the Azure Identity library can authenticate to Azure Service Bus using Microsoft Entra ID tokens. This credential chain attempts multiple authentication sources (environment variables, managed identity, Visual Studio, etc.) to obtain a token, which is then used to authorize requests to the Service Bus namespace via Azure RBAC.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Using an Microsoft Entra ID token obtained via DefaultAzureCredential
Why this is correct
Azure Functions can authenticate to other Azure services (like Key Vault, Storage, Cosmos DB) using Microsoft Entra ID tokens. DefaultAzureCredential is part of the Azure Identity client library, providing a chain of credential types that attempt to authenticate in various environments (local development, Azure deployment) using the most appropriate method, such as a developer's logged-in account, environment variables, or a managed identity, ultimately acquiring an Microsoft Entra ID token. This enables secure, token-based access without hardcoding secrets.
- ✓
Using a connection string with shared access policy
Why this is correct
Many Azure services, such as Azure Storage, Azure Service Bus, and Azure Cosmos DB, support authentication via a connection string. This string typically contains the service endpoint and a Shared Access Key (SAK) or a Shared Access Signature (SAS) token, which grants specific permissions to access the resource. While effective, it's crucial to store connection strings securely, preferably in Azure Key Vault or application settings, to prevent exposure of the underlying keys.
- ✓
Using a system-assigned managed identity
Why this is correct
A system-assigned managed identity provides an Azure Function with an automatically managed identity in Microsoft Entra ID. This identity can then be granted specific Azure RBAC roles to access other Azure resources, such as Azure Key Vault or Azure Storage, without needing to manage any credentials in the function's code or configuration. It simplifies authentication and enhances security by eliminating the need for developers to handle secrets.
- ✗
Using a client certificate
Why it's wrong here
While client certificates are a valid authentication mechanism in some scenarios, such as mutual TLS for web apps or specific enterprise integrations, they are generally not a standard or directly supported method for an Azure Function to authenticate itself to other Azure services like Azure Storage, Service Bus, or Key Vault. Azure Functions primarily leverage Microsoft Entra ID, managed identities, or connection strings for outbound authentication to Azure resources, making client certificates an uncommon and often unsupported approach in this context.
- ✗
Using a SAS key stored in code
Why it's wrong here
While a Shared Access Signature (SAS) key can grant granular access to Azure Storage resources, directly embedding a SAS key within the function's code is a significant security anti-pattern. Hardcoding any secret, including a SAS key, makes it difficult to rotate, increases the risk of exposure if the code is compromised, and violates the principle of least privilege. Instead, SAS tokens should be generated on demand, retrieved securely from Key Vault, or managed via connection strings stored in application settings.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Azure App Configuration Service
Key term
Key Vault Secrets
Key Vault Secrets are secure containers in Microsoft Azure that store sensitive information like passwords, connection strings, and API keys, keeping them encrypted and accessible only to authorized applications and users.
Key term
Azure Functions Bindings
Azure Functions Bindings are declarative connections that link your serverless function code to Azure services or external resources, handling input and output data automatically without writing extra networking or authentication code.
About these practice questions
Courseiva writes every AZ-204 question from scratch — 883 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.