Courseiva

CCNA Develop Azure compute solutions Questions

75 of 226 questions · Page 1/4 · Develop Azure compute solutions · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQhard

You are developing a serverless application using Azure Functions that processes order messages from an Azure Service Bus queue. Each order message is approximately 64 KB in size. The function must process messages in order and exactly once. The current implementation uses a Service Bus trigger with batch processing enabled. You notice that occasionally duplicate messages are processed. You need to ensure exactly-once processing while maintaining message ordering. What should you do?

A.Disable batch processing in the function trigger and process messages one at a time.
B.Enable sessions on the Service Bus queue and update the function trigger to use sessions.
C.Increase the lock duration on the Service Bus queue to 5 minutes.
D.Set the maxDeliveryCount property on the queue to 1.
AnswerB

Enabling sessions on the Azure Service Bus queue and configuring the Azure Function trigger to utilize them is the most effective solution for achieving exactly-once processing. Service Bus sessions provide a mechanism for ordered handling of related messages and ensure that only one receiver processes messages for a specific session at any given time. This unique receiver lock, combined with the ability to maintain session state, effectively prevents duplicate processing and ensures messages are handled sequentially within their logical grouping.

Why this answer

Enabling sessions on the Service Bus queue and using a session-enabled trigger guarantees message ordering and exactly-once processing. Sessions group related messages into a logical sequence, and the Service Bus trigger locks the entire session, ensuring that messages within a session are processed in order and that no other consumer can process the same session concurrently. This prevents duplicate processing while maintaining the required ordering.

Exam trap

The trap here is that candidates often confuse disabling batch processing or increasing lock duration with solving duplicate processing, but these do not address the root cause of duplicate deliveries; only session-based or duplicate detection mechanisms guarantee exactly-once processing with ordering.

How to eliminate wrong answers

Option A is wrong because disabling batch processing only processes messages one at a time but does not prevent duplicates; the trigger can still receive the same message multiple times if the lock expires or if there is a transient failure. Option C is wrong because increasing the lock duration only gives more time to process a message before the lock expires, but it does not prevent duplicate deliveries caused by other factors like receiver crashes or competing consumers. Option D is wrong because setting maxDeliveryCount to 1 will cause the message to be dead-lettered after the first failed delivery attempt, but it does not prevent duplicates from being delivered in the first place; duplicate detection requires a different mechanism like sessions or duplicate detection history.

Practice this question →
2
MCQmedium

You are developing an Azure Logic App that processes files from an FTP server. The workflow must run every 10 minutes and process only new files. You need to ensure that files are not processed more than once. What should you use?

A.Use the FTP trigger 'When a file is added' with a recurrence of 10 minutes.
B.Use the 'When a file is added' trigger and store processed file names in a SQL database.
C.Use the FTP trigger 'When a file is added or modified' with a recurrence of 10 minutes.
D.Use the Sliding Window trigger and set the window size to 10 minutes.
AnswerA

Correct. The 'When a file is added' trigger with a recurrence of 10 minutes uses built-in state management to process only new files, preventing reprocessing.

Why this answer

The 'When a file is added' FTP trigger in Azure Logic Apps automatically tracks processed files using a built-in 'trigger state' mechanism. When combined with a recurrence schedule (e.g., every 10 minutes), it ensures that only new files since the last run are processed, preventing duplicate processing without external state management.

Exam trap

The trap here is that candidates often incorrectly assume that the 'When a file is added or modified' trigger is required for deduplication, but the plain 'When a file is added' trigger already has built-in state tracking. Using 'or modified' would also process modified files, which is not desired.

How to eliminate wrong answers

Option A is wrong because the 'When a file is added' trigger does not inherently track which files have already been processed; it can reprocess files if the trigger runs again without state persistence. Option B is wrong because storing processed file names in a SQL database introduces unnecessary complexity and external dependencies; the built-in trigger state already handles deduplication. Option D is wrong because the Sliding Window trigger is designed for event-based triggers (e.g., Azure Service Bus, Event Hubs) and is not applicable to FTP triggers; it does not provide file-level deduplication.

Practice this question →
3
MCQhard

You deploy a containerized application on Azure Container Instances (ACI). The application writes data that must persist across container restarts and be accessible from multiple instances. Which volume mount should you configure?

A.Azure Files share
B.emptyDir volume
C.Azure Disk
D.ConfigMap
AnswerA

Azure Files offers SMB shares that can be mounted as volumes in ACI, persisting data independent of the container lifecycle.

Why this answer

Azure Files shares provide a fully managed SMB file share in the cloud that can be mounted as a volume in Azure Container Instances. This allows data written by the container to persist across restarts and be accessed concurrently by multiple container instances, meeting the requirements for durability and shared access.

Exam trap

The trap here is confusing Azure Disk (which is block storage with ReadWriteOnce semantics) with Azure Files (which is file storage with ReadWriteMany semantics), leading candidates to choose Azure Disk for persistence without considering multi-instance access requirements.

How to eliminate wrong answers

Option B is wrong because an emptyDir volume is ephemeral and tied to the lifecycle of a pod; data is lost when the container restarts and cannot be shared across multiple instances. Option C is wrong because Azure Disk supports ReadWriteOnce access mode, meaning it can only be mounted by a single container instance at a time, not multiple instances concurrently. Option D is wrong because a ConfigMap is designed for injecting configuration data (e.g., environment variables, files) into containers, not for persistent storage of application data.

Practice this question →
4
Multi-Selecteasy

You are developing an Azure App Service web app that must authenticate users via Microsoft Entra ID. Which TWO components are required to set up authentication?

Select 2 answers
A.A managed identity
B.Client ID and Client Secret
C.An App Registration in Microsoft Entra ID
D.An Azure AD B2C tenant
E.Azure Front Door
AnswersB, C

A Client ID, also known as the Application ID, uniquely identifies the application within Microsoft Entra ID, while a Client Secret is a confidential credential (like a password or certificate) used by confidential client applications, such as web apps, to prove their identity. These two components are fundamental in OAuth 2.0 flows, enabling the application to securely acquire access tokens and ID tokens from Microsoft Entra ID for user authentication and authorization.

Why this answer

To authenticate users via Microsoft Entra ID in an Azure App Service web app, you must register the app in Entra ID (Option C) to establish an identity and configure authentication. The Client ID and Client Secret (Option B) are then used as credentials in the OAuth 2.0 authorization code flow to verify the app's identity and obtain tokens. These two components are mandatory for the standard OpenID Connect authentication flow.

Exam trap

The trap here is that candidates often confuse managed identities (used for Azure resource-to-resource authentication) with the credentials needed for user authentication, leading them to select Option A instead of the correct Client ID and Secret.

Practice this question →
5
MCQhard

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

A.Store the ACR admin password in every deployment manifest
B.Attach the ACR to AKS or grant the kubelet managed identity AcrPull
C.Make the container registry public
D.Use an App Service deployment slot
AnswerB

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

Why this answer

Attaching an ACR to an AKS cluster or granting the kubelet managed identity the AcrPull role eliminates the need to store registry passwords in Kubernetes secrets. This leverages Azure AD managed identities for secure, password-less authentication, where the AKS cluster's kubelet uses its managed identity to authenticate with ACR via Azure Resource Manager tokens. The AcrPull role assignment authorizes the identity to pull images, ensuring credentials are never exposed in manifests or secrets.

Exam trap

The trap here is that candidates may think storing credentials in Kubernetes secrets (option A) is acceptable, but the question explicitly forbids that, and they might overlook the managed identity integration as the secure, password-less alternative.

How to eliminate wrong answers

Option A is wrong because storing the ACR admin password in every deployment manifest violates security best practices by exposing static credentials in plaintext, and it requires manual rotation of passwords across all manifests. Option C is wrong because making the container registry public exposes all images to the internet without authentication, creating a severe security vulnerability and violating least-privilege principles. Option D is wrong because App Service deployment slots are a feature for staging and swapping deployments in Azure App Service, not for authenticating to ACR from AKS; they have no relevance to Kubernetes image pull authentication.

Practice this question →
6
Drag & Dropmedium

Arrange the steps to implement Azure Functions with a Cosmos DB trigger 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

First create Cosmos DB, then Function App, add trigger binding, write code, test.

Practice this question →
7
MCQmedium

You develop an Azure Function app that processes orders. The function must write order status updates to a database. You need to ensure that if the function fails after writing to the database, the order is not lost and can be retried. Which pattern should you implement?

A.Use a Durable Functions orchestration
B.Use a retry policy in the function code
C.Enable function-level exception handling
D.Use an Azure Storage Queue for the function input
AnswerA

Durable Functions orchestrations are specifically designed for stateful workflows, allowing you to define a reliable sequence of operations that can span multiple function invocations and external system interactions. The orchestrator function maintains its state, automatically retries failed activity functions, and can implement complex compensation logic to ensure the entire order processing workflow completes atomically or achieves eventual consistency, even across failures and reboots. This provides robust error handling and guarantees the overall process state.

Why this answer

Durable Functions orchestrations provide built-in support for reliable execution and automatic retry on failure. By using an orchestration, you can write the order status to the database as an activity function, and if the function fails after the write, the orchestration can replay from the last checkpoint, ensuring the order is not lost and can be retried without duplicating the write.

Exam trap

The trap here is that candidates often confuse a simple retry policy (Option B) with the durable checkpointing and replay mechanism, not realizing that a retry policy alone cannot prevent duplicate writes or recover from failures that occur after a side effect has been committed.

How to eliminate wrong answers

Option B is wrong because a retry policy in the function code only retries the current invocation; if the failure occurs after the database write, the retry would re-execute the entire function, potentially causing duplicate writes or inconsistent state. Option C is wrong because enabling function-level exception handling merely catches errors but does not provide a mechanism to replay or retry the operation from a known safe point, so the order could be lost if the function fails after the database write. Option D is wrong because using an Azure Storage Queue for input only decouples the trigger but does not inherently provide checkpointing or replay capabilities; the function would still need to manage its own retry and idempotency logic to avoid losing the order.

Practice this question →
8
Multi-Selecthard

You are designing a serverless application using Azure Functions that needs to read from an Azure Storage Blob, process the data, and write to Azure Cosmos DB. Which THREE bindings are required?

Select 3 answers
A.HTTP trigger
B.Cosmos DB input binding
C.Blob input binding
D.Cosmos DB output binding
E.Timer trigger
AnswersA, C, D

An HTTP trigger allows an Azure Function to be invoked directly by an HTTP request, making it ideal for creating API endpoints, webhooks, or responding to direct user interactions. It provides a unique URL that external clients can call, passing data in the request body or query parameters to initiate the function's execution. This mechanism is fundamental for building responsive, on-demand serverless applications that react to external events.

Why this answer

The HTTP trigger is correct because the question describes a serverless application that needs to be invoked to read from Blob Storage, process data, and write to Cosmos DB. An HTTP trigger allows the function to be started via an HTTP request, which is the typical entry point for such event-driven processing. Without a trigger, the function cannot execute; the HTTP trigger provides the necessary invocation mechanism.

Exam trap

The trap here is that candidates often confuse input bindings with output bindings, mistakenly thinking a Cosmos DB input binding is needed to read data, when in fact the data source is Blob Storage and only an output binding to Cosmos DB is required.

Practice this question →
9
MCQeasy

You are building a serverless API using Azure Functions. The API must authenticate requests using Microsoft Entra ID. You need to restrict access to users from a specific Microsoft Entra tenant only. What should you configure in the function app?

A.Set the 'Allowed Token Audiences' to the application ID.
B.Enable 'Require Authentication' and set the action to 'Login with Microsoft Entra ID'.
C.Set the 'Client ID' to the application ID.
D.Set the 'Issuer URL' to the specific tenant's endpoint.
AnswerD

Setting the 'Issuer URL' to the specific tenant's endpoint is the correct method for restricting access to a single Microsoft Entra ID tenant. The 'iss' (issuer) claim in a JWT identifies the security token service (STS) that issued the token. By configuring the Azure Function's authentication settings to validate against a specific tenant's issuer URL (e.g., `https://login.microsoftonline.com/<tenant-id>/v2.0`), the function will only accept tokens originating from that precise tenant, effectively enforcing tenant-specific access control.

Why this answer

Setting the 'Issuer URL' to the specific tenant's endpoint (e.g., https://login.microsoftonline.com/{tenant-id}/v2.0) tells Azure Functions to validate that the token was issued by that exact tenant. This restricts access to users from that tenant only, as tokens from other tenants will fail issuer validation.

Exam trap

The trap here is that candidates confuse 'Client ID' (which identifies the app) or 'Allowed Token Audiences' (which validates the audience) with tenant restriction, but only the Issuer URL enforces which tenant's tokens are accepted.

How to eliminate wrong answers

Option A is wrong because 'Allowed Token Audiences' validates that the token is intended for your application (audience claim), not the tenant; it does not restrict which tenant issued the token. Option B is wrong because enabling 'Require Authentication' with 'Login with Microsoft Entra ID' simply enforces authentication but does not restrict to a specific tenant; it allows any Microsoft Entra ID tenant by default. Option C is wrong because setting the 'Client ID' identifies your application to the identity provider, but does not enforce tenant restriction; it is used for audience validation, not issuer validation.

Practice this question →
10
MCQmedium

You have an Azure Function app that uses a Service Bus queue trigger. The function processes messages, but sometimes it takes longer than 5 minutes to process a single message. You notice that the message is processed multiple times. What is the most likely cause?

A.The function's timeout is set to 5 minutes
B.The lock duration on the queue is shorter than the processing time
C.The maxDeliveryCount is set too high
D.The queue has sessions enabled
AnswerB

When the lock duration configured on the Service Bus queue is shorter than the actual time required for the Azure Function to fully process a message, the message's lock will expire prematurely. Upon expiration, the Service Bus makes the message available again to other consumers, even if the original function instance is still actively working on it. This scenario directly leads to duplicate processing, as another function instance or consumer can pick up and process the same message while the first attempt is still underway, resulting in redundant operations.

Why this answer

The most likely cause is that the lock duration on the Service Bus queue is shorter than the time required to process the message. When the lock expires, the message becomes visible to other consumers (or the same consumer on retry), causing it to be processed multiple times. The default lock duration for a Service Bus queue is 30 seconds, and if processing exceeds that, the message will be re-delivered.

Exam trap

The trap here is that candidates often confuse the function's timeout setting (which terminates the function) with the Service Bus lock duration (which controls message visibility), leading them to incorrectly select option A.

How to eliminate wrong answers

Option A is wrong because the function's timeout (default 5 minutes for the Consumption plan) controls how long the function can run before being terminated, but it does not directly cause duplicate processing; the message would still be locked during that time. Option C is wrong because maxDeliveryCount controls how many times a message can be delivered before being moved to the dead-letter queue, not the frequency of duplicate processing due to lock expiration. Option D is wrong because enabling sessions does not cause duplicate processing; sessions are used for message ordering and grouping, and they actually extend the lock duration automatically until the session is completed.

Practice this question →
11
MCQhard

You are designing a solution that uses Azure Functions to process events from Azure Event Hubs. The function must process events in order and exactly once per partition. What should you do?

A.Enable session state in the function app.
B.Use a Service Bus queue trigger with a singleton lock.
C.Disable checkpointing to ensure no duplicates.
D.Use the Event Hubs trigger for Azure Functions with default configuration.
AnswerD

