AZ-204 Practice Question: Connect to and consume Azure services and third-party services
Which TWO authentication mechanisms can be used to securely connect an Azure Function app to an Azure SQL Database using managed identities?
⚠ Common exam trap
Test-takers frequently confuse managed identities with service principals or certificate-based authentication, thinking any Microsoft Entra ID-backed method qualifies, but only system-assigned and user-assigned managed identities are the two specific managed identity types that eliminate credential management entirely.
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
✓
System-assigned managed identity
It creates an identity directly in Microsoft Entra ID tied to the Function app's lifecycle, allowing the app to authenticate to Azure SQL Database via the Active Directory Managed Identity authentication method without storing credentials. Option B (User-assigned managed identity) is also correct because it is a standalone Azure resource that can be assigned to the Function app, enabling the same passwordless Entra ID token-based authentication to Azure SQL Database and supporting identity reuse across resources. Option C (Service principal with client secret) is not a managed identity mechanism and requires storing and rotating a secret, so it does not meet the managed identity requirement. Option D (Certificate-based authentication) is a separate credential-based approach that is not a managed identity and requires managing certificates. Option E (Connection string with access key) uses SQL credentials or keys rather than managed identities and does not provide the passwordless Entra ID authentication described.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
System-assigned managed identity
Why this is correct
A system-assigned managed identity is automatically created and managed by Azure for a specific Azure resource instance, such as a Virtual Machine or App Service. Its lifecycle is directly tied to the resource, and it is automatically deleted when the resource is deleted. This identity authenticates to Microsoft Entra ID and can then be granted permissions to access other Azure services securely without needing to manage credentials in code. It provides a highly secure and automated way for Azure resources to authenticate.
- ✓
User-assigned managed identity
Why this is correct
A user-assigned managed identity is a standalone Azure resource that can be created once and assigned to multiple Azure services. Unlike system-assigned identities, its lifecycle is independent of any single resource, allowing for greater flexibility in managing access across various applications. It enables Azure resources to authenticate to Microsoft Entra ID and access other services securely, centralizing credential management and enhancing security by eliminating hardcoded secrets.
- ✗
Service principal with client secret
Why it's wrong here
A service principal with a client secret represents an application identity in Microsoft Entra ID, allowing applications to authenticate. While it provides programmatic access, it requires developers to manually manage and rotate the client secret, which is a sensitive credential. This manual management introduces a risk of secret leakage or expiration issues, making it less secure and more cumbersome than managed identities, which automate credential handling.
- ✗
Certificate-based authentication
Why it's wrong here
Certificate-based authentication involves using X.509 certificates for an application or service principal to prove its identity to Microsoft Entra ID. While highly secure when implemented correctly, it necessitates the manual generation, deployment, and rotation of certificates. This operational overhead for certificate lifecycle management, including renewal and revocation, makes it distinct from managed identities, which abstract away credential management entirely.
- ✗
Connection string with access key
Why it's wrong here
A connection string with an access key grants direct, full administrative access to a specific Azure resource, such as a storage account or Cosmos DB. This method relies on symmetric keys that must be stored and managed by the application, often in configuration files or environment variables. The significant security risk lies in the potential for these highly privileged keys to be exposed, as they are not automatically rotated or protected by Microsoft Entra ID identity and access management.
Go deeper
Related to this question
Learn chapter
App Service Auto-Scaling
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 Microsoft Entra ID authentication without storing credentials.
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.
About these practice questions
One of 883 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.