Develop Azure compute solutions →mediumMultiple ChoiceObjective-mapped

AZ-204 Develop Azure compute solutions Practice Question

Exhibit

Refer to the exhibit.

{
  "type": "Microsoft.Web/sites/config",
  "apiVersion": "2023-01-01",
  "name": "[concat(parameters('siteName'), '/appsettings')]",
  "properties": {
    "WEBSITE_RUN_FROM_PACKAGE": "1",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "AzureWebJobsStorage": "[concat('DefaultEndpointsProtocol=https;AccountName=', parameters('storageAccountName'), ';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName')), '2023-01-01').keys[0].value, ';EndpointSuffix=core.windows.net')]"
  }
}

You are deploying an Azure Functions app using ARM template. The exhibit shows a portion of the template. You notice that the AzureWebJobsStorage connection string includes the account key directly. What is the MOST important security concern?

⚠ Common exam trap

The trap here is that candidates often focus on superficial issues like hardcoded names or protocol strings, missing the fundamental security risk of embedding a secret (the account key) in plaintext within an ARM template.

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

✓

The storage account key is exposed in the template, which could be compromised.

Embedding the storage account key directly in an ARM template exposes a long-lived secret in plaintext. If the template is stored in source control, shared, or logged, the key can be compromised, granting an attacker full access to the storage account. This violates the principle of least privilege and security best practices for infrastructure as code.

Answer analysis

Option-by-option breakdown

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

✗
The FUNCTIONS_WORKER_RUNTIME is set to dotnet-isolated, which is outdated.
Why it's wrong here
The `dotnet-isolated` worker runtime is a fully supported and recommended option for Azure Functions developed with .NET, allowing for greater control over dependencies and middleware. It enables the use of newer .NET versions like .NET 6, 7, and 8, running the function app in an isolated process from the host. Therefore, stating it is outdated is incorrect, as it represents a modern and secure approach to .NET function development.
✗
The storage account name is hardcoded in the connection string.
Why it's wrong here
ARM templates are designed to be dynamic, often utilizing parameters to provide configurable values during deployment. If the storage account name is passed into the template as a parameter and then referenced within the connection string, it is not considered hardcoded. This approach allows for flexible deployments across different environments without modifying the template itself, making the assertion of hardcoding incorrect.
✓
The storage account key is exposed in the template, which could be compromised.
Why this is correct
Directly embedding sensitive information, such as a storage account access key, within an ARM template constitutes a significant security vulnerability. Anyone with read access to the template, whether in source control or deployment logs, could potentially extract this key and gain unauthorized access to the associated storage account. Best practices mandate using Azure Key Vault to store secrets securely and referencing them via managed identities or Key Vault references in the template, preventing direct exposure.
✗
The connection string does not use HTTPS.
Why it's wrong here
Azure Storage connection strings, by default, establish secure communication using HTTPS. Even if `DefaultEndpointsProtocol=https` is not explicitly stated, the Azure SDKs and standard connection string formats will typically default to HTTPS for all interactions with Azure Storage services. The primary security concern in such a scenario would not be the lack of HTTPS, but rather the insecure handling of the connection string's sensitive components, like the account key.

Quick reference

Cloud Service Model Comparison

Model	You Manage	Provider Manages	Examples
IaaS	OS, runtime, apps, data	Hardware, hypervisor, networking	EC2, Azure VMs, GCP Compute Engine
PaaS	Apps and data	OS, runtime, middleware, hardware	Elastic Beanstalk, Azure App Service
SaaS	Data and settings only	Everything else	Microsoft 365, Salesforce, Workday
FaaS / Serverless	Function code only	Infra, scaling, runtime	Lambda, Azure Functions, Cloud Run
CaaS	Containers and apps	Kubernetes, OS, hardware	EKS, AKS, GKE

Go deeper

AZ-204 Develop Azure compute solutions Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Cloud Service Model Comparison

Related to this question