Develop Azure compute solutions →mediumMultiple ChoiceObjective-mapped

AZ-204 Develop Azure compute solutions Practice Question

Exhibit

public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    [Blob("samples-workitems/{rand-guid}", FileAccess.Write)] Stream blobStream,
    ILogger log)
{
    string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
    byte[] bytes = Encoding.UTF8.GetBytes(requestBody);
    await blobStream.WriteAsync(bytes, 0, bytes.Length);
    return new OkResult();
}

Refer to the exhibit. You have an HTTP-triggered Azure Function that writes the request body to a blob in the 'samples-workitems' container. The function runs successfully but does not create a blob. What is the most likely cause?

⚠ Common exam trap

Test-takers frequently assume the function code itself must be wrong (e.g., invalid container name or binding syntax) when the issue is a missing configuration setting that the Azure Functions runtime requires to connect to storage.

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 connection string is not set in the function app settings

The most likely cause is that the storage account connection string is not set in the function app settings. Azure Functions require the connection string for the storage account to be configured via the `AzureWebJobsStorage` app setting (or a custom connection setting referenced in the binding). Without it, the runtime cannot authenticate or communicate with Blob Storage, so the output binding silently fails to write the blob, even though the function executes successfully.

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 container name 'samples-workitems' is invalid
Why it's wrong here
The container name 'samples-workitems' is perfectly valid according to Azure Blob Storage naming conventions. Container names must be lowercase, between 3 and 63 characters long, and can only contain letters, numbers, and the dash (-) character. They must also start and end with a letter or number, all of which 'samples-workitems' adheres to.
✗
The blob name pattern {rand-guid} is not supported
Why it's wrong here
The blob name pattern {rand-guid} is a fully supported binding expression within Azure Functions. This expression dynamically generates a new globally unique identifier (GUID) for each function execution. Utilizing {rand-guid} ensures that each output blob has a unique name, effectively preventing overwrites and collisions in the target storage container.
✓
The storage account connection string is not set in the function app settings
Why this is correct
Azure Functions bindings, particularly for external services like Blob Storage, critically depend on a configured connection string to authenticate and authorize access. This connection string, often referenced by a setting like `AzureWebJobsStorage` or a custom name specified in the binding's `connection` property, must be present in the Function App's application settings. Without this essential configuration, the Azure Functions runtime cannot establish a connection to the specified storage account, leading to binding failures.
✗
The blob output binding syntax is incorrect
Why it's wrong here
The provided blob output binding syntax is standard and correctly structured for an Azure Function. A typical blob output binding specifies `type: "blob"`, `direction: "out"`, a `name` for the parameter, and a `path` defining the container and blob name pattern. This syntax effectively instructs the Azure Functions runtime on how to write data to a blob in the specified storage account.

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