CCNA Azure Compute Solutions Questions — Page 2 of 4

MCQmedium

You are developing a web application that allows users to upload images. The application is deployed on Azure App Service. After upload, the images must be processed to generate thumbnails and to extract metadata. The processing should happen asynchronously and must be resilient to failures. You need to design the solution using serverless components. The solution must minimize latency for the user during upload, and the processing must be retried automatically if it fails. You also need to ensure that the processing is idempotent, so that duplicate messages do not cause duplicate thumbnails. Which approach should you use? Option A: Use Azure Functions with a Blob Storage trigger to process each image as it is uploaded. The function generates thumbnails and stores metadata in Cosmos DB. Use the `leaseBlob` property to prevent duplicate processing. Option B: Use Azure Functions with an Event Grid trigger to process images. The function generates thumbnails and stores metadata in Cosmos DB. Use Event Grid's built-in retry policy and idempotent logic in the function. Option C: Use Azure Logic Apps with a Blob Storage connector to process images. The logic app generates thumbnails and stores metadata in Cosmos DB. Configure retry policy on the connector. Option D: Use Azure Functions with a Service Bus queue trigger. The web app sends a message to the queue after upload. The function processes the message, generates thumbnails, and stores metadata. Use message deduplication to ensure idempotency.

A.Azure Functions with Blob Storage trigger, using leaseBlob

B.Azure Logic Apps with Blob Storage connector

C.Azure Functions with Event Grid trigger

D.Azure Functions with Service Bus queue trigger and duplicate detection

AnswerD

Service Bus duplicate detection ensures idempotency; the queue separates upload from processing.

Why this answer

Option D is correct because it uses a Service Bus queue with duplicate detection, which ensures idempotent processing by automatically discarding duplicate messages within a defined time window. The web app uploads the image and immediately sends a message to the queue, minimizing user latency. The Azure Function triggered by the queue processes the image asynchronously, and Service Bus's built-in retry policy (via dead-lettering and max delivery count) provides resilience against failures.

Exam trap

The trap here is that candidates often choose Event Grid (Option B) because it is serverless and has retry policies, but they overlook that Event Grid does not provide built-in message deduplication, which is critical for idempotent processing in this scenario.

How to eliminate wrong answers

Option A is wrong because Blob Storage triggers do not have a `leaseBlob` property for deduplication; blob leases are used for concurrency control, not for preventing duplicate processing of the same blob event, and Blob Storage triggers can miss events or fire duplicates without built-in deduplication. Option B is wrong because Event Grid triggers have a retry policy but lack built-in message deduplication; idempotency must be implemented manually in the function, and Event Grid does not guarantee exactly-once delivery, making duplicate handling error-prone. Option C is wrong because Logic Apps with a Blob Storage connector are not serverless in the same sense (they have higher latency and cost), and the connector does not provide message-level deduplication; retry policies on connectors do not ensure idempotent processing of duplicate blob events.

Practice this question →

MCQeasy

You are developing an Azure Function that uses a Service Bus queue trigger. You need to ensure that the function processes messages one at a time to guarantee order. Which configuration should you use?

A.Set the batchSize to 1 in host.json

B.Set the maxMessages to 1 in the ServiceBusTrigger attribute

C.Set the function to run on a Premium Plan

D.Set the maxDequeueCount to 1 in host.json

AnswerA

Correct. This ensures one message per function invocation, maintaining order.

Why this answer

Option A is correct because setting `batchSize` to 1 in `host.json` forces the Service Bus trigger to process only one message at a time from the queue. This ensures strict message ordering, as the function will not fetch or process the next message until the current one is completed (either successfully or moved to the dead-letter queue). The Service Bus trigger uses a message pump that respects the `batchSize` setting to control concurrency.

Exam trap

The trap here is that candidates often confuse `batchSize` (which controls how many messages are fetched at once) with `maxConcurrentCalls` (which controls how many parallel executions are allowed), and incorrectly assume that setting `maxConcurrentCalls` to 1 in the trigger attribute is the solution, but the attribute does not have a `maxMessages` property.

How to eliminate wrong answers

Option B is wrong because `maxMessages` is not a valid property of the `ServiceBusTrigger` attribute; the correct attribute property to control concurrency is `IsBatched` or `MaxConcurrentCalls`, but neither directly limits batch size to 1 for ordering. Option C is wrong because the Premium Plan provides higher throughput and predictable performance but does not inherently enforce single-message processing; ordering must be configured via `batchSize`. Option D is wrong because `maxDequeueCount` in `host.json` controls the number of times a message can be retried before being dead-lettered, not the concurrency or batch size.

Practice this question →

Multi-Selectmedium

Which THREE are benefits of using Azure Logic Apps compared to Azure Functions for workflow orchestration?

Select 3 answers

A.Native connectors to hundreds of services

B.Support for long-running workflows with checkpointing

C.Better suited for custom code logic

D.Visual designer for workflow creation

E.Lower cost for high-volume processing

AnswersA, B, D

Large library of connectors.

Why this answer

Option A is correct because Azure Logic Apps provides over 400 prebuilt connectors to services like Office 365, Dynamics 365, Salesforce, and SQL Server, enabling rapid integration without writing any code. This native connector ecosystem is a key differentiator from Azure Functions, which requires custom code to interact with external services via SDKs or HTTP calls.

Exam trap

The trap here is that candidates often confuse the low-code nature of Logic Apps with being 'better for custom logic,' when in fact Azure Functions excel at custom code, and Logic Apps are superior for integration and orchestration with native connectors and visual design.

Practice this question →

MCQmedium

You develop a containerized application that runs on Azure Container Instances (ACI). The application needs to securely access Azure SQL Database using a connection string. You want to minimize administrative effort and avoid storing secrets in the container image. What should you do?

A.Embed the connection string in the container image as a configuration file.

B.Store the connection string in an environment variable in the container group.

C.Enable managed identity for the container group and use Microsoft Entra authentication to Azure SQL.

D.Mount a volume from Azure Key Vault using a secret volume.

AnswerC

Managed identity eliminates the need for secrets and is the recommended approach.

Why this answer

Option C is correct because enabling a managed identity for the container group allows the application to authenticate to Azure SQL Database using Microsoft Entra ID (formerly Azure Active Directory) without storing any secrets. The application requests an access token from the Azure Instance Metadata Service (IMDS) endpoint at 169.254.169.254, then uses that token to connect to Azure SQL. This eliminates the need to manage connection strings or secrets, minimizing administrative effort and keeping secrets out of the container image.

Exam trap

The trap here is that candidates often confuse environment variables (Option B) as a secure alternative to embedding secrets, but environment variables are still plaintext and visible in the container's process list, whereas managed identity provides true secretless authentication.

How to eliminate wrong answers

Option A is wrong because embedding the connection string in the container image as a configuration file violates the requirement to avoid storing secrets in the image; anyone with access to the image can extract the secret. Option B is wrong because storing the connection string in an environment variable in the container group still exposes the secret in plaintext within the container's runtime environment and requires manual management of the secret value. Option D is wrong because mounting a volume from Azure Key Vault using a secret volume still requires the container to have a connection string (or secret) to access Key Vault initially, and it introduces additional complexity without leveraging the simpler managed identity approach.

Practice this question →

MCQhard

A company runs an ASP.NET Core web app on Azure App Service. They need to implement health checks that monitor the app's dependencies, such as a database and an external API. The health endpoint should return a 200 status if all dependencies are healthy, a 503 if any dependency is unhealthy, and a 400 if the request is malformed. Which approach should you take?

A.Implement custom health checks using the ASP.NET Core Health Checks middleware.

B.Use the ASP.NET Core Diagnostics middleware to generate a health page.

C.Configure Application Insights availability tests.

D.Use the built-in health check endpoint in Azure App Service.

AnswerA

Allows custom status codes and dependency checks.

Why this answer

Option A is correct because the ASP.NET Core Health Checks middleware allows you to implement custom health checks that monitor specific dependencies like a database and an external API. You can configure the middleware to return a 200 OK status when all checks pass, a 503 Service Unavailable when any check fails, and a 400 Bad Request for malformed requests by using the appropriate response writer and status code mapping.

Exam trap