The Azure Functions Event Hubs trigger, with its default configuration, is the ideal choice for processing Event Hubs events reliably and in order. It automatically handles partition management, ensuring that events within a single Event Hub partition are processed sequentially. Furthermore, it leverages built-in checkpointing to an Azure Storage account, which tracks the progress of event processing for each partition, enabling "at-least-once" delivery and facilitating "exactly-once" processing when combined with idempotent function logic.

Why this answer

The Event Hubs trigger for Azure Functions, by default, processes events in order and exactly once per partition. It uses checkpointing to track the offset of the last successfully processed event, ensuring that each event is processed only once and in sequence within a partition. This default behavior aligns with the requirement without needing additional configuration.

Exam trap

The trap here is that candidates may think they need to manually configure session state or disable checkpointing to achieve ordering and exactly-once processing, but the default Event Hubs trigger already handles this via partition-based ordering and checkpointing.

How to eliminate wrong answers

Option A is wrong because session state is a feature of Service Bus, not Event Hubs; it enables ordered processing of messages in a session, but Event Hubs partitions inherently provide ordering without session state. Option B is wrong because a Service Bus queue trigger with a singleton lock would not process events from Event Hubs; it is designed for Service Bus queues and does not support Event Hubs partitions or checkpointing. Option C is wrong because disabling checkpointing would cause the function to reprocess events from the beginning each time, leading to duplicates and loss of ordering, which contradicts the 'exactly once' requirement.

Practice this question →
12
MCQmedium

A web app experiences intermittent high latency. You discover that the Azure SQL database is experiencing a high number of connection timeouts. The application uses Entity Framework Core with the default connection pooling settings. You need to improve database connection reliability without changing the application code. What should you do?

A.Set the Minimum Pool Size to 10 in the connection string.
B.Increase the maximum pool size in the connection string.
C.Set the Connection Lifetime to 300 seconds.
D.Enable Multipool in the connection string.
AnswerA

Intermittent high latency often indicates significant overhead associated with establishing new database connections. Setting the 'Min Pool Size' to a value like 10 ensures that at least ten connections are always kept open and ready in the connection pool, even when returned by the application. This significantly reduces the time required to acquire a connection during demand spikes, as new physical connections do not need to be created, directly mitigating latency caused by connection establishment.

Why this answer

Setting the Minimum Pool Size to 10 pre-creates a baseline of open connections in the pool, reducing the frequency of new connection creations during traffic spikes. This mitigates intermittent connection timeouts caused by the default pool starting empty and struggling to keep up with demand under high latency. Since the application uses Entity Framework Core with default pooling, this change is applied via the connection string without modifying code.

Exam trap

The trap here is that candidates often assume increasing the maximum pool size solves all connection issues, but the real problem is the delay in creating new connections from an empty pool, which is addressed by setting a minimum pool size.

How to eliminate wrong answers

Option B is wrong because increasing the maximum pool size only raises the cap on concurrent connections, but the intermittent timeouts are due to connections being created too slowly under load, not because the pool is full. Option C is wrong because setting Connection Lifetime to 300 seconds causes connections to be recycled after 5 minutes, which can actually increase churn and timeout risk during high latency, not improve reliability. Option D is wrong because 'Multipool' is not a valid connection string keyword in SQL Server or Entity Framework Core; it is a fabricated term.

Practice this question →
13
MCQmedium

You are implementing an order processing system using Azure Durable Functions. The function must send notifications to multiple channels (email, SMS, push) in parallel and wait for all to complete before sending a confirmation. Which Durable Functions feature should you utilize?

A.Orchestration trigger with fan-out/fan-in pattern
B.Entity trigger
C.Activity trigger with retry policy
D.Timer trigger
AnswerA

The Orchestration trigger with a fan-out/fan-in pattern is the ideal choice for an order processing system. This pattern allows an orchestrator function to concurrently invoke multiple activity functions (e.g., inventory check, payment processing, shipping label generation) using `Task.WhenAll` to await their collective completion. After all parallel tasks finish, the orchestrator aggregates their results before proceeding, ensuring efficient and coordinated execution of complex, multi-step workflows.

Why this answer

The fan-out/fan-in pattern in Durable Functions allows you to invoke multiple activity functions in parallel (fan-out) and then wait for all of them to complete (fan-in) using `Task.WhenAll`. This is exactly what is needed to send notifications to email, SMS, and push simultaneously and then proceed only after all have finished, making option A correct.

Exam trap

The trap here is that candidates often confuse the fan-out/fan-in pattern with simple parallel execution using Entity triggers or assume that retry policies alone can coordinate multiple channels, but only the orchestration trigger with `Task.WhenAll` provides the required synchronization barrier.

How to eliminate wrong answers

Option B is wrong because Entity triggers are designed for managing stateful entities (like counters or actors) and are not suited for orchestrating parallel task execution with a completion barrier. Option C is wrong because an Activity trigger with retry policy handles individual task retries but cannot coordinate multiple parallel activities or wait for all to finish before proceeding. Option D is wrong because Timer triggers are for scheduled or periodic execution, not for orchestrating parallel workflows with a fan-in step.

Practice this question →
14
MCQeasy

A company uses Azure Functions with a consumption plan. The function processes messages from a queue. During peak hours, the function takes longer to execute, and some messages are processed twice. What is the most likely cause?

A.The function timeout is set too low.
B.The queue message visibility timeout is shorter than the function processing time.
C.The function uses blob output binding incorrectly.
D.The function app is using a premium plan instead of consumption.
AnswerB

When the queue message visibility timeout is shorter than the actual function processing time, the message becomes visible again in the queue before the initial function instance has successfully completed its work and deleted the message. This allows another available function instance, potentially on a different host, to pick up and process the exact same message. This concurrent processing of the same message by multiple instances is the direct cause of duplicate operations.

Why this answer

In Azure Functions with a consumption plan, the queue message visibility timeout determines how long a message is invisible to other consumers after being dequeued. If the function's processing time exceeds this visibility timeout, the message becomes visible again and can be picked up by another function instance, leading to duplicate processing. This is the most likely cause of messages being processed twice during peak hours when execution times increase.

Exam trap

The trap here is that candidates often confuse the function timeout (which terminates execution) with the queue visibility timeout (which controls message re-delivery), leading them to incorrectly select option A.

How to eliminate wrong answers

Option A is wrong because the function timeout (default 5 minutes for consumption plan) controls the maximum execution duration, not message visibility; a low timeout would cause the function to fail or be terminated, not duplicate processing. Option C is wrong because incorrect blob output binding would cause errors or missing data, not duplicate message processing. Option D is wrong because a premium plan provides dedicated instances and faster execution, which would reduce the likelihood of timeouts and duplicates, not cause them.

Practice this question →
15
MCQeasy

Your company develops a multi-tenant SaaS application hosted on Azure Kubernetes Service (AKS). Each tenant has isolated compute resources. You need to ensure that no single tenant can consume all cluster resources and affect others. You also want to optimize resource utilization by packing pods efficiently. You evaluate the following approaches: A) Use namespace resource quotas per tenant and let the Kubernetes scheduler handle packing. B) Deploy each tenant to a separate AKS cluster. C) Use Azure Policy to enforce pod resource limits. D) Use a service mesh to control traffic between tenants. Which approach should you recommend?

A.Use namespace resource quotas per tenant and let the Kubernetes scheduler handle packing.
B.Use a service mesh to control traffic between tenants.
C.Use Azure Policy to enforce pod resource limits.
D.Deploy each tenant to a separate AKS cluster.
AnswerA

Using namespace resource quotas per tenant is the most effective and efficient strategy for multi-tenant SaaS applications on Kubernetes. By assigning each tenant a dedicated namespace with a ResourceQuota, you define the maximum aggregate CPU, memory, and storage resources that all pods within that tenant's namespace can consume. The Kubernetes scheduler then intelligently places pods across available nodes, optimizing resource utilization and ensuring fair sharing while preventing any single tenant from monopolizing cluster resources. This approach provides strong logical isolation and cost efficiency.

Why this answer

Namespace resource quotas per tenant provide hard limits on compute resources (CPU, memory) and object counts, preventing any single tenant from exhausting cluster resources. The Kubernetes scheduler then efficiently packs pods within those quotas, optimizing utilization without manual intervention. This approach balances isolation and resource efficiency in a multi-tenant AKS environment.

Exam trap

The trap here is that candidates confuse Azure Policy (which enforces pod-level limits) with namespace-level resource quotas, missing that quotas are the correct mechanism for tenant-level aggregate resource isolation in a shared cluster.

How to eliminate wrong answers

Option B is wrong because deploying each tenant to a separate AKS cluster increases operational complexity and cost, and does not optimize resource utilization—idle resources in one cluster cannot be shared with another. Option C is wrong because Azure Policy can enforce pod resource limits (e.g., via built-in policies like 'Kubernetes cluster containers should have CPU and memory resource limits defined'), but it does not provide tenant-level resource quotas or prevent a tenant from consuming all cluster resources across namespaces; it only ensures individual pods have limits, not aggregate tenant consumption. Option D is wrong because a service mesh (e.g., Istio, Linkerd) controls east-west traffic between services, not resource consumption or isolation; it addresses network segmentation and observability, not compute resource guarantees.

Practice this question →
16
MCQmedium

You are developing a solution that uses Azure Container Registry (ACR) to store Docker images. You need to ensure that only authorized users can deploy images from ACR to an AKS cluster. What should you do?

A.Configure AKS RBAC to limit image pull permissions.
B.Use Kubernetes secrets to store ACR credentials.
C.Use the AKS cluster's managed identity with AcrPull role assignment.
D.Enable the admin account on ACR and use the credentials in AKS.
AnswerC

Managed identity provides secure access without secrets.

Why this answer

Using an AKS cluster's managed identity with the AcrPull role assignment enables secure, password-less authentication to ACR. Option A is incorrect because AKS RBAC controls Kubernetes resources, not ACR permissions. Option B is incorrect because storing ACR credentials as Kubernetes secrets is less secure and requires manual management.

Option D is incorrect because enabling the admin account on ACR is a shared credential approach that is not recommended for production.

Practice this question →
17
MCQhard

Your company is migrating a legacy on-premises .NET Framework 4.7.2 web application to Azure. The application uses session state stored in-memory and reads/writes to a local SQL Server database. The migration must minimize code changes, support auto-scaling, and handle session state across multiple instances. You plan to use Azure App Service with Windows OS. You need to recommend a solution for session state storage and database connectivity. Which option should you choose?

A.Use Azure Cache for Redis as the session state provider via the RedisSessionStateProvider NuGet package, and configure the database connection string in Azure App Service App Settings.
B.Store session state in Azure Table Storage using a custom session state provider, and use a connection string for Azure SQL Database.
C.Configure session state using Azure SQL Database with a session state database, and update the connection string in web.config.
D.Use App Service's built-in session state with ARR affinity and connect to Azure SQL Database using Managed Identity.
AnswerA

Azure Cache for Redis provides a highly performant, scalable, and distributed cache solution ideal for managing session state in cloud environments. The `RedisSessionStateProvider` NuGet package integrates seamlessly with existing ASP.NET applications, requiring minimal code changes to leverage this robust backend. Configuring the connection string in Azure App Service App Settings ensures secure management, easy updates without redeploying, and supports auto-scaling effectively by centralizing session data.

Why this answer

Azure Cache for Redis provides a distributed, in-memory session state provider that supports session state sharing across multiple App Service instances without requiring code changes to the application logic. The RedisSessionStateProvider NuGet package is a drop-in replacement for the default in-memory provider, and configuring the database connection string in App Settings allows you to change the target without modifying web.config, minimizing migration effort.

Exam trap

The trap here is that candidates often confuse ARR affinity with a valid session state solution, not realizing that it prevents horizontal scaling by forcing requests to a single instance, which contradicts the auto-scaling requirement.

How to eliminate wrong answers

Option B is wrong because Azure Table Storage is a NoSQL key-value store that does not natively support session state expiration or locking, and implementing a custom provider would require significant code changes, contradicting the requirement to minimize code changes. Option C is wrong because using Azure SQL Database for session state introduces higher latency and cost compared to an in-memory cache, and it requires updating web.config rather than using App Settings, which is less flexible for auto-scaling scenarios. Option D is wrong because ARR affinity (sticky sessions) prevents true auto-scaling by pinning a user to a specific instance, and while Managed Identity is good for database connectivity, it does not solve the session state sharing problem across instances.

Practice this question →
18
Multi-Selecteasy

Your company is migrating a monolithic application to Azure. The application consists of several components that need to be deployed and scaled independently. You need to design a container orchestration solution. Which TWO services should you consider?

Select 2 answers
A.Azure Container Instances
B.Azure Container Apps
C.Azure Batch
D.Azure Service Fabric
E.Azure Kubernetes Service (AKS)
AnswersB, E

Azure Container Apps is an excellent choice for migrating monolithic applications to a microservices architecture, offering a serverless platform for running containerized applications. It provides built-in capabilities for HTTP/HTTPS ingress, event-driven scaling, and Dapr integration, simplifying the deployment and management of microservices without the operational overhead of a full Kubernetes cluster. Its focus on independent scaling and revision management makes it ideal for modern application patterns.

Why this answer

Azure Container Apps (B) is correct because it provides a serverless container orchestration platform that allows you to deploy and scale microservices independently without managing the underlying Kubernetes infrastructure. It supports event-driven scaling, revision management, and split traffic routing, making it ideal for migrating monolithic applications to a microservices architecture with minimal operational overhead.

Exam trap

The trap here is that candidates often confuse Azure Container Instances (ACI) with a full orchestration solution, but ACI lacks the multi-container scaling and service discovery features required for independent component deployment, while Azure Kubernetes Service (AKS) is the correct choice for full control over Kubernetes, and Container Apps offers a managed abstraction layer.

Practice this question →
19
MCQmedium

You are deploying a containerized application to Azure Container Instances. The container image is stored in a private Azure Container Registry (ACR). You need to ensure that ACI can pull the image without storing credentials in the container group definition. What should you use?

A.Enable managed identity for the container group and assign the AcrPull role.
B.Generate a SAS token for the ACR and use it in the image registry credential.
C.Create a service principal with AcrPull role and pass its credentials.
D.Use the ACR admin account and provide the credentials in the container group.
AnswerA

Enabling a managed identity for the Azure Container Instance (ACI) container group provides an Azure Active Directory identity that the ACI can use to authenticate. By assigning the AcrPull role to this managed identity on the Azure Container Registry (ACR), ACI can securely pull images without requiring any explicit credentials to be stored or managed within the container group definition. This eliminates the risk of credential exposure and simplifies credential rotation, adhering to the principle of least privilege.

Why this answer

Enabling a managed identity for the container group and assigning the AcrPull role allows Azure Container Instances to authenticate to Azure Container Registry using Azure AD without storing any credentials in the container group definition. The managed identity is automatically authenticated by Azure, and ACR supports token exchange via Azure AD, so ACI can pull the image securely without embedding secrets.

Exam trap

The trap here is that candidates often confuse SAS tokens (which are for Azure Storage) with ACR authentication, or they assume that a service principal is acceptable even though it requires embedding credentials, missing the managed identity option that eliminates credential storage entirely.

How to eliminate wrong answers

