CCNA Azure Compute Solutions Questions — Page 2 of 4

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 Azure Container Instances (ACI) are designed to protect sensitive values by encrypting them at rest and masking them from standard display in the Azure portal, logs, and `az container show` output. When defined with the `secureValue` property, ACI ensures that the secret is injected into the container at runtime without being persistently exposed in plain text within the container's configuration. This mechanism significantly reduces the risk of accidental or malicious disclosure, making it the recommended approach for handling secrets directly within ACI.

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

Mounting an Azure Files share as a volume is the correct approach for persistent storage in Azure Container Instances (ACI). Azure Files provides fully managed SMB file shares that can be easily mounted into an ACI container group, allowing the containerized application to write logs or other persistent data to a network-attached file system. This ensures that data persists beyond the lifecycle of the individual container instance, even if the container restarts or is redeployed, offering a robust and cost-effective solution for stateful applications.

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

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 is the correct solution as it enables an Azure App Service to establish outbound connectivity to resources located within a specified Azure Virtual Network. By injecting the App Service's outbound traffic into a delegated subnet within the VNet, it can securely access private endpoints, virtual machines, or other services that are not publicly exposed. This allows the image resize worker to call internal services or storage accounts privately.

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

Azure Container Apps natively supports binding custom domains directly to a container app's ingress, providing a streamlined and cost-effective solution. This feature includes integrated certificate management, allowing users to either upload their own TLS/SSL certificates or leverage free, automatically renewed managed certificates provided by Azure. This direct approach simplifies the configuration of secure HTTPS endpoints without requiring additional, external services, making it the most appropriate choice.

Why this answer

Azure Container Apps allows you to attach a custom domain and upload an SSL/TLS certificate directly at the environment level, which is the correct approach for securing a microservice with a custom domain. This configuration ensures that the Container App responds to HTTPS requests on your domain without needing an additional front-end service.

Exam trap

The trap here is that candidates often assume a separate front-end service like Azure Front Door or Application Gateway is required for custom domains and SSL, when in fact Azure Container Apps environments natively support this at the ingress level, making those additional services redundant for this specific requirement.

How to eliminate wrong answers

Option A is wrong because Azure Front Door is a global load balancer and CDN, not a required component for attaching a custom domain and certificate directly to a Container App; it adds unnecessary complexity and cost. Option C is wrong because Azure API Management is an API gateway for managing APIs, not a service for attaching custom domains and certificates to the underlying Container App; it would only proxy requests, not satisfy the requirement at the app level. Option D is wrong because Azure Application Gateway is a regional web traffic load balancer with SSL termination, but it is not the native way to attach a custom domain and certificate to a Container App; the Container App environment itself supports this directly.

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

Dapr's Service Invocation building block provides a consistent and secure way for microservices to communicate with each other directly. It abstracts away complexities like service discovery, mTLS encryption, and retries, enabling reliable synchronous calls between services regardless of their underlying protocol or location. This makes it a fundamental component for direct, internal service-to-service communication within a distributed application.

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

Azure AD pod identity in AKS securely assigns a managed identity to a Kubernetes pod, eliminating the need for hardcoded credentials when the microservice needs to access other Azure resources. For incoming API requests, the Microsoft.Identity.Web library provides a robust framework within the API code to validate JSON Web Tokens (JWTs), ensuring their authenticity, integrity, and crucially, checking the 'scope' claims to enforce fine-grained authorization based on the caller's permissions. This approach aligns with modern secure development practices by leveraging managed identities and explicit token-based authorization.

Why this answer

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

Azure App Service offers a direct and secure integration feature to import certificates from Azure Key Vault. This 'Key Vault Certificate' option securely retrieves the certificate, including its private key, from Key Vault, allowing it to be bound to a custom domain within the App Service without manual export or upload. This method also supports automatic renewal if the certificate is renewed in Key Vault.

Why this answer

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 are purpose-built for orchestrating long-running, stateful workflows that can inherently exceed the standard Azure Functions timeout limits. A blob-triggered client function can initiate a Durable Orchestration, which then manages the execution of multiple activity functions, persisting its state between asynchronous operations. This allows the overall workflow to run for hours or even days by breaking down the large file processing into smaller, manageable, and independently executable steps.

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

Enabling Azure AD Pod Identity (or its successor, Azure AD Workload Identity) allows individual pods within an AKS cluster to acquire and use an Azure Active Directory managed identity. By assigning a specific managed identity to a pod, that pod can then authenticate directly with Azure SQL Database using its identity, completely eliminating the need for connection strings, usernames, or passwords in the application code or configuration files. This method provides secure, credential-less authentication, aligning with best practices for microservices security.

Why this answer

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 →

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 provides a fully managed, cloud-based file share that can be mounted as a volume into an Azure Container Instance. This solution offers durable and persistent storage, meaning data written to the share remains intact even if the container instance stops, restarts, or is deleted. Its independence from the container's lifecycle makes it the ideal choice for stateful applications requiring reliable data persistence in ACI.

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 →

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 →

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

Attaching the Azure Container Registry (ACR) to an Azure Kubernetes Service (AKS) cluster, or explicitly granting the kubelet's managed identity the AcrPull role, is the recommended and most secure method for image authentication. This approach leverages Azure's native identity and access management, allowing the AKS cluster's nodes (via their managed identity) to securely pull images from the private ACR without requiring explicit credentials in Kubernetes manifests. It adheres to the principle of least privilege, providing only the necessary read access.

Why this answer

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 →

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

Azure WebJobs are an integral feature of Azure App Service, allowing you to run scripts or executables as background processes within your web app instance. By enabling "Always On" for the App Service plan, the underlying host process for the WebJob is kept alive indefinitely, preventing the App Service from being unloaded due to inactivity and ensuring the continuous execution of the long-running microservice without interruption. This makes them ideal for persistent background tasks tightly coupled with an App Service.

Why this answer

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 →

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 is the correct and idiomatic approach for implementing built-in retry logic in Durable Functions orchestrations. The `context.CallActivityWithRetryAsync` method automatically handles transient failures by retrying the specified activity function based on the provided `RetryOptions`, which define the `FirstRetryInterval` (5 seconds) and `MaxNumberOfAttempts` (3), ensuring robustness without manual retry loops.

Why this answer

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 →

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

When message processing fails due to a transient issue, updating the message's visibility timeout using the `UpdateMessage` operation is the recommended pattern. This action makes the message invisible for a specified duration, preventing other consumers from attempting to process it immediately. After the timeout expires, the message becomes visible again, allowing for a delayed retry attempt, which is crucial for resolving transient errors without losing the message.

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 →

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

Azure Container Instances (ACI) offers the fastest and simplest way to run a single container or a small group of containers in Azure without managing any underlying infrastructure. It is a serverless solution that allows for immediate deployment and billing by the second, making it ideal for scenarios requiring quick starts, burst workloads, or simple containerized applications that don't need full orchestration capabilities. Its restart policy ensures the container can be configured to run once, always, or on failure, perfectly suiting a straightforward container deployment need.

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 →

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 is the appropriate choice for persistent storage when a single pod requires dedicated, block-level storage. It natively supports the ReadWriteOnce access mode, meaning the volume can be mounted as read-write by a single node. In AKS, Azure Disks are provisioned dynamically via a StorageClass and PersistentVolumeClaim, ensuring data persistence even if the pod restarts or is rescheduled to a different node within the same cluster. This makes it ideal for stateful applications where data integrity for a single instance is paramount.

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 →

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