The trap here is that candidates often confuse the built-in Azure App Service health check endpoint (which only returns 200 OK for the app's root) with the customizable ASP.NET Core Health Checks middleware that supports dependency monitoring and custom status codes.

How to eliminate wrong answers

Option B is wrong because the ASP.NET Core Diagnostics middleware is designed for developer exception pages and status code pages, not for implementing dependency-specific health checks with custom status codes like 503 or 400. Option C is wrong because Application Insights availability tests are used for monitoring the availability of a web endpoint from external locations, not for implementing an internal health endpoint that checks application dependencies and returns specific HTTP status codes. Option D is wrong because the built-in health check endpoint in Azure App Service only provides a basic ping check (returning 200 OK) and does not support custom dependency monitoring or returning 503 or 400 status codes.

Practice this question →

MCQeasy

You are developing a serverless application using Azure Functions. The function must process messages from an Azure Storage Queue and write results to Azure Cosmos DB. Which binding should you use for the output?

A.Azure Blob Storage output binding

B.Azure Cosmos DB input binding

C.Azure Storage Queue output binding

D.Azure Cosmos DB output binding

AnswerD

Output binding writes data to Cosmos DB.

Why this answer

Option D is correct because the Azure Cosmos DB output binding allows you to write the results of queue-triggered function execution directly to a Cosmos DB container. The function processes messages from an Azure Storage Queue (input binding) and uses the output binding to insert or upsert documents into Cosmos DB without writing any SDK code.

Exam trap

The trap here is that candidates may confuse input and output bindings, selecting the Cosmos DB input binding (Option B) because they see 'Cosmos DB' and forget the direction, or choose the Blob Storage binding (Option A) because they associate storage with output without reading the requirement for Cosmos DB.

How to eliminate wrong answers

Option A is wrong because the Azure Blob Storage output binding writes data to blobs, not to Cosmos DB, so it cannot satisfy the requirement to write results to Cosmos DB. Option B is wrong because the Azure Cosmos DB input binding is used to read data from Cosmos DB before function execution, not to write output results. Option C is wrong because the Azure Storage Queue output binding writes messages to a queue, which is unrelated to writing results to Cosmos DB.

Practice this question →

MCQhard

A Durable Functions workflow for a checkout API must call five independent activity functions and continue only after all results are available. Which pattern is appropriate?

A.Fan-out/fan-in

B.Human interaction

C.Function chaining

D.Monitor pattern

AnswerA

Fan-out/fan-in runs activities in parallel and aggregates results after all complete.

Why this answer

The fan-out/fan-in pattern is correct because Durable Functions provides the `CallActivityAsync` method in parallel to invoke multiple independent activity functions simultaneously, and the `Task.WhenAll` pattern waits for all results before proceeding. This matches the requirement to call five independent activities and continue only after all results are available, which is the exact definition of fan-out/fan-in.

Exam trap

The trap here is that candidates confuse function chaining (sequential execution) with fan-out/fan-in (parallel execution), failing to recognize that the requirement for 'independent' activities and 'continue only after all results are available' explicitly demands parallelism, not sequential chaining.

How to eliminate wrong answers

Option B (Human interaction) is wrong because it involves waiting for external human approval via `WaitForExternalEvent`, not parallel execution of independent activities. Option C (Function chaining) is wrong because it executes activities sequentially, each depending on the previous output, which does not allow parallel execution. Option D (Monitor pattern) is wrong because it polls an external resource on a timer, not orchestrating parallel activity calls.

Practice this question →

Multi-Selecthard

You are designing a serverless application using Azure Functions. The application processes messages from Azure Service Bus. You need to ensure that processing is idempotent and that messages are not lost. Which THREE actions should you take?

Select 3 answers

A.Process messages in batches to improve throughput.

B.Implement idempotency in the function logic.

C.Use PeekLock mode and manually complete messages after processing.

D.Use the AutoComplete option to automatically mark messages as complete.

E.Set the max delivery count on the Service Bus queue to prevent infinite retries.

AnswersB, C, E

Idempotency ensures that duplicate messages do not cause side effects.

Why this answer

Option B is correct because idempotency ensures that processing the same message multiple times produces the same result, which is critical for serverless applications where retries or duplicate deliveries can occur. Azure Functions can receive the same Service Bus message more than once due to transient failures or redelivery, so the function logic must handle duplicates safely, often by checking a unique message ID or using a deduplication store.

Exam trap

The trap here is that candidates often confuse AutoComplete with reliability, but AutoComplete can lead to message loss if the function crashes after processing but before the completion is committed, whereas PeekLock with manual completion ensures messages are not lost.

Practice this question →

MCQmedium

You deploy a containerized background job to Azure Container Instances (ACI). The job should automatically restart only if it exits with a non-zero exit code (i.e., crashes). You want to minimize costs. Which restart policy should you configure?

A.Always

B.OnFailure

C.Never

D.Retry

AnswerB

This policy restarts only when the container exits with a non-zero exit code, which matches the requirement to restart on failure while minimizing costs.

Why this answer

The OnFailure restart policy is correct because it restarts the container only when it exits with a non-zero exit code, indicating a crash or error. This matches the requirement to automatically restart only on failure while minimizing costs, as it avoids unnecessary restarts on successful completions.

Exam trap

The trap here is that candidates may confuse the OnFailure policy with the Always policy, thinking that Always is needed for automatic restarts, but they overlook the cost implication and the specific requirement to restart only on failure.

How to eliminate wrong answers

Option A is wrong because the Always restart policy restarts the container regardless of the exit code, even on successful completions, which would incur unnecessary costs and is not aligned with the requirement to restart only on failure. Option C is wrong because the Never restart policy does not restart the container under any circumstances, so it would not automatically restart on a crash. Option D is wrong because Retry is not a valid restart policy for Azure Container Instances; the valid policies are Always, OnFailure, and Never.

Practice this question →

Multi-Selectmedium

Your company is deploying a multi-container application using Azure Container Instances (ACI) in a virtual network. You need to ensure that containers can communicate with each other using localhost. Which TWO actions should you take?

Select 2 answers

A.Define environment variables on each container with the hostnames.

B.Deploy all containers in the same container group.

C.Assign different private IP addresses to each container.

D.Deploy containers in separate container groups and use service discovery.

E.Use the container group's fully qualified domain name (FQDN) to communicate.

AnswersB, E

Containers in the same group share the same network stack.

Why this answer

Option B is correct because containers within the same container group in Azure Container Instances share the same network namespace, including the same IP address and port space. This allows them to communicate over localhost (127.0.0.1) without additional configuration, as they are essentially running on the same virtual machine.

Exam trap

The trap here is that candidates often confuse container groups with separate containers in a Docker Compose or Kubernetes pod context, assuming that localhost communication requires explicit network configuration or service discovery, when in fact ACI container groups inherently share the same network namespace.

Practice this question →

MCQhard

You host a web application on Azure App Service using multiple deployment slots (production and staging). After swapping staging into production, users report errors. You need to ensure that the staging slot is warmed up before swapping and that any errors during swap cause an automatic rollback. What should you configure?

A.Configure deployment slot settings to be sticky.

B.Enable auto swap and configure a custom warm-up path.

C.Use swap with preview and complete the swap after verification.

D.Configure manual swap and run a warm-up script before swapping.

AnswerB

Auto swap with a custom warm-up path ensures the slot is warmed up; Azure automatically rolls back if the warm-up fails.

Why this answer

Option B is correct because enabling auto swap with a custom warm-up path ensures the staging slot is fully warmed up before the swap occurs, and if the warm-up fails or the application returns errors during the swap, Azure App Service automatically rolls back to the previous slot. This directly addresses the requirement for both pre-swap warm-up and automatic rollback on errors.

Exam trap

The trap here is that candidates often confuse 'swap with preview' (which requires manual completion) with automatic rollback, or think that sticky settings alone can handle warm-up and error recovery, when in fact auto swap with a custom warm-up path is the only built-in mechanism that combines both warm-up and automatic rollback.

How to eliminate wrong answers

Option A is wrong because making deployment slot settings sticky (slot-specific) only ensures that configuration and connection strings remain with the slot after a swap; it does not provide any warm-up or automatic rollback functionality. Option C is wrong because swap with preview allows you to validate the staging slot before completing the swap, but it does not automatically roll back on errors; you must manually complete or cancel the swap, which does not meet the 'automatic rollback' requirement. Option D is wrong because manual swap with a warm-up script requires custom scripting and does not provide built-in automatic rollback on swap errors; the rollback would need to be manually orchestrated.

Practice this question →

MCQhard

Refer to the exhibit. You run this Azure CLI command to configure an Azure Web App for Containers. The web app fails to start, and the logs show 'unauthorized: authentication required'. What is the most likely cause?

A.The command did not include admin credentials or managed identity configuration

B.The image tag 'latest' does not exist

C.The web app is configured to use a deployment slot, but the slot is not specified

D.The --docker-registry-server-url is incorrect

AnswerA

Correct: Without credentials, the web app cannot authenticate to the registry.

Why this answer

Option A is correct because the Azure CLI command `az webapp config container set` without specifying `--docker-registry-server-user` and `--docker-registry-server-password` (or a managed identity configuration) means the web app cannot authenticate with a private container registry. The 'unauthorized: authentication required' error indicates the registry requires credentials, and the web app has none configured, so it fails to pull the image.

Exam trap

The trap here is that candidates assume the 'latest' tag always exists or that the registry URL is the only configuration needed, overlooking that private registries require explicit authentication credentials or managed identity setup.

How to eliminate wrong answers

Option B is wrong because if the 'latest' tag did not exist, the error would be 'manifest not found' or 'image not found', not 'unauthorized: authentication required'. Option C is wrong because deployment slots are unrelated to registry authentication; the error is about pulling the image, not routing traffic to a slot. Option D is wrong because an incorrect `--docker-registry-server-url` would cause a 'connection refused' or 'name resolution failure' error, not an authentication error.

Practice this question →

MCQhard

You have a Durable Functions orchestration that calls an activity function which may throw an exception due to a transient network issue. You want to retry the activity up to 3 times with a 2-second delay between attempts and exponential backoff. Which method should you use in the orchestrator function?

A.await context.CallActivityAsync("MyActivity", input);

B.await context.CallActivityWithRetryAsync("MyActivity", new RetryOptions(TimeSpan.FromSeconds(2), 3), input);

C.await context.CallSubOrchestratorAsync("MyActivity", input);

D.await context.CallHttpAsync(HttpMethod.Get, new Uri("..."), input);

AnswerB

Correct. CallActivityWithRetryAsync with RetryOptions(TimeSpan.FromSeconds(2), 3) implements up to 3 attempts with a 2-second initial delay.

Why this answer

Option B is correct because the `CallActivityWithRetryAsync` method is specifically designed for retrying activity functions in Durable Functions. It accepts a `RetryOptions` object where you can configure the delay (`TimeSpan.FromSeconds(2)`) and the maximum number of retry attempts (3), and it automatically applies exponential backoff between retries. This directly satisfies the requirement to retry the activity up to 3 times with a 2-second initial delay and exponential backoff.

Exam trap

The trap here is that candidates may confuse `CallActivityWithRetryAsync` with `CallActivityAsync` or `CallSubOrchestratorAsync`, not realizing that only `CallActivityWithRetryAsync` provides the built-in retry mechanism with configurable delay and exponential backoff for activity functions.

How to eliminate wrong answers

Option A is wrong because `CallActivityAsync` does not support any retry logic; if the activity throws an exception, the orchestration will fail immediately without retrying. Option C is wrong because `CallSubOrchestratorAsync` is used to call another orchestrator function, not an activity function, and it does not provide built-in retry configuration for transient failures. Option D is wrong because `CallHttpAsync` is used for making HTTP calls from orchestrator functions, not for calling activity functions, and it does not support the retry policy described in the question.

Practice this question →

MCQmedium

An Azure Container Instance running a claims processing function requires a password at startup. The password must not be visible in the portal or container logs. What should be used?

A.Plain environment variable

B.Secure environment variable

C.Public blob containing the password

D.Container command-line argument

AnswerB

Secure environment variables in ACI protect sensitive values and hide them from normal display.

Why this answer

Secure environment variables in Azure Container Instances are encrypted at rest and in transit, and are never exposed in the Azure portal, container logs, or to other users. This ensures the password remains confidential while being available to the container at startup, meeting the requirement of not being visible in the portal or logs.

Exam trap

The trap here is that candidates often confuse 'secure environment variables' with 'plain environment variables' or assume that command-line arguments are not logged, when in fact they are captured in container logs and visible in the portal.

How to eliminate wrong answers

Option A is wrong because plain environment variables are stored in plaintext and are visible in the Azure portal and container logs, violating the security requirement. Option C is wrong because a public blob containing the password would be accessible to anyone with the URL, completely compromising the password's confidentiality. Option D is wrong because container command-line arguments are logged in the container's startup logs and can be viewed in the portal, making them visible and insecure.

Practice this question →

MCQmedium

You deploy a containerized application to Azure Container Instances (ACI). The application writes logs that must persist across container restarts and be accessible from a file system. The solution must minimize cost and complexity. Which configuration should you use?

A.Mount an Azure Files share as a volume

B.Store logs in Azure Container Registry

C.Use a Docker volume in the container

D.Pass log path via an environment variable

AnswerA

Correct. Azure Files provides SMB file shares that can be mounted as volumes in ACI, offering persistent storage at low cost with minimal complexity.

Why this answer

Mounting an Azure Files share as a volume in Azure Container Instances provides persistent, shared file storage that survives container restarts and is accessible via the container's file system. This approach minimizes cost by using standard Azure Files storage (pay only for consumed capacity) and complexity by leveraging ACI's native volume mount support without requiring additional orchestration or stateful infrastructure.

Exam trap

The trap here is that candidates confuse ephemeral Docker volumes (which are lost on restart) with persistent Azure Files shares, or mistakenly think Azure Container Registry can store runtime data like logs.

How to eliminate wrong answers

Option B is wrong because Azure Container Registry is a private registry for storing and managing container images, not a runtime storage location for application logs; logs written to ACR would not be accessible from the container's file system and would not persist across restarts. Option C is wrong because Docker volumes in ACI are ephemeral and tied to the container's lifecycle — they are lost when the container is restarted or recreated, failing the persistence requirement. Option D is wrong because an environment variable only passes configuration data (like a log path string) into the container; it does not provide any actual storage mechanism for log data to persist or be accessed from the file system.

Practice this question →

MCQmedium

You have an Azure Function with a Service Bus queue trigger. The function processes messages that must be handled in order within each partition of the queue. You need to ensure that the function does not process multiple messages from the same partition concurrently, while still allowing parallel processing across different partitions. Which setting should you configure?

A.Set the batch size to 1 in the function configuration.

B.Set the maxConcurrentCallsPerSession to 1, or use a session-enabled queue and set maxConcurrentSessions to 1 if using sessionId.

C.Use a consumption plan, which automatically limits concurrency.

D.Use a queue trigger instead of a Service Bus trigger.

AnswerB

This setting limits the number of concurrent calls per partition/session, ensuring sequential processing within a partition while allowing parallel processing across partitions.

Why this answer

Option B is correct because Service Bus sessions provide exactly-once-in-order message processing within a partition (session). Setting `maxConcurrentCallsPerSession` to 1 ensures that only one message from a given session is processed at a time, while `maxConcurrentSessions` controls how many different sessions can be processed in parallel. This allows concurrent processing across partitions but serializes processing within each partition.

Exam trap

The trap here is that candidates often confuse batch size with concurrency control, thinking that reducing batch size to 1 prevents parallel processing, when in fact it only limits the number of messages retrieved per fetch, not the number of concurrent executions.

How to eliminate wrong answers

Option A is wrong because setting batch size to 1 only limits how many messages are fetched at once, but does not prevent concurrent processing of multiple messages from the same partition—multiple function instances could still process them in parallel. Option C is wrong because the Consumption Plan does not automatically limit concurrency per partition; it only scales the number of function instances, which can still lead to concurrent processing of the same partition. Option D is wrong because a queue trigger (e.g., Storage Queue) does not support session-based ordering or partition-level concurrency control; it processes messages in a first-in-first-out manner but without guaranteed ordering or partition isolation.

Practice this question →

MCQmedium

A image resize worker runs in Azure App Service and must call a private API hosted inside a virtual network. Which feature allows outbound access from the app to the VNet?

A.Regional VNet integration

B.Azure CDN custom domain

C.Application Gateway path routing

D.Private Endpoint for the web app only

AnswerA

Regional VNet integration enables App Service outbound connectivity to resources in a virtual network.

Why this answer

Regional VNet integration enables an Azure App Service app to make outbound calls to resources in a virtual network (VNet) over the Microsoft backbone network. It uses a delegated subnet in the VNet to assign the app a network interface in the VNet, allowing it to reach private APIs without exposing them to the public internet.

Exam trap

The trap here is confusing inbound connectivity (Private Endpoint) with outbound connectivity (VNet integration), leading candidates to select Private Endpoint when the question asks for outbound access from the app to the VNet.

How to eliminate wrong answers

Option B is wrong because Azure CDN custom domain is a content delivery feature that caches and serves public endpoints, not a mechanism for outbound VNet access from an app. Option C is wrong because Application Gateway path routing is an inbound load-balancing and routing feature for HTTP traffic, not an outbound connectivity feature from App Service to a VNet. Option D is wrong because a Private Endpoint for the web app only provides inbound access from the VNet to the app, not outbound access from the app to resources in the VNet.

Practice this question →

MCQmedium

A report export service hosted on App Service returns intermittent 502 errors during deployment. The team wants zero-downtime release with validation before traffic moves. What should be implemented?

A.Deploy to a staging slot, validate health, then swap

B.Deploy directly to production during business hours

C.Restart the App Service plan before each deployment

D.Disable health checks

AnswerA

Slot swaps allow pre-production validation and reduce deployment interruption.

Why this answer

Deploying to a staging slot and then swapping with production ensures zero-downtime because the swap operation warms up the target slot (staging) before routing traffic to it. The health check validation before swap confirms the new release is stable, preventing 502 errors from reaching users. This approach leverages Azure App Service deployment slots, which support traffic routing and warm-up during swap.

Exam trap

The trap here is that candidates may think restarting the plan or disabling health checks is a valid fix, but these actions cause downtime or remove safety nets, whereas deployment slots with health checks provide the required zero-downtime release and validation.

How to eliminate wrong answers

Option B is wrong because deploying directly to production during business hours risks exposing users to a faulty release, causing 502 errors and downtime without any validation or rollback safety. Option C is wrong because restarting the App Service plan before each deployment does not prevent 502 errors; it causes all instances to restart simultaneously, leading to downtime and potential request failures. Option D is wrong because disabling health checks removes the mechanism that detects unhealthy instances, allowing faulty deployments to serve traffic and worsen 502 errors.

Practice this question →

MCQhard

You are deploying a microservice to Azure Container Apps. The service requires a custom domain and SSL/TLS certificate. Which resource should you configure to meet these requirements?

A.Azure Front Door with a custom domain

B.Azure Container Apps environment with a custom domain and certificate attached

C.Azure API Management in front of the Container App

D.Azure Application Gateway with SSL termination

AnswerB

Correct: Container Apps supports custom domains and managed certificates.

Why this answer

Option A is correct because Container Apps supports custom domains and certificates via the environment. Option B is wrong because API Management is a separate service. Option C is wrong because Front Door is for global load balancing.

Option D is wrong because App Gateway is for traditional web apps.

Practice this question →

Multi-Selecthard

Your Azure Container Apps solution uses Dapr for microservices communication. Which THREE Dapr building blocks are essential for service-to-service invocation and state management?

Select 3 answers

A.Service Invocation

B.Bindings

C.Pub/Sub

D.Actors

E.State Management

AnswersA, C, E

Service Invocation is the building block for direct service-to-service calls.

Why this answer

Service Invocation (A) is correct because Dapr's service invocation building block enables direct, secure service-to-service communication using gRPC or HTTP, with built-in mTLS, retries, and observability. State Management (E) is correct because it provides a key-value store abstraction for managing state across microservices, supporting pluggable state stores like Redis, Cosmos DB, or SQL Server. Pub/Sub (C) is correct because it enables asynchronous event-driven communication between services, decoupling producers and consumers via message brokers like Kafka, RabbitMQ, or Azure Service Bus.

Exam trap

The trap here is that candidates often confuse Bindings with service invocation (both involve external communication) or assume Actors are required for state management, but Dapr separates these concerns into distinct building blocks with specific use cases.

Practice this question →

MCQmedium

Your company develops a microservices-based application deployed on Azure Kubernetes Service (AKS). One of the microservices is a web API that processes user uploads and stores them in Azure Blob Storage. The API is stateless and scales horizontally. You need to implement authentication and authorization for the API using Microsoft Entra ID. The API should validate tokens issued by Entra ID and allow only users with the 'Files.Upload' scope. You need to configure the API's code and AKS deployment accordingly. Which approach should you use?

A.Use Azure AD pod identity in AKS to assign a managed identity to the pod, and implement token validation in the API code using the Microsoft.Identity.Web library.

B.Store the storage account access keys in the API configuration and validate requests using shared access signatures.

C.Configure the API to use client certificate authentication instead of tokens.

D.Expose the API through Azure API Management (APIM) and configure APIM to validate tokens and check scope.

AnswerA

Pod identity provides managed identity; API validates tokens and checks scope.

Why this answer

Option A is correct because Azure AD pod identity allows you to assign a managed identity to the pod, which the API can use to authenticate with Microsoft Entra ID. The Microsoft.Identity.Web library simplifies token validation and scope checking in ASP.NET Core applications, enabling the API to validate tokens issued by Entra ID and enforce the 'Files.Upload' scope. This approach aligns with the stateless, horizontally scalable nature of the microservice and avoids managing secrets.

Exam trap

The trap here is that candidates may think Azure API Management (APIM) is required for token validation in AKS, but the question explicitly asks for configuring the API's code and AKS deployment, making the pod identity and library approach the correct in-code solution without an extra gateway.

How to eliminate wrong answers

Option B is wrong because storage account access keys are shared secrets that do not provide user-level authentication or authorization; they grant full access to the storage account, not per-user scope validation. Option C is wrong because client certificate authentication does not involve tokens issued by Microsoft Entra ID and cannot validate the 'Files.Upload' scope; it is a different authentication mechanism. Option D is wrong because while APIM can validate tokens and check scopes, the question specifies configuring the API's code and AKS deployment, not introducing an additional APIM layer; APIM would add latency and complexity not required by the scenario.

Practice this question →

MCQeasy

You need to deploy an Azure App Service web app that uses a custom domain (www.contoso.com) and SSL/TLS certificate. The certificate is stored in Azure Key Vault. What should you use to bind the certificate to the App Service?

A.Configure Azure Front Door to terminate SSL and forward traffic to App Service.

B.Use an App Service Managed Certificate for the custom domain.

C.Import the certificate from Key Vault into App Service using the 'Key Vault Certificate' option.

D.Export the certificate from Key Vault as a PFX file and upload it to App Service.

AnswerC

This integrates directly with Key Vault and allows SSL binding.

Why this answer

Option C is correct because Azure App Service supports direct integration with Azure Key Vault to import a certificate using the 'Key Vault Certificate' option. This allows you to bind an SSL/TLS certificate stored in Key Vault to your custom domain without manually exporting or managing the PFX file, ensuring secure and seamless certificate lifecycle management.

Exam trap

The trap here is that candidates may confuse the manual PFX export and upload method (Option D) as the only way to use a Key Vault certificate, missing the native 'Key Vault Certificate' integration that is more secure and automated.

How to eliminate wrong answers

Option A is wrong because Azure Front Door terminates SSL at the edge and forwards traffic to App Service over HTTP or HTTPS, but it does not bind the certificate directly to the App Service custom domain; the certificate must still be bound to the App Service for end-to-end SSL. Option B is wrong because an App Service Managed Certificate is a free, built-in certificate for custom domains, but it cannot be imported from Key Vault; it is automatically provisioned and managed by App Service, not sourced from an external Key Vault. Option D is wrong because while you can export a certificate from Key Vault as a PFX file and upload it to App Service, this is a manual, less secure approach that bypasses the native Key Vault integration; the recommended and more secure method is to use the 'Key Vault Certificate' option to directly reference the certificate without exporting.

Practice this question →

MCQhard

You are developing a solution that processes large files uploaded to Azure Blob Storage. Each file must be processed by a long-running operation that may take up to 30 minutes. You need to use Azure Functions with a consumption plan. How should you handle the processing?

A.Use a Blob trigger function with a retry policy

B.Increase the function timeout to 30 minutes

C.Use an Event Grid trigger function to process the blob

D.Use Durable Functions with a blob-triggered client function

AnswerD

Durable Functions can persist state and run longer.

Why this answer

D is correct because Azure Functions on a Consumption Plan have a default timeout of 5 minutes and a maximum of 10 minutes. A blob-triggered client function can start a Durable Functions orchestration, which can run for up to 30 minutes (or longer) by using the orchestration's timeout and retry capabilities, avoiding the Consumption Plan's timeout limit.

Exam trap

The trap here is that candidates assume increasing the function timeout or using a retry policy can solve long-running operations, but they overlook the hard 10-minute limit on Consumption Plan and the need for a stateful orchestration pattern like Durable Functions.

How to eliminate wrong answers

Option A is wrong because a retry policy does not extend the function's execution timeout; it only retries the function on failure, but the function still cannot run longer than the Consumption Plan's maximum timeout (10 minutes). Option B is wrong because the maximum timeout for Azure Functions on a Consumption Plan is 10 minutes (configurable up to 10 minutes), not 30 minutes; increasing the timeout beyond 10 minutes is not supported on Consumption Plan. Option C is wrong because an Event Grid trigger function still runs under the same Consumption Plan timeout constraints (max 10 minutes) and does not inherently support long-running operations beyond that limit.

Practice this question →

MCQmedium

You are developing a microservices application on Azure Kubernetes Service (AKS). One of the services needs to securely access Azure SQL Database without storing connection strings in the application code. You need to use managed identities. What should you do?

A.Store the connection string in Azure Key Vault and use the Key Vault FlexVolume driver.

B.Use the AKS cluster's managed identity to access Azure SQL.

C.Create a service principal and use its credentials in the pod.

D.Enable Azure AD Pod Identity and assign a managed identity to the pod.

AnswerD

Pod Identity allows the pod to authenticate to Azure SQL using managed identity.

Why this answer

Option D is correct because Azure AD Pod Identity allows you to assign an Azure Active Directory (Azure AD) managed identity directly to a pod in AKS. The pod can then use that identity to authenticate to Azure SQL Database without storing any connection strings or secrets in the code. This is the recommended approach for pod-level managed identity access to Azure resources.

Exam trap

The trap here is that candidates often confuse the AKS cluster's managed identity (which is for cluster-level operations like load balancers) with pod-level managed identities, leading them to incorrectly select Option B.

How to eliminate wrong answers

Option A is wrong because storing the connection string in Key Vault and using the FlexVolume driver still requires the pod to retrieve a secret, which does not eliminate the need for a connection string; it only moves it to a vault. Option B is wrong because the AKS cluster's managed identity is a system-assigned identity for the cluster itself, not for individual pods, and it cannot be used directly by a pod to access Azure SQL. Option C is wrong because creating a service principal and using its credentials in the pod would require storing the service principal's secret (password or certificate) in the pod, which defeats the purpose of avoiding stored credentials.

Practice this question →

100

MCQmedium

You are deploying a container group to Azure Container Instances that runs a stateful application. The application writes data to the /data directory. You need to ensure that the data is preserved if the container restarts. Which volume mount type should you use?

A.EmptyDir

B.Azure Files share

C.Secret

D.ConfigMap

AnswerB

An Azure Files share is a durable, managed file share that persists data independently of the container lifecycle.

Why this answer

Azure Files shares provide persistent, shared storage that can be mounted into Azure Container Instances (ACI) using the SMB 3.0 protocol. This ensures that data written to the /data directory survives container restarts because the share exists independently of the container lifecycle. EmptyDir volumes are ephemeral and tied to the pod's lifetime, making them unsuitable for stateful applications that require data persistence across restarts.

Exam trap

The trap here is that candidates often confuse EmptyDir with persistent storage, assuming it survives restarts because it is used in Kubernetes pods, but in ACI, EmptyDir is ephemeral and tied to the container group's lifecycle, not the container's restart policy.

How to eliminate wrong answers

Option A is wrong because EmptyDir volumes are created empty when a container starts and are deleted when the container is removed or restarted, so they do not preserve data across restarts. Option C is wrong because Secret volumes are used to inject sensitive data (e.g., passwords, certificates) as read-only files, not for persistent application data storage. Option D is wrong because ConfigMap volumes are designed to inject non-sensitive configuration data (e.g., key-value pairs) as read-only files, and they do not support write operations or persistence across restarts.

Practice this question →

101

MCQmedium

A web app for a webhook processor needs separate staging and production environments. The team must warm up the new version before swapping traffic. Which App Service feature should be used?

A.Deployment slots

B.Backup and restore

C.App Service access restrictions

D.Always On only

AnswerA

Deployment slots provide separate environments and support warm-up before swap.

Why this answer

Deployment slots are the correct feature because they enable separate staging and production environments within the same App Service plan, allowing you to warm up the new version in a staging slot before performing a zero-downtime swap with the production slot. This directly supports the requirement for traffic swapping after warm-up, which is a core capability of slot-swapping in Azure App Service.

Exam trap

The trap here is that candidates may confuse Always On with a warm-up mechanism, but Always On only prevents idle unload and does not provide environment separation or traffic swapping capabilities.

How to eliminate wrong answers

Option B is wrong because Backup and restore is a disaster recovery feature that creates snapshots of app content and configuration, not a mechanism for staging or traffic swapping. Option C is wrong because App Service access restrictions control inbound network access via IP rules or service endpoints, not environment separation or traffic routing. Option D is wrong because Always On only prevents the app from being unloaded after idle time, ensuring it stays warm but does not provide separate environments or the ability to swap traffic between versions.

Practice this question →

102

MCQhard

A Kubernetes-based IoT command API on AKS must pull images from Azure Container Registry without storing registry passwords in Kubernetes secrets. What should be used?

A.Use an App Service deployment slot

B.Store the ACR admin password in every deployment manifest

C.Attach the ACR to AKS or grant the kubelet managed identity AcrPull

D.Make the container registry public

AnswerC

AKS can authenticate to ACR through managed identity permissions such as AcrPull.

Why this answer

Option C is correct because attaching an ACR to an AKS cluster or granting the kubelet managed identity the AcrPull role enables Azure AD-based authentication without storing credentials in Kubernetes secrets. The kubelet on each node uses its managed identity to obtain an ACR access token via Azure AD, allowing secure image pulls. This approach eliminates the need for manual password management and follows security best practices for Azure-integrated workloads.

Exam trap

The trap here is that candidates may confuse AKS authentication with App Service features or assume that making the registry public is acceptable for development, when in fact Azure AD managed identity with AcrPull is the secure, recommended approach for production workloads.

How to eliminate wrong answers

Option A is wrong because App Service deployment slots are a feature for staging and swapping web app versions, not for authenticating Kubernetes to a container registry. Option B is wrong because storing the ACR admin password in every deployment manifest violates security best practices by exposing static credentials in plaintext, and the admin account is intended for emergency use only, not routine automation. Option D is wrong because making the container registry public exposes all images to the internet, creating a severe security risk and violating the principle of least privilege.

Practice this question →

103

MCQeasy

You need to deploy a microservice that runs a long-running background job (up to 30 minutes). The job should not be affected by App Service recycling. Which Azure technology should you use?

A.Azure Automation Runbook

B.Azure WebJobs with Always On enabled

C.Azure Functions (Consumption plan)

D.Azure Kubernetes Service (AKS)

AnswerB

WebJobs run in App Service background and with Always On, they persist.

Why this answer

Option B is correct because Azure WebJobs with Always On enabled ensures the WebJob runs continuously on a dedicated App Service instance, preventing it from being unloaded during idle periods or App Service recycling. This allows the long-running background job (up to 30 minutes) to complete without interruption, as the WebJob runs in the same process as the web app and is not subject to the 5-minute timeout of the Consumption plan.

Exam trap

The trap here is that candidates often choose Azure Functions (Consumption plan) because of its simplicity, forgetting that the Consumption plan has a hard 5-minute execution timeout, making it unsuitable for long-running jobs, while WebJobs with Always On is the correct choice for persistent background processing within App Service.

How to eliminate wrong answers

Option A is wrong because Azure Automation Runbooks are designed for short-lived, automated tasks (up to 3 hours) but are not optimized for continuous background jobs within an App Service context; they run in a sandbox that can be recycled and lack the tight integration with App Service recycling behavior. Option C is wrong because Azure Functions on the Consumption plan have a maximum execution timeout of 5 minutes (10 minutes for the Premium plan), which is insufficient for a job that runs up to 30 minutes; the function host can also be recycled during idle periods. Option D is wrong because Azure Kubernetes Service (AKS) is a container orchestration platform that adds unnecessary complexity and cost for a single long-running background job; while it can handle long-running tasks, it is overkill compared to the simpler WebJobs solution, and the question specifically asks for a technology that is not affected by App Service recycling, which AKS does not directly address.

Practice this question →

104

MCQhard

You are implementing a Durable Functions orchestration that calls an activity function which may fail transiently. You want to retry the activity up to 3 times with a 5-second delay and exponential backoff. Which code snippet should you use?

A.await context.CallActivityAsync("Activity", input);

B.await context.CallActivityWithRetryAsync("Activity", new RetryOptions(TimeSpan.FromSeconds(5), 3), input);

C.await context.CallActivityAsync("Activity", input, new RetryOptions(TimeSpan.FromSeconds(5), 3));

D.Use a durable timer and a loop to retry manually.

AnswerB

This uses the built-in retry support in Durable Functions with the specified first retry interval and maximum number of attempts.

Why this answer

Option B is correct because the Durable Functions SDK provides the `CallActivityWithRetryAsync` method, which accepts a `RetryOptions` object to configure retry count and delay. The `RetryOptions` constructor takes `TimeSpan.FromSeconds(5)` as the first retry interval and `3` as the maximum number of attempts, including the initial call. This built-in method handles exponential backoff automatically, eliminating the need for manual retry logic.

Exam trap

The trap here is that candidates may confuse `CallActivityAsync` with `CallActivityWithRetryAsync`, assuming that retry options can be passed as an additional parameter to the former, or they may underestimate the value of the built-in retry mechanism and opt for a manual loop, which is less robust and not idiomatic in Durable Functions.

How to eliminate wrong answers

Option A is wrong because `CallActivityAsync` does not accept retry parameters and will only execute the activity once, failing immediately on transient errors. Option C is wrong because `CallActivityAsync` does not have an overload that accepts `RetryOptions`; the retry mechanism is only available via `CallActivityWithRetryAsync`. Option D is wrong because while a manual loop with a durable timer could technically work, it is not the recommended or idiomatic approach in Durable Functions, and it would require additional code to implement exponential backoff correctly, making it less reliable and more error-prone than the built-in method.

Practice this question →

105

MCQeasy

You are developing a solution that processes messages from an Azure Storage Queue. Each message triggers a long-running operation that may take up to 30 minutes. You need to ensure that if the processing fails, the message is not lost and can be retried later. The current implementation uses a console application that polls the queue and deletes messages after processing. What should you change?

A.Move the message to a poison queue after the first failure.

B.After processing fails, update the message's visibility timeout to a later time so it becomes visible again for retry.

C.Increase the polling interval to reduce the chance of missing messages.

D.Delete the message only if processing succeeds; otherwise, leave it in the queue.

AnswerB

This allows the message to be retried after a delay without loss.

Why this answer

The correct approach is to update the message's visibility timeout to a later time when processing fails. This makes the message reappear in the queue after the specified timeout, allowing another consumer to retry processing. Azure Storage Queue messages have a default visibility timeout of 30 seconds, but you can extend it to up to 7 days.

This ensures the message is not lost and can be retried without being deleted or moved prematurely.

Exam trap

The trap here is that candidates often think leaving the message in the queue (Option D) is sufficient, but they forget that the message remains invisible after being dequeued unless its visibility timeout is explicitly updated to make it visible again for retries.

How to eliminate wrong answers

Option A is wrong because moving a message to a poison queue after the first failure would prevent retries; poison queues are typically used after a maximum number of retries (e.g., 5) have been exhausted, not after a single failure. Option C is wrong because increasing the polling interval does not address the need to retry failed messages; it only reduces how often the queue is checked, which could delay processing but does not handle failure recovery. Option D is wrong because simply leaving the message in the queue without updating its visibility timeout means it will remain invisible (due to the default visibility timeout) and never be reprocessed; the message must be made visible again for retries.

Practice this question →

106

MCQeasy

You need to deploy a containerized application to Azure that must be restarted automatically if it crashes. The solution should minimize management overhead. Which compute service should you use?

A.Azure Container Instances

B.Azure Functions

C.Azure Kubernetes Service (AKS)

D.Azure Virtual Machines

AnswerA

ACI provides simple container deployment with restart policy.

Why this answer

Azure Container Instances (ACI) is the correct choice because it provides a serverless container platform that automatically restarts containers if they crash when configured with a restart policy of 'Always' or 'OnFailure'. This minimizes management overhead by eliminating the need to manage underlying infrastructure, orchestration, or virtual machines, making it ideal for simple, stateless containerized applications that require automatic recovery.

Exam trap

The trap here is that candidates often choose AKS because of its robust orchestration and self-healing capabilities, but they overlook the explicit requirement to minimize management overhead, which AKS does not satisfy due to the need to manage clusters, node pools, and networking.

How to eliminate wrong answers

Option B (Azure Functions) is wrong because it is a serverless compute service designed for event-driven, short-lived code execution, not for hosting long-running containerized applications; it does not natively support running arbitrary containers with automatic restart on crash. Option C (Azure Kubernetes Service) is wrong because while it can restart crashed containers via pod health probes and replica sets, it introduces significant management overhead for cluster configuration, node pools, and orchestration, which contradicts the requirement to minimize management overhead. Option D (Azure Virtual Machines) is wrong because it requires manual configuration of container runtime, restart policies, and VM health monitoring, resulting in high management overhead and no built-in automatic container restart without additional tooling like Azure Monitor or custom scripts.

Practice this question →

107

MCQhard

Your company has an Azure Kubernetes Service (AKS) cluster. You need to deploy a containerized application that requires persistent storage across pod restarts. The storage must be backed by Azure Disk and support ReadWriteOnce access mode. Which volume type should you use?

A.Azure Disk

B.Azure Blob Storage

C.EmptyDir

D.Azure Files

AnswerA

Azure Disk supports ReadWriteOnce, suitable for persistent storage for one pod.

Why this answer

Azure Disk is the correct volume type because it provides a durable block storage device that can be attached to a pod in an AKS cluster. It supports the ReadWriteOnce (RWO) access mode, meaning the disk can be mounted as read-write by a single node, which aligns with the requirement for persistent storage that survives pod restarts. Azure Disk is ideal for stateful applications that need high-performance, low-latency storage and do not require concurrent access from multiple pods.

Exam trap

The trap here is that candidates often confuse Azure Files (which supports ReadWriteMany) with Azure Disk (which supports ReadWriteOnce), or they mistakenly choose EmptyDir thinking it provides persistence, when in fact it is temporary and tied to the pod's lifecycle.

How to eliminate wrong answers

Option B is wrong because Azure Blob Storage is object storage, not block storage, and it does not support the ReadWriteOnce access mode; it is typically accessed via REST APIs or Azure Blob CSI driver with different access modes (e.g., ReadWriteMany for multiple clients). Option C is wrong because EmptyDir is ephemeral storage that is created when a pod is assigned to a node and is deleted when the pod is removed, so it does not persist across pod restarts. Option D is wrong because Azure Files supports ReadWriteMany (RWX) access mode, not ReadWriteOnce, and is designed for concurrent access from multiple pods across nodes, which is not required here.

Practice this question →

108

MCQeasy

You are developing a background job that runs every hour on Azure App Service. The job must be resilient to restarts and should not affect the web app's performance. Which technology should you use?

A.A background thread in the web application

B.Azure Logic Apps

C.WebJobs (triggered)

D.Azure Functions (Consumption plan)

AnswerC

Correct: WebJobs run in the same App Service plan and can be scheduled.

Why this answer

WebJobs (triggered) are designed specifically for running background tasks on Azure App Service. They run as separate processes from the web app, ensuring they do not affect the web app's performance, and they are resilient to restarts because the Azure WebJobs SDK automatically handles restart and retry logic. This makes them the ideal choice for a scheduled hourly job that must survive App Service restarts.

Exam trap

The trap here is that candidates often confuse Azure Functions with WebJobs, not realizing that WebJobs run inside the App Service sandbox and share the same scaling and restart behavior, whereas Functions on the Consumption plan are independent and subject to cold starts and different billing models.

How to eliminate wrong answers

Option A is wrong because a background thread in the web application runs within the same process as the web app, so if the App Service restarts, the thread is lost, and it can also degrade the web app's performance by competing for CPU and memory resources. Option B is wrong because Azure Logic Apps is a serverless workflow orchestrator that runs outside of App Service and is not designed to be a background job directly attached to a specific web app; it introduces additional latency and cost for a simple hourly task. Option D is wrong because Azure Functions on the Consumption plan can have cold start delays and are not directly tied to the App Service's lifecycle, meaning they do not benefit from the same restart resilience and shared resource management as WebJobs running within the same App Service plan.

Practice this question →

109

Multi-Selectmedium

You are deploying an Azure App Service that must be accessible only from your corporate network via a VPN. You need to restrict inbound traffic. Which TWO actions should you take?

Select 2 answers

A.Use Azure Front Door with WAF

B.Deploy the App Service inside a VNet using an App Service Environment

C.Configure a service endpoint

D.Enable VNet integration for the App Service

E.Configure IP address restrictions in the App Service

AnswersB, E

ASE can be deployed inside a VNet, ensuring only VNet traffic reaches it.

Why this answer

Option B is correct because deploying the App Service inside a VNet using an App Service Environment (ASE) places the App Service on dedicated infrastructure that is fully integrated into your virtual network. This ensures that inbound traffic is only possible from within the VNet, which is accessible via your corporate VPN, effectively isolating the App Service from the public internet.

Exam trap

The trap here is that candidates often confuse VNet integration (which only handles outbound traffic) with the ability to restrict inbound traffic, leading them to select Option D instead of recognizing that only an App Service Environment (ASE) provides full inbound isolation within a VNet.

Practice this question →

110

MCQeasy

You are deploying a containerized application to Azure Container Instances (ACI). The application writes temporary data to a local disk that must persist across container restarts (e.g., after a crash). Which configuration should you use?

A.Mount an Azure Files share as a volume in the container group.

B.Use the temporary disk automatically allocated by ACI.

C.Store data in an Azure Cosmos DB database.

D.Use an emptyDir volume as available in Kubernetes.

AnswerA

Azure Files shares are persistent and can be mounted across container restarts, providing durable storage.

Why this answer

Option A is correct because Azure Container Instances (ACI) supports mounting an Azure Files share as a persistent volume. When a container restarts (e.g., after a crash), the temporary disk is wiped, but data written to an Azure Files share persists independently of the container's lifecycle. This meets the requirement for data to survive container restarts.

Exam trap

The trap here is that candidates often confuse the temporary disk (which is ephemeral) with persistent storage, or they incorrectly assume Kubernetes concepts like emptyDir apply to ACI, when ACI has its own volume mounting mechanisms (Azure Files, secrets, empty directories).

How to eliminate wrong answers

Option B is wrong because the temporary disk automatically allocated by ACI is ephemeral; its contents are lost when the container restarts or is redeployed, so it cannot persist data across restarts. Option C is wrong because Azure Cosmos DB is a globally distributed NoSQL database designed for structured data and high availability, not for temporary local disk storage; it introduces unnecessary latency and cost for simple temporary data persistence. Option D is wrong because emptyDir volumes are a Kubernetes concept and are not available in Azure Container Instances; ACI does not support Kubernetes-native volume types like emptyDir.

Practice this question →

111

Multi-Selectmedium

You are developing a solution that uses Azure Container Instances (ACI) to run a batch processing job. The job runs for approximately 30 minutes and requires access to a configuration file stored in Azure Files. You need to ensure the container instance can access the file share securely without using a public endpoint. Which TWO actions should you take?

Select 2 answers

A.Mount the Azure Files share using the storage account name and key.

B.Use a managed identity assigned to the container group to authenticate to the storage account.

C.Deploy the container group in an Azure virtual network that has a service endpoint to Azure Storage.

D.Use a shared access signature (SAS) token to mount the file share.

E.Enable the storage account's firewall to allow access from the container group's public IP.

AnswersA, C

Mount requires key, which can be securely passed via environment variables.

Why this answer

Option A is correct because mounting an Azure Files share using the storage account name and key is a supported method in Azure Container Instances. This approach uses the SMB protocol to directly attach the file share to the container, providing access to the configuration file without requiring a public endpoint. The storage account key is passed securely as part of the container group configuration, and the mount is handled internally within the Azure infrastructure.

Exam trap

The trap here is that candidates often assume managed identities can be used for any Azure resource authentication, but Azure Container Instances does not support managed identities for Azure Files mounts, and they may overlook that service endpoints provide private connectivity without needing to change the authentication method.

Practice this question →

112

Matchingmedium

Match each Azure security feature to its function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Securely store and manage secrets, keys, and certificates

Cloud workload protection with threat detection

Enforce organizational standards and compliance rules

Fine-grained access management for Azure resources

Why these pairings

These are essential security and governance tools in Azure.

Practice this question →

113

Multi-Selectmedium

A company is designing a serverless application using Azure Functions. They need to orchestrate multiple functions in a workflow, handle errors, and manage state. Which TWO features should they use?

Select 2 answers

A.Fan-out/Fan-in pattern

B.Azure Event Grid

C.Durable Functions

D.Azure Logic Apps

E.Azure Data Factory

AnswersA, C

This pattern is used in Durable Functions for parallel processing.

Why this answer

Option A is correct because the Fan-out/Fan-in pattern is a core feature of Durable Functions that allows you to execute multiple functions in parallel (fan-out) and then aggregate their results (fan-in). This pattern is essential for orchestrating workflows, handling errors via retry policies, and managing state across function executions. Durable Functions provide built-in state management and checkpointing, making them ideal for serverless orchestration scenarios.

Exam trap

The trap here is that candidates may confuse Azure Logic Apps with Durable Functions, but Logic Apps is a separate service with its own pricing and execution model, not a feature of Azure Functions, and the question explicitly asks for features within a serverless application using Azure Functions.

Practice this question →

114

MCQmedium

You are developing a web application that processes images uploaded by users. The images must be resized and analyzed for offensive content before being stored. You need to implement the solution with minimal latency and cost. What should you do?

A.Use Azure Batch to process images in parallel.

B.Use Durable Functions to orchestrate the resizing and analysis.

C.Use Azure Logic Apps with a trigger for each upload.

D.Use an Azure Function triggered by Blob Storage, with Consumption plan.

AnswerD

Functions with Consumption plan are event-driven, cost-effective, and scale automatically.

Why this answer

Option D is correct because using an Azure Function triggered by Blob Storage on a Consumption plan provides a serverless, event-driven architecture that automatically scales to process each image upload with minimal latency and cost. The Consumption plan charges only for execution time and resources used, making it cost-effective for sporadic workloads, while the Blob Storage trigger ensures immediate processing upon upload without polling or additional infrastructure.

Exam trap

The trap here is that candidates often over-engineer the solution by choosing orchestration tools like Durable Functions or Logic Apps for simple sequential tasks, missing that a single Azure Function triggered by Blob Storage is the simplest, lowest-latency, and most cost-effective approach for event-driven image processing.

How to eliminate wrong answers

Option A is wrong because Azure Batch is designed for large-scale, compute-intensive batch jobs with job scheduling and pool management, which introduces overhead and latency unsuitable for real-time, per-upload processing. Option B is wrong because Durable Functions are meant for orchestrating long-running, stateful workflows with checkpoints and retries, adding unnecessary complexity and latency for simple, sequential operations like resizing and analysis. Option C is wrong because Azure Logic Apps incur higher per-action costs and introduce connector-based latency compared to a direct Azure Function trigger, and they are better suited for enterprise integration workflows rather than lightweight, event-driven image processing.

Practice this question →

115

MCQeasy

You deploy a container to Azure Container Instances. The container needs to persist data when it restarts. You mount an Azure Files share to a directory inside the container. Which volume type is this?

A.emptyDir

B.gitRepo

C.azureFile

D.secret

AnswerC

Correct. azureFile volume mounts an Azure Files share, which persists data across container restarts.

Why this answer

Option C is correct because Azure Container Instances supports mounting an Azure Files share as a volume to persist data across container restarts. The `azureFile` volume type references a pre-created Azure storage account and file share, which is mounted into the container's filesystem using SMB 3.0 protocol. This ensures data survives container crashes or restarts, as it is stored externally in Azure Files.

Exam trap

The trap here is that candidates may confuse `emptyDir` with persistent storage because it is commonly used in Kubernetes for temporary data, but in Azure Container Instances, `emptyDir` does not survive container restarts, whereas `azureFile` is the correct choice for persistence.

How to eliminate wrong answers

Option A is wrong because `emptyDir` is a temporary volume that exists only as long as the container runs; it is created empty when a container starts and is deleted when the container stops, so it does not persist data across restarts. Option B is wrong because `gitRepo` is a volume type used to clone a Git repository into the container at startup, not for persistent storage of application data. Option D is wrong because `secret` is used to inject sensitive data (e.g., certificates, keys) into a container as files, not for general-purpose persistent data storage.

Practice this question →

116

MCQmedium

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?

A.The container name 'samples-workitems' is invalid

B.The blob name pattern {rand-guid} is not supported

C.The storage account connection string is not set in the function app settings

D.The blob output binding syntax is incorrect

AnswerC

Correct: Without the connection string, the binding cannot connect to storage.

Why this answer

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.

Exam trap

The trap here is that candidates 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.

How to eliminate wrong answers

Option A is wrong because 'samples-workitems' is a valid container name; Azure Blob Storage allows lowercase letters, numbers, and hyphens, and this name follows those rules. Option B is wrong because the `{rand-guid}` pattern is a supported binding expression in Azure Functions that generates a random GUID for the blob name. Option D is wrong because the binding syntax shown (using `direction`, `type`, `name`, `path`, and `connection`) is correct for a blob output binding in a function.json file.

Practice this question →

117

Multi-Selectmedium

You are planning to migrate an on-premises application to Azure App Service. The application consists of a web frontend and a background worker that processes messages from a queue. Which TWO Azure services should you use to implement this solution?

Select 2 answers

A.Azure Kubernetes Service

B.Azure Batch

C.Azure Functions

D.Azure App Service

E.Azure Logic Apps

AnswersC, D

Can process queue messages as background worker.

Why this answer

Azure Functions (C) is correct because it provides a serverless compute service that can be triggered by queue messages, making it ideal for the background worker that processes messages from a queue. Azure App Service (D) is correct because it hosts the web frontend, providing a fully managed platform for web applications with built-in scaling and load balancing.

Exam trap

The trap here is that candidates often confuse Azure Functions with Azure Logic Apps, but Logic Apps is a workflow orchestration service (not a compute service) and cannot run arbitrary code like a background worker processing queue messages.

Practice this question →

118

MCQmedium

You are deploying a containerized application to Azure Container Instances. The application must restart automatically if it crashes. You set the restart policy to 'Always'. However, the container keeps restarting continuously even when there is no crash. What is the most likely cause?

A.The container is configured with an Azure Files volume that is not accessible.

B.The application inside the container exits with a non-zero exit code on startup.

C.The container is trying to bind to a port that is already in use on the host.

D.The container is exceeding the allocated CPU or memory limits.

AnswerB

Non-zero exit triggers restart; if immediate, leads to loop.

Why this answer

Option B is correct because if the application exits with a non-zero exit code, the 'Always' restart policy treats it as a failure and restarts it. This can lead to a continuous restart loop if the application fails immediately on startup. Option A is wrong because CPU/memory limits don't cause restart loops unless the container is repeatedly terminated (OOMKilled), but that would show a crash.

Option C is wrong because volumes causing crashes would exit with non-zero, same as B. Option D is wrong because public IP assignment doesn't affect restart behavior.

Practice this question →

119

MCQhard

You are deploying a containerized application on Azure Container Instances (ACI) that needs to run as a background job every hour. The job processes data from an Azure SQL Database and sends a report via email. You need to minimize costs while ensuring the job runs reliably on schedule. The job takes about 10 minutes to complete. What should you do?

A.Use Azure Batch with a job schedule to run the container as a task.

B.Create an Azure Logic App with a recurrence trigger that starts the container group using the 'Start Container Group' action, and stop it after completion.

C.Deploy the container on a single Azure virtual machine and schedule it using Windows Task Scheduler.

D.Use an Azure Function with a timer trigger that uses the Azure Container Instances SDK to start the container group.

AnswerB

Logic App can start and stop ACI on schedule, minimizing cost.

Why this answer

Option B is correct because it uses Azure Logic Apps with a recurrence trigger to start the container group only when needed, and stops it after the job completes. This minimizes costs by avoiding continuous running charges for the container, while the Logic App itself incurs minimal execution cost. The job's 10-minute duration fits well within the 1-hour recurrence window, ensuring reliable scheduling without idle compute time.

Exam trap

The trap here is that candidates may assume an Azure Function with a timer trigger is the cheapest option, but they overlook the Function's execution timeout limits and the need to manage container lifecycle, making Logic Apps the more reliable and cost-effective choice for this specific scenario.

How to eliminate wrong answers

Option A is wrong because Azure Batch is designed for large-scale parallel batch processing across multiple nodes, which is overkill and more expensive for a single container running a 10-minute job every hour. Option C is wrong because deploying a dedicated Azure VM incurs continuous compute costs even when the job is not running, and Windows Task Scheduler does not natively manage container lifecycle or provide the same reliability as Azure-native scheduling. Option D is wrong because an Azure Function with a timer trigger using the ACI SDK to start the container group would still require the container to run continuously or incur additional complexity for stopping it, and the Function's execution time limit (default 5 minutes, max 10 minutes) may not reliably accommodate the job's 10-minute duration without premium plans.

Practice this question →

120

MCQeasy

A company deploys a stateful application as a container in Azure Container Instances (ACI). They need persistent storage that can be shared across multiple container instances and retain data after container restarts. Which volume mount should they use?

A.emptyDir

B.Azure Files share

C.Host path

D.Secret volume

AnswerB

Azure Files share volumes provide durable, shared storage that persists beyond container restarts and can be used by multiple container groups.

Why this answer

Azure Files shares provide fully managed SMB file shares in the cloud that can be mounted as volumes in Azure Container Instances. This allows multiple container instances to read and write to the same persistent storage concurrently, and data persists independently of container lifecycles, surviving restarts or deletions. The scenario requires shared, persistent storage across instances, which Azure Files uniquely supports among the given options.

Exam trap

The trap here is that candidates often confuse emptyDir (which is ephemeral and pod-scoped) with persistent storage, or assume host path works in ACI because it works in Kubernetes, but ACI does not expose host filesystem access.

How to eliminate wrong answers

Option A is wrong because emptyDir volumes are ephemeral and tied to a pod's lifecycle; data is lost when the container or pod is deleted, and it cannot be shared across separate container instances. Option C is wrong because host path volumes mount a directory from the underlying host node's filesystem, which is not supported in Azure Container Instances (ACI is a serverless container service without direct host node access) and would not provide shared access across multiple instances. Option D is wrong because secret volumes are used to inject sensitive data (e.g., certificates, keys) into containers as files, not for persistent or shared storage; they are read-only and ephemeral.

Practice this question →

121

MCQmedium

You have an Azure App Service web app that experiences high CPU usage during peak hours. You need to scale out automatically based on CPU load. Which scaling solution should you use?

A.Manual scaling

B.Traffic Manager

C.Autoscale with a CPU percentage rule

D.Scale sets autoscale

AnswerC

Autoscale can scale out when CPU exceeds a threshold.

Why this answer

Autoscale with a CPU percentage rule is the correct solution because Azure App Service supports built-in autoscaling that can automatically increase or decrease the number of instances based on a metric like CPU percentage. This allows the web app to handle peak-hour traffic by scaling out when CPU usage exceeds a defined threshold, ensuring performance without manual intervention.

Exam trap

The trap here is that candidates may confuse 'scale sets autoscale' (which is for VMs) with App Service autoscale, or think Traffic Manager can scale resources, when it only distributes traffic.

How to eliminate wrong answers

Option A is wrong because manual scaling requires human intervention to adjust instance counts, which cannot automatically respond to CPU load during peak hours. Option B is wrong because Traffic Manager is a DNS-based traffic load balancer that routes traffic across endpoints but does not scale the underlying compute resources based on CPU metrics. Option D is wrong because 'Scale sets autoscale' refers to Virtual Machine Scale Sets, which are used for scaling VMs, not for Azure App Service web apps; App Service has its own autoscale feature that does not require scale sets.

Practice this question →

122

MCQhard

You are designing a serverless architecture using Azure Functions for a data processing pipeline. The pipeline must process messages from an Azure Service Bus queue. Each message can take up to 5 minutes to process. You need to ensure that if a function fails, the message is not lost and is retried after a delay. What should you configure?

A.Use the PeekLock message receive mode and manually complete the message only after successful processing.

B.Use Durable Functions with a retry policy.

C.Set the Azure Functions retry policy in the host.json file.

D.Configure the Service Bus queue to dead-letter messages after a specified number of delivery attempts.

AnswerD

Prevents message loss and allows retries via MaxDeliveryCount.

Why this answer

Option C is correct because Service Bus queue dead-lettering automatically moves poison messages after exceeding MaxDeliveryCount. Enabling dead-lettering ensures failed messages are preserved for later investigation. Option A is wrong because Durable Functions are for orchestrating long-running workflows, not for simple retry logic.

Option B is wrong because Azure Functions host-level retry policy doesn't apply to Service Bus triggers; Service Bus itself handles retries via MaxDeliveryCount. Option D is wrong because using PeekLock mode with automatic completion on success is the default; if the function fails without calling complete, the lock expires and the message becomes visible again, which can cause infinite retries without dead-lettering.

Practice this question →

123

MCQhard

You are developing a solution that uses Azure Container Apps. Your application is a microservice that needs to expose a gRPC endpoint. The service must scale to zero when idle. What should you do?

A.Use Azure Functions with a gRPC trigger.

B.Deploy the microservice to Azure Container Apps and configure a scale rule with minReplicas set to 0.

C.Deploy the microservice to Azure Kubernetes Service with a virtual node.

D.Deploy the microservice to Azure Container Instances with a scale rule.

AnswerB

Container Apps supports scaling to zero and gRPC.

Why this answer

Azure Container Apps natively supports gRPC endpoints and can scale to zero by setting `minReplicas` to 0 in a scale rule. This configuration allows the microservice to run only when there are active requests, reducing costs during idle periods. The combination of gRPC support and dynamic scaling makes Container Apps the correct choice for this scenario.

Exam trap

The trap here is that candidates may assume Azure Functions can handle gRPC via custom handlers or that ACI supports autoscaling, but neither service provides native gRPC support or the scale-to-zero capability required for this specific workload.

How to eliminate wrong answers

Option A is wrong because Azure Functions does not have a native gRPC trigger; it supports HTTP, timer, and other triggers, but gRPC is not a supported binding, and Functions cannot scale to zero for gRPC workloads. Option C is wrong because Azure Kubernetes Service (AKS) with virtual nodes does not support scaling to zero; virtual nodes enable burst scaling but maintain a minimum number of pods, and AKS typically incurs cluster management overhead. Option D is wrong because Azure Container Instances (ACI) does not support scale rules or automatic scaling to zero; it is designed for single-instance containers with manual scaling or restart policies, not dynamic scale-to-zero behavior.

Practice this question →

124

MCQhard

You are troubleshooting a containerized application running on Azure Kubernetes Service (AKS). The application logs indicate that it cannot connect to an Azure SQL Database using a managed identity. The pod is configured with a user-assigned managed identity. Which step is most likely missing?

A.The Azure SQL Database firewall is blocking the pod IP

B.The pod's service account is not linked to the managed identity

C.The managed identity is not in the same Microsoft Entra ID tenant as the AKS cluster

D.The AKS cluster does not have the Azure AD Pod Identity add-on enabled

AnswerD

Correct: The add-on is required to assign the identity to pods.

Why this answer

The AKS cluster requires the Azure AD Pod Identity add-on (or the newer Workload Identity) to enable pods to authenticate to Azure resources using managed identities. Without this add-on, the pod's user-assigned managed identity cannot be used to obtain tokens for connecting to Azure SQL Database, even if the identity is correctly assigned to the pod.

Exam trap

The trap here is that candidates often assume assigning a managed identity to a pod is sufficient, but they overlook the requirement for the AKS cluster to have the Azure AD Pod Identity add-on enabled to bridge the pod and the identity for token acquisition.

How to eliminate wrong answers

Option A is wrong because the pod's IP is not the issue; Azure SQL Database firewall rules block IP addresses, but managed identity authentication uses Azure AD tokens, not the pod's IP, so the firewall is not the missing step. Option B is wrong because the pod's service account does not need to be linked to the managed identity; instead, the pod is assigned the identity via Azure AD Pod Identity or Workload Identity, not through a service account binding. Option C is wrong because the managed identity must be in the same Microsoft Entra ID tenant as the AKS cluster for authentication to work; if it were in a different tenant, the token request would fail, but the question implies the identity is correctly assigned, so this is not the missing step.

Practice this question →

125

Drag & Dropmedium

Arrange the steps to deploy an Azure App Service using Azure CLI in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

To deploy an App Service, first create a resource group, then an App Service plan, then the web app, deploy code, and finally verify.

Practice this question →

126

MCQmedium

Your Azure App Service web app experiences slow response times during peak hours. You suspect the App Service plan is under-provisioned. You need to scale out the app automatically based on CPU usage. What should you configure?

A.Configure scheduled scaling in the app

B.Manually increase instance count

C.Configure scale up in the App Service plan

D.Configure autoscale rules in the App Service plan

AnswerD

Autoscale can scale out based on CPU usage.

Why this answer

Autoscale rules in the App Service plan allow you to automatically scale out (increase instance count) based on metrics like CPU usage. This is the correct solution because it dynamically adjusts capacity in response to demand during peak hours without manual intervention.

Exam trap

The trap here is confusing 'scale up' (vertical scaling, changing plan tier) with 'scale out' (horizontal scaling, adding instances), and assuming scheduled scaling can react to real-time CPU spikes.

How to eliminate wrong answers

Option A is wrong because scheduled scaling is used for predictable load patterns (e.g., time-of-day), not for reactive scaling based on CPU usage. Option B is wrong because manually increasing the instance count is a one-time action and does not provide automatic scaling based on CPU metrics. Option C is wrong because scale up increases the size (tier) of the App Service plan (e.g., from S1 to S2), not the number of instances; it does not address horizontal scaling (scale out).

Practice this question →

127

MCQhard

You are designing a solution that uses Azure Container Instances (ACI) to run a batch job. The job must run only once a day and should not incur costs when idle. Which configuration should you use?

A.Use Azure Kubernetes Service with a node pool that scales to zero

B.Deploy a container group with a restart policy of Always

C.Use a scheduled job that creates a container group with restart policy Never and delete after completion

D.Use Azure Container Apps with scale-to-zero minimum replicas

AnswerC

Correct: This runs once and stops, minimizing cost.

Why this answer

Option C is correct because Azure Container Instances (ACI) supports a restart policy of 'Never' for one-off batch jobs, and you can orchestrate the creation and deletion of the container group using a scheduled job (e.g., Azure Logic Apps, Azure Functions, or a cron-based trigger). This ensures the container runs exactly once per day and incurs no cost when idle, as the container group is deleted after completion.

Exam trap

The trap here is that candidates may confuse the 'restart policy' with cost management, assuming 'Always' or 'OnFailure' are acceptable, or they may overcomplicate the solution by choosing AKS or Container Apps, which introduce unnecessary complexity and cost for a simple scheduled batch job.

How to eliminate wrong answers

Option A is wrong because Azure Kubernetes Service (AKS) with a node pool that scales to zero still incurs costs for the control plane and requires more complex orchestration than needed for a simple daily batch job; AKS is overkill and not the simplest solution for a single container. Option B is wrong because a restart policy of 'Always' would cause the container to restart continuously after completion, incurring ongoing costs and not meeting the requirement to run only once a day. Option D is wrong because Azure Container Apps with scale-to-zero minimum replicas still incurs costs for the underlying infrastructure (e.g., the environment and networking) and is designed for HTTP-triggered workloads, not scheduled batch jobs; it also does not natively support a 'run once and delete' pattern without additional orchestration.

Practice this question →

128

MCQeasy

You are deploying a new version of an ASP.NET Core web application to Azure App Service. You want to test the new version with a subset of users before making it available to everyone. You also need to be able to switch back instantly if issues are found. Which App Service feature should you use?

A.Create a separate App Service plan and deploy the new version there.

B.Use Azure DevOps deployment pipelines with deployment gates.

C.Use Azure Traffic Manager to route traffic between the old and new versions.

D.Use deployment slots with swapping.

AnswerD

Deployment slots allow you to deploy to a staging slot, test it, and then swap with the production slot. You can also route a percentage of traffic to the staging slot for A/B testing. Swapping back is immediate and provides a fast rollback.

Why this answer

Deployment slots in Azure App Service allow you to deploy a new version of your application to a staging slot, then gradually route a subset of user traffic to it using slot-specific routing rules (e.g., cookie-based affinity). If issues arise, you can instantly revert by swapping the slots back, which requires no redeployment and preserves the previous version's warm instances.

Exam trap

The trap here is that candidates confuse Azure Traffic Manager (DNS-level routing) with deployment slots (App Service–level routing), not realizing that Traffic Manager cannot provide instant rollback or cookie-based traffic splitting within a single App Service instance.

How to eliminate wrong answers

Option A is wrong because creating a separate App Service plan does not provide built-in traffic splitting or instant rollback; you would need additional load-balancing logic and manual DNS changes, which are slower and more complex. Option B is wrong because Azure DevOps deployment gates control when a release proceeds (e.g., based on monitoring), but they do not natively route a subset of live traffic to a new version or support instant rollback without redeployment. Option C is wrong because Azure Traffic Manager operates at the DNS level, routing traffic between entire App Service instances (not slots within the same app), and it cannot provide instant rollback (DNS propagation delays) or cookie-based session affinity for a subset of users.

Practice this question →

129

MCQmedium

A long-running claims processing function must process thousands of independent files. The developer wants status tracking, checkpoints, and replay-safe orchestration. Which Azure Functions capability should be used?

A.Durable Functions orchestrator

B.Timer trigger only

C.Azure Policy remediation

D.Blob lifecycle management

AnswerA

Durable Functions provides stateful orchestration, checkpointing, and durable execution history.

Why this answer

Durable Functions orchestrator is correct because it provides built-in support for status tracking, checkpoints (via event sourcing), and replay-safe orchestration, which are essential for a long-running claims processing function that must handle thousands of independent files reliably. The orchestrator function manages state and execution flow, automatically saving progress and allowing replay from checkpoints in case of failures, ensuring exactly-once processing semantics.

Exam trap

The trap here is that candidates may confuse a simple timer-triggered function (which can process files on a schedule) with the need for stateful orchestration, overlooking that Durable Functions is the only option that provides built-in checkpointing and replay safety for long-running, fault-tolerant workflows.

How to eliminate wrong answers

Option B is wrong because a Timer trigger only invokes a function on a schedule and does not provide any state management, checkpointing, or replay capabilities for long-running workflows. Option C is wrong because Azure Policy remediation is designed for enforcing compliance rules and automatically remediating non-compliant resources, not for orchestrating business logic or tracking processing status. Option D is wrong because Blob lifecycle management automates tiering or deletion of blobs based on age or tags, but it cannot manage orchestration state, checkpoints, or replay logic for a claims processing workflow.

Practice this question →

130

Multi-Selecthard

An Azure Functions report export service processes Service Bus messages. The function sometimes fails after partially completing work. Which two practices improve correctness?

Select 2 answers

A.Use dead-letter handling for repeatedly failing messages

B.Store connection strings in source code

C.Disable retries for all messages

D.Make the handler idempotent

AnswersA, D

Dead-letter queues isolate messages that cannot be processed after retries.

Why this answer

Option A is correct because Azure Functions can use dead-letter handling to isolate messages that repeatedly fail processing, preventing them from blocking the queue and allowing investigation without data loss. This is a standard pattern for Service Bus triggered functions to manage poison messages gracefully.

Exam trap

The trap here is that candidates often confuse disabling retries with improving correctness, when in fact retries with dead-lettering and idempotent handlers are the correct reliability patterns for Service Bus triggered functions.

Practice this question →

131

MCQhard

You are designing a microservices solution using Azure Container Apps. One service must be exposed externally via HTTPS, while others should only be accessible within the environment. You need to configure networking for this scenario. What should you do?

A.Enable external ingress at the environment level and use network policies to restrict access.

B.Deploy the external service in a different environment and use an internal load balancer.

C.Configure each container app's ingress: set the external service to 'External' and the internal services to 'Internal'.

D.Use a Dapr sidecar to route requests between services.

AnswerC

Container Apps support per-app ingress configuration.

Why this answer

Option C is correct because Azure Container Apps allows you to control ingress at the individual container app level. Setting the external service's ingress to 'External' makes it reachable from the internet via HTTPS, while setting internal services to 'Internal' restricts access to only within the Container Apps environment, using the internal FQDN. This provides the required isolation without needing separate environments or complex network policies.

Exam trap

The trap here is that candidates may think network policies or separate environments are needed for isolation, but Azure Container Apps provides per-app ingress control as a simpler and more direct solution.

How to eliminate wrong answers

Option A is wrong because Azure Container Apps does not support network policies at the environment level; ingress is configured per container app, not globally. Option B is wrong because deploying the external service in a different environment would require separate management and an internal load balancer is not used for external HTTPS exposure; the external service should be in the same environment with external ingress enabled. Option D is wrong because Dapr sidecars handle service-to-service communication and state management, not ingress or network exposure control.

Practice this question →

132

MCQmedium

You are deploying an Azure App Service using an ARM template. After deployment, you find that the application settings are not applied. What is the most likely issue?

A.The resource is missing a dependsOn property for the parent site

B.The resource type should be 'Microsoft.Web/sites/appsettings'

C.The apiVersion is outdated, use '2021-02-01'

D.The property 'MyApp:Setting1' uses a colon, which is not allowed

AnswerA

Without dependsOn, the config resource may be deployed before the site exists, causing failure.

Why this answer

When deploying application settings via an ARM template, the 'Microsoft.Web/sites/config' resource (which contains the appsettings) must have a 'dependsOn' property referencing the parent 'Microsoft.Web/sites' resource. Without this dependency, Azure Resource Manager may attempt to apply the settings before the site exists, causing the settings to be silently ignored or not applied. This is a common deployment ordering issue.

Exam trap

The trap here is that candidates often focus on syntax errors (like colons or resource types) rather than the implicit deployment ordering requirement, missing that the 'dependsOn' property is mandatory for child resources to ensure they are applied after the parent site exists.

How to eliminate wrong answers

Option B is wrong because the correct resource type for application settings is 'Microsoft.Web/sites/config' with the name 'appsettings', not 'Microsoft.Web/sites/appsettings'. Option C is wrong because while apiVersion matters, an outdated version would typically cause a validation error, not silent failure of settings application; the core issue is the missing dependency. Option D is wrong because colons are allowed in App Service application setting names; they are commonly used for .NET Core configuration keys like 'MyApp:Setting1'.

Practice this question →

133

MCQeasy

You are developing a solution that needs to perform a multi-step workflow. The workflow involves calling several third-party APIs, and some steps may require waiting for a human approval via email. The workflow may run for hours. You want to use Azure Functions to implement this orchestration. Which Azure Functions feature should you use?

A.Durable Functions

B.Timer trigger functions

C.Service Bus queue trigger functions

D.Blob storage trigger functions

AnswerA

Durable Functions is designed for stateful orchestrations, supporting long-running workflows, waiting for external events, and managing multi-step processes.

Why this answer

Durable Functions is the correct choice because it is an extension of Azure Functions that enables stateful, long-running orchestration workflows. It supports waiting for external events (like human approval via email), managing multi-step API calls, and handling execution that may run for hours, all while preserving state through checkpoints and replay.

Exam trap

The trap here is that candidates may confuse trigger-based functions (like Timer or Queue triggers) with orchestration capabilities, not realizing that Durable Functions is the only Azure Functions feature that provides built-in state management and external event waiting for long-running workflows.

How to eliminate wrong answers

Option B is wrong because Timer trigger functions are designed for scheduled, time-based execution and cannot handle multi-step orchestration or wait for external events like human approval. Option C is wrong because Service Bus queue trigger functions process individual messages and do not provide built-in orchestration capabilities for chaining steps or pausing for external input. Option D is wrong because Blob storage trigger functions react to blob creation or updates and are not suited for orchestrating multi-step workflows with human interaction.

Practice this question →

134

MCQhard

Your company has an Azure Kubernetes Service (AKS) cluster that hosts multiple microservices. You are tasked with deploying a new microservice that processes incoming HTTP requests and publishes messages to an Azure Service Bus topic. The microservice must scale based on the number of messages in the topic, and it must support graceful shutdown to complete in-flight requests. You need to choose the appropriate compute platform. The microservice is stateless and can be containerized. You want to minimize operational overhead and cost. The solution must automatically scale to zero when there are no messages. Which option should you choose? Option A: Deploy the microservice as an Azure Function with a Service Bus trigger on the Consumption plan. Option B: Deploy the microservice as a container in AKS with a Horizontal Pod Autoscaler based on Service Bus queue length. Option C: Deploy the microservice as an Azure Container App with a Service Bus scale rule. Option D: Deploy the microservice as an Azure App Service WebJob with continuous mode.

A.Azure Container App with Service Bus scale rule

B.AKS with HPA based on Service Bus queue length

C.Azure Function with Service Bus trigger on Consumption plan

D.Azure App Service WebJob with continuous mode

AnswerA

Container Apps support scale-to-zero and custom scale rules based on Service Bus message count.

Why this answer

Azure Container Apps (ACA) with a Service Bus scale rule is the correct choice because it provides event-driven scaling based on the number of messages in a Service Bus topic, can scale to zero when there are no messages, supports graceful shutdown via terminationGracePeriodSeconds, and minimizes operational overhead compared to AKS. ACA is a serverless container platform that abstracts Kubernetes complexity while still allowing containerized workloads, making it ideal for stateless microservices that need to scale on demand.

Exam trap

The trap here is that candidates often choose Azure Functions for event-driven scaling, but the requirement for containerization and graceful shutdown makes Azure Container Apps the better fit, as Functions are not containerized and have limited control over shutdown behavior.

How to eliminate wrong answers

Option B (AKS with HPA based on Service Bus queue length) is wrong because the Horizontal Pod Autoscaler (HPA) in AKS cannot natively scale based on Service Bus queue length; it requires a custom metrics adapter or KEDA, and AKS does not scale to zero pods (minimum replica count is typically 1). Option C (Azure Function with Service Bus trigger on Consumption plan) is wrong because Azure Functions are not containerized; the requirement states the microservice must be containerized, and Functions run as code, not containers. Option D (Azure App Service WebJob with continuous mode) is wrong because WebJobs run in an App Service plan that cannot scale to zero (always has at least one instance) and does not support containerized deployments natively.

Practice this question →

135

MCQmedium

You are designing a solution that uses Azure Container Instances (ACI) to run a batch processing job. The job is expected to run for up to 2 hours. You need to minimize costs. Which ACI configuration should you use?

A.Use a container group with a restart policy of 'OnFailure' or 'Never'.

B.Use GPU-enabled containers for faster processing.

C.Deploy the container group in a virtual network.

D.Use a container group with a restart policy of 'Always'.

AnswerA

The container stops after the job completes, reducing cost.

Why this answer

Option A is correct because setting the restart policy to 'OnFailure' or 'Never' ensures that the container does not restart after the batch job completes, avoiding unnecessary compute charges. ACI bills per second of container runtime, so any idle or restarted container time directly increases cost. For a finite batch job, a restart policy that prevents automatic restarts is the most cost-effective choice.

Exam trap

The trap here is that candidates often assume 'Always' is safer for reliability, but for batch jobs that complete successfully, 'Always' causes continuous restarts and unbounded costs, while 'OnFailure' or 'Never' align with the cost-minimization goal.

How to eliminate wrong answers

Option B is wrong because GPU-enabled containers incur significantly higher costs per second and are unnecessary for standard batch processing jobs that do not require GPU acceleration. Option C is wrong because deploying a container group in a virtual network adds networking overhead and does not reduce compute costs; it is typically used for security or integration, not cost minimization. Option D is wrong because a restart policy of 'Always' causes the container to restart indefinitely after the job completes, leading to continuous billing for idle runtime, which directly contradicts the goal of minimizing costs.

Practice this question →

136

MCQeasy

Your company has an Azure App Service web app that runs on a Standard App Service plan. You need to scale out the app to handle increased traffic during business hours and scale in during off-hours. What should you configure?

A.Configure autoscale rules on the App Service plan to scale out and in based on CPU usage.

B.Manually increase the instance count during business hours.

C.Scale up the App Service plan to a Premium plan.

D.Use Azure Traffic Manager to distribute load.

AnswerA

Autoscale can adjust instance count automatically based on metrics or schedule.

Why this answer

Option A is correct because Azure App Service autoscale rules allow you to automatically scale out (increase instance count) and scale in (decrease instance count) based on metrics like CPU usage. This meets the requirement to handle increased traffic during business hours and reduce costs during off-hours without manual intervention. Autoscale is configured at the App Service plan level, not the web app itself, and works with the Standard tier and above.

Exam trap

The trap here is confusing 'scaling up' (increasing the plan tier or instance size) with 'scaling out' (increasing the number of instances), and assuming that manual scaling or Traffic Manager can achieve automatic scaling based on load.

How to eliminate wrong answers

Option B is wrong because manually increasing the instance count during business hours does not automate the process; the requirement is to scale out and in automatically based on traffic patterns, not manually. Option C is wrong because scaling up to a Premium plan increases the resources (e.g., CPU, memory) of each instance but does not scale out (add more instances) to handle increased traffic; autoscale is already available on the Standard plan. Option D is wrong because Azure Traffic Manager distributes traffic across endpoints for global load balancing and failover, but it does not scale the number of instances in an App Service plan; it works at the DNS level, not the compute scaling level.

Practice this question →

137

MCQeasy

You are developing an Azure Function that runs on a Consumption plan. The function needs to process a large file uploaded to Azure Blob Storage. The processing is CPU-intensive and may take up to 30 minutes. What should you use to implement the function?

A.Use a blob trigger and set the batchSize to 1 to avoid timeouts.

B.Configure the function app to use a Premium plan to allow longer execution times.

C.Set the functionTimeout in host.json to 30 minutes on the Consumption plan.

D.Create an orchestrator function using Durable Functions to manage the processing.

AnswerB

Premium plan allows up to 60 minutes execution time.

Why this answer

Azure Functions on a Consumption plan have a maximum execution timeout of 10 minutes (or 5 minutes by default). For CPU-intensive processing that may take up to 30 minutes, you must use a Premium plan, which supports unlimited execution duration (subject to the functionTimeout setting, which can be set up to 60 minutes by default and up to unlimited if configured). The Premium plan also provides dedicated instances and pre-warmed workers, which are suitable for long-running, resource-intensive workloads.

Exam trap

The trap here is that candidates often assume they can simply increase the functionTimeout in host.json on a Consumption plan, not realizing that the Consumption plan enforces a hard cap of 10 minutes regardless of the setting.

How to eliminate wrong answers

Option A is wrong because a blob trigger on a Consumption plan still enforces the 10-minute timeout; setting batchSize to 1 only controls concurrency, not execution duration, and does not prevent timeout. Option C is wrong because the functionTimeout setting on a Consumption plan cannot exceed 10 minutes (the maximum allowed is 10 minutes, and the default is 5 minutes); setting it to 30 minutes would be ignored or cause an error. Option D is wrong because Durable Functions are designed for orchestrating stateful workflows and fan-out/fan-in patterns, not for simply extending the execution timeout of a single CPU-intensive function; they add complexity and overhead without solving the fundamental timeout limitation on a Consumption plan.

Practice this question →

138

Multi-Selecthard

Which THREE factors should you consider when choosing between Azure Container Instances (ACI) and Azure Kubernetes Service (AKS) for a containerized workload? (Choose three.)

Select 3 answers

A.The need for orchestration of multiple containers

B.The restart policy for containers

C.The need for GPU-accelerated compute

D.The availability of Azure Application Gateway Ingress Controller

E.The maximum resource limits per container instance

AnswersA, B, E

ACI is suitable for single-container deployments or simple multi-container groups; AKS is better for complex orchestration.

Why this answer

Option A is correct because AKS provides full orchestration capabilities for managing multiple containers across a cluster, including service discovery, load balancing, and scaling. ACI is designed for single-container or simple multi-container groups without native orchestration, making AKS the appropriate choice when complex orchestration is required.

Exam trap

The trap here is that candidates mistakenly think GPU support is exclusive to AKS, but ACI also supports GPU-accelerated compute, making it a non-differentiating factor; similarly, the Application Gateway Ingress Controller is an AKS-only feature, so it is not a factor to 'consider when choosing' but rather a feature that only exists in one service.

Practice this question →

139

MCQeasy

A company has an Azure App Service web app that occasionally returns 500 errors. You need to diagnose the root cause without impacting production traffic. Which feature should you use?

A.Kudu console

B.Deployment slots

C.Application Insights

D.Autoscaling rules

AnswerB

Slots allow you to test changes in staging before swapping to production.

Why this answer

Deployment slots allow you to route a copy of your production traffic to a staging slot for debugging without affecting the live site. By swapping the staging slot into production after testing, you can reproduce and diagnose 500 errors in an isolated environment. This feature provides zero-downtime deployment and traffic routing, making it ideal for diagnosing production issues safely.

Exam trap

The trap here is that candidates often confuse monitoring tools like Application Insights with the ability to safely reproduce and debug issues in an isolated environment, overlooking the slot-swapping and traffic-routing capabilities of deployment slots.

How to eliminate wrong answers

Option A is wrong because the Kudu console provides direct file system access and command-line tools for debugging, but it operates on the live production site and can impact traffic if misused, and it does not isolate traffic for safe diagnosis. Option C is wrong because Application Insights is a monitoring and telemetry service that helps identify performance issues and errors after they occur, but it does not provide an isolated environment to reproduce and debug errors without affecting production traffic. Option D is wrong because Autoscaling rules automatically adjust the number of instances based on load, but they do not help diagnose the root cause of 500 errors and may even mask underlying issues by scaling out.

Practice this question →

140

MCQeasy

You are developing a web application that runs on Azure App Service. The application needs to store session state. Which Azure service provides the best performance and reliability for session state storage?

A.Azure Table Storage

B.Azure Blob Storage

C.Azure Cache for Redis

D.Azure SQL Database

AnswerC

Correct: Redis is the recommended session state provider for performance.

Why this answer

Azure Cache for Redis provides the best performance and reliability for session state storage because it is an in-memory data store with sub-millisecond latency, designed for high-throughput, low-latency scenarios like session caching. It supports session state providers natively in ASP.NET and ASP.NET Core, ensuring fast reads and writes for each user request without the overhead of disk I/O or network latency associated with other storage options.

Exam trap

The trap here is that candidates often choose Azure SQL Database or Table Storage because they are familiar with them for data storage, but they overlook that session state is a transient, high-frequency access pattern that demands an in-memory cache like Redis, not a durable or relational store.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a NoSQL key-value store optimized for structured, non-relational data at scale, but it has higher latency (typically 10-50 ms per operation) and lacks the in-memory speed needed for session state, which requires frequent, fast reads and writes. Option B is wrong because Azure Blob Storage is designed for storing large unstructured data like images and videos, not for high-frequency, low-latency access patterns; its latency (often 50-100+ ms) and lack of native session state provider support make it unsuitable for session state. Option D is wrong because Azure SQL Database is a relational database with transactional consistency, but its disk-based storage and connection overhead (e.g., TCP handshake, query parsing) introduce higher latency (typically 5-50 ms) compared to Redis, and it is overkill for simple key-value session data, leading to unnecessary cost and complexity.

Practice this question →

141

MCQeasy

You need to monitor the performance of an Azure App Service web app. You want to track the number of HTTP 500 errors over the last hour. Which Azure Monitor metric should you use?

A.Data In

B.Average Response Time

C.Http5xx

D.Requests

AnswerC

Http5xx metric tracks number of server error responses.

Why this answer

The Http5xx metric in Azure Monitor tracks the count of HTTP 500-level server error responses returned by your App Service. Since the question specifically asks for the number of HTTP 500 errors over the last hour, this metric directly provides that count without any aggregation or filtering needed.

Exam trap

The trap here is that candidates may confuse 'Http5xx' with 'Requests' or 'Average Response Time', thinking that a high error count would be reflected in those metrics, but they do not directly count error status codes.

How to eliminate wrong answers

Option A is wrong because Data In measures the amount of incoming data (in bytes) to the app, not error counts. Option B is wrong because Average Response Time measures the average time taken to serve requests, not the count of specific HTTP status codes. Option D is wrong because Requests tracks the total number of HTTP requests received, regardless of their response status, so it does not isolate 500 errors.

Practice this question →

142

MCQmedium

You need to deploy an Azure Functions app that runs on a dedicated App Service plan. The function must be triggered by an HTTP request and call a downstream API that requires OAuth 2.0 authentication. Which approach should you use to store the API credentials securely?

A.Use Azure App Configuration with plain text

B.Store credentials in a configuration file in the deployment package

C.Use Key Vault references in the function app settings

D.Store credentials in the function code as constants

AnswerC

Key Vault references securely inject secrets.

Why this answer

Option C is correct because Azure Key Vault references in function app settings allow you to securely store and retrieve sensitive information like OAuth 2.0 credentials (client ID, client secret) without exposing them in code or configuration files. The function app resolves these references at runtime using a managed identity, ensuring credentials are never stored in plaintext or accessible via source control.

Exam trap

The trap here is that candidates may confuse Azure App Configuration (a configuration store) with Azure Key Vault (a secrets store), assuming both are equally secure for credentials, but App Configuration does not natively encrypt values or support managed identity-based access for secrets without Key Vault integration.

How to eliminate wrong answers

Option A is wrong because Azure App Configuration is a service for managing application settings and feature flags, but storing credentials as plain text there violates security best practices and does not provide encryption at rest or access control for secrets. Option B is wrong because storing credentials in a configuration file within the deployment package exposes them to anyone with access to the package or source repository, and they are not encrypted or managed centrally. Option D is wrong because hardcoding credentials as constants in function code makes them visible in source control, difficult to rotate, and a severe security risk; Azure Functions should never embed secrets directly in code.

Practice this question →

143

MCQhard

A Durable Functions workflow for a booking backend must call five independent activity functions and continue only after all results are available. Which pattern is appropriate?

A.Monitor pattern

B.Fan-out/fan-in

C.Human interaction

D.Function chaining

AnswerB

Fan-out/fan-in runs activities in parallel and aggregates results after all complete.

Why this answer

The fan-out/fan-in pattern is designed for scenarios where multiple independent tasks must execute in parallel, and the workflow must wait for all results before proceeding. In Durable Functions, this is implemented using `Task.WhenAll()` to fan out activity function calls and then aggregate their results, which matches the requirement of calling five independent activities and continuing only after all results are available.

Exam trap

The trap here is that candidates often confuse the fan-out/fan-in pattern with function chaining, mistakenly thinking that sequential execution is sufficient, or they incorrectly apply the Monitor pattern when the requirement is simply parallel execution without polling.

How to eliminate wrong answers

Option A is wrong because the Monitor pattern is used for polling an external resource until a specific condition is met, not for parallel execution of independent tasks. Option C is wrong because the Human Interaction pattern involves waiting for manual input or approval, which is not applicable to automated parallel activity calls. Option D is wrong because Function chaining executes activities sequentially, one after another, which does not achieve the parallel execution required here.

Practice this question →

144

MCQhard

You have an Azure App Service web app that uses a custom domain with TLS/SSL binding. You need to migrate the app to a new App Service plan in a different region. What is the correct order of steps?

A.Create the new plan, deploy the app, export the current plan, bind the domain

B.Export the current plan, create the new plan, bind the domain, deploy the app

C.Bind the domain to the new plan, export the current plan, create the new plan, deploy the app

D.Export the current plan, create the new plan, deploy the app, bind the domain and certificate

AnswerD

Correct order: export configuration, create new plan, deploy app, then bind domain and TLS.

Why this answer

First export the current App Service plan (or scale up), then create the new plan, deploy the app, and finally bind the custom domain and TLS certificate. Option D is the correct sequence. Option A misses the certificate binding.

Option B is out of order. Option C exports after creating the new plan.

Practice this question →

145

Multi-Selectmedium

Which TWO actions should you take to ensure high availability for a stateful ASP.NET application deployed on Azure App Service?

Select 2 answers

A.Enable ARR Affinity (client affinity) to maintain session state.

B.Scale up the App Service plan to a higher tier.

C.Deploy the application to multiple regions and use Traffic Manager.

D.Store session state in Azure Files share.

E.Disable session state to allow any instance to handle requests.

AnswersA, C

ARR affinity ensures requests from same client go to same instance.

Why this answer

Option A is correct because enabling ARR Affinity (client affinity) ensures that all requests from a given client session are routed to the same instance, preserving in-memory session state. Without this, a stateful ASP.NET application would lose session data if subsequent requests are load-balanced to different instances, causing session state errors.

Exam trap

The trap here is that candidates often confuse scaling up (Option B) with high availability, not realizing that scaling up only adds resources to a single instance, whereas high availability requires redundancy across instances or regions.

Practice this question →

146

MCQeasy

You are developing a solution that needs to run a background task every 10 minutes to clean up temporary files in Azure Blob Storage. You want to use Azure Functions with the Consumption Plan to minimize cost. Which trigger type should you use?

A.HTTPTrigger

B.TimerTrigger

C.BlobTrigger

D.ServiceBusTrigger

AnswerB

TimerTrigger is specifically designed for running functions on a schedule using a CRON expression. It is ideal for periodic tasks every 10 minutes.

Why this answer

B is correct because TimerTrigger is designed for scheduled execution of background tasks at fixed intervals, such as every 10 minutes. It uses a cron expression to define the schedule and runs on the Consumption Plan, which scales to zero when idle, minimizing cost. This makes it the ideal choice for periodic cleanup of temporary files in Azure Blob Storage.

Exam trap

The trap here is that candidates may confuse BlobTrigger (event-driven on blob changes) with a scheduled cleanup task, not realizing that TimerTrigger is the only trigger that natively supports recurring time-based execution without external dependencies.

How to eliminate wrong answers

Option A is wrong because HTTPTrigger requires an incoming HTTP request to invoke the function, making it unsuitable for a scheduled background task that must run autonomously every 10 minutes. Option C is wrong because BlobTrigger fires only when a new or updated blob is detected in a container, not on a fixed time schedule, so it cannot enforce a periodic cleanup routine. Option D is wrong because ServiceBusTrigger responds to messages arriving on a Service Bus queue or topic, which would require an external sender to produce messages every 10 minutes, adding unnecessary complexity and cost compared to a simple TimerTrigger.

Practice this question →

147

MCQeasy

You are developing a containerized application that will be deployed to Azure Container Instances (ACI). The application consists of a web front-end and a background worker that processes messages from an Azure Storage Queue. You need to ensure that the worker container runs continuously and processes messages as they arrive. The solution must minimize cost and management overhead. What should you do?

A.Use Azure Container Apps with a scale rule that triggers on queue length.

B.Run the worker inside an Azure virtual machine with a container runtime.

C.Deploy the worker as a container in ACI with the restart policy set to OnFailure.

D.Deploy the worker as a container group in ACI with the restart policy set to Always.

AnswerD

ACI with Always restart ensures the worker keeps running and is cost-effective with no orchestration overhead.

Why this answer

Option D is correct because ACI with a restart policy of Always ensures the worker container restarts immediately after it finishes processing a message, allowing it to continuously poll the Azure Storage Queue for new messages. This minimizes cost by using a serverless container model without provisioning VMs or managing orchestration, and it reduces management overhead compared to alternatives like Azure Container Apps or VMs.

Exam trap

The trap here is that candidates mistakenly choose the OnFailure restart policy (Option C) thinking it will restart the container after each message, but they overlook that a successful exit (exit code 0) does not trigger a restart, causing the worker to stop after processing one message.

How to eliminate wrong answers

Option A is wrong because Azure Container Apps introduces additional orchestration and scaling complexity, which increases cost and management overhead unnecessarily for a simple background worker that can run continuously in ACI. Option B is wrong because running the worker inside an Azure VM with a container runtime requires managing the VM, patching, and scaling, which increases cost and overhead compared to a serverless ACI solution. Option C is wrong because the OnFailure restart policy only restarts the container if it exits with a non-zero exit code, but a worker that processes messages successfully will exit with code 0 and stop, preventing it from continuously polling the queue.

Practice this question →

148

Multi-Selecteasy

Which TWO actions can you perform using Azure Container Registry (ACR) tasks?

Select 2 answers

A.Schedule a task to patch base images

B.Automatically build a container image on code commit

C.Import images from another registry

D.Deploy images to AKS

E.Automatically scan images for vulnerabilities

AnswersA, B

ACR Tasks can run on schedule to rebuild images.

Why this answer

ACR Tasks supports automated patching of base images through the 'base image update' trigger. When a base image in a public or private registry is updated, ACR Tasks can automatically rebuild any container images that depend on it, ensuring security patches are applied without manual intervention. This is configured via the `--base-image-trigger-enabled` flag in the `az acr task create` command.

Exam trap

The trap here is that candidates confuse ACR Tasks with the broader Azure Container Registry feature set, assuming that import, deployment, or scanning are part of ACR Tasks when they are separate services or commands.

Practice this question →

149

Multi-Selecteasy

You are developing an Azure Functions app that processes events from an Event Hubs instance. The function must scale out automatically based on the number of partitions in the Event Hub. You need to ensure that each function instance processes events from at least one partition. Which THREE configurations should you use?

Select 3 answers

A.Set the function app to use the 'Event Scale' mode with a target of one instance per partition.

B.Set the 'MaxBatchSize' property to 1 to ensure even distribution.

C.Configure the function to use an event processor host with blob storage for checkpointing.

D.Select the Premium App Service plan for the function app.

E.Use the EventHubs trigger with the 'PartitionKey' parameter set to the partition ID.

AnswersA, C, E

Event Scale mode maximizes parallelism per partition.

Why this answer

Option A is correct because the 'Event Scale' mode with a target of one instance per partition ensures that the function app scales out to match the number of Event Hub partitions, with each instance processing events from at least one partition. This mode is specifically designed for event-driven scaling with Event Hubs, guaranteeing that each partition is processed by a dedicated instance for optimal throughput and ordering.

Exam trap

The trap here is that candidates confuse batch size configuration (MaxBatchSize) with scaling behavior, or assume a Premium plan is mandatory for partition-level scaling, when in fact the Event Scale mode and checkpointing are the key mechanisms.

Practice this question →

150

MCQhard

You are designing a solution that uses Azure Batch for parallel processing of large datasets. Each task requires significant CPU and memory. You need to minimize compute costs while ensuring tasks complete within a deadline. Which pool configuration should you use?

A.A mix of dedicated and low-priority VMs without retry

B.Low-priority VMs with a task retry policy

C.Use Azure Container Instances instead of Batch

D.Dedicated VMs only

AnswerB

Low-priority VMs reduce cost and retry ensures completion.

Why this answer

Low-priority VMs (now called Spot VMs) offer significant cost savings but can be preempted. Using them with a task retry policy ensures completion. Dedicated VMs are more expensive.

Practice this question →