Option B is wrong because SAS tokens are used for delegated access to Azure Storage (blobs, files, queues, tables), not for authenticating to Azure Container Registry; ACR does not support SAS tokens for image pull operations. Option C is wrong because while a service principal with AcrPull role can authenticate to ACR, it requires passing the service principal's credentials (client ID and secret) in the container group definition, which violates the requirement of not storing credentials. Option D is wrong because using the ACR admin account requires providing the admin username and password directly in the container group definition, which stores credentials in the deployment artifact and is a security anti-pattern.

Practice this question →
20
Multi-Selecthard

An Azure Functions document rendering job 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.Make the handler idempotent
C.Disable retries for all messages
D.Store connection strings in source code
AnswersA, B

Using dead-letter handling is a critical practice for robust message processing in Azure Functions. When a message repeatedly fails to process after a configured number of retries, perhaps due to malformed data or an unrecoverable external dependency issue, it should be moved to a dead-letter queue. This prevents "poison messages" from endlessly blocking the main queue and allows for subsequent manual inspection, debugging, or automated reprocessing logic without losing the message entirely.

Why this answer

Azure Functions can use dead-letter queues (DLQ) to isolate messages that repeatedly fail processing, preventing them from blocking the queue and allowing investigation without data loss. Option B is correct because making the handler idempotent ensures that if a message is retried after a partial failure (e.g., the function crashes mid-execution), reprocessing the same message does not cause duplicate or inconsistent state, which is critical for correctness in a Service Bus triggered function.

Exam trap

The trap here is that candidates may think disabling retries (Option C) prevents duplicate processing, but they overlook that retries are essential for transient fault tolerance, and the correct approach is to combine idempotency with dead-letter handling for permanent failures.

Practice this question →
21
MCQhard

You are reviewing the ARM template for an App Service. What is the effect of the 'alwaysOn' property set to true?

A.The app will enable health checks at /health.
B.The app will scale out to multiple instances automatically.
C.The app will stay loaded in memory to avoid cold starts.
D.The app will be redeployed whenever the code changes.
AnswerC

When `alwaysOn` is enabled for an Azure App Service, the platform sends periodic internal requests to the application to ensure it remains active and loaded in memory. This crucial setting prevents the application from being idled out and unloaded, which is particularly beneficial for applications that experience infrequent traffic or require immediate responsiveness. By keeping the app loaded, it effectively eliminates "cold starts," where the application would otherwise incur significant latency while restarting and initializing resources upon the first request after a period of inactivity.

Why this answer

Setting 'alwaysOn' to true in an Azure App Service ARM template ensures that the app is kept loaded in memory even when there is no incoming traffic. This prevents the app from being unloaded after a period of inactivity, which eliminates cold starts on subsequent requests. Cold starts occur when the app process is recycled or unloaded, causing a delay as the runtime and application code are reloaded.

Exam trap

The trap here is that candidates may confuse 'alwaysOn' with health checks or scaling features, as the name suggests constant availability, but it specifically addresses process idle behavior, not load balancing or monitoring.

How to eliminate wrong answers

Option A is wrong because health checks are configured separately via the 'healthCheckPath' property in the site config, not by the 'alwaysOn' property. Option B is wrong because automatic scaling is controlled by autoscale rules or scaling settings, not by the 'alwaysOn' property which only affects the app's in-memory state. Option D is wrong because redeployment on code changes is handled by deployment slots, continuous deployment pipelines, or triggers like webhooks, not by the 'alwaysOn' property.

Practice this question →
22
MCQhard

You are creating an Azure Container Instance using the Azure CLI command shown in the exhibit. The container needs to connect to a SQL database. After running the command, you notice that the DB_PASSWORD environment variable is visible in the container's logs. What is the most likely reason?

A.The --secure-environment-variables flag is misspelled.
B.The --secure-environment-variables flag is not supported for ACI.
C.The DB_PASSWORD value contains special characters that were not escaped.
D.The container image logs environment variables at startup, exposing the secure variable.
AnswerD

Although the `--secure-environment-variables` flag prevents the `DB_PASSWORD` from being visible in the Azure portal, Azure CLI output, or platform-generated logs, it does not prevent the application *running inside the container* from accessing and subsequently logging that variable. If the container's startup script or application code is configured to print all environment variables or specifically the `DB_PASSWORD` to `stdout` or `stderr`, this sensitive information will then appear in the container's application logs, effectively circumventing the platform's security measure. This scenario represents a common vulnerability where application-level logging exposes data that was securely injected.

Why this answer

The `--secure-environment-variables` flag in Azure CLI for Azure Container Instances does not prevent the values from being logged by the container itself. The flag only masks the values in the Azure portal and CLI output, but if the container image explicitly logs environment variables at startup (e.g., via a startup script or application code), the secure variable will be exposed in the container logs. The issue is not with Azure's handling but with the container image's behavior.

Exam trap

The trap here is that candidates assume `--secure-environment-variables` fully protects the variable from any exposure, but it only masks it in Azure's management plane, not from the container's own logging or process environment.

How to eliminate wrong answers

Option A is wrong because the correct flag is `--secure-environment-variables` (with a hyphen), and the exhibit shows it spelled correctly; a misspelling would cause a CLI parsing error, not silent exposure in logs. Option B is wrong because `--secure-environment-variables` is indeed supported for ACI (since API version 2018-10-01) and correctly masks values in Azure CLI output and portal. Option C is wrong because special characters in environment variable values require proper escaping in the shell command, but this would cause a syntax error or incorrect value assignment, not exposure in logs after successful deployment.

Practice this question →
23
MCQmedium

Your organization runs a critical e-commerce application on Azure App Service. The application uses a Standard App Service plan with three instances. During a flash sale, traffic spikes cause some requests to fail with HTTP 503 errors. The operations team reports that the app's CPU usage reaches 95% during spikes. You need to ensure the application remains responsive without manual intervention. The solution must minimize cost while handling unpredictable traffic patterns. You evaluate the following options: A) Enable autoscale to scale out based on CPU usage threshold of 70%, with a maximum of 10 instances. B) Change the App Service plan to Premium v3 and enable zone redundancy. C) Implement a queue-based load leveling pattern using Azure Queue Storage and a background process. D) Use Azure Front Door with a Web Application Firewall (WAF) policy to distribute traffic. Which option should you recommend?

A.Use Azure Front Door with a Web Application Firewall (WAF) policy to distribute traffic.
B.Enable autoscale to scale out based on CPU usage threshold of 70%, with a maximum of 10 instances.
C.Implement a queue-based load leveling pattern using Azure Queue Storage and a background process.
D.Change the App Service plan to Premium v3 and enable zone redundancy.
AnswerB

Enabling autoscale directly addresses the need for dynamic compute capacity by automatically adding or removing instances based on defined metrics. Setting a CPU usage threshold of 70% ensures that new instances are provisioned proactively when demand increases, while the maximum of 10 instances prevents unbounded scaling. This approach effectively handles traffic spikes by scaling out horizontally, optimizing both performance and cost efficiency.

Why this answer

Enabling autoscale on the Standard App Service plan allows the application to automatically scale out from 3 to up to 10 instances when CPU exceeds 70%, handling traffic spikes without manual intervention. This minimizes cost by only adding instances when needed, and the Standard plan supports autoscale natively, making it the most cost-effective solution for unpredictable traffic patterns.

Exam trap

The trap here is that candidates often confuse traffic distribution solutions (like Azure Front Door) with scaling solutions, or assume that upgrading the plan is necessary for high availability, when autoscale on the existing Standard plan is the most cost-effective and direct fix for CPU-driven 503 errors.

How to eliminate wrong answers

Option A is wrong because Azure Front Door with WAF is a global load balancer and security layer that distributes traffic across endpoints but does not scale the underlying App Service instances; it would not resolve CPU saturation causing 503 errors. Option C is wrong because a queue-based load leveling pattern decouples request processing but introduces latency and complexity for a synchronous e-commerce application where users expect immediate responses, and it does not directly address CPU spikes on the web tier. Option D is wrong because changing to Premium v3 and enabling zone redundancy improves availability and performance but significantly increases cost and does not provide dynamic scaling based on CPU usage; it is overprovisioning for unpredictable spikes.

Practice this question →
24
MCQeasy

You need to deploy a container that runs a simple web server on Azure Container Instances. The container should be accessible via a public IP address. Which property should you set in the container group configuration?

A.ipAddress.type = "Public"
B.osType = "Linux"
C.restartPolicy = "Always"
D.volumes.mountPath = "/mnt"
AnswerA

To deploy a container running a simple web server that is accessible from the internet, a public IP address is essential. Setting the `ipAddress.type` property to "Public" in the Azure Container Instances (ACI) deployment configuration explicitly requests and ensures that the container group receives a publicly routable IP address. This configuration allows external clients to connect to the web server running within the container via its exposed port, making it externally accessible.

Why this answer

To make a container group accessible from the internet via a public IP address, you must set the `ipAddress.type` property to `"Public"`. This instructs Azure Container Instances to assign a public IP and optionally a fully qualified domain name (FQDN) to the container group, allowing inbound traffic from the internet to reach the container's exposed ports.

Exam trap

The trap here is that candidates often confuse operational settings like OS type or restart policy with networking configuration, mistakenly thinking they influence public accessibility, when in fact only the `ipAddress.type` property controls public IP assignment in Azure Container Instances.

How to eliminate wrong answers

Option B is wrong because `osType` (e.g., "Linux" or "Windows") determines the underlying operating system for the container, not its network accessibility; a public IP can be assigned regardless of the OS type. Option C is wrong because `restartPolicy` (e.g., "Always") controls whether the container restarts after it exits, not its network exposure; it does not affect public IP assignment. Option D is wrong because `volumes.mountPath` specifies where a volume is mounted inside the container for persistent storage, which has no bearing on making the container publicly reachable.

Practice this question →
25
MCQmedium

An Azure Functions image resize worker must run for up to 30 minutes and uses a VNet integration feature. The team wants serverless scaling without managing virtual machines. Which hosting plan should be used? The design must avoid adding custom operational scripts.

A.App Service Free tier
B.Premium plan
C.Azure Batch pool
D.Consumption plan
AnswerB

The Azure Functions Premium plan is specifically engineered for production workloads requiring enhanced capabilities, including robust virtual network integration for secure access to resources. It supports significantly longer execution durations, with a default timeout of 60 minutes configurable to unlimited, and utilizes pre-warmed instances to eliminate cold starts, ensuring consistent low-latency performance for tasks like image resizing.

Why this answer