Triggered WebJobs are an integral feature of Azure App Service, allowing you to run scripts or executables as background processes within the same App Service plan as your web application. They are ideal for scheduled tasks, as they can be configured to run on a CRON schedule (e.g., hourly) and leverage the existing compute resources without impacting the web app's performance significantly. This provides a highly integrated, cost-effective, and reliable solution for background processing directly alongside the web application.

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 →

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

Mounting an Azure Files share as a volume in an Azure Container Instances (ACI) container group is the correct approach for persistent storage. Azure Files provides fully managed file shares that can be accessed via SMB or NFS protocols. When mounted as a volume, data written to the share by the container persists even if the container restarts, the container group is deleted, or a new container group is deployed, ensuring data durability for stateful applications.

Why this answer

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 →

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

Azure Container Instances (ACI) supports mounting Azure Files shares directly, enabling persistent storage for containers. To mount an Azure Files share, the container group requires the storage account name and its corresponding storage account key. This key acts as the primary credential for authentication and authorization to access the file share. For security, the storage account key should be passed to the container securely, typically via environment variables marked as secure or through Azure Key Vault integration, rather than hardcoding it in the container definition.

Why this answer

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 →

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

Azure Security Center provides unified security management and threat protection; Azure Sentinel is a cloud-native SIEM/SOAR; Azure Key Vault safeguards keys and secrets; Azure Active Directory manages identity and access. Common confusions include mixing Security Center with Sentinel or Sentinel with Azure AD.

Practice this question →

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 a common and powerful serverless orchestration technique, particularly well-suited for Azure Durable Functions. It involves executing multiple functions in parallel (fan-out) and then waiting for all of them to complete before aggregating their results (fan-in). This enables efficient parallel processing of independent tasks within a single, stateful workflow, making it ideal for scenarios like image processing, batch data processing, or complex report generation.

Why this answer

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 →

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

An Azure Function triggered by Blob Storage on a Consumption plan is an ideal solution because it is inherently event-driven, reacting immediately to new image uploads. The Consumption plan offers a serverless execution model, meaning you only pay for the compute resources and execution time consumed, making it highly cost-effective for intermittent or variable workloads. Furthermore, it automatically scales out or in based on demand, ensuring high availability and performance without manual intervention, perfectly suiting a web application's dynamic image processing needs.

Why this answer

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 →

100

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

An azureFile volume mounts an Azure Files share directly into a container, providing robust, network-attached persistent storage. Data written to this volume is stored externally in Azure Storage, ensuring it survives container restarts, crashes, or even the complete deletion and recreation of the container instance. This decoupling of storage from the container lifecycle is crucial for stateful applications requiring data durability and availability across container operations.

Why this answer

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 →

101

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

Azure Functions bindings, particularly for external services like Blob Storage, critically depend on a configured connection string to authenticate and authorize access. This connection string, often referenced by a setting like `AzureWebJobsStorage` or a custom name specified in the binding's `connection` property, must be present in the Function App's application settings. Without this essential configuration, the Azure Functions runtime cannot establish a connection to the specified storage account, leading to binding failures.

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 →

102

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

Azure Functions is a serverless compute service that allows you to run event-driven code without provisioning or managing infrastructure. It is an excellent choice for a background worker processing queue messages, as it can be directly triggered by new messages in an Azure Storage Queue or Service Bus Queue. This enables automatic scaling and cost-efficiency, as you only pay for the compute resources consumed when your function is actively processing messages.

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 →

103

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

Container orchestrators, such as Azure Container Instances (ACI), are designed to monitor the primary process running within a container. When this process exits with a non-zero status code, it signals an abnormal termination or a critical failure within the application. ACI's default restart policies (like 'Always' or 'OnFailure') will then automatically attempt to restart the container. If the application consistently fails and exits immediately upon startup with a non-zero code, this creates a continuous restart loop, as the orchestrator repeatedly tries to bring up a failing container.

Why this answer

The 'Always' restart policy in Azure Container Instances restarts the container whenever it stops, regardless of the exit code. If the application exits with a non-zero exit code on startup (e.g., due to a configuration error or missing dependency), the container will stop immediately, triggering an infinite restart loop. This is the most likely cause because the container is not crashing due to external factors but rather failing during its initialization phase.

Exam trap

The trap here is that candidates often confuse 'Always' with 'OnFailure' — 'Always' restarts on any exit, including non-zero exit codes on startup, while 'OnFailure' only restarts on non-zero exit codes, making the continuous restart loop a symptom of an application that fails immediately with a non-zero exit code.

How to eliminate wrong answers

Option A is wrong because an inaccessible Azure Files volume would cause the container to fail at mount time, but the restart policy would still apply; however, the container would not restart continuously unless the application itself exits with a non-zero code after the mount failure. Option C is wrong because port binding conflicts on the host are not a direct concern in Azure Container Instances, as each container instance gets its own isolated network namespace and port mapping is handled by the platform. Option D is wrong because exceeding CPU or memory limits would cause the container to be throttled or killed by the Azure Container Instances orchestrator, but the restart policy would then restart it; however, the continuous restart loop described is more characteristic of an application that exits immediately on startup rather than resource exhaustion, which typically results in a single termination followed by a restart.

Practice this question →

104

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

This solution effectively leverages Azure Logic Apps' serverless workflow capabilities to precisely manage the lifecycle of an Azure Container Instance (ACI) container group. A recurrence trigger initiates the workflow on a defined schedule, and the dedicated 'Start Container Group' and 'Stop Container Group' actions ensure the container is provisioned and de-provisioned only for the duration of the task, significantly minimizing operational costs for intermittent workloads.

Why this answer

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 →

105

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, network-attached storage that persists independently of the container's lifecycle. This fully managed file share service supports SMB and NFS protocols, allowing multiple container instances or groups to concurrently read from and write to the same data. Its ability to provide shared, persistent storage that survives container restarts and can be accessed across different nodes makes it an ideal solution for stateful applications requiring high availability and data durability.

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 →

106

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

Azure Autoscale is the correct solution for dynamically adjusting the number of App Service instances based on performance metrics. By configuring an autoscale rule with a CPU percentage threshold, the system automatically scales out (adds instances) when the CPU utilization exceeds the defined limit, and scales in (removes instances) when it drops below a specified lower threshold. This ensures optimal performance and cost efficiency by matching resource capacity to demand.

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 →

107

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

Azure Container Apps is specifically designed for hosting microservices and supports gRPC ingress natively, allowing direct exposure of gRPC endpoints. Crucially, it enables configuring scale rules that include setting minReplicas to 0, which means the container app can scale down completely when idle, incurring no cost for compute resources. This combination of gRPC support and true scale-to-zero capability makes it an ideal solution for cost-efficient, event-driven microservices.

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 →

108

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

