Correct Answer: Enable a system-assigned Managed Identity on the App Service and configure the SQL Database to allow that identity via Azure AD authentication, then use the DefaultAzureCredential in the connection string
Managed Identity eliminates the need for credentials entirely. The App Service obtains an Azure AD token automatically using its system-assigned identity, which is then used to aut...
Correct Answer
Enable a system-assigned Managed Identity on the App Service and configure the SQL Database to allow that identity via Azure AD authentication, then use the DefaultAzureCredential in the connection string
Why This Answer Is Correct
Managed Identity eliminates the need for credentials entirely. The App Service obtains an Azure AD token automatically using its system-assigned identity, which is then used to authenticate to Azure SQL. The connection string uses 'Authentication=Active Directory Managed Identity' — no password required.
This question evaluates your knowledge of Azure App Service — a core concept tested in Microsoft Certified: Azure Developer Associate (AZ-204). Understanding Azure App Service is essential for designing scalable, secure, and cost-effective cloud architectures. Mastery of this topic will help you answer scenario-based questions confidently on exam day.
You are deploying a web application to Azure App Service. Your team uses slot deployments. After deploying a new version to the staging slot and running smoke tests, you swap staging to production. Users report the app is slow for the first few minutes after the swap. What feature eliminates this cold-start issue?
Your Azure App Service web app stores connection strings for a database. You need to ensure the connection string value is different between your staging and production deployment slots. Which approach is correct?
Your team deploys a new version of a web application to Azure App Service using deployment slots. After deploying to the staging slot and running smoke tests, you perform a slot swap to production. Users report a brief period where some requests returned a 500 error during the swap. What caused this, and how should you fix it?
You are hosting a REST API on Azure App Service. To comply with corporate security standards, the API must only accept requests from a single external partner company's static public IP address. The solution must run at the platform level to prevent invalid traffic from consuming compute resources in your App Service plan. How should you configure this?