The Premium plan is correct because it supports VNet integration, allows execution durations up to 30 minutes (unlike the Consumption plan's 10-minute default), and provides serverless scaling without requiring you to manage virtual machines or add custom operational scripts. It is the only plan that combines these capabilities for a long-running, VNet-connected function.

Exam trap

The trap here is that candidates often assume the Consumption plan is the only serverless option, forgetting that the Premium plan also provides serverless scaling with additional features like VNet integration and extended execution duration.

How to eliminate wrong answers

Option A is wrong because the App Service Free tier does not support VNet integration and has strict resource limits (e.g., 1 GB memory, 60 minutes of CPU per day) that cannot sustain a 30-minute image resize worker. Option C is wrong because Azure Batch requires you to manage a pool of virtual machines or use a job scheduler, which adds operational scripts and contradicts the requirement to avoid managing VMs. Option D is wrong because the Consumption plan has a maximum execution timeout of 10 minutes (configurable up to 10 minutes by default) and does not support VNet integration without a dedicated plan.

Practice this question →
26
MCQmedium

You are deploying a containerized application to Azure Container Instances (ACI). The application requires a connection string to an Azure SQL Database. The connection string contains a password that is stored as a secret in Azure Key Vault. The container image expects to read the connection string from an environment variable named SQL_CONNECTION_STRING. You want to pass the secret securely without embedding it in the YAML deployment file and without modifying the container image. The ACI container group will use a system-assigned managed identity that has access to the Key Vault secret. Which approach should you use?

A.Mount a volume from Azure Files containing the connection string
B.Use a secure environment variable with a Key Vault reference syntax (e.g., secret://myvault/secretname)
C.Use the managed identity inside the container to call the Key Vault SDK and retrieve the secret
D.Store the connection string as an environment variable in ACI configuration but mark it as secure
AnswerB

Using a secure environment variable with a Key Vault reference syntax (e.g., secret://myvault/secretname) is the recommended and most secure approach for ACI. Azure Container Instances natively supports resolving these references at runtime. When an ACI container group is configured with a managed identity and appropriate access policies to Azure Key Vault, the ACI platform intercepts this special syntax, uses its managed identity to fetch the secret from Key Vault, and then injects the actual secret value as an environment variable into the container *before* the application starts. This ensures the secret never appears in the deployment definition or container image, adhering to security best practices and requiring no application code changes.

Why this answer

Azure Container Instances supports Key Vault references in environment variables using the `secret://` syntax, which allows you to securely inject secrets into containers at runtime without exposing them in the deployment YAML. The system-assigned managed identity is automatically used by the ACI infrastructure to authenticate to Key Vault and retrieve the secret, so no code changes to the container image are required.

Exam trap

The trap here is that candidates often assume they must write code inside the container to use the managed identity with the Key Vault SDK, but ACI provides a built-in mechanism to inject secrets as environment variables without any code changes.

How to eliminate wrong answers

Option A is wrong because mounting a volume from Azure Files would require the connection string to be stored in a file, which still exposes the secret in the storage account and does not leverage Key Vault for secret management. Option C is wrong because using the managed identity inside the container to call the Key Vault SDK would require modifying the container image to include code for secret retrieval, which violates the requirement of not modifying the image. Option D is wrong because marking an environment variable as 'secure' in ACI only hides its value in the Azure portal and logs, but the secret is still embedded in the deployment configuration and can be retrieved by anyone with access to the resource definition.

Practice this question →
27
MCQeasy

You deploy a containerized application to Azure Container Instances (ACI). The application needs to store configuration settings that might change at runtime. You need to update the configuration without redeploying the container. What should you do?

A.Use environment variables in the container group
B.Mount an Azure Files share and update the configuration file
C.Use Application Settings in the container
D.Modify the container image to include new configuration
AnswerB

While Azure Container Instances supports mounting Azure Files shares as volumes, simply updating a configuration file on the mounted share does not automatically trigger a configuration refresh within the running container. The application inside the container would need to implement specific logic to continuously monitor the file for changes or be restarted to re-read the updated configuration. This method introduces additional complexity and does not provide a truly dynamic, out-of-the-box configuration update mechanism for ACI.

Why this answer

To update configuration settings at runtime without redeploying the container in Azure Container Instances (ACI), you should mount an Azure Files share. The application can read its configuration from a file stored on this share. When configuration changes are needed, you can update the file directly on the Azure Files share.

The container itself does not need to be redeployed or restarted, provided the application is designed to periodically re-read the configuration file or react to file changes. This approach allows for dynamic configuration updates independent of the container lifecycle.

Exam trap

The trap here is that candidates confuse Azure Container Instances with Azure App Service, mistakenly selecting 'Application Settings' (Option C) which is an App Service feature, not available in ACI.

How to eliminate wrong answers

Option B is wrong because mounting an Azure Files share and updating a configuration file requires the application to watch for file changes and reload configuration, which adds complexity and is not a built-in ACI feature for runtime updates without redeployment. Option C is wrong because 'Application Settings' is an Azure App Service concept, not applicable to Azure Container Instances; ACI does not have an Application Settings blade. Option D is wrong because modifying the container image to include new configuration requires rebuilding, pushing to a registry, and redeploying the container group, which contradicts the requirement to avoid redeployment.

Practice this question →
28
MCQmedium

An Azure Functions IoT command API must run for up to 30 minutes and uses a VNet integration feature. The team wants serverless scaling without managing virtual machines. Which hosting plan should be used?

A.Azure Batch pool
B.Consumption plan
C.App Service Free tier
D.Premium plan
AnswerD

The Premium plan supports longer execution duration, VNet integration, pre-warmed instances, and serverless scale.

Why this answer

The Premium plan (Elastic Premium EP) is the correct choice because it supports VNet integration for accessing resources inside a virtual network, allows execution durations up to 30 minutes (the Consumption plan caps at 10 minutes by default), and provides serverless scaling without requiring you to manage virtual machines. This plan also offers always-ready instances to reduce cold start latency, which is critical for IoT command APIs.

Exam trap

The trap here is that candidates often assume the Consumption plan supports VNet integration and long timeouts because it is the default serverless option, but they overlook the explicit 10-minute timeout limit and the lack of native VNet integration without a dedicated gateway.

How to eliminate wrong answers

Option A is wrong because Azure Batch pool is designed for large-scale parallel and high-performance computing jobs, not for hosting a single long-running API with serverless scaling, and it requires managing virtual machine pools. Option B is wrong because the Consumption plan has a maximum execution timeout of 10 minutes (configurable up to 10 minutes) and does not support VNet integration for outbound traffic without additional configuration like a VNet NAT gateway, making it unsuitable for a 30-minute API. Option C is wrong because the App Service Free tier does not support VNet integration, has a 60-second request timeout, and lacks serverless scaling (it runs on shared, fixed-capacity VMs).

Practice this question →
29
MCQmedium

You find the above ARM template for an App Service. What is a security concern with this configuration?

A.The connection string is stored in the source code.
B.The password is passed as a parameter and may be exposed in deployment logs.
C.The connection string type should be 'Custom' instead of 'SQLAzure'.
D.The connection string is not encrypted at rest.
AnswerB

This statement is correct because while ARM templates support `securestring` parameters to prevent values from being displayed in the Azure portal after deployment, the actual parameter value can still be captured and exposed in deployment logs during the execution phase. This risk is particularly relevant in CI/CD pipelines or if the parameter is used in a way that triggers logging of its content. For true secret management, integrating with Azure Key Vault is the recommended secure approach.

Why this answer

When a password is passed as an ARM template parameter, its value can be captured in deployment logs (e.g., Azure Activity Logs or PowerShell verbose output) if the parameter is not marked as 'secureString'. This exposes sensitive credentials to anyone with log access, violating security best practices. In contrast, using a secureString parameter encrypts the value and masks it in logs.

Exam trap

The trap here is that candidates focus on the connection string being in the template (Option A) or its type (Option C), but the real security issue is the plaintext parameter exposure in deployment logs, which is a common oversight in ARM template security.

How to eliminate wrong answers

Option A is wrong because the connection string is not stored in source code; it is defined in the ARM template and deployed as a resource property, which is a standard practice. Option C is wrong because 'SQLAzure' is a valid connection string type for Azure SQL Database, and changing it to 'Custom' would not address security concerns. Option D is wrong because connection strings in App Service are encrypted at rest by default using Azure platform-managed keys; the concern is about exposure during deployment, not at rest.

Practice this question →
30
MCQhard

You are designing a solution that uses Azure Container Instances (ACI) to run a batch job that processes images. The job is triggered by a message in Azure Queue Storage. Each image takes about 5 minutes to process. You need to ensure that the container runs only when there are messages in the queue and scales automatically. What should you use?

A.Use Azure Logic Apps with a Container Instances connector.
B.Use Azure Functions with a custom container and queue trigger.
C.Use Azure Batch to process the images in a pool of VMs.
D.Deploy the image processing job as a pod in Azure Kubernetes Service.
AnswerA

Azure Logic Apps provide a robust, serverless workflow engine perfectly suited for event-driven scenarios, such as processing messages from a queue. Its native Azure Container Instances (ACI) connector enables the dynamic creation and execution of a new container instance for each incoming queue message. This design ensures true 'from zero' scaling, where compute resources are provisioned only when needed and deallocated immediately after the containerized task completes, optimizing cost and operational overhead for sporadic batch jobs.

Why this answer

Azure Logic Apps provides a serverless workflow that can be triggered by a queue message (via the Azure Queue Storage connector) and then use the Container Instances connector to start a container group. This ensures the container runs only when messages are present and scales automatically by creating a new container instance per message, matching the requirement for event-driven, on-demand execution without idle costs.

Exam trap

The trap here is that candidates often assume Azure Functions is the only serverless option for queue-triggered workloads, overlooking that Logic Apps can directly orchestrate ACI creation without writing custom code, which is simpler and more aligned with the requirement to 'run the container only when there are messages'.

How to eliminate wrong answers

Option B is wrong because Azure Functions with a custom container and queue trigger runs the function code inside the container, but it does not directly orchestrate the creation of a separate ACI container for each batch job; the function would need to manage ACI lifecycle manually, adding complexity and not leveraging ACI's native scaling. Option C is wrong because Azure Batch is designed for large-scale parallel batch processing with a pool of VMs, which is overkill for a simple queue-triggered job and introduces unnecessary overhead for managing a VM pool. Option D is wrong because Azure Kubernetes Service (AKS) is a full orchestration platform for containerized applications, requiring cluster management and scaling configuration, which is excessive for a single batch job that should run only on demand; it does not natively integrate with Azure Queue Storage triggers without additional components like KEDA.

Practice this question →
31
MCQeasy

You are deploying a containerized application using Azure Kubernetes Service (AKS). You need to ensure that sensitive configuration data, such as API keys, is not stored in container images. Which Kubernetes resource should you use?

A.Deployment
B.ConfigMap
C.PersistentVolume
D.Secret
AnswerD

A Kubernetes Secret object is specifically engineered to store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys, within the cluster. Secrets provide a more secure mechanism for injecting this data into pods compared to plain text in ConfigMaps or direct pod definitions. They can be mounted as data volumes or exposed as environment variables, with Kubernetes handling base64 encoding and offering integration with external secret management systems for enhanced security.

Why this answer

Kubernetes Secrets are specifically designed to store sensitive data like API keys, connection strings, and passwords. They are stored in etcd as base64-encoded values (and can be encrypted at rest) and are injected into pods as environment variables or mounted as volumes, ensuring the sensitive data never resides in the container image.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both are interchangeable for configuration, but ConfigMaps store data in plain text and are not secure for sensitive information, while Secrets provide base64 encoding and optional encryption for sensitive data.

How to eliminate wrong answers

Option A is wrong because a Deployment manages replica sets and pod lifecycle, but it does not provide any mechanism for storing or injecting sensitive configuration data. Option B is wrong because ConfigMaps store non-sensitive configuration data in plain text (base64-encoded but not encrypted by default) and are not intended for secrets; using a ConfigMap for API keys would expose them in plain text. Option C is wrong because a PersistentVolume provides storage for stateful workloads (e.g., databases) but is not designed for injecting sensitive configuration into pods; it would require manual management of secret files and does not integrate with Kubernetes RBAC or encryption for secrets.

Practice this question →
32
MCQmedium

You have an Azure Function app that processes orders. The function uses a queue trigger from Azure Storage. Recent load tests show that the function is not scaling out fast enough under high load. What should you do to improve scaling?

A.In the function code, increase the number of retries on failure
B.In host.json, increase the batchSize and increase the newBatchThreshold
C.In host.json, increase the batchSize and decrease the newBatchThreshold
D.Switch from Consumption plan to Premium plan
AnswerD

Switching to an Azure Functions Premium plan provides significantly more predictable scaling and eliminates cold starts by maintaining pre-warmed instances. Unlike the Consumption plan, which dynamically provisions resources on demand, the Premium plan offers dedicated, always-ready instances that can scale out much faster and more consistently, ensuring lower latency and higher throughput for order processing during peak loads. This dedicated resource model is crucial for performance-critical applications requiring rapid responsiveness.

Why this answer

Switching to the Premium plan provides faster scale-out capabilities, including pre-warmed instances and more scalable infrastructure, which helps the function scale out more quickly under high load compared to the Consumption plan.

Exam trap

The trap is that candidates may think increasing batch sizes improves throughput, but for faster scaling, smaller batches trigger more frequent fetch operations, which the scale controller uses to decide to add instances. The key is to balance efficiency with scale-out speed.

How to eliminate wrong answers

Option A is wrong because increasing the number of retries on failure does not affect scaling speed; it only affects fault tolerance for individual message processing failures. Option C is wrong because decreasing newBatchThreshold would cause the runtime to wait longer before fetching a new batch, which would actually slow down scaling and worsen the problem. Option D is wrong because switching to Premium plan provides more predictable scaling and VNET integration but does not inherently improve scaling speed; the bottleneck here is the queue trigger configuration, not the hosting plan.

Practice this question →
33
MCQeasy

You are deploying a containerized application to Azure Container Instances. The application requires a custom domain name and SSL/TLS certificate. What should you do?

A.Place an Azure Application Gateway in front of the container group.
B.Configure the container to listen on port 443 and map a custom domain.
C.Upload the certificate to the container and configure the web server.
D.Use a private endpoint with a custom domain.
AnswerA

Azure Application Gateway serves as a Layer 7 load balancer and web application firewall, perfectly suited for exposing containerized applications like those in Azure Container Instances (ACI). It provides robust SSL/TLS termination at the edge, offloading this compute-intensive task from the backend containers. Furthermore, Application Gateway enables custom domain mapping and advanced routing rules, allowing traffic to be directed to specific container instances based on URL paths or hostnames, ensuring secure and flexible access to the application.

Why this answer

Azure Container Instances (ACI) does not natively support custom domain names or SSL/TLS termination. By placing an Azure Application Gateway in front of the container group, you can offload SSL/TLS termination at the gateway layer, map a custom domain via the gateway's frontend IP, and route traffic to the container group's private IP. This is the recommended pattern for adding HTTPS and custom domains to ACI workloads.

Exam trap

The trap here is that candidates assume Azure Container Instances supports custom domains and SSL/TLS natively, similar to Azure App Service, but ACI lacks these features, requiring an external load balancer or gateway like Application Gateway.

How to eliminate wrong answers

Option B is wrong because simply configuring the container to listen on port 443 and mapping a custom domain does not provide SSL/TLS termination; ACI does not support binding a custom domain or certificate directly to the container group's public IP. Option C is wrong because uploading a certificate to the container and configuring the web server would require managing the certificate lifecycle inside the container, but ACI still cannot expose a custom domain name on its public endpoint; the container's FQDN is auto-generated and cannot be changed. Option D is wrong because a private endpoint with a custom domain only enables private connectivity within a virtual network; it does not expose the container group to the internet with a custom domain and SSL/TLS certificate.

Practice this question →
34
Multi-Selecteasy

You are creating an Azure Functions app that uses a Blob Storage trigger to process new files. The function must process files only when they are completely written (i.e., no ongoing writes). You need to avoid processing partially written files. Which TWO configurations should you consider?

Select 2 answers
A.Increase the 'BatchSize' to reduce the frequency of trigger evaluations.
B.Check the blob's 'LastModified' timestamp in the function code to verify no recent changes.
C.Use a timer-triggered function that lists blobs and processes those with a stable size.
D.Use the 'BlobTrigger' with the 'LeaseBlob' property set to 'True'.
E.Set the 'ScanBlob' property to 'True' in the trigger binding.
AnswersB, C

Checking the 'LastModified' timestamp and ensuring a sufficient delay since the last modification can help guarantee the blob is fully written. This is a valid manual approach. Therefore, B is correct.

Why this answer

Checking the blob's 'LastModified' timestamp in the function code allows you to verify that no recent writes have occurred. By comparing the timestamp to the current time and adding a delay, you can ensure the file is complete before processing. Option C is correct because a timer-triggered function can periodically list blobs and check for a stable size (unchanged over a period) to determine if the blob is fully written.

This avoids the trigger firing on partially written files. Options D and E are incorrect because 'LeaseBlob' and 'ScanBlob' are not valid properties of the Azure Functions Blob trigger binding. The recommended approach is to manually acquire a lease inside the function code, which is not explicitly listed as an option here.

Exam trap

Candidates often assume that the Blob trigger has built-in properties like 'LeaseBlob' or 'ScanBlob' to handle partial writes, but these are not valid. Instead, the proper patterns are to check the blob's timestamp or use a separate timer-triggered function to poll for stability.

Practice this question →
35
MCQhard

You are building a serverless API using Azure Functions with an HTTP trigger. The API must authenticate requests using Microsoft Entra ID (formerly Azure AD). You need to validate the token in the function code. Which component should you use?

A.Configure the Azure Functions host to use Microsoft Entra ID authentication.
B.Use the Microsoft Authentication Library (MSAL) to validate the token.
C.Use the Microsoft.Identity.Web library to validate the token.
D.Use Azure AD B2C to validate the token.
AnswerC

Microsoft.Identity.Web provides token validation for Microsoft Entra ID tokens.

Why this answer

Microsoft.Identity.Web is the recommended library for integrating Azure Functions with Microsoft Entra ID. It provides built-in token validation, including signature verification, issuer validation, and audience checking, by leveraging the same middleware used in ASP.NET Core. This library simplifies the process of validating JWT tokens issued by Microsoft Entra ID without requiring manual token parsing or validation logic.

Exam trap

The trap here is that candidates often confuse MSAL (for token acquisition) with token validation libraries, or assume that host-level Easy Auth (Option A) is equivalent to in-code validation, when the question explicitly requires validation within the function code.

How to eliminate wrong answers

Option A is wrong because configuring the Azure Functions host to use Microsoft Entra ID authentication (Easy Auth) offloads authentication to the host layer, but the question specifically requires validating the token in the function code, not at the host level. Option B is wrong because MSAL is designed for acquiring tokens, not for validating them; it does not include token validation APIs, and using it for validation would be incorrect and unsupported. Option D is wrong because Azure AD B2C is a separate identity service for customer-facing applications with custom policies, not the appropriate choice for validating tokens from Microsoft Entra ID in a serverless API.

Practice this question →
36
MCQhard

You are a developer at a financial services company. You need to design a solution for processing real-time stock trade data. The system receives thousands of trades per second from an on-premises system. Each trade must be validated, enriched with reference data, and then stored in a data lake for analytics. You have the following requirements: - The processing must be serverless and scale automatically with high throughput. - The enrichment step requires calling an external REST API that can handle up to 100 requests per second. If the API is overwhelmed, trades must be retried with exponential backoff. - The solution must minimize cost and operational overhead. - Trades must be processed in order per stock symbol. You provision an Azure Event Hubs namespace with a single event hub. Trades are sent to the event hub with the stock symbol as the partition key. You configure an Azure Functions app with an Event Hubs trigger to process events. The function validates, enriches by calling the external API, and writes the enriched trade to Azure Data Lake Storage. During testing, you notice that some trades are processed out of order for the same stock symbol when the external API throttles requests. What should you do to ensure ordering per stock symbol?

A.Use Durable Functions to orchestrate the processing and enforce ordering.
B.Increase the 'maxEventBatchSize' setting to 100 in the host.json file to improve throughput.
C.Set the 'maxEventBatchSize' to 1 in the host.json file to process one event at a time per instance.
D.Use a different partition key such as a unique trade ID to distribute load evenly.
AnswerC

Setting 'maxEventBatchSize' to 1 in the host.json file ensures that the Azure Function's Event Hubs trigger processes only one event at a time from each partition it consumes. This configuration is critical for maintaining strict sequential processing order within an Event Hubs partition. By forcing single-event processing, the function guarantees that event N is fully processed before event N+1 from the same partition is even delivered, thereby preserving the required transactional integrity.

Why this answer

Setting 'maxEventBatchSize' to 1 ensures that each function instance processes only one event at a time. When the external API throttles and triggers retries with exponential backoff, processing of subsequent events for the same partition (stock symbol) is blocked until the current event completes. This preserves the per-partition ordering guarantee that Event Hubs provides, as events within a partition are processed sequentially by a single consumer.

Exam trap

The trap here is that candidates often assume increasing batch size improves throughput without realizing that it can break ordering when retries are involved, or they mistakenly think Durable Functions are needed for any ordering requirement.

How to eliminate wrong answers

Option A is wrong because Durable Functions add unnecessary complexity and cost for this scenario; they are designed for long-running workflows and state management, not for preserving per-partition ordering in a high-throughput event stream. Option B is wrong because increasing 'maxEventBatchSize' to 100 would allow multiple events to be processed concurrently within a single function invocation, which can break ordering when retries occur due to throttling. Option D is wrong because using a unique trade ID as the partition key would distribute trades for the same stock symbol across multiple partitions, eliminating the ordering guarantee that Event Hubs provides per partition.

Practice this question →
37
MCQmedium

You have an Azure Function app that uses an Event Hubs trigger. The function processes events in batches. You notice that some events are being processed more than once. Which setting should you adjust to minimize duplicate processing?

A.Increase the maxRetries per event
B.Enable checkpointing in the function code
C.Increase the event batch size
D.Decrease the prefetch count
AnswerB

Enabling checkpointing in the function code is crucial for ensuring "at-least-once" processing and preventing duplicate event reprocessing. Checkpointing involves recording the offset of the last successfully processed event for each partition in a durable store, typically Azure Storage. When a function instance restarts, scales out, or a new instance takes over a partition, it retrieves the last checkpointed offset and begins processing events from that point, effectively preventing the re-delivery of already processed events. This mechanism is fundamental for managing distributed Event Hubs consumers.

Why this answer

Checkpointing in Azure Event Hubs stores the offset of the last successfully processed event in a durable store (e.g., Azure Blob Storage). When the function restarts or scales, it resumes from that checkpoint, preventing reprocessing of already-handled events. Without checkpointing, the default behavior may start from the earliest offset or use the `latest` position, leading to duplicate processing.

Exam trap

The trap here is that candidates often confuse retry policies or batch sizes with the checkpointing mechanism, not realizing that duplicate processing in Event Hubs is typically caused by missing or infrequent checkpointing, not by event handling failures.

How to eliminate wrong answers

Option A is wrong because increasing `maxRetries` per event only controls how many times a failed event is retried, not the root cause of duplicate processing from checkpointing gaps. Option C is wrong because increasing the event batch size processes more events per invocation but does not affect whether events are reprocessed after a restart or scaling event. Option D is wrong because decreasing the prefetch count reduces the number of events buffered locally, which can reduce the chance of duplicates from a crash during processing, but it does not address the fundamental need for checkpointing to persist progress across function restarts.

Practice this question →
38
Multi-Selectmedium

You are designing a solution that uses Azure Functions to process messages from an Azure Service Bus queue. Which TWO configurations can improve the throughput of the function?

Select 2 answers
A.Set maxDeliveryCount to a higher value
B.Set maxMessagesPerBatch to a higher value
C.Set newBatchThreshold to a lower value
D.Set maxMessagesPerBatch to a lower value
E.Set maxEventBatchSize to a higher value
AnswersB, C

Correct. A higher maxMessagesPerBatch allows the function to retrieve and process more messages per invocation, reducing the number of fetch operations and improving throughput.

Why this answer

Increasing maxMessagesPerBatch allows the function to retrieve and process more messages in a single batch, reducing the overhead of multiple fetch operations. Decreasing newBatchThreshold makes the trigger fetch a new batch sooner when fewer messages remain, keeping the function busy and reducing idle time, which improves throughput.

Exam trap

A common mistake is to think that lowering newBatchThreshold reduces throughput because it increases fetch frequency, but in reality it reduces idle time and can improve throughput by keeping the function continuously busy.

Practice this question →
39
MCQmedium

You are deploying a sensitive configuration to Azure Container Instances. The configuration must be encrypted at rest and not visible in the container logs. What should you use?

A.Environment variables in the container group
B.Azure Key Vault with managed identity and secret volumes
C.Azure Files volume mounted into the container
D.ConfigMap in a Kubernetes cluster
AnswerB

Azure Key Vault provides a secure, centralized store for secrets, encrypting them at rest and in transit. A managed identity grants the Azure Container Instance (ACI) secure, authenticated access to Key Vault without needing hardcoded credentials. By mounting secrets as volumes, they are injected directly into the container's filesystem, making them accessible to the application while avoiding exposure in environment variables or logs, thus enhancing security posture.

Why this answer

Azure Key Vault with managed identity and secret volumes is the correct choice because it allows you to mount secrets as files into the container without exposing them in environment variables or logs. The secrets are encrypted at rest in Key Vault and are only accessible via a managed identity assigned to the container group, ensuring the configuration remains secure and invisible in container logs.

Exam trap

The trap here is that candidates often choose environment variables (Option A) because they are easy to implement, but they overlook the requirement that the configuration must not be visible in container logs, which environment variables inherently violate.

How to eliminate wrong answers

Option A is wrong because environment variables in the container group are visible in the container logs and can be exposed through the Azure portal or CLI, failing the requirement to not be visible in logs. Option C is wrong because Azure Files volumes are not encrypted at rest by default (unless using Azure Storage Service Encryption, but the configuration data would still be visible in the container's file system and potentially in logs if accessed). Option D is wrong because ConfigMap is a Kubernetes concept and does not apply to Azure Container Instances, which is a serverless container service without Kubernetes orchestration.

Practice this question →
40
MCQmedium

Your company develops a microservices application deployed to Azure Kubernetes Service (AKS). You need to enable secure communication between services using managed identities. Which Azure service should you use to manage the identities and access control for the pods?

A.Azure Service Bus
B.Microsoft Entra Workload ID
C.Azure Key Vault
D.Azure Policy
AnswerB

Microsoft Entra Workload ID for Kubernetes enables Kubernetes pods to authenticate to Azure resources using a Microsoft Entra ID application and service principal, without needing to manage secrets. It leverages Kubernetes service accounts and federated identity credentials to allow pods to obtain tokens directly from Microsoft Entra ID. This facilitates secure, fine-grained access control for microservices within an AKS cluster, eliminating the need for manual secret rotation and enhancing the security posture.

Why this answer

Microsoft Entra Workload ID (formerly Azure AD Workload Identity) is the correct choice because it integrates with Kubernetes to automatically project an Azure AD-managed identity into each pod. This allows pods to authenticate to Azure resources (e.g., Key Vault, Storage) without managing secrets, using federated identity credentials that map a Kubernetes service account to an Azure AD application or user-assigned managed identity.

Exam trap

The trap here is that candidates often confuse Azure Key Vault (a secret store) with identity management, but Key Vault cannot authenticate pods—it requires an identity service like Workload ID to grant access to its secrets.

How to eliminate wrong answers

Option A is wrong because Azure Service Bus is a message broker for decoupling applications, not an identity or access control service for pods. Option C is wrong because Azure Key Vault stores secrets, keys, and certificates but does not manage identities or provide pod-level authentication; it relies on an identity service like Workload ID to grant access. Option D is wrong because Azure Policy enforces compliance rules on Azure resources (e.g., requiring TLS) but cannot assign or manage managed identities for AKS pods.

Practice this question →
41
MCQmedium

Your company uses Azure App Service to host a web application that requires periodic database maintenance. The maintenance tasks are time-consuming and must run outside of peak hours. You need to schedule these tasks to run automatically at 2:00 AM every Sunday. The tasks should be implemented as an Azure Function that runs in the same App Service plan to reduce costs. What should you do?

A.Deploy the maintenance code as an Azure Function in the Consumption plan and configure a timer trigger.
B.Create a separate Azure Function App in the same App Service plan and configure a timer trigger.
C.Add a WebJob to the App Service that uses a scheduled trigger to run the maintenance code.
D.Use Azure Logic Apps with a recurrence trigger to call the web application's maintenance endpoint.
AnswerB

Creating a separate Azure Function App, even within the same App Service plan, introduces an additional logical application resource. While sharing the App Service plan reduces infrastructure costs, this approach creates a distinct management and deployment unit for the function. The scenario requires implementing *an* Azure Function to run alongside an existing web application, implying integration or a single function within the existing application's context. This option is tempting because Azure Function Apps are the standard hosting unit for functions, and they can indeed share an App Service plan, making it the correct choice when a new, dedicated logical application for functions is desired.

Why this answer

Creating a separate Azure Function App and hosting it on the *same existing dedicated App Service Plan* (e.g., Basic, Standard, Premium) allows the Azure Function to run using the existing compute resources. This directly meets the requirement to run in the 'same App Service plan to reduce costs' by leveraging existing infrastructure. A timer trigger is the appropriate mechanism to schedule the function to run automatically at 2:00 AM every Sunday. This option also fulfills the requirement that the tasks 'should be implemented as an Azure Function'.

Option A is incorrect because deploying to a Consumption plan would create a *separate* Function App resource with a serverless billing model, which does not align with the 'in the same App Service plan' requirement for cost reduction in the context of an existing dedicated App Service plan.

Option C is incorrect because, while WebJobs are suitable for background tasks and can share an App Service plan, they are not Azure Functions. The STEM explicitly requires the tasks to be implemented as an Azure Function.

Option D is incorrect because Azure Logic Apps are a separate service, incurring separate costs, and do not fulfill the requirement to implement the task 'as an Azure Function' and run it 'in the same App Service plan' for cost reduction.

Exam trap

Candidates might overlook the specific requirement to implement the task 'as an Azure Function' and instead choose a WebJob, which is a different technology for background tasks. Another trap is confusing the cost implications of deploying an Azure Function to a Consumption plan (which is a separate serverless billing model) versus deploying it to an existing dedicated App Service Plan (which shares resources and costs with other apps on that plan).

How to eliminate wrong answers

Option A is wrong because deploying the Azure Function in the Consumption plan would incur separate costs and does not run in the same App Service plan, violating the cost-reduction requirement. Option B is wrong because creating a separate Azure Function App in the same App Service plan still requires a separate Function App resource, which adds management overhead and does not leverage the existing App Service's built-in WebJob feature for cost efficiency. Option D is wrong because Azure Logic Apps is a separate service with its own pricing model, and using it to call a maintenance endpoint would introduce additional costs and complexity, not reducing costs as required.

Practice this question →
42
MCQmedium

You are developing a solution that processes orders from an e-commerce website. The order processing logic is CPU-intensive and can take up to 30 seconds per order. You need to ensure that the web front-end remains responsive and that orders are processed reliably. What should you use?

A.Use Azure WebJobs to process orders in the same App Service plan.
B.Add orders to Azure Queue Storage and process them using a background worker role.
C.Use Azure Service Bus Queues with sessions for order processing.
D.Use Azure Functions with Durable Functions to manage order processing state.
AnswerB

This approach leverages Azure Queue Storage as a robust, asynchronous message broker, effectively decoupling the order submission front-end from the actual processing logic. When an order is placed, the front-end quickly adds a message to the queue, ensuring immediate responsiveness to the user. A separate background worker role, which could be an Azure Function, a VM, or a containerized application, then independently retrieves and processes these messages at its own pace, providing fault tolerance and allowing for independent scaling of the processing component. This design enhances system reliability and user experience by preventing processing delays from affecting the interactive application.

Why this answer

Azure Queue Storage provides a reliable, asynchronous message-passing mechanism that decouples the CPU-intensive order processing from the web front-end. By adding orders to a queue and processing them with a background worker (e.g., a WebJob or Worker Role), the web front-end remains responsive, and the queue ensures at-least-once delivery and durability, even if the worker fails or restarts.

Exam trap

The trap here is that candidates often choose Azure Service Bus Queues (Option C) because they assume 'reliable' messaging requires a premium service, but Azure Queue Storage is fully reliable for this scenario and simpler/cheaper, while sessions are a red herring for unordered processing.

How to eliminate wrong answers

Option A is wrong because running CPU-intensive work in the same App Service plan (via WebJobs) can still compete for resources (CPU, memory) with the web front-end, potentially causing responsiveness issues; it does not truly decouple the workload. Option C is wrong because Azure Service Bus Queues with sessions are designed for ordered, grouped message processing (e.g., FIFO per session), but the scenario does not require session-based ordering or grouping—simple reliable queuing suffices, and Service Bus adds unnecessary complexity and cost. Option D is wrong because Durable Functions are optimized for orchestrating long-running, stateful workflows with checkpoints, not for simple CPU-intensive batch processing; they introduce overhead for state management and are not the simplest or most cost-effective solution for this use case.

Practice this question →
43
MCQhard

You are deploying a Docker container to Azure Container Instances (ACI). The container must use GPU resources for machine learning inference. You need to select the appropriate option to provision GPU-enabled containers. What should you do?

A.Deploy the container to a container group with a GPU-enabled SKU (e.g., NV series).
B.Mount a GPU volume from the host.
C.Use Azure Batch with GPU-enabled pools.
D.Enable container GPU support in the Dockerfile.
AnswerA

To deploy a Docker container with GPU capabilities in Azure Container Instances, the correct approach is to provision a container group with a GPU-enabled SKU. This explicitly allocates a physical GPU from Azure's infrastructure, such as an NV-series VM, directly to your container instance. ACI then manages the necessary drivers and resources, making the GPU available to your containerized application for accelerated workloads like machine learning inference or training.

Why this answer

Azure Container Instances supports GPU resources only when you deploy a container group using a GPU-optimized SKU, such as the NV-series (e.g., Standard_NC6s_v3). These SKUs provide NVIDIA Tesla GPUs (e.g., K80, P100, V100) that are directly exposed to the container, enabling hardware-accelerated machine learning inference. You must specify the GPU SKU in the container group's resource requests during deployment, and the container image must include the appropriate NVIDIA CUDA drivers or runtime.

Exam trap

The trap here is that candidates confuse local Docker GPU configuration (e.g., `--gpus all` in Dockerfile or docker run) with ACI's infrastructure-level GPU provisioning, assuming that a Dockerfile directive alone will enable GPU access in ACI, when in fact the SKU selection is mandatory and overrides any local settings.

How to eliminate wrong answers

Option B is wrong because ACI does not support mounting a GPU volume from the host; GPU access is provided exclusively through the container group's SKU selection, not via volume mounts. Option C is wrong because Azure Batch with GPU-enabled pools is a separate service for batch processing, not a direct method to provision a single GPU container in ACI; the question specifically asks about ACI deployment. Option D is wrong because enabling GPU support in the Dockerfile (e.g., using `--gpus all` or NVIDIA runtime) is a local Docker configuration that does not affect ACI's provisioning; ACI ignores Dockerfile GPU directives and requires the SKU-based approach.

Practice this question →
44
MCQeasy

Refer to the exhibit. You deploy this ARM template to a resource group. The template fails with a 'ResourceNotFound' error. What is the most likely cause?

A.The App Service plan 'myplan' does not exist in the resource group.
B.The 'apiVersion' is incorrect.
C.The template is missing the 'dependsOn' property.
D.The 'type' property is incorrect for a web app.
AnswerA

An Azure App Service Web App requires an existing App Service Plan to host it. If the ARM template attempts to deploy a web app and references an App Service Plan by name ('myplan') that is neither defined within the same template nor already present in the target resource group, the deployment will fail. The Azure Resource Manager (ARM) engine will return a `ResourceNotFound` error because it cannot locate the specified parent hosting plan for the web app.

Why this answer

The ARM template references an App Service plan named 'myplan' in the 'serverFarmId' property of the Microsoft.Web/sites resource. If 'myplan' does not exist in the same resource group, the deployment fails with a 'ResourceNotFound' error because Azure Resource Manager cannot resolve the dependency on a non-existent resource. The template does not include a definition for the App Service plan, so it must already exist in the resource group.

Exam trap

Microsoft often tests the distinction between a missing resource and a missing dependency; the trap here is that candidates assume a 'ResourceNotFound' error always means a missing 'dependsOn' property, when in fact it indicates the referenced resource does not exist at all.

How to eliminate wrong answers

Option B is wrong because an incorrect 'apiVersion' typically causes a 'NoRegisteredProviderFound' or 'InvalidApiVersion' error, not a 'ResourceNotFound' error. Option C is wrong because the 'dependsOn' property is not required when referencing an existing resource by name; it is only needed to enforce deployment order when both resources are defined in the same template. Option D is wrong because the 'type' property 'Microsoft.Web/sites' is correct for a web app; an incorrect type would result in a 'InvalidResourceType' or 'ResourceNotFound' error only if the resource provider does not recognize it.

Practice this question →
45
MCQhard

You deploy the above ARM template. Later, you update the web app's code by deploying a new ZIP package to Azure Blob Storage and updating the WEBSITE_RUN_FROM_PACKAGE setting with the new package URL. However, the web app continues to run the old code. What is the most likely cause?

A.The app setting name is misspelled. It should be 'WEBSITE_RUN_FROM_ZIP'.
B.The setting requires a value of '0' to enable external packages.
C.The ARM template uses an incorrect apiVersion.
D.The value '1' indicates the package is from local storage, not an external URL.
AnswerD

When 'WEBSITE_RUN_FROM_PACKAGE' is set to '1', it instructs the Azure App Service to run the application directly from a zip package that has already been deployed to the 'data/SitePackages' folder within the app's local file system. This value does not signify an external URL; rather, it points to a locally staged package. To run an application from an external URL, the value of 'WEBSITE_RUN_FROM_PACKAGE' must be the full HTTP or HTTPS URL of the zip package itself, allowing the App Service to download and mount it dynamically.

Why this answer

When the WEBSITE_RUN_FROM_PACKAGE app setting is set to '1', it tells Azure App Service to use a local package stored in the site's wwwroot folder. To use an external package from Azure Blob Storage, the setting must be set to the full URL of the blob (with a SAS token if private). Keeping the value as '1' means the service ignores the new blob URL and continues to run the old local package.

Exam trap

The trap here is that candidates assume setting the value to '1' is a generic 'enable' flag, not realizing it has a specific meaning (local package) and that external packages require the full URL as the setting value.

How to eliminate wrong answers

Option A is wrong because the correct app setting name is 'WEBSITE_RUN_FROM_PACKAGE', not 'WEBSITE_RUN_FROM_ZIP'; the latter is not a recognized setting. Option B is wrong because a value of '0' disables the run-from-package feature entirely, causing the app to run from the deployed files directly, not enabling external packages. Option C is wrong because the apiVersion in the ARM template only affects deployment of the template itself, not the runtime behavior of the web app after it's deployed; an incorrect apiVersion would cause a deployment failure, not silent use of old code.

Practice this question →
46
Multi-Selecteasy

You are deploying an Azure App Service that uses a Linux container to host a custom web application. You need to configure continuous deployment from a GitHub repository. Which TWO actions should you take?

Select 2 answers
A.Set up an FTP trigger to poll the GitHub repository for changes.
B.Use the App Service built-in CI/CD feature to connect to GitHub.
C.Configure the 'Deployment Center' in the App Service to use GitHub Actions.
D.Use the Kudu service to sync with GitHub.
E.Push the container image to Docker Hub and configure webhook.
AnswersB, C

Built-in CI/CD supports GitHub.

Why this answer

Azure App Service provides a built-in CI/CD feature that directly integrates with GitHub, enabling automatic deployment of code changes without additional configuration. Option C is also correct because the Deployment Center in App Service allows you to configure GitHub Actions as the CI/CD pipeline, which builds and deploys the container to the App Service on each push.

Exam trap

The trap here is that candidates may think Kudu is the only deployment engine for App Service, but for Linux containers, the built-in CI/CD and GitHub Actions are the supported methods, and Kudu is not used for GitHub sync in this scenario.

Practice this question →
47
MCQeasy

You are developing an API using Azure API Management (APIM). The API is backed by an Azure Function that processes requests. You need to implement caching for responses that are expensive to compute. The cache should expire after 10 minutes. What should you configure in APIM?

A.Configure Azure Redis Cache as an external cache in APIM.
B.Add a cache-lookup and cache-store policy to the API operation.
C.Implement response caching in the Azure Function code.
D.Use Azure Front Door to cache responses.
AnswerB

Adding `cache-lookup` and `cache-store` policies directly to an API operation is the standard and most effective method for implementing response caching within Azure API Management. These policies leverage APIM's highly optimized, built-in cache, allowing the gateway to check for cached responses before forwarding requests and to store backend responses for subsequent requests, centralizing cache management at the API gateway level.

Why this answer

Azure API Management (APIM) provides built-in caching policies—`cache-lookup` and `cache-store`—that can be applied directly to an API operation. These policies cache the response from the backend (the Azure Function) and respect the `cache-control` header or a specified duration, such as 10 minutes, without requiring an external cache. This is the simplest and most direct way to implement response caching for expensive-to-compute operations within APIM.

Exam trap

The trap here is that candidates often assume an external cache like Redis is required for any caching in APIM, but the built-in cache-lookup and cache-store policies use APIM's internal cache by default, making external Redis optional and only needed for advanced scenarios like multi-region deployments or higher cache capacity.

How to eliminate wrong answers

Option A is wrong because configuring Azure Redis Cache as an external cache in APIM is an optional enhancement for scenarios requiring a distributed cache across multiple APIM instances, but it is not necessary for basic response caching; the built-in cache-lookup and cache-store policies work with APIM's internal cache by default. Option C is wrong because implementing response caching in the Azure Function code would cache responses at the function level, but the question specifically asks what to configure in APIM, and APIM caching policies provide centralized control, offload the backend, and can cache even non-cacheable responses from the function. Option D is wrong because Azure Front Door is a global load balancer and CDN that caches at the edge, not within APIM; it operates at a different layer and does not integrate with APIM's policy-based caching for API operations.

Practice this question →
48
MCQmedium

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

A.Regional VNet integration
B.Azure CDN custom domain
C.Application Gateway path routing
D.Private Endpoint for the web app only
AnswerA

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

Why this answer

Regional VNet integration enables an Azure App Service app to make outbound calls to resources in a virtual network (VNet) using the app's outbound IP addresses. It works by injecting the app's outbound traffic into the VNet via a delegated subnet, allowing the app to reach private APIs hosted inside the VNet without exposing them to the public internet.

Exam trap

The trap here is that candidates often confuse Private Endpoint (inbound) with VNet integration (outbound), mistakenly thinking a Private Endpoint on the app allows it to call VNet resources, when in fact it only allows VNet resources to call the app.

How to eliminate wrong answers

Option B is wrong because Azure CDN custom domain is a content delivery feature that caches and serves static content from edge locations; it does not provide outbound connectivity from an App Service to a VNet. Option C is wrong because Application Gateway path routing is an inbound traffic management feature that routes external HTTP/S requests to backend pools; it does not enable outbound access from the app to the VNet. Option D is wrong because Private Endpoint for the web app only secures inbound traffic to the app from the VNet; it does not allow the app to make outbound calls to resources inside the VNet.

Practice this question →
49
MCQeasy

You deploy a web application to Azure App Service. You need to deploy a new version of the application without downtime and have the ability to test the new version before switching traffic. Which feature should you use?

A.Deployment slots
B.Auto-scaling
C.Backup
D.Custom domains
AnswerA

Azure App Service deployment slots provide a separate, live environment for your web application, distinct from the production slot. This enables you to deploy new application versions to a staging slot, test them thoroughly, and then perform a near-instantaneous swap with the production slot. This process ensures zero downtime for end-users during deployments and allows for easy rollback if issues are discovered post-swap, making it ideal for continuous delivery.

Why this answer

Deployment slots are live, independently running app versions in Azure App Service that allow you to deploy a new build to a staging slot, validate it with zero impact on production, and then swap it into production with instant traffic redirection. This swap operation is atomic and warm-up aware, ensuring no downtime during the transition.

Exam trap

The trap here is that candidates confuse auto-scaling with deployment strategies, thinking scaling out instances can serve new code without downtime, but auto-scaling only replicates the existing app version and does not provide a mechanism to test or switch traffic between builds.

How to eliminate wrong answers

Option B (Auto-scaling) is wrong because it adjusts the number of instances based on load metrics, not for staging or testing new code versions. Option C (Backup) is wrong because it creates point-in-time copies of app files and databases for disaster recovery, not for zero-downtime deployment or pre-production validation. Option D (Custom domains) is wrong because it maps a DNS name to the app's endpoint and has no role in deployment staging or traffic switching.

Practice this question →
50
MCQhard

You are designing a serverless data processing pipeline. The pipeline receives JSON messages from an Azure Event Hubs instance. Each message must be enriched with data from a Cosmos DB database and then written to a Parquet file in Azure Data Lake Storage Gen2. The enrichment step involves a lookup that takes approximately 2 seconds per message. The pipeline must process up to 1000 messages per second. You need to choose the most cost-effective and scalable compute option. Consider the following options: A) Use a single Azure Function with Event Hubs trigger and output to Data Lake Storage. B) Use a Durable Functions orchestration with fan-out/fan-in pattern. C) Use Azure Stream Analytics with a reference data input from Cosmos DB and output to Data Lake Storage. D) Use an Azure Databricks notebook with structured streaming. Which option should you recommend?