"The AKS cluster does not have the Azure AD Pod Identity add-on enabled" is the correct answer. This add-on is essential because it deploys the necessary Kubernetes components, specifically the Managed Identity Controller (MIC) and Node Managed Identity (NMI) server, which facilitate the assignment of Azure managed identities to individual pods. Without these components, pods cannot intercept token requests or acquire the required Azure AD tokens from the assigned managed identity to authenticate with Azure resources like Azure SQL Database.

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 →

109

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

1Step 1

2Step 2

3Step 3

4Step 4

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 →

110

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 rules in an App Service plan enable the system to automatically adjust the number of instances (scale out or in) based on predefined performance metrics, such as CPU utilization, memory usage, or HTTP queue length. By configuring rules to scale out when metrics like CPU usage exceed a threshold, the web app can dynamically add more instances to distribute the load and improve response times. This ensures the application maintains optimal performance and availability even during unpredictable traffic spikes, without requiring manual intervention.

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 →

111

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

This approach is optimal for cost efficiency. A scheduled job can programmatically create an Azure Container Instance (ACI) container group, which offers per-second billing. Setting the restart policy to Never ensures the container stops and releases all compute resources immediately upon successful completion, while explicitly deleting the container group after its run guarantees no lingering charges, making it ideal for one-off, batch-like tasks.

Why this answer

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 →

112

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 →

113

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 orchestrators are specifically designed for complex, stateful, and long-running workflows, making them ideal for processing thousands of claims reliably. They provide built-in checkpointing and durable execution history, ensuring that the workflow state is preserved even across infrastructure failures or reboots. This allows the claims processing function to pause and resume, managing the progress of each claim without losing context and coordinating multiple steps effectively over extended periods.

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 →

114

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

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 →

115

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

Azure Container Apps provides granular control over ingress at the individual container app level, making this the correct and most efficient solution. For the external service, configuring its ingress as 'External' makes it publicly accessible via a fully qualified domain name (FQDN) generated by the platform. Conversely, setting the ingress for internal services to 'Internal' ensures they are only reachable by other container apps within the same environment, or via VNet integration, without exposing them to the public internet. This approach directly addresses the requirement for mixed external and internal access within a single, unified environment.

Why this answer

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 →

116

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

When deploying nested resources like application settings (Microsoft.Web/sites/config) for an Azure App Service, it is crucial to explicitly define a dependency on the parent Microsoft.Web/sites resource. Without the dependsOn property, Azure Resource Manager (ARM) might attempt to deploy the child configuration resource before the parent App Service instance has been fully provisioned and is ready to accept configuration changes. This can lead to deployment failures, as the target parent resource for the settings would not yet exist or be in a stable state.

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 →

117

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 →

118

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.Deploy the microservice as an Azure Function with a Service Bus trigger on the Consumption plan.

B.AKS with HPA based on Service Bus queue length

C.Deploy the microservice as an Azure Container App with a Service Bus scale rule.

D.Azure App Service WebJob with continuous mode

AnswerC

Azure Container Apps with a Service Bus scale rule is the correct choice because it offers event-driven scaling to zero, supports containerized workloads, and provides configurable graceful shutdown, all with minimal operational overhead.

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. Azure Functions with a Service Bus trigger also scales based on messages and can scale to zero, but it does not natively support containerization (unless using custom containers which adds complexity) and has less control over graceful shutdown.

AKS requires managing a cluster and does not scale to zero. App Service WebJobs are not containerized and do not scale based on Service Bus metrics.

Exam trap

The trap is that candidates often choose Azure Functions for its event-driven scaling and scale-to-zero capability, but overlook the requirement for containerization and graceful shutdown. Azure Container Apps provides both container support and fine-grained shutdown control, making it the optimal choice.

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 →

119

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

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 →

120

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 rules on the App Service plan provide the capability to automatically adjust the number of instances (scale out) when demand, such as CPU usage, exceeds a defined threshold, and scale in when demand decreases. This ensures the web app maintains optimal performance and availability under fluctuating loads without requiring manual intervention, making it the most efficient and automated solution for dynamic capacity management.

Why this answer

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 →

121

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

The Azure Functions Premium plan is specifically designed to support longer execution durations, allowing functions to run for up to 60 minutes. This plan provides pre-warmed instances to eliminate cold starts and offers dedicated compute resources, making it ideal for workloads requiring extended processing times beyond the Consumption plan's inherent limits. Migrating to a Premium plan directly addresses the need for increased execution time by providing a higher platform-level timeout.

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 →

122

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, D, E

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.

Why this answer

Azure Container Instances (ACI) has specific maximum resource limits for a single container group (e.g., 16 vCPU, 112 GiB memory), making it suitable for smaller, burstable workloads. Azure Kubernetes Service (AKS) allows for much larger, distributed applications by scaling out across multiple nodes and pods, making the overall resource capacity a key differentiator (E).

The Azure Application Gateway Ingress Controller (AGIC) is an AKS-specific feature that allows Application Gateway to act as an Ingress controller for an AKS cluster. If a workload requires this specific ingress solution, AKS is the appropriate choice, whereas ACI does not offer this native integration (D).

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. Another trap is misinterpreting the role of specific integration features like the Application Gateway Ingress Controller (AGIC). AGIC is an AKS-only feature; therefore, the *need* for AGIC is a critical factor when choosing between AKS and ACI.

While both ACI and AKS have restart policies, the advanced orchestration capabilities of AKS (covered by option A) provide more robust and automated restart management and self-healing across a cluster, making 'restart policy' alone a less precise differentiating factor compared to orchestration, resource limits, or specific integration needs.

Practice this question →

123

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

AnswerC

Application Insights provides comprehensive Application Performance Monitoring (APM) by collecting telemetry such as requests, exceptions, dependencies, and performance counters directly from your application. It offers end-to-end transaction tracing, allowing developers to visualize the flow of requests and pinpoint the exact code path and dependencies causing HTTP 500 errors, complete with stack traces and contextual data. This non-intrusive monitoring solution is ideal for diagnosing production issues without impacting user experience or requiring manual intervention.

Why this answer

Application Insights is a powerful diagnostic tool that provides detailed telemetry and performance monitoring for your web app. It can automatically detect and analyze 500 errors, showing stack traces, request details, and dependencies. This allows you to identify the root cause without impacting production traffic, as it works passively by collecting data.

Exam trap

The trap here is that candidates might consider deployment slots for isolating issues, but while slots are excellent for safe deployments and testing new code, they are not the primary tool for *diagnosing the root cause* of *existing, occasional 500 errors* in a live production application. Application Insights is specifically designed for passive monitoring and detailed telemetry collection to identify such root causes without direct interaction or reproduction efforts.

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 →

124

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

Azure Cache for Redis is an in-memory data store based on the open-source Redis, providing extremely low-latency data access and high throughput. This makes it ideal for caching and managing session state in distributed web applications. Its support for various data structures, along with built-in features like data expiration and atomic operations, perfectly aligns with the requirements for efficient, scalable, and resilient session management.

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 →

125

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