A.Use a single Azure Function with Event Hubs trigger and output to Data Lake Storage. [wrong]
B.Use a Durable Functions orchestration with fan-out/fan-in pattern.
C.Use Azure Stream Analytics with a reference data input from Cosmos DB and output to Data Lake Storage.
D.Use an Azure Databricks notebook with structured streaming. [wrong]
AnswerC

Scalable, serverless, supports enrichment and Parquet output.

Why this answer

Azure Stream Analytics with a reference data input from Cosmos DB is the most cost-effective and scalable option because it can handle high-throughput streams (up to 1 GB/s) with sub-second latency, and it natively supports enriching incoming events with static or slowly-changing reference data (like Cosmos DB) without requiring custom code. The enrichment lookup is performed in-memory within the Stream Analytics job, avoiding per-message function invocation overhead and enabling linear scale-out across streaming units to meet 1000 messages/second with a 2-second lookup.

Exam trap

The trap here is that candidates often assume Azure Functions are the default serverless choice for all event processing, but they fail to recognize that per-message enrichment with a 2-second lookup creates a throughput bottleneck that only a streaming engine like Stream Analytics can handle cost-effectively at scale.

How to eliminate wrong answers

Option A is wrong because a single Azure Function with an Event Hubs trigger cannot scale to 1000 messages/second with a 2-second enrichment per message — the function would be severely throttled by its concurrency limits (default 200 max per plan) and the 2-second lookup would create a backlog, causing massive event processing delays and potential data loss. Option B is wrong because Durable Functions orchestration with fan-out/fan-in is designed for long-running workflows and stateful coordination, not for high-throughput stateless stream processing; the orchestration overhead and checkpointing would introduce latency and cost that far exceed the requirements. Option D is wrong because Azure Databricks with structured streaming, while scalable, is overkill and cost-inefficient for this simple enrichment and write pipeline — it requires a running cluster with VMs, incurs high per-hour costs, and introduces operational complexity (cluster management, autoscaling delays) that is unnecessary compared to a fully managed serverless service like Stream Analytics.

Practice this question →
51
MCQmedium

You develop an Azure Durable Functions application that orchestrates a series of activities. The orchestrator function calls activity functions that perform long-running tasks. You need to ensure that the orchestrator function can handle transient errors and retry failed activity functions. Which feature should you use?

A.Polly library for retry logic
B.Built-in retry policies in Durable Functions
C.Application Insights alerts
D.Azure Storage queue message retries
AnswerB

Durable Functions provides robust built-in retry policies specifically designed for activity function calls, allowing orchestrators to gracefully handle transient failures. When calling an activity function, the orchestrator can specify `RetryOptions` that include parameters like `MaxNumberOfAttempts`, `FirstRetryInterval`, and `BackoffCoefficient`. This enables the Durable Functions runtime to automatically re-attempt failed activity executions after a specified delay, without requiring any custom retry logic within the activity function itself.

Why this answer

Durable Functions provides built-in retry policies that can be configured directly on activity function calls within orchestrator functions. This allows you to specify parameters such as max retry count, backoff interval, and retry timeout, enabling the orchestrator to automatically retry failed activities without custom code or external dependencies.

Exam trap

The trap here is that candidates may assume any retry mechanism (like Polly or queue retries) works equally well, but they fail to recognize that Durable Functions' built-in retry policies are the only option that integrates seamlessly with the orchestrator's deterministic replay and state management.

How to eliminate wrong answers

Option A is wrong because the Polly library is a general-purpose .NET resilience framework that would require manual integration and does not leverage Durable Functions' native replay and checkpointing mechanisms, leading to potential state inconsistencies. Option C is wrong because Application Insights alerts are used for monitoring and notification, not for implementing retry logic within the orchestrator's execution flow. Option D is wrong because Azure Storage queue message retries apply to queue-triggered functions, not to activity function calls orchestrated by Durable Functions; the orchestrator manages retries at the function invocation level, not via queue message dequeue counts.

Practice this question →
52
MCQeasy

You are designing a solution that runs background jobs to process images. The jobs can run up to 10 minutes each. You need to ensure the jobs are resilient to failures and can be retried automatically. Which Azure service should you use?

A.Azure Logic Apps with a recurrence trigger
B.Azure Queue Storage with an Azure Function trigger
C.Azure Service Bus with a WebJob
D.Azure Event Grid with a Logic App
AnswerB

Azure Queue Storage provides a highly reliable and scalable messaging solution, perfect for decoupling background job requests. When a message is added, an Azure Function is triggered, offering automatic scaling based on queue depth and cost-effective, consumption-based execution. This combination inherently supports automatic retries for transient failures and robust poison message handling, ensuring durable and resilient processing of potentially long-running background tasks without manual intervention.

Why this answer