The 'Http5xx' metric specifically counts the number of HTTP responses with a status code in the 500-599 range, which unequivocally indicates server-side errors. These errors signify that the App Service or the underlying application encountered an unexpected condition that prevented it from fulfilling a valid request. Monitoring this metric is a direct and critical way to identify and track application performance degradation caused by internal server failures.

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 →

126

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

Using Key Vault references in Azure Function app settings is the recommended and most secure method for managing sensitive credentials. This approach allows the function app to retrieve secrets dynamically from Azure Key Vault at runtime, without ever storing the secret value directly in the app's configuration or code. The function app uses its managed identity to authenticate with Key Vault, ensuring that secrets are accessed securely, rotated easily, and never exposed in plain text within the application environment.

Why this answer

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 →

127

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 →

128

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

This is the correct order for migrating an App Service with a custom domain and certificate, ensuring minimal downtime and proper configuration. First, exporting the current plan captures all necessary application settings and environment variables. Next, creating the new App Service Plan and deploying the application with the exported configuration ensures the app is fully functional in the new environment. Finally, binding the custom domain and its TLS/SSL certificate ensures secure and uninterrupted service delivery to end-users.

Why this answer

The proper sequence for migrating an Azure App Service web app with a custom domain and TLS/SSL binding to a new plan in a different region is: first, capture the existing web app's configuration (e.g., by exporting its ARM template, which includes custom domain and certificate binding details), then create the new App Service plan in the target region, deploy the app (which involves creating the new web app resource and deploying its code, potentially using the captured configuration), and finally bind the custom domain and certificate to the new web app. This ensures the custom domain and TLS/SSL binding are correctly associated with the new web app after it's deployed, avoiding downtime or misconfiguration.

Exam trap

The trap here is that candidates often think they can bind the domain and certificate before deploying the app, or that exporting the plan is optional, but Azure requires the app to be deployed and running to validate domain ownership and certificate binding.

How to eliminate wrong answers

Option A is wrong because exporting the current plan should occur before creating the new plan to capture the app's configuration, and deploying the app before binding the domain and certificate is out of order (binding should come after deployment). Option B is wrong because binding the domain before deploying the app is incorrect; the app must be deployed first to have the necessary endpoints and configuration for domain binding. Option C is wrong because binding the domain to the new plan before exporting the current plan and creating the new plan is logically impossible and violates the dependency order.

Practice this question →

129

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

Enabling ARR Affinity, also known as client affinity, ensures that all subsequent requests from a specific client are routed to the same App Service instance that handled the initial request. This mechanism is crucial for maintaining in-memory session state, preventing data loss or inconsistent user experiences if the application relies on server-side session variables. While it doesn't provide redundancy for the session state itself, it guarantees session stickiness, which is vital for the functional continuity of stateful applications within a scaled-out environment. It helps prevent session-related errors that could otherwise impact perceived availability.

Why this answer

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 →

130

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

The TimerTrigger is the appropriate choice for executing Azure Functions on a predefined schedule, making it ideal for background tasks that need to run periodically. It leverages CRON expressions, allowing developers to specify precise execution intervals, such as every 10 minutes, daily, or on specific days of the week. This trigger is purpose-built for reliable, time-based task automation without requiring external orchestration.

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 →

131

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

Deploying the worker as a container group in Azure Container Instances (ACI) with the restart policy set to `Always` is the most appropriate solution. ACI offers a serverless platform, eliminating the need to manage underlying virtual machines or orchestration infrastructure. The `Always` restart policy ensures that the container is automatically restarted by ACI if it stops for any reason, guaranteeing continuous availability for the worker process to handle incoming messages efficiently and cost-effectively.

Why this answer

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 virtual machines.

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 →

132

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 TWO configurations should you use?

Select 2 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

Event Scale mode maximizes parallelism per partition.

Why this answer

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. Option C is correct because an event processor host with blob storage for checkpointing enables load balancing across multiple instances, ensuring each instance handles one or more partitions. Option E is incorrect because 'PartitionKey' is used when sending events to Event Hubs to assign a partition, not in the trigger binding; the trigger automatically distributes partitions across instances.

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 →

133

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

This approach is optimal for cost-effective large-scale parallel processing in Azure Batch. Low-priority VMs offer significant cost savings by utilizing surplus Azure capacity, making them ideal for workloads that can tolerate interruptions. The crucial addition of a task retry policy ensures that if a low-priority VM is preempted and a task is interrupted, Azure Batch automatically reschedules and restarts that task on another available node. This combination guarantees eventual task completion and maintains the overall reliability of the solution while dramatically reducing compute costs.

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 →

134

MCQeasy

A company deploys an Azure Function app that processes orders. The function needs to scale out automatically when the queue length grows and be billed only for execution time. Which hosting plan should you use?

A.App Service Plan

B.Consumption Plan

C.Premium Plan

D.Dedicated Plan

AnswerB

The Consumption Plan is the quintessential serverless hosting option for Azure Functions, automatically provisioning and scaling compute resources on demand in response to events. It charges only for the resources consumed (memory, CPU) and the execution time, billed per second, making it highly cost-efficient for intermittent or variable workloads. This plan eliminates the need to manage infrastructure and ensures costs directly align with actual function usage for processing orders.

Why this answer

The Consumption Plan is correct because it automatically scales out the function app based on the length of the Azure Storage queue trigger, and you are billed only for the execution time (per-second billing) and resources consumed. This plan is ideal for event-driven workloads like order processing, where scaling is demand-driven and idle time incurs no cost.

Exam trap

The trap here is that candidates often confuse the Premium Plan's pre-warmed instances and VNET support with the Consumption Plan's true pay-per-execution model, mistakenly thinking Premium is required for auto-scaling, when in fact the Consumption Plan handles queue-length-based scaling natively and is the only plan with pure execution-time billing.

How to eliminate wrong answers

Option A is wrong because the App Service Plan runs on dedicated VMs and incurs continuous billing even when the function is idle, and it does not provide automatic scale-out based solely on queue length without manual configuration or auto-scale rules. Option C is wrong because the Premium Plan, while offering pre-warmed instances and VNET connectivity, incurs a baseline cost for always-ready instances and is not billed purely on execution time like the Consumption Plan. Option D is wrong because the Dedicated Plan is essentially the same as the App Service Plan, running on reserved instances with continuous billing and no built-in queue-length-based auto-scaling without additional setup.

Practice this question →

135

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. What should you configure?

A.Manually increase the instance count during peak hours.

B.Configure an autoscale rule to scale up the App Service plan.

C.Configure an autoscale rule to scale out based on CPU percentage.

D.Use Azure Front Door to distribute load across multiple instances.

AnswerC

Configuring an autoscale rule to "scale out" based on CPU percentage is the most effective solution for an Azure App Service web app experiencing high variability. Scaling out dynamically adds more instances of the web app to the App Service plan when the average CPU utilization across existing instances exceeds a defined threshold. This horizontal scaling distributes the incoming load across multiple instances, ensuring consistent performance and responsiveness during peak demand without manual intervention.

Why this answer

Azure App Service autoscale rules allow you to scale out (increase instance count) based on a metric like CPU percentage. This automatically adds more instances when CPU exceeds a threshold, distributing the load and reducing CPU usage per instance during peak hours.

Exam trap

The trap here is that candidates often confuse 'scale up' (changing the plan tier) with 'scale out' (adding instances), and may incorrectly select Option B thinking it addresses CPU load, but scaling up does not increase instance count.

How to eliminate wrong answers

Option A is wrong because manually increasing the instance count is not an automatic solution; it requires human intervention and does not meet the requirement to scale automatically. Option B is wrong because 'scale up' refers to increasing the resources (e.g., SKU size) of the App Service plan, not adding more instances; scaling up changes the plan tier (e.g., from Standard to Premium) and does not directly address high CPU load via horizontal scaling. Option D is wrong because Azure Front Door is a global load balancer and CDN service that distributes traffic at the application layer, but it does not automatically scale the number of instances; it can route traffic to multiple instances but does not configure autoscaling rules based on CPU load.

Practice this question →

136

MCQeasy

You are developing an Azure Function that processes messages from an Azure Storage queue. The function must handle transient failures when writing to a downstream database. You need to implement a retry policy. What is the recommended approach?

A.Do nothing; Azure Functions automatically retries failed executions indefinitely.

B.Use a try-catch block in the function code to retry on failure.

C.Configure the retry policy in the function's host.json file.

D.Use Durable Functions with a retry policy.

AnswerC

Configuring the retry policy within the function's `host.json` file is the recommended and most efficient method for handling transient failures in Azure Functions. This built-in capability allows developers to declaratively specify retry counts, delay strategies (fixed or exponential backoff), and maximum retry intervals, offloading the retry logic from application code to the robust runtime.

Why this answer

Azure Functions provides a built-in retry policy that can be configured declaratively in the host.json file, specifically using the 'retry' section for fixed-delay or exponential-backoff strategies. This is the recommended approach for handling transient failures in a clean, configurable manner without custom code, and it applies to all function executions in the function app.

Exam trap

The trap here is that candidates often assume custom try-catch logic (Option B) is the only way to implement retries, overlooking the fact that Azure Functions provides a declarative, built-in retry mechanism in host.json that is simpler and more maintainable.

How to eliminate wrong answers

Option A is wrong because Azure Functions does not automatically retry failed executions indefinitely; the default behavior is to retry up to a limited number of times (e.g., 5 for consumption plan) with a delay, but this is not indefinite and can be overridden. Option B is wrong because using a try-catch block to implement custom retry logic is error-prone, mixes concerns, and bypasses the built-in retry infrastructure that handles backoff, poison messages, and logging consistently. Option D is wrong because Durable Functions with a retry policy is overkill for a simple queue-triggered function; it introduces orchestration overhead and is intended for long-running workflows, not for transient database write failures in a straightforward message processing scenario.

Practice this question →

137

MCQeasy

You need to run a batch job every night that processes data from Azure Blob Storage and writes results to Azure SQL Database. The job may run for up to 2 hours. Which Azure service should you use?

A.Azure Logic Apps.

B.Azure Batch.

C.Azure Functions (Consumption plan).

D.Azure Container Instances.

AnswerD

Azure Container Instances (ACI) provides a serverless platform to run Docker containers directly, eliminating the need to manage underlying virtual machines or orchestrators like Kubernetes. It is ideal for executing single, isolated, and potentially long-running batch jobs, as containers can run for extended durations, typically up to 24 hours. ACI offers a simple, cost-effective, and on-demand compute solution for running a nightly batch job by providing dedicated resources for a containerized application.

Why this answer

Azure Container Instances (ACI) is the correct choice because it allows you to run a containerized batch job on-demand without managing underlying infrastructure. The job's duration of up to 2 hours fits well within ACI's default timeout of 60 minutes (configurable up to 24 hours), and you can trigger it nightly via a scheduler like Azure Logic Apps or a timer-triggered Azure Function. ACI provides fast startup, per-second billing, and direct access to Azure Blob Storage and SQL Database via connection strings or managed identities.

Exam trap

The trap here is that candidates often choose Azure Functions (Consumption plan) for batch jobs because of its serverless appeal, but they overlook the strict 10-minute execution timeout, which makes it impossible for a 2-hour job without switching to the Premium plan or using Durable Functions.

How to eliminate wrong answers

Option A is wrong because Azure Logic Apps is a workflow orchestration service, not a compute runtime for long-running batch jobs; it has a built-in action timeout of 2 minutes for HTTP requests and 1 minute for API connections, making it unsuitable for a 2-hour processing job. Option B is wrong because Azure Batch is designed for large-scale parallel and high-performance computing (HPC) workloads, not a simple nightly batch job; it requires creating a pool of VMs, managing job scheduling, and is overkill for a single containerized task. Option C is wrong because Azure Functions on the Consumption plan has a maximum execution timeout of 10 minutes (configurable up to 60 minutes for the Premium plan), so it cannot handle a job that may run for up to 2 hours.

Practice this question →

138

MCQmedium

A company deploys a microservices application on Azure Kubernetes Service (AKS). They need to automatically scale individual microservices based on custom metrics (e.g., queue depth). Which feature should they use?

A.Horizontal Pod Autoscaler

B.Virtual Node

C.Vertical Pod Autoscaler

D.Cluster Autoscaler

AnswerA

The Horizontal Pod Autoscaler (HPA) automatically scales the number of pod replicas in a deployment or replica set based on observed CPU utilization, memory usage, or other custom metrics. For microservices applications, HPA is the correct choice as it can leverage application-specific custom metrics from sources like Azure Monitor or Prometheus to dynamically adjust the number of running pods to match real-time demand, ensuring optimal performance and resource efficiency.

Why this answer

The Horizontal Pod Autoscaler (HPA) is the correct choice because it automatically scales the number of pod replicas in a deployment or replica set based on observed metrics, including custom metrics like queue depth. HPA queries the Kubernetes Metrics API, which can be extended with custom metrics adapters (e.g., Prometheus Adapter) to support application-specific metrics, enabling fine-grained scaling for each microservice.

Exam trap

The trap here is that candidates often confuse Horizontal Pod Autoscaler (scaling replicas) with Cluster Autoscaler (scaling nodes) or Vertical Pod Autoscaler (scaling pod resources), but only HPA supports custom metrics for per-microservice replica scaling.

How to eliminate wrong answers

Option B (Virtual Node) is wrong because it enables serverless compute by provisioning pods on Azure Container Instances (ACI) to handle burst capacity, not for scaling based on custom metrics. Option C (Vertical Pod Autoscaler) is wrong because it adjusts CPU/memory resource requests and limits of existing pods, not the number of replicas, and does not respond to custom metrics like queue depth. Option D (Cluster Autoscaler) is wrong because it scales the number of AKS nodes (VMs) in the cluster based on pending pod resource requests, not individual microservice replicas based on custom application metrics.

Practice this question →

139

MCQmedium

A company deploys a microservices application on Azure Kubernetes Service (AKS). They need to securely store configuration settings such as database connection strings and API keys. The solution must minimize administrative overhead and automatically rotate keys. What should they use?

A.Store secrets as Kubernetes Secrets objects with base64 encoding.