Azure Queue Storage with an Azure Function trigger is the correct choice because it provides a reliable, message-based architecture for background job processing. Queue messages persist until processed, and the Azure Function trigger automatically retries on failure (up to 5 times by default, with configurable policies). This handles the 10-minute job duration via the queue's visibility timeout, which can be set to match the job's maximum runtime, ensuring messages are not prematurely reprocessed.

Exam trap

The trap here is that candidates often confuse Azure Queue Storage with Azure Service Bus, assuming Service Bus is always better for reliability, but Queue Storage is simpler, cheaper, and perfectly suited for long-running background jobs with automatic retry via Azure Functions.

How to eliminate wrong answers

Option A is wrong because Azure Logic Apps with a recurrence trigger is designed for scheduled, time-based workflows, not for resilient, failure-retry background job processing triggered by queue messages. Option C is wrong because Azure Service Bus with a WebJob is overly complex for this scenario; WebJobs are a legacy technology and Service Bus is better suited for enterprise messaging with advanced features like sessions and transactions, not simple image processing jobs. Option D is wrong because Azure Event Grid with a Logic App is an event-driven pattern for reacting to events (e.g., blob created), but it lacks built-in retry and queue-based persistence for long-running jobs; Event Grid has a 5-minute timeout and no native retry for failed processing.

Practice this question →
53
Multi-Selecteasy

You are developing a web application that will be deployed to Azure App Service. You need to configure automatic scaling based on CPU usage. Which TWO settings should you configure?

Select 2 answers
A.Configure authentication for the scaling endpoint.
B.Set the minimum and maximum instance count.
C.Set the Always On setting to On.
D.Configure a scale in condition based on CPU percentage.
E.Configure a scale out condition based on CPU percentage.
AnswersD, E

Configuring a scale-in condition based on CPU percentage is a fundamental aspect of optimizing resource utilization for an Azure App Service. This rule specifies that when the average CPU utilization across all instances drops below a defined threshold (e.g., 20%) for a sustained period, the autoscaling engine should reduce the number of active instances. This action helps to minimize operational costs during periods of low demand by releasing unnecessary resources.

Why this answer

Configuring a scale-in condition based on CPU percentage allows the App Service plan to automatically reduce the number of instances when CPU usage drops below a defined threshold, which is essential for cost optimization. Option E is correct because configuring a scale-out condition based on CPU percentage enables the platform to automatically add instances when CPU usage exceeds a threshold, ensuring the application can handle increased load. Together, these two settings define the autoscale rules that react to CPU metrics, which is the core requirement for CPU-based automatic scaling.

Exam trap

The trap here is that candidates often confuse the prerequisite settings (like instance count limits) with the actual scaling condition rules, or they think that only one direction (scale-out or scale-in) is needed, but autoscale requires both to be fully defined for CPU-based scaling to work correctly.

Practice this question →
54
MCQhard

You have an Azure Function app that uses .NET 8 isolated process. The function must connect to an Azure SQL database using a managed identity. The function app has a system-assigned managed identity enabled. Which code snippet correctly retrieves the access token?

A.new SqlConnection(connectionString) using Integrated Security=true;
B.var token = await new Azure.Identity.DefaultAzureCredential().GetTokenAsync("https://database.windows.net");
C.var credential = new DefaultAzureCredential(); var token = await credential.GetTokenAsync(new TokenRequestContext(new[] {"https://database.windows.net/.default"}));
D.var credential = new ManagedIdentityCredential(); var token = await credential.GetTokenAsync("https://database.windows.net");
AnswerC

This option is correct as it properly utilizes the `Azure.Identity` library to obtain an access token for a Managed Identity. `DefaultAzureCredential` intelligently determines the appropriate credential type in an Azure environment, and `GetTokenAsync` is correctly invoked with a `TokenRequestContext` specifying the `https://database.windows.net/.default` scope, which is the standard for Azure SQL Database.

Why this answer

It uses `DefaultAzureCredential` to obtain an access token for Azure SQL Database by specifying the resource URI `https://database.windows.net/.default` in a `TokenRequestContext`. In a .NET 8 isolated process function app with a system-assigned managed identity, `DefaultAzureCredential` automatically attempts managed identity authentication as one of its credential sources, making it the recommended approach. The `GetTokenAsync` method requires a `TokenRequestContext` object, not a plain string, to correctly request the token for the Azure SQL resource.

Exam trap

The trap here is that candidates often forget that `GetTokenAsync` requires a `TokenRequestContext` object with an array of scopes, not a plain string URL, and they may also omit the `/.default` suffix required for Azure SQL Database token requests.

How to eliminate wrong answers

Option A is wrong because `Integrated Security=true` is used for Windows authentication in on-premises environments, not for managed identity authentication to Azure SQL Database; it does not retrieve an access token. Option B is wrong because `GetTokenAsync` expects a `TokenRequestContext` object, not a plain string URL; passing `"https://database.windows.net"` without the `/.default` scope and without wrapping it in a `TokenRequestContext` will cause a compilation error. Option D is wrong because `ManagedIdentityCredential` is valid but the `GetTokenAsync` method still requires a `TokenRequestContext` object, not a plain string; additionally, using `DefaultAzureCredential` is preferred for flexibility in local development and production scenarios.

Practice this question →
55
MCQmedium

You find the above ARM template snippet in a deployment. What is the effect of this configuration on the App Service?

A.Allows cross-origin requests from app.contoso.com and portal.contoso.com without credentials.
B.Configures the App Service to require authentication for cross-origin requests.
C.Enables CORS for all origins by setting allowedOrigins to a wildcard.
D.Blocks all cross-origin requests because supportCredentials is false.
AnswerA

The `allowedOrigins` property explicitly lists `https://app.contoso.com` and `https://portal.contoso.com`, granting these specific domains permission to make cross-origin requests to the App Service. Concurrently, `supportCredentials: false` dictates that the browser should not include credentials, such as cookies, HTTP authentication headers, or client-side SSL certificates, with these permitted cross-origin requests. This configuration enables secure communication from the specified front-end applications to the App Service API without relying on credential-based authentication at the CORS level.

Why this answer

The ARM template snippet sets `allowedOrigins` to specific domains (`app.contoso.com` and `portal.contoso.com`) and `supportCredentials` to `false`. This configuration allows cross-origin requests from those two origins but does not include credentials (cookies, HTTP authentication, or client-side certificates) in the requests, as per the CORS specification.

Exam trap

The trap here is that candidates often confuse `supportCredentials: false` with blocking all cross-origin requests, when in fact it only disallows credentials while still allowing non-credentialed requests from the specified origins.

How to eliminate wrong answers

Option B is wrong because CORS does not require authentication; it controls which origins can make cross-origin requests, and `supportCredentials` being `false` means credentials are not sent, not that authentication is required. Option C is wrong because `allowedOrigins` is set to specific domains, not a wildcard (`*`), so it does not enable CORS for all origins. Option D is wrong because `supportCredentials: false` does not block all cross-origin requests; it only prevents credentials from being included in the requests, while the allowed origins can still make non-credentialed requests.

Practice this question →
56
MCQmedium

Your Azure Function app uses an Event Hub trigger. Under high load, some events are processed multiple times. You need to ensure exactly-once processing without losing events. What should you implement?

A.Make the function idempotent
B.Use Azure Queue Storage instead
C.Enable checkpointing
D.Increase the batch size
AnswerA

When an Azure Function processes Event Hub messages, especially under high load or transient errors, messages can be delivered multiple times due to the at-least-once delivery guarantee. Implementing idempotency means designing the function's logic so that processing the same event multiple times produces the same result as processing it once, without adverse side effects. This typically involves using a unique identifier from the event to check if the operation has already been completed before performing it again, often by storing processing status in a durable store like Azure Cosmos DB or Table Storage.

Why this answer

Making the function idempotent ensures that even if the Event Hub trigger delivers the same event multiple times (which can happen under high load due to at-least-once delivery semantics), the function's side effects are safe to repeat. Idempotency is the only reliable way to achieve exactly-once processing in a distributed system where the trigger itself does not guarantee deduplication.

Exam trap

The trap here is that candidates confuse checkpointing with deduplication, assuming it guarantees exactly-once processing, when in reality checkpointing only tracks read progress and does not prevent duplicate event delivery within the same batch or across restarts.

How to eliminate wrong answers

Option B is wrong because switching to Azure Queue Storage does not inherently solve duplicate processing; queues also use at-least-once delivery and require idempotent consumers. Option C is wrong because checkpointing tracks progress in the Event Hub partition but does not prevent duplicate deliveries; it only helps resume from the last checkpoint after a restart, not deduplicate within a batch. Option D is wrong because increasing the batch size increases throughput but amplifies the risk of duplicates and does not address the root cause of duplicate event processing.

Practice this question →
57
MCQhard

You deploy an Azure Function app that uses the Premium plan. The function processes messages from an Azure Service Bus queue. Under heavy load, some messages are processed multiple times. You need to ensure exactly-once processing without losing messages. What should you do?

A.Enable duplicate detection on the Service Bus queue.
B.Use Peek-Lock mode instead of Receive and Delete.
C.Set the maxDeliveryCount to 1 on the queue.
D.Reduce the batch size in the function host.json.
AnswerA

Enabling duplicate detection on an Azure Service Bus queue is the primary mechanism to ensure exactly-once message processing. When activated, Service Bus stores a history of message IDs for a configurable time window, typically up to seven days. If a producer attempts to send a message with an MessageId that matches one already processed within that window, Service Bus automatically rejects the duplicate, preventing its delivery to consumers and thus ensuring that each unique message is processed only once.

Why this answer

Enabling duplicate detection on the Service Bus queue ensures that the Service Bus broker itself discards duplicate messages based on a user-defined time window. This prevents the function from processing the same message multiple times, even if the function host restarts or the message is re-delivered due to transient failures. Duplicate detection works by tracking the MessageId of each message and ignoring any subsequent message with the same MessageId within the detection window.

Exam trap

The trap here is that candidates often confuse client-side idempotency (e.g., using a database unique constraint) with broker-level duplicate detection, or they mistakenly believe that Peek-Lock mode alone guarantees exactly-once processing, ignoring the risk of crashes after processing but before completion.

How to eliminate wrong answers

Option B is wrong because Peek-Lock mode is already the default for Service Bus triggered Azure Functions and does not prevent duplicate processing; it only provides explicit message completion, which can still lead to duplicates if the function crashes after processing but before completing the message. Option C is wrong because setting maxDeliveryCount to 1 does not guarantee exactly-once processing; it simply limits the number of delivery attempts, but the message can still be processed multiple times if it is re-queued or if the function host restarts after processing but before the message is settled. Option D is wrong because reducing the batch size in host.json only controls how many messages are fetched at once, which can reduce the blast radius of duplicates but does not eliminate the root cause of duplicate processing.

Practice this question →
58
MCQhard

Images are uploaded to a high-volume Blob Storage account. An Azure Function with a Blob Storage trigger processes each new image. The team has observed processing delays of up to 10 minutes on accounts with large numbers of containers and blobs. They need processing to start within seconds of upload. What should the developer change?

A.Replace the Blob Storage trigger with an Event Grid trigger and create a Blob Created event subscription that targets the Function's endpoint
B.Switch to a Timer trigger that runs every 30 seconds and lists newly created blobs via the SDK
C.Use a Queue Storage trigger and write blob metadata to the queue from the upload client
D.Move the Function to a Premium plan, which uses a dedicated worker and eliminates Blob trigger polling delays
AnswerA

Event Grid delivers blob creation events within seconds of the upload by pushing events rather than polling. The Function receives the event payload (which includes the blob URI) and begins processing immediately. This eliminates the polling delay inherent in the Blob Storage trigger on large accounts.

Why this answer

Event Grid provides near-real-time event delivery (typically under 1 second) for Blob Created events, eliminating the polling latency inherent in the Blob Storage trigger. The Blob Storage trigger polls Azure Storage logs for new blobs, which can cause delays of up to 10 minutes in high-volume accounts with many containers and blobs. By switching to an Event Grid trigger, the function is invoked directly via HTTP webhook as soon as the blob is created, meeting the requirement for processing to start within seconds.

Exam trap

The trap here is that candidates often assume upgrading the hosting plan (Premium) will fix latency issues, but the root cause is the polling-based Blob Storage trigger, not the underlying infrastructure; the correct solution is to switch to an event-driven trigger like Event Grid.

How to eliminate wrong answers

Option B is wrong because a Timer trigger running every 30 seconds still introduces up to 30 seconds of delay, and listing blobs via the SDK is inefficient and does not guarantee sub-second processing; it also adds unnecessary overhead and complexity. Option C is wrong because it requires modifying the upload client to write metadata to a queue, which is an architectural change that adds coupling and does not leverage the existing blob upload event; the question asks what the developer should change in the current setup, not how to redesign the client. Option D is wrong because moving to a Premium plan does not change the underlying polling mechanism of the Blob Storage trigger; the delay is caused by the trigger's polling interval, not by the plan's performance or dedicated workers.

Practice this question →
59
MCQhard

A containerized checkout API deployed to Azure Container Apps must scale to zero when idle and scale out based on queue length. What should the developer configure?

A.A KEDA-based scale rule for the queue trigger
B.A manual replica count only
C.An Availability Set
D.An Azure Front Door health probe
AnswerA

This is the correct approach for event-driven scaling in Azure Container Apps. KEDA (Kubernetes Event-driven Autoscaling) integrates directly with Container Apps, allowing it to monitor external event sources like Azure Storage Queues. A KEDA-based scale rule would specify the queue to monitor and define thresholds (e.g., messages per replica) that trigger scaling actions, ensuring the API scales out when queue length increases and scales in (potentially to zero) when the queue is empty. This efficiently handles fluctuating loads for a checkout API processing asynchronous requests.

Why this answer

Azure Container Apps supports KEDA (Kubernetes Event-Driven Autoscaling) for scaling based on external metrics. A KEDA-based scale rule configured with an Azure Queue Storage trigger allows the containerized checkout API to scale to zero when no messages are in the queue and scale out dynamically as queue length increases, meeting the requirement precisely.

Exam trap

The trap here is that candidates may confuse Azure Container Apps' built-in HTTP scaling rules with KEDA-based event-driven scaling, or incorrectly assume that a manual replica count or a load-balancing health probe can achieve the required queue-based autoscaling behavior.

How to eliminate wrong answers

Option B is wrong because a manual replica count only provides static scaling and cannot scale to zero or scale out based on queue length, which is required for event-driven workloads. Option C is wrong because an Availability Set is a virtual machine (VM) high-availability construct in Azure, not applicable to Azure Container Apps which is a serverless container platform. Option D is wrong because an Azure Front Door health probe is used for load balancing and health monitoring at the HTTP/HTTPS edge, not for autoscaling based on queue metrics.

Practice this question →
60
MCQhard

You have implemented a long-running order processing workflow using Azure Durable Functions. The orchestration may run for hours and involves multiple activity functions. You need to monitor the status of all running orchestrations and receive alerts when an orchestration fails. Which approach provides the most comprehensive and real-time monitoring?

A.Use the Durable Functions HTTP API to poll the status of each orchestration.
B.Use Azure Monitor to create alerts on custom metrics published by the Durable Functions.
C.Enable Application Insights for the Functions app and use its telemetry to monitor orchestration execution and set alerts.
D.Use Azure Logic Apps to periodically check the orchestration status and send alerts.
AnswerC