B.Use Azure Key Vault with the Secrets Store CSI driver.

C.Use Azure App Configuration with feature flags.

D.Store secrets as environment variables in the container's deployment YAML.

AnswerB

This is the most secure and recommended approach for microservices on AKS. Azure Key Vault provides a highly secure, centralized store for secrets, certificates, and keys, with robust access controls, auditing, and encryption at rest. The Secrets Store CSI driver allows Kubernetes pods to mount secrets from Key Vault as an ephemeral volume, making them available to containers as files, and supports automatic secret rotation without requiring pod restarts, significantly enhancing security and reducing operational overhead.

Why this answer

Azure Key Vault with the Secrets Store CSI driver allows you to mount secrets as volumes or environment variables in AKS pods without exposing them in plaintext or requiring manual rotation. The CSI driver synchronizes secrets from Key Vault to a Kubernetes volume, and Key Vault supports automatic key rotation policies, minimizing administrative overhead while ensuring security.

Exam trap

The trap here is that candidates often confuse Azure App Configuration (which is for non-sensitive config and feature flags) with Azure Key Vault (which is the correct service for secrets), or they assume base64 encoding in Kubernetes Secrets provides security, when it is merely obfuscation.

How to eliminate wrong answers

Option A is wrong because Kubernetes Secrets with base64 encoding are not encrypted by default; base64 is merely an encoding, not encryption, and secrets can be easily decoded, plus they lack automatic rotation capabilities. Option C is wrong because Azure App Configuration is designed for feature flags and application configuration management, not for securely storing sensitive secrets like connection strings and API keys; it does not natively support automatic key rotation. Option D is wrong because storing secrets as environment variables in deployment YAML exposes them in plaintext within the YAML file and pod specifications, violating security best practices and providing no automatic rotation mechanism.

Practice this question →

140

MCQeasy

You are building a solution that processes real-time telemetry from IoT devices. The telemetry data must be ingested, processed with minimal latency, and stored in Azure Blob Storage for long-term analytics. You need to choose the serverless compute service that is best suited for this scenario. What should you use?

A.Azure Functions with Event Hubs trigger

B.Azure Batch with Event Hubs input

C.Azure Logic Apps with Event Hubs connector

D.Azure WebJobs with Event Hubs SDK

AnswerA

This is the optimal choice for real-time telemetry processing due to its serverless nature and event-driven architecture. The Event Hubs trigger allows Azure Functions to automatically scale out to handle high-throughput, low-latency ingestion of millions of events per second, processing them efficiently on a consumption-based billing model without managing underlying infrastructure. This makes it highly cost-effective and responsive for dynamic workloads, perfectly aligning with real-time processing requirements.

Why this answer

Azure Functions with an Event Hubs trigger is the best choice because it provides a serverless, event-driven compute model that can process high-throughput telemetry data with minimal latency. The Event Hubs trigger scales automatically based on the number of partitions and events, ensuring real-time processing, and the output can directly write to Azure Blob Storage for long-term analytics.

Exam trap

The trap here is that candidates often confuse Azure Logic Apps (which also has an Event Hubs connector) with Azure Functions, but Logic Apps are designed for orchestration and have higher latency, making them inappropriate for real-time, high-throughput telemetry processing.

How to eliminate wrong answers

Option B is wrong because Azure Batch is designed for large-scale parallel batch processing (e.g., HPC, rendering) and is not optimized for real-time, low-latency event ingestion; it requires explicit job scheduling and is not event-triggered. Option C is wrong because Azure Logic Apps are workflow orchestrators with higher latency and overhead, making them unsuitable for high-throughput, real-time telemetry processing; they are better for business process automation. Option D is wrong because Azure WebJobs run in the context of an App Service plan, which is not serverless and incurs ongoing costs even when idle; they lack the automatic scaling and event-driven triggers of Functions for Event Hubs.

Practice this question →

141

MCQhard

You are implementing an Azure Durable Functions orchestration. The orchestration calls several activity functions that may fail transiently. You need to retry an activity up to 3 times with a 5-second delay, doubling the delay each time (exponential backoff). Which method should you use to call the activity?

A.CallActivityAsync with a try-catch loop that implements retry logic

B.CallActivityWithRetryAsync with RetryOptions(maxAttempts: 3, firstRetryInterval: TimeSpan.FromSeconds(5), backoffCoefficient: 2)

C.Use a timer trigger to schedule retries after failure

D.Set the activity function's retry policy in the function.json file

AnswerB

The `CallActivityWithRetryAsync` method is the native and most robust way to implement retry logic for activity function calls within a Durable Functions orchestration. By utilizing `RetryOptions`, developers can declaratively specify the exact retry policy, including `maxAttempts`, `firstRetryInterval`, and `backoffCoefficient`, which directly maps to the requirement of 3 attempts with an initial 5-second delay that doubles exponentially. This approach leverages Durable Functions' built-in state management and reliability features, ensuring that the retry logic persists across orchestrator rehydrations and host restarts without manual state tracking.

Why this answer

`CallActivityWithRetryAsync` is the built-in method in Durable Functions for calling activity functions with automatic retry policies, including exponential backoff. The `RetryOptions` object allows you to specify `maxAttempts` (3), `firstRetryInterval` (5 seconds), and `backoffCoefficient` (2) to double the delay each time, exactly matching the requirement without custom code.

Exam trap

The trap here is that candidates may think manual retry logic (Option A) is acceptable, but Durable Functions orchestrators must be deterministic and cannot use custom retry loops that introduce non-deterministic behavior like random delays or external state.

How to eliminate wrong answers

Option A is wrong because manually implementing retry logic with a try-catch loop inside the orchestrator function violates the deterministic replay requirement of Durable Functions, leading to potential runtime errors or infinite replays. Option C is wrong because using a timer trigger to schedule retries after failure is an external, non-orchestration approach that bypasses the built-in retry capabilities and adds unnecessary complexity, failing to leverage Durable Functions' native support for retries. Option D is wrong because activity functions do not have a retry policy configurable in `function.json`; retry policies are defined at the orchestration level via `RetryOptions` when calling the activity, not in the activity's metadata.

Practice this question →

142

MCQhard

You deploy the above ARM template resource. After deployment, the web app cannot connect to Application Insights. The Application Insights resource exists in the same region. What is the most likely cause?

A.The dependsOn is incorrect; it should reference the Application Insights resource ID.

B.The app setting 'APPINSIGHTS_INSTRUMENTATIONKEY' is deprecated; you should use 'APPLICATIONINSIGHTS_CONNECTION_STRING' instead.

C.The web app needs a user-assigned managed identity to access Application Insights.

D.The instrumentation key must be set under a different name, like 'APPINSIGHTS_KEY'.

AnswerB

The `APPINSIGHTS_INSTRUMENTATIONKEY` application setting is indeed deprecated for Azure Application Insights integration in modern Azure App Services and functions. The current and recommended practice is to utilize the `APPLICATIONINSIGHTS_CONNECTION_STRING` setting instead. This connection string provides enhanced security, supports sovereign clouds, and enables custom endpoint configurations, offering a more robust and flexible way to send telemetry data.

Why this answer