Enabling Application Insights for the Functions app is the correct approach because it automatically captures comprehensive telemetry for Durable Functions, including orchestration lifecycle events (e.g., started, completed, failed, suspended, resumed) and activity function executions. This rich, structured data, accessible via Kusto Query Language (KQL), allows for detailed monitoring of individual orchestration instances, identification of bottlenecks, and the creation of precise alerts on failed orchestrations with full contextual information, enabling rapid diagnosis and resolution.

Why this answer

Application Insights provides comprehensive, real-time monitoring for Durable Functions by automatically capturing orchestration lifecycle events, including failures, retries, and durations. It enables proactive alerting on failure metrics (e.g., 'orchestration-failed') without polling, and offers rich diagnostic tools like distributed tracing and custom querying. This is the most integrated and feature-rich approach for monitoring long-running orchestrations.

Exam trap

The trap here is that candidates often assume Azure Monitor is the primary monitoring tool, but for Durable Functions, Application Insights is the recommended and most comprehensive solution because it natively captures orchestration-specific telemetry without custom instrumentation.

How to eliminate wrong answers

Option A is wrong because polling the Durable Functions HTTP API for each orchestration is inefficient, introduces latency, and does not provide real-time alerting; it also requires custom code to manage state and scale. Option B is wrong because Azure Monitor custom metrics require manual instrumentation and publishing from within the function code, which is less comprehensive than the automatic telemetry collected by Application Insights. Option D is wrong because Logic Apps add unnecessary complexity and cost, and periodic polling still cannot match the real-time, event-driven monitoring and alerting capabilities of Application Insights.

Practice this question →
61
MCQhard

You have an Azure Container Apps environment running multiple microservices. One microservice is experiencing high CPU usage and slow response times. You need to configure autoscaling rules to scale based on HTTP requests. Which scaling rule should you add?

A.HTTP scaling rule (KEDA)
B.CPU percentage scaling rule
C.Memory percentage scaling rule
D.Custom scaling rule using Azure Monitor metrics
AnswerA

An HTTP scaling rule, powered by KEDA (Kubernetes Event-driven Autoscaling), is the most appropriate choice for web microservices in Azure Container Apps. This rule directly monitors the rate of incoming HTTP requests or the number of concurrent requests per replica, allowing the container app to scale out proactively as web traffic increases. This direct correlation ensures rapid and efficient response to fluctuating demand, maintaining optimal performance and availability for user-facing applications.

Why this answer

KEDA's HTTP scaling rule is specifically designed to scale Azure Container Apps based on the number of concurrent HTTP requests, which directly addresses high CPU usage and slow response times caused by request load. Unlike CPU or memory metrics, HTTP scaling reacts to incoming request volume proactively, allowing the microservice to handle spikes before resource saturation occurs.

Exam trap

The trap here is that candidates often choose CPU or memory scaling rules because they seem directly related to high CPU usage, but the question explicitly asks for scaling based on HTTP requests, which requires a request-based scaler like KEDA's HTTP scaler, not resource-based metrics.

How to eliminate wrong answers

Option B is wrong because CPU percentage scaling rule reacts to resource utilization after it has already increased, which is reactive and may not prevent slow response times during sudden request surges. Option C is wrong because memory percentage scaling rule is typically used for memory-bound workloads, not CPU-bound or request-driven scenarios, and memory often lags behind CPU as a scaling signal. Option D is wrong because custom scaling rules using Azure Monitor metrics require additional configuration and are not as straightforward or purpose-built as KEDA's HTTP scaler for request-based autoscaling in Container Apps.

Practice this question →
62
MCQmedium

You have an Azure App Service that runs a web API. The API is accessed by multiple client applications. You need to implement authentication and authorization using Microsoft Entra ID. The solution must allow client applications to obtain access tokens using the OAuth 2.0 client credentials flow. Which authentication setting should you configure in the App Service?

A.Enable the 'Token store' in the Authentication / Authorization blade.
B.Configure the app to use the Microsoft.Identity.Web library to validate tokens.
C.Use the built-in authentication module with Microsoft Entra ID as the identity provider.
D.Upload a client certificate and configure certificate-based authentication.
AnswerC

Easy Auth can validate tokens issued by Microsoft Entra ID.

Why this answer

Configuring the built-in authentication module in Azure App Service with Microsoft Entra ID as the identity provider allows the App Service to validate access tokens issued by Microsoft Entra ID. Client applications can use the OAuth 2.0 client credentials flow to obtain tokens from Microsoft Entra ID and then present them to the App Service. The built-in auth module does not perform token acquisition; it only validates tokens at the gateway level, simplifying the validation process for the app.

Exam trap

A common misconception is that the built-in authentication module handles the entire OAuth 2.0 client credentials flow, including token acquisition. In reality, the module only validates tokens; the client applications must independently obtain tokens from Microsoft Entra ID. Additionally, candidates may consider Microsoft.Identity.Web (Option B) as an App Service setting, but it is a library used within the application code for token validation and acquisition, not a configuration option in the App Service itself.

How to eliminate wrong answers

Option A is wrong because the 'Token store' is a feature that caches tokens for the authenticated user session, but it does not configure the identity provider or enable the client credentials flow; it is used for storing tokens after authentication is already set up. Option B is wrong because the Microsoft.Identity.Web library is a client-side library used within the application code to validate tokens and handle authentication, not a configuration setting in the App Service's Authentication / Authorization blade; the question asks for a setting to configure in the App Service, not code changes. Option D is wrong because certificate-based authentication is used for client certificate authentication (mutual TLS), which is a different mechanism than the OAuth 2.0 client credentials flow; it does not involve obtaining access tokens via Microsoft Entra ID.

Practice this question →
63
MCQeasy

You are deploying a web application to Azure App Service. The application needs to read configuration settings that vary by deployment environment (development, staging, production). You want to minimize application changes and leverage Azure services. What should you use?

A.Use Azure Key Vault secrets for configuration values.
B.Use Azure DevOps variable groups and inject them at build time.
C.Use Azure App Configuration with feature flags.
D.Use Azure App Service application settings.
AnswerD

Azure App Service application settings are key-value pairs that are exposed to the application as environment variables at runtime. These settings can be easily configured and managed directly within the Azure portal, Azure CLI, or PowerShell, and critically, they can be configured per deployment slot. This allows for seamless environment-specific configurations (e.g., development, staging, production) and dynamic updates without requiring code changes or redeployments, making them the most straightforward and effective solution for web application configuration.

Why this answer

Azure App Service application settings are the correct choice because they are natively supported by the App Service platform, allowing you to define key-value pairs that are injected as environment variables at runtime. This approach requires no application code changes, as the settings are automatically available via standard configuration APIs (e.g., `Environment.GetEnvironmentVariable` in .NET or `process.env` in Node.js), and you can configure different values per deployment slot (e.g., development, staging, production) without redeploying the application.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing Azure App Configuration or Key Vault for all configuration needs, forgetting that Azure App Service application settings are the simplest, most direct way to handle environment-specific, non-sensitive settings without additional code or services.

How to eliminate wrong answers

Option A is wrong because Azure Key Vault secrets are designed for storing sensitive data (e.g., passwords, connection strings) and require explicit code changes to retrieve them via SDK calls or a managed identity, adding complexity for non-sensitive configuration settings. Option B is wrong because Azure DevOps variable groups are a build-time mechanism that injects values during the CI/CD pipeline, not a runtime configuration service; this would require modifying the build process and does not leverage Azure App Service's native environment-based settings. Option C is wrong because Azure App Configuration with feature flags is a centralized configuration service for managing feature toggles and hierarchical settings, but it is overkill for simple environment-specific key-value pairs and requires additional SDK integration in the application code.

Practice this question →
64
MCQhard

A containerized booking backend deployed to Azure Container Apps must scale to zero when idle and scale out based on queue length. What should the developer configure?

A.A manual replica count only
B.An Availability Set
C.An Azure Front Door health probe
D.A KEDA-based scale rule for the queue trigger
AnswerD

Azure Container Apps uses KEDA scale rules to scale replicas based on event sources such as queues.

Why this answer

KEDA (Kubernetes Event-Driven Autoscaling) is natively integrated with Azure Container Apps to enable event-driven scaling. By configuring a KEDA-based scale rule with an Azure Queue Storage trigger, the container app can scale to zero replicas when the queue is empty and scale out based on the queue length, meeting the requirement for idle scaling and queue-driven scaling.

Exam trap

The trap here is that candidates may confuse Azure Front Door health probes (used for traffic routing) with scaling triggers, or assume manual replica counts or Availability Sets are relevant to container scaling, when in fact KEDA is the specific technology for event-driven scaling in Azure Container Apps.

How to eliminate wrong answers

Option A is wrong because a manual replica count only sets a fixed number of replicas and cannot scale to zero or dynamically scale based on queue length. Option B is wrong because an Availability Set is a feature for virtual machine high availability within a region, not applicable to Azure Container Apps which uses replica-based scaling. Option C is wrong because an Azure Front Door health probe is used for load balancing and routing traffic based on backend health, not for scaling container replicas based on queue metrics.

Practice this question →
65
MCQmedium

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

A.Azure Functions with Blob Storage trigger, using leaseBlob
B.Azure Logic Apps with Blob Storage connector
C.Azure Functions with Event Grid trigger
D.Azure Functions with Service Bus queue trigger and duplicate detection
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
66
MCQeasy

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

A.Set the batchSize to 1 in host.json
B.Set the maxMessages to 1 in the ServiceBusTrigger attribute
C.Set the function to run on a Premium Plan
D.Set the maxDequeueCount to 1 in host.json
AnswerA

Setting the `batchSize` to `1` within the `host.json` file for the Service Bus trigger ensures that the Azure Function runtime processes only one message per function invocation. This configuration is crucial when strict message ordering or atomicity for individual messages is required, preventing the function from receiving multiple messages in a single batch. It directly controls the maximum number of messages the trigger will attempt to retrieve and process concurrently within one execution, effectively disabling batching.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
67
MCQmedium

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

A.Embed the connection string in the container image as a configuration file.
B.Store the connection string in an environment variable in the container group.
C.Enable managed identity for the container group and use Microsoft Entra authentication to Azure SQL.
D.Mount a volume from Azure Key Vault using a secret volume.
AnswerC

Enabling managed identity for the container group and using Microsoft Entra authentication to Azure SQL is the most secure and recommended approach. A managed identity provides an automatic, Azure AD-managed identity for the container group, allowing it to authenticate to Azure SQL Database without any credentials needing to be stored in code or configuration. This eliminates the risk of secret leakage and simplifies credential rotation, as Azure handles the identity lifecycle.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
68
MCQhard

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

A.Implement custom health checks using the ASP.NET Core Health Checks middleware.
B.Use the ASP.NET Core Diagnostics middleware to generate a health page.
C.Configure Application Insights availability tests.
D.Use the built-in health check endpoint in Azure App Service.
AnswerA

The ASP.NET Core Health Checks middleware provides a robust and extensible framework for monitoring the operational health of an application and its dependencies. Developers can register custom health checks for various components like databases, external APIs, or message queues, defining specific logic to determine their status. This middleware exposes an endpoint that returns detailed health reports, allowing for custom HTTP status codes (e.g., 200 for healthy, 503 for unhealthy, or even 400 for specific application-defined issues) based on the aggregated health of all registered checks, making it ideal for granular application-level monitoring.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
69
MCQeasy

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

A.Azure Blob Storage output binding
B.Azure Cosmos DB input binding
C.Azure Storage Queue output binding
D.Azure Cosmos DB output binding
AnswerD

The Azure Cosmos DB output binding is the correct choice because it is specifically designed to write new documents or update existing ones within an Azure Cosmos DB collection directly from an Azure Function. This binding handles the underlying connection and data serialization, allowing the function to output a C# object, JavaScript object, or array of objects that are then automatically persisted as JSON documents into the specified Cosmos DB database and collection.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
70
MCQhard

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

A.Fan-out/fan-in
B.Human interaction
C.Function chaining
D.Monitor pattern
AnswerA

The Fan-out/fan-in pattern in Durable Functions is specifically designed to execute multiple activity functions concurrently and then wait for all of them to complete before proceeding. This is achieved by initiating several parallel tasks and then using `Task.WhenAll` (or similar language construct) within the orchestrator function to aggregate their results. For a checkout API needing to call five distinct services, this pattern efficiently distributes the workload and ensures all necessary responses are collected before the workflow continues.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
71
MCQmedium

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

A.Always
B.OnFailure
C.Never
D.Retry
AnswerB

The "OnFailure" restart policy is specifically designed for task-based or batch jobs that require retries only when they terminate unexpectedly. It instructs Azure Container Instances to restart the container exclusively when its exit code is non-zero, which signifies an error or abnormal termination. This precisely matches the requirement to restart on failure, preventing unnecessary re-execution of successfully completed jobs and optimizing resource utilization and cost efficiency for idempotent background tasks.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
72
Multi-Selectmedium

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

Select 1 answer
A.Define environment variables on each container with the hostnames.
B.Deploy all containers in the same container group.
C.Assign different private IP addresses to each container.
D.Deploy containers in separate container groups and use service discovery.
E.Use the container group's fully qualified domain name (FQDN) to communicate.
AnswersB

Correct. Containers in the same container group share the same network namespace, enabling localhost communication.

Why this answer

Containers within the same container group in Azure Container Instances share the same network namespace, including the same IP address and port space. This allows them to communicate over localhost (127.0.0.1) without additional configuration, as they are essentially running on the same virtual machine. Option E is incorrect because using the container group's FQDN does not enable localhost communication; the FQDN resolves to the group's IP address, which is not localhost.

Containers in the same group can communicate via localhost directly, without needing the FQDN.

Exam trap

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

Practice this question →
73
MCQhard

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

A.Configure deployment slot settings to be sticky.
B.Enable auto swap and configure a custom warm-up path.
C.Use swap with preview and complete the swap after verification.
D.Configure manual swap and run a warm-up script before swapping.
AnswerB

Enabling auto swap combined with a custom warm-up path is the correct solution because it automates the entire deployment and verification process. Auto swap automatically initiates the swap after a successful deployment to the staging slot. The custom warm-up path ensures the application fully initializes and becomes responsive before the swap is finalized, and crucially, if the warm-up path returns an HTTP error, Azure App Service automatically rolls back the swap, preventing a broken application from reaching production.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
74
MCQhard

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

A.The command did not include admin credentials or managed identity configuration
B.The image tag 'latest' does not exist
C.The web app is configured to use a deployment slot, but the slot is not specified
D.The --docker-registry-server-url is incorrect
AnswerA

The error likely indicates an unauthorized or access denied issue when the Azure Web App attempts to pull the Docker image from the Azure Container Registry (ACR). To successfully pull images from a private registry like ACR, the web app requires explicit authentication. This can be achieved by providing ACR admin credentials (username and password) via application settings or by configuring a system-assigned or user-assigned managed identity with AcrPull role permissions on the ACR. Without either method, the pull operation will fail due to lack of authorization.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
75
MCQhard

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

A.await context.CallActivityAsync("MyActivity", input);
B.await context.CallActivityWithRetryAsync("MyActivity", new RetryOptions(TimeSpan.FromSeconds(2), 3), input);
C.await context.CallSubOrchestratorAsync("MyActivity", input);
D.await context.CallHttpAsync(HttpMethod.Get, new Uri("..."), input);
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
Page 1 of 4 · 226 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Develop Azure compute solutions questions.

Start 20-question session