The ARM template likely sets the 'APPINSIGHTS_INSTRUMENTATIONKEY' app setting, which is deprecated. Application Insights now requires the 'APPLICATIONINSIGHTS_CONNECTION_STRING' app setting for authentication and telemetry ingestion, as the instrumentation key alone is no longer sufficient for newer SDK versions and regional endpoints.

Exam trap

The trap here is that candidates assume the instrumentation key is still the primary connection method, but Microsoft deprecated it in favor of the connection string, which is required for newer SDK versions and regional routing.

How to eliminate wrong answers

Option A is wrong because the dependsOn property in ARM templates controls deployment order, not runtime connectivity; even if the dependency is missing, the web app can still connect to Application Insights after both resources are deployed. Option C is wrong because a managed identity is not required for Application Insights access; the connection string or instrumentation key provides direct authentication without identity. Option D is wrong because 'APPINSIGHTS_KEY' is not a recognized app setting name; the correct deprecated key is 'APPINSIGHTS_INSTRUMENTATIONKEY', and the modern replacement is 'APPLICATIONINSIGHTS_CONNECTION_STRING'.

Practice this question →

143

MCQhard

Your Azure Functions app uses a consumption plan and processes messages from an Azure Service Bus queue. You notice that message processing takes up to 10 minutes, and some messages are being processed multiple times. What is the most likely cause?

A.The max delivery count for the queue is set too low.

B.The function host is configured with a low maximum instance count.

C.The lock duration on the Service Bus queue is shorter than the processing time.

D.The function does not handle poison messages correctly.

AnswerC

In Service Bus's peek-lock mode, a message is locked for a specific duration when received by a function. If the function's processing time exceeds this lock duration and the lock is not explicitly renewed, the lock automatically expires. Upon expiration, the message becomes visible and available again in the queue, allowing another function instance (or even the same instance) to pick it up and process it anew, leading directly to duplicate processing.

Why this answer

The default lock duration for a Service Bus queue is 30 seconds, which is far shorter than the 10-minute processing time. When the lock expires, the message becomes visible to other consumers, causing duplicate processing. While Azure Functions attempts to automatically renew the message lock during processing, this auto-renewal has a maximum duration (default 5 minutes).

Since the processing time (10 minutes) exceeds this duration, the lock will eventually expire, leading to the message becoming available for re-delivery.

Exam trap

The trap here is that candidates often assume duplicate processing is caused by scaling or retry policies, when in fact it is the lock duration being shorter than the processing time that directly leads to message re-delivery.

How to eliminate wrong answers

Option A is wrong because the max delivery count controls how many times a message can be delivered before being moved to the dead-letter queue; a low value would cause premature dead-lettering, not duplicate processing. Option B is wrong because a low maximum instance count limits scaling but does not cause duplicate processing; it might increase latency but not reprocessing of the same message. Option D is wrong because poison message handling (dead-lettering after exceeding max delivery count) is a consequence of repeated failures, not the root cause of duplicate processing; the function is not handling poison messages incorrectly—it is processing them multiple times due to lock expiration.

Practice this question →

144

MCQmedium

You develop a serverless application using Azure Functions. The function must process images uploaded to a blob container. You need to ensure the function runs only when a new blob is created, and that it scales out automatically for high upload volumes. Which trigger and hosting plan combination should you use?

A.Blob trigger + Consumption plan

B.HTTP trigger + Consumption plan

C.Queue trigger + Consumption plan

D.Timer trigger + Consumption plan

AnswerA

The Blob trigger is the most direct and efficient mechanism for reacting to new or updated blobs in Azure Storage. It leverages Azure Event Grid internally to provide an immediate, event-driven response without polling. When combined with the Consumption plan, the function scales automatically from zero instances to handle high volumes of uploads, ensuring cost-effectiveness by only charging for actual execution time.

Why this answer

A Blob trigger is designed to run a function when a blob is created or updated in Azure Blob Storage, which directly matches the requirement to process images only when a new blob is uploaded. The Consumption plan provides automatic scaling based on demand, handling high upload volumes by dynamically allocating resources without manual intervention. This combination ensures event-driven execution and cost-effective scaling.

Exam trap

The trap here is that candidates might confuse the Blob trigger with other triggers (HTTP, Queue, Timer) that can indirectly process blobs, but the question explicitly requires the function to run only when a new blob is created, which only the Blob trigger directly supports.

How to eliminate wrong answers

Option B is wrong because an HTTP trigger requires an explicit HTTP request to invoke the function, not a blob creation event, so it would not automatically run when a new blob is uploaded. Option C is wrong because a Queue trigger responds to messages in an Azure Storage Queue, not directly to blob creation events; while you could chain a blob trigger to a queue, the question specifies the function must run only when a new blob is created, making a queue trigger an indirect and unnecessary intermediary. Option D is wrong because a Timer trigger runs on a fixed schedule (e.g., every 5 minutes) and cannot respond to real-time blob creation events, leading to delays or missed uploads.

Practice this question →

145

MCQhard

You are developing an Azure Functions app that processes large files from Azure Blob Storage. When a file is uploaded, the function triggers and reads the entire file into memory, causing high memory usage. You need to optimize the function to handle large files efficiently. Which approach should you recommend?

A.Stream the blob content directly to the processing logic

B.Use a byte array to read the blob in chunks

C.Read the blob content into a temporary file on disk

D.Increase the memory allocation of the function app

AnswerA

When processing large blobs, streaming directly to the processing logic is the most memory-efficient and scalable approach. This method allows the Azure Function to process data in chunks as it arrives, without loading the entire blob into memory simultaneously. By avoiding full in-memory buffering, it prevents out-of-memory errors and ensures efficient resource utilization, which is crucial for serverless environments operating under memory constraints.

Why this answer

Streaming the blob content directly to the processing logic avoids loading the entire file into memory at once. The Azure Blob Storage SDK supports reading blob content as a stream (e.g., using `BlobClient.OpenReadAsync()`), which allows the function to process data in chunks, significantly reducing memory pressure for large files.

Exam trap

The trap here is that candidates often assume reading in chunks with a byte array is sufficient, but they overlook that the byte array itself still holds the entire chunk in memory, whereas streaming processes data without retaining it, which is the key optimization for large files.

How to eliminate wrong answers

Option B is wrong because using a byte array to read the blob in chunks still requires allocating a large buffer in memory, which can lead to high memory usage and potential `OutOfMemoryException` for very large files. Option C is wrong because writing the blob content to a temporary file on disk introduces unnecessary I/O overhead and disk space consumption, which is inefficient for serverless functions that may have limited local storage. Option D is wrong because increasing memory allocation only raises the ceiling for memory usage without addressing the root cause of inefficient memory management; it does not prevent the function from loading the entire file into memory and may increase costs.

Practice this question →

146

MCQhard

You are building a real-time dashboard that displays data from Azure Event Hubs. You need to aggregate events over a one-minute window and update the dashboard every minute. Which Azure service should you use?

A.Azure Stream Analytics

B.Azure Data Factory

C.Azure Analysis Services

D.Azure Logic Apps

AnswerA

Azure Stream Analytics is purpose-built for real-time analytics on streaming data, making it the ideal choice for a real-time dashboard. It allows for continuous data ingestion, transformation, and aggregation from sources like Azure Event Hubs or IoT Hubs using a SQL-like query language. This service is optimized for low-latency processing, enabling immediate insights and visualization of live data streams.

Why this answer

Azure Stream Analytics is the correct choice because it is designed for real-time stream processing, allowing you to aggregate events from Azure Event Hubs over a one-minute tumbling window and output results to a dashboard or sink. It natively supports windowing functions (e.g., TumblingWindow, HoppingWindow) and can handle high-throughput, low-latency data streams, making it ideal for updating a dashboard every minute.

Exam trap

The trap here is that candidates often confuse Azure Stream Analytics with Azure Data Factory, mistakenly thinking Data Factory can handle real-time streaming when it is actually designed for batch-oriented data movement and transformation.

How to eliminate wrong answers

Option B is wrong because Azure Data Factory is a data integration and orchestration service for batch ETL/ELT pipelines, not for real-time stream processing or windowed aggregations. Option C is wrong because Azure Analysis Services is an analytical engine for semantic models and OLAP cubes, designed for interactive reporting on pre-aggregated data, not for ingesting and aggregating live event streams. Option D is wrong because Azure Logic Apps is a workflow automation service for orchestrating business processes and integrating services, but it lacks native support for high-throughput, low-latency stream processing and windowed aggregations over Event Hubs.

Practice this question →

147

MCQmedium

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

A.Secure environment variable

B.Container command-line argument

C.Public blob containing the password

D.Plain environment variable

AnswerA

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 they are not visible in the Azure portal or container logs. This ensures the password is available to the container at startup without exposing it through the portal interface or log output, meeting the security requirement.

Exam trap

The trap here is that candidates may confuse secure environment variables with plain environment variables, assuming both are equally hidden, but only secure environment variables are encrypted and excluded from portal and log visibility.

How to eliminate wrong answers

Option B is wrong because command-line arguments are passed as part of the container's process command line, which can be logged by the container runtime or appear in process listings, making them visible in logs and potentially the portal. Option C is wrong because a public blob containing the password would be accessible to anyone with the URL, violating security by exposing the password to unauthorized users. Option D is wrong because plain environment variables are stored in plain text and can be viewed in the Azure portal's container settings and may be captured in container logs, failing the requirement to keep the password hidden.

Practice this question →

148

MCQmedium

You are designing a serverless application using Azure Functions. The solution must process messages from an Azure Service Bus queue and update a Cosmos DB database. Which binding configuration should you use on the function?

A.Service Bus trigger with Table storage output binding

B.Blob trigger with Cosmos DB output binding

C.HTTP trigger with Cosmos DB input binding

D.Service Bus trigger with Cosmos DB output binding

AnswerD

This combination correctly leverages Azure Functions for a queue-driven database update. A Service Bus trigger is specifically designed to activate an Azure Function whenever a new message is posted to an Azure Service Bus queue or topic. The Cosmos DB output binding then provides a straightforward and efficient way for the function to persist or update documents within an Azure Cosmos DB container, directly fulfilling the requirement for a queue-triggered database interaction.

Why this answer

The requirement specifies processing messages from an Azure Service Bus queue and updating a Cosmos DB database. A Service Bus trigger binds the function to the queue, and a Cosmos DB output binding writes the processed data directly to Cosmos DB, enabling a seamless serverless workflow without additional code for database operations.

Exam trap

The trap here is that candidates may confuse output bindings with input bindings or choose a trigger that does not match the event source, such as selecting a Blob or HTTP trigger when the requirement explicitly states a Service Bus queue as the message source.

How to eliminate wrong answers

Option A is wrong because it uses a Table storage output binding, which writes to Azure Table Storage, not Cosmos DB, and thus does not meet the requirement to update a Cosmos DB database. Option B is wrong because it uses a Blob trigger, which responds to blob storage events, not Service Bus messages, so it cannot process messages from the Service Bus queue. Option C is wrong because it uses an HTTP trigger, which requires an external HTTP request to invoke the function, and a Cosmos DB input binding only reads data from Cosmos DB, not updates it.

Practice this question →

149

MCQmedium

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

A.The FUNCTIONS_WORKER_RUNTIME is set to dotnet-isolated, which is outdated.

B.The storage account name is hardcoded in the connection string.

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

D.The connection string does not use HTTPS.

AnswerC

Directly embedding sensitive information, such as a storage account access key, within an ARM template constitutes a significant security vulnerability. Anyone with read access to the template, whether in source control or deployment logs, could potentially extract this key and gain unauthorized access to the associated storage account. Best practices mandate using Azure Key Vault to store secrets securely and referencing them via managed identities or Key Vault references in the template, preventing direct exposure.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

Option A is wrong because 'dotnet-isolated' is the current recommended mode for .NET 8+ isolated worker processes, not outdated. Option B is wrong because hardcoding the storage account name is a maintainability concern, not a security vulnerability; the key exposure is the critical risk. Option D is wrong because connection strings for Azure Storage (using the default HTTPS endpoint) inherently use HTTPS; the protocol is not a security issue here.

Practice this question →

150

MCQmedium

You deploy an Azure Function app that runs on the Consumption plan. The function writes logs to Application Insights. You notice that some log entries are missing during periods of high load. You need to ensure that all logs are captured without significantly increasing cost. What should you do?

A.Adjust the sampling rate in the Application Insights configuration to 100%.

B.Change the function app to the Premium plan to get more CPU and memory.

C.Create a separate Application Insights resource for the function app.

D.Disable sampling in the function's host.json.

AnswerA

Adjusting the Application Insights sampling rate to 100% directly addresses missing telemetry by ensuring that all generated data, including logs, requests, and dependencies, is sent from the function app to the Application Insights resource. By default, Application Insights SDKs often employ adaptive sampling to reduce data volume and associated costs, which can lead to certain telemetry items being discarded. Setting the sampling rate to 100% overrides this behavior, guaranteeing maximum data capture, though it may increase ingestion costs if the telemetry volume is high.

Why this answer

Under high load, Application Insights uses adaptive sampling by default to reduce data volume, which can cause log entries to be dropped. Adjusting the sampling rate to 100% in the Application Insights configuration ensures all telemetry data is captured, while still running on the Consumption plan, which does not significantly increase cost because the function app itself scales and you only pay for execution time and resources used.

Exam trap

The trap here is that candidates often think disabling sampling in host.json or upgrading the plan will fix missing logs, but they overlook that Application Insights sampling is controlled at the Application Insights configuration level, not the function app's host configuration.

How to eliminate wrong answers

Option B is wrong because upgrading to the Premium plan increases CPU and memory but does not affect Application Insights sampling behavior; logs would still be subject to sampling unless explicitly configured. Option C is wrong because creating a separate Application Insights resource does not change the sampling rate; the default adaptive sampling still applies and would continue to drop logs under high load. Option D is wrong because disabling sampling in host.json only affects the function app's own logging pipeline, not the Application Insights ingestion sampling; the Application Insights SDK still applies adaptive sampling at the telemetry channel level.

Practice this question →