CCNA Develop Azure compute solutions Questions — Page 3 of 4

151

MCQeasy

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

A.App Service Plan

B.Consumption Plan

C.Premium Plan

D.Dedicated Plan

AnswerB

Consumption Plan scales automatically based on demand and charges only for execution time (per-second billing).

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

152

MCQmedium

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

A.Manually increase the instance count during peak hours.

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

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

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

AnswerC

Autoscale can add instances when CPU exceeds a threshold.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

153

MCQeasy

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

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

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

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

D.Use Durable Functions with a retry policy.

AnswerC

Built-in retry supports exponential backoff and is easy to configure.

Why this answer

Option A is correct because the built-in retry policy for Azure Functions (in host.json) allows you to specify retry count and strategy (fixed delay or exponential backoff) for Storage queue triggers. Option B is wrong because implementing retry logic inside the function code is less maintainable and duplicates built-in functionality. Option C is wrong because Durable Functions are for orchestrating long-running workflows, not for simple retries.

Option D is wrong because the built-in retry policy is configurable.

Practice this question →

154

MCQeasy

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

A.Azure Logic Apps.

B.Azure Batch.

C.Azure Functions (Consumption plan).

D.Azure Container Instances.

AnswerD

ACI can run containers for up to 2 hours.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

155

MCQmedium

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

A.Horizontal Pod Autoscaler

B.Virtual Node

C.Vertical Pod Autoscaler

D.Cluster Autoscaler

AnswerA

HPA can scale pods based on custom metrics from Azure Monitor or Prometheus.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

156

MCQmedium

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

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

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

C.Use Azure App Configuration with feature flags.

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

AnswerB

This integrates with AKS, supports automatic rotation, and reduces overhead.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

157

MCQeasy

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

A.Azure Functions with Event Hubs trigger

B.Azure Batch with Event Hubs input

C.Azure Logic Apps with Event Hubs connector

D.Azure WebJobs with Event Hubs SDK

AnswerA

Functions are serverless and the Event Hubs trigger is designed for high-throughput, low-latency event ingestion.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

158

MCQhard

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

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

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

C.Use a timer trigger to schedule retries after failure

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

AnswerB

This uses the native retry mechanism: 3 attempts, 5s initial delay, doubled each time (5, 10, 20 seconds approximate).

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

159

Multi-Selectmedium

You are designing a solution that uses Azure Functions to process events from Azure Event Hubs. Which TWO features should you enable to ensure the function processes events in order and exactly once?

Select 2 answers

A.Durable Functions

B.Process events in batches

C.Implement checkpointing in the function

D.Enable session support on Event Hubs and use the session-enabled trigger

E.Use a retry policy in the function

AnswersC, D

Checkpointing stores the last processed event offset, ensuring exactly-once processing.

Why this answer

Option C is correct because checkpointing in Azure Functions allows the function to record the last successfully processed event offset and partition. When the function resumes, it reads from that checkpoint, ensuring that events are processed exactly once within the partition, even if the function restarts or scales.

Exam trap

The trap here is that candidates often think Durable Functions or retry policies guarantee exactly-once processing, but they do not address the fundamental need for checkpointing and session-aware consumption to maintain order and prevent duplicates in a distributed event processing system.

Practice this question →

160

Multi-Selecthard

Which THREE factors should you consider when choosing between Azure Functions (Consumption plan) and Azure Container Instances for running a background job that processes messages from Azure Service Bus?

Select 3 answers

A.Scaling behavior (automatic vs. manual).

B.Cost model (per execution vs. per second).

C.Ability to use custom base images.

D.Native support for Service Bus trigger.

E.Cold start latency.

AnswersA, B, E

Functions auto-scale; ACI may need manual scaling or scale rules.

Why this answer

Option A is correct because Azure Functions on the Consumption plan automatically scales out based on the number of incoming Service Bus messages, handling up to 200 concurrent instances per function app, while Azure Container Instances require manual scaling or external orchestration (e.g., KEDA) to adjust the number of container groups. This makes scaling behavior a key differentiator when choosing between the two services for a background job.

Exam trap

The trap here is that candidates often assume Azure Container Instances are always cheaper or more flexible for custom images, but they overlook the critical operational difference in scaling behavior and native trigger support, which are primary decision factors for event-driven background jobs.

Practice this question →

161

MCQhard

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

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

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

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

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

AnswerB

Application Insights now requires the connection string for authentication.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

162

MCQhard

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

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

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

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

D.The function does not handle poison messages correctly.

AnswerC

When lock expires, the message becomes available again and is reprocessed.

Why this answer

Option C is correct because the default lock duration for a Service Bus queue is 30 seconds, which is far shorter than the 10-minute processing time. When the lock expires, the message becomes visible to other consumers, causing duplicate processing. The function host does not extend the lock automatically unless the client explicitly renews it, leading to multiple deliveries.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

163

MCQmedium

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

A.Blob trigger + Consumption plan

B.HTTP trigger + Consumption plan

C.Queue trigger + Consumption plan

D.Timer trigger + Consumption plan

AnswerA

Correct. Blob trigger fires on new blobs, and Consumption plan scales out automatically to handle high volumes while charging only for execution time.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

164

MCQhard

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

A.Stream the blob content directly to the processing logic

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

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

D.Increase the memory allocation of the function app

AnswerA

Streaming processes data as it arrives, without loading the entire blob into memory.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

165

MCQhard

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

A.Azure Stream Analytics

B.Azure Data Factory

C.Azure Analysis Services

D.Azure Logic Apps

AnswerA

Stream Analytics is designed for real-time analytics on streaming data.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

166

MCQmedium

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

A.Secure environment variable

B.Container command-line argument

C.Public blob containing the password

D.Plain environment variable

AnswerA

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

Why this answer

Secure environment variables in Azure Container Instances are encrypted at rest and in transit, and they are not visible in the Azure portal or container logs. This ensures the password is available to the container at startup without exposing it through the portal interface or log output, meeting the security requirement.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

167

Multi-Selecthard

Which THREE considerations are important when designing an Azure Function that uses Durable Functions for fan-out/fan-in pattern?

Select 3 answers

A.The orchestrator function must be deterministic.

B.The orchestrator function should not perform any I/O operations directly.

C.Orchestration history is stored in memory to reduce latency.

D.The orchestrator function should be triggered by an HTTP trigger directly.

E.The function app must have a storage account connection string configured.

AnswersA, B, E

Non-deterministic code can cause issues during replay.

Why this answer

The orchestrator function in Durable Functions must be deterministic because it replays execution history multiple times to recover state after a process restart or to handle async operations. Non-deterministic code (e.g., random numbers, current time) would produce different results on replay, breaking the reliable execution model that Durable Functions relies on for fan-out/fan-in patterns.

Exam trap

The trap here is that candidates often confuse the orchestrator's role with a regular function, thinking it can perform I/O directly or be triggered by HTTP, when in fact it must be stateless and deterministic, relying on activity functions for all I/O.

Practice this question →

168

Multi-Selectmedium

Which THREE features does Azure Container Instances (ACI) provide?

Select 3 answers

A.Integrate with Azure Virtual Network by default.

B.Assign a public IP address and DNS name label.

C.Mount Azure Files shares as volumes.

D.Configure restart policies.

E.Run containers as nested containers (Docker-in-Docker).

AnswersB, C, D

ACI supports public IP and DNS labels.

Why this answer

Option B is correct because Azure Container Instances allows you to assign a public IP address and a DNS name label to a container group, enabling direct internet access to the container. This is configured at the container group level, and the DNS name label must be unique within the Azure region.

Exam trap

The trap here is that candidates often assume ACI automatically integrates with Azure Virtual Network, but this requires explicit configuration and is not enabled by default.

Practice this question →

169

MCQmedium

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

A.Service Bus trigger with Table storage output binding

B.Blob trigger with Cosmos DB output binding

C.HTTP trigger with Cosmos DB input binding

D.Service Bus trigger with Cosmos DB output binding

AnswerD

Correct combination for queue-triggered DB update.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

170

MCQmedium

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

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

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

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

D.The connection string does not use HTTPS.

AnswerC

Hardcoding keys in templates is insecure; use managed identities or Key Vault.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

171

MCQmedium

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

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

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

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

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

AnswerA

Setting sampling to 100% ensures all telemetry is sent, but may increase cost; however, for the Consumption plan it's acceptable if volume is manageable.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

172

MCQmedium

Your AKS cluster runs a microservices application. You need to expose an internal service only within the cluster virtual network. Which Service type should you use?

A.NodePort

B.Internal LoadBalancer (with annotation)

C.LoadBalancer

D.ClusterIP

AnswerB

Creates an internal load balancer accessible from the VNet.

Why this answer

ClusterIP is default and only accessible within the cluster, not from the VNet. LoadBalancer creates external IP, NodePort exposes on node IP, ExternalName maps to external DNS.

Practice this question →

173

Multi-Selecteasy

Which TWO features of Azure App Service can help you reduce application downtime during deployments?

Select 2 answers

A.Continuous deployment from GitHub.

B.Traffic Manager.

C.Deployment slots.

D.Auto-heal.

E.Slot swap with auto-swap.

AnswersC, E

Slots allow staging and swap with no downtime.

Why this answer

Deployment slots (C) are a feature of Azure App Service that allow you to deploy a new version of your application to a staging slot, perform validation, and then swap it into production with zero downtime. Slot swap with auto-swap (E) automates this process, ensuring that the production slot is updated only after the staging slot is fully warmed up and ready, eliminating downtime during the transition.

Exam trap

The trap here is that candidates often confuse high-availability features like Traffic Manager or Auto-heal with deployment-specific downtime reduction, but only deployment slots and slot swap directly address zero-downtime deployments within a single App Service instance.

Practice this question →

174

MCQmedium

You are implementing an Azure Durable Functions application that processes orders. The function must call three external APIs (payment gateway, inventory system, and shipping calculator) in parallel, then aggregate the results once all three have completed. Which Durable Functions pattern should you use?

A.Function chaining

B.Fan-out/Fan-in

C.Monitor

D.Human interaction

AnswerB

Fan-out calls multiple activity functions in parallel, and fan-in waits for all to complete before aggregating results.

Why this answer

The Fan-out/Fan-in pattern is designed exactly for this scenario: it triggers multiple function tasks in parallel (fan-out) and then aggregates their results once all complete (fan-in). In Durable Functions, this is implemented using `CallActivityAsync` in a loop with `Task.WhenAll` to wait for all parallel activities to finish, allowing the orchestrator to collect and process the combined results.

Exam trap

The trap here is that candidates may confuse 'parallel execution' with 'chaining' or 'monitoring', but the key differentiator is the need to wait for all parallel tasks to finish before aggregating results, which is the hallmark of the Fan-out/Fan-in pattern.

How to eliminate wrong answers

Option A is wrong because Function chaining executes activities sequentially, one after another, which would not achieve the required parallel API calls and would increase total execution time. Option C is wrong because the Monitor pattern is used for polling an external status or waiting for a condition to be met, not for parallel execution and aggregation of multiple independent tasks. Option D is wrong because the Human interaction pattern involves waiting for external input (e.g., approval or manual intervention), which is unrelated to parallel API calls and result aggregation.

Practice this question →

175

MCQeasy

Configuration values that control whether a new checkout experience is enabled must be changeable without redeploying the App Service application. The team uses ASP.NET Core. Which Azure service provides the correct combination of runtime configuration reload and feature flag management?

A.Azure App Configuration with the feature management library enabled for ASP.NET Core

B.App Service Application Settings with the flag stored as an environment variable

C.An ARM template parameter file stored in the application's repository

D.An Azure DevOps pipeline variable referenced during the build stage

AnswerA

App Configuration's feature flags integrate with IFeatureManager in ASP.NET Core. The library polls App Configuration at a configurable interval (e.g., 30 seconds). Toggling a feature flag in the portal causes the running application to pick up the change at the next polling cycle without a restart or redeployment.

Why this answer

Azure App Configuration with the feature management library for ASP.NET Core provides a centralized, managed service that supports dynamic configuration reload without restarting the application and built-in feature flag management. The feature management library integrates with the .NET Core configuration system, allowing feature flags to be evaluated and toggled at runtime via the `IFeatureManager` interface, with automatic refresh based on a configurable cache expiration. This meets the requirement of changing the checkout experience without redeploying the App Service.

Exam trap

The trap here is that candidates often confuse App Service Application Settings (which require a restart) with Azure App Configuration (which supports dynamic reload), or they assume pipeline variables can be changed at runtime without understanding they are compile-time artifacts.

How to eliminate wrong answers

Option B is wrong because App Service Application Settings stored as environment variables require an application restart to take effect when changed, and they lack native feature flag management capabilities like gradual rollout or targeting. Option C is wrong because an ARM template parameter file stored in the repository is used for infrastructure deployment, not runtime configuration; any change would require redeploying the ARM template and the application. Option D is wrong because an Azure DevOps pipeline variable referenced during the build stage is baked into the application at build time, so changing it requires a new build and deployment, violating the 'without redeploying' requirement.

Practice this question →

176

Matchingmedium

Match each Azure service to its primary purpose.

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

Concepts

Matches

NoSQL globally distributed database

Serverless compute for event-driven apps

Workflow automation and integration

Enterprise message broker with queues and topics

Event routing service for pub/sub

Why these pairings

These are core Azure services for building cloud applications.

Practice this question →

177

MCQeasy

You are developing a web app that runs on Azure App Service. The app needs to read a connection string from configuration. Which is the recommended approach to access the connection string in the app code?

A.Call an HTTP endpoint on the App Service instance

B.Use Environment.GetEnvironmentVariable("SQLAZURECONNSTR_MyConn")

C.Use Azure.Identity.DefaultAzureCredential and Key Vault

D.Read from appsettings.json using IConfiguration

AnswerB

Correct: App Service prefixes connection strings with the type, and they are available as environment variables.

Why this answer

Option B is correct because Azure App Service automatically injects connection strings defined in the 'Connection strings' blade as environment variables with a specific prefix. For SQL Azure, the prefix is 'SQLAZURECONNSTR_', so the environment variable name becomes 'SQLAZURECONNSTR_MyConn'. Using Environment.GetEnvironmentVariable is the recommended way to retrieve these values at runtime, as they are securely stored and managed by the platform.

Exam trap

The trap here is that candidates often assume IConfiguration or appsettings.json is the primary source for connection strings, but Azure App Service overrides these with environment variables when connection strings are configured in the portal, and the exam expects you to know the specific prefix-based environment variable naming convention.

How to eliminate wrong answers

Option A is wrong because there is no standard HTTP endpoint on an App Service instance that exposes connection strings; this approach is not supported and would require custom implementation. Option C is wrong because while Azure.Identity.DefaultAzureCredential and Key Vault are valid for secrets, they are not the recommended approach for App Service connection strings—App Service already manages them securely via environment variables, and using Key Vault adds unnecessary complexity and latency for this specific scenario. Option D is wrong because reading from appsettings.json using IConfiguration would only work for connection strings hardcoded in the file, not for those configured in the App Service portal; the portal-defined connection strings override appsettings.json values and are injected as environment variables, not into the IConfiguration pipeline by default.

Practice this question →

178

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?

A.App Service Free tier

B.Premium plan

C.Azure Batch pool

D.Consumption plan

AnswerB

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

Why this answer

The Premium plan is correct because it supports VNet integration, allows execution for up to 30 minutes (unlimited execution duration), and provides serverless scaling without managing virtual machines. The Consumption plan has a 10-minute timeout and lacks VNet integration for all triggers, while the Premium plan offers these features with pre-warmed instances and dedicated compute resources.

Exam trap

The trap here is that candidates often assume the Consumption plan supports VNet integration for all triggers and has a flexible timeout, but in reality, VNet integration is limited to Premium and Dedicated plans, and Consumption has a hard 10-minute timeout.

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, making it unsuitable for a long-running image resize worker. Option C is wrong because Azure Batch pool requires managing virtual machines and a job scheduler, not serverless scaling without VM management. Option D is wrong because the Consumption plan has a maximum execution timeout of 10 minutes (260 seconds for HTTP triggers) and does not support VNet integration for all trigger types, failing the 30-minute requirement.

Practice this question →

179

Multi-Selecthard

Which TWO options are valid ways to scale an Azure Functions app running on the Premium plan?

Select 2 answers

A.Disable scale-to-zero to keep instances always warm.

B.Configure pre-warmed instances to reduce cold start.

C.Set minimum and maximum instance counts.

D.Scale out based on the length of a storage queue.

E.Set the scale mode to 'Automatic' with no configuration.

AnswersB, C

Pre-warmed instances are a Premium feature.

Why this answer

Option B is correct because pre-warmed instances in the Premium plan reduce cold start latency by keeping a specified number of instances always loaded and ready to handle requests. Option C is correct because the Premium plan allows you to set both minimum and maximum instance counts, giving you control over baseline capacity and scaling limits. These settings are configured in the function app's scale settings and are not available in the Consumption plan.

Exam trap

The trap here is that candidates confuse the Premium plan's scaling capabilities with the Consumption plan's, mistakenly thinking that options like disabling scale-to-zero or configuring queue-length-based scaling rules are directly configurable in the Premium plan, when in fact the Premium plan's scaling is automatic and only allows setting min/max instance counts and pre-warmed instances.

Practice this question →

180

MCQhard

You are building a serverless application using Azure Functions. The function processes large CSV files uploaded to Azure Blob Storage. Each file can be up to 100 MB. The function must parse the file and insert each row into a SQL database. You need to minimize cold start latency and ensure the function can handle the processing within the default timeout. What should you do?

A.Use the Premium plan with pre-warmed instances.

B.Use a dedicated App Service plan with Always On enabled.

C.Use Durable Functions to split processing into smaller chunks.

D.Use the Consumption plan and increase the function timeout to 10 minutes.

AnswerB

Always On keeps the function warm, and the plan allows up to 230 seconds execution time.

Why this answer

Option B is correct because a Dedicated App Service plan with Always On enabled eliminates cold starts by keeping the function host loaded continuously, and it provides a default timeout of 30 minutes (configurable up to 230 minutes), which is sufficient for processing 100 MB CSV files. The Consumption plan has a default timeout of 5 minutes (max 10 minutes), which may not be enough for large file processing, and it suffers from cold starts. The Premium plan reduces cold starts with pre-warmed instances but is not necessary when a Dedicated plan with Always On is more cost-effective and meets the requirements.

Exam trap

The trap here is that candidates often assume the Premium plan with pre-warmed instances is the only way to eliminate cold starts, overlooking that a Dedicated App Service plan with Always On provides the same benefit with a longer default timeout and lower cost for predictable workloads.

How to eliminate wrong answers

Option A is wrong because the Premium plan with pre-warmed instances reduces cold starts but is not the most cost-effective choice when a Dedicated App Service plan with Always On can achieve the same goal with lower cost for predictable workloads. Option C is wrong because Durable Functions are designed for orchestrating long-running workflows and fan-out/fan-in patterns, not for directly solving cold start latency or extending the default timeout for a single function execution. Option D is wrong because the Consumption plan's maximum timeout is 10 minutes, which may still be insufficient for processing a 100 MB CSV file, and it does not address cold start latency.

Practice this question →

181

MCQmedium

You deploy a container to Azure Container Instances (ACI). The container runs a background job that 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.Set restart policy to Always and use a private container registry

B.Set restart policy to OnFailure and use a single container group

C.Set restart policy to Never and use a public container registry

D.Set restart policy to OnFailure and deploy in a virtual network

AnswerB

OnFailure restarts only on crashes, and a single container group is the simplest and lowest-cost configuration.

Why this answer

The OnFailure restart policy restarts the container only when it exits with a non-zero exit code, which matches the requirement to restart only on crashes. This policy minimizes costs because the container does not run continuously when it exits successfully, unlike the Always policy. Using a single container group is the simplest and most cost-effective deployment for a single background job.

Exam trap

The trap here is that candidates may confuse OnFailure with Always, thinking that any restart policy that restarts on failure must also restart on success, or they may over-engineer the solution by adding unnecessary features like a virtual network or private registry.

How to eliminate wrong answers

Option A is wrong because the Always restart policy restarts the container regardless of exit code, causing unnecessary runs and higher costs, and using a private container registry does not affect restart behavior. Option C is wrong because the Never restart policy does not restart the container at all, even on crashes, failing the requirement. Option D is wrong because deploying in a virtual network adds complexity and cost without any benefit for the restart policy requirement; the OnFailure policy itself is correct, but the virtual network is unnecessary and increases expenses.

Practice this question →

182

MCQhard

You are running a containerized application on Azure Container Instances. The application requires a custom DNS server. How should you configure this?

A.Set the DNS server in the container's environment variables

B.Use the 'dnsConfig' property in the container group configuration

C.Set the restart policy to 'Always'

D.Configure the DNS server in the Dockerfile

AnswerB

dnsConfig sets custom DNS servers for the container group.

Why this answer

Azure Container Instances (ACI) supports custom DNS server configuration at the container group level via the 'dnsConfig' property in the deployment JSON or ARM template. This property allows you to specify an array of DNS server IP addresses and optional search domains, which are applied to all containers within the group. Environment variables cannot override DNS resolution, and the Dockerfile's DNS settings are ignored by ACI because the container group's network stack is managed by the Azure platform.

Exam trap

The trap here is that candidates assume DNS configuration can be set via environment variables or the Dockerfile, similar to how they might configure it in a standalone Docker environment, but ACI requires explicit container group-level network settings that override any container-level DNS directives.

How to eliminate wrong answers

Option A is wrong because environment variables are for runtime configuration (e.g., connection strings, feature flags) and have no effect on DNS resolution; ACI does not interpret any environment variable as a DNS server. Option C is wrong because the restart policy ('Always', 'OnFailure', 'Never') controls container restart behavior after exit, not network or DNS configuration. Option D is wrong because the Dockerfile's DNS settings (e.g., '--dns' in Docker build or 'dns' directive) are overridden by the container orchestrator; ACI uses its own network namespace and ignores Dockerfile-level DNS configuration.

Practice this question →

183

Multi-Selecteasy

You are deploying a web app to Azure App Service. You need to enable continuous deployment from a GitHub repository. Which TWO actions are required?

Select 2 answers

A.Create a new App Service plan

B.Set up a build provider like GitHub Actions or Kudu

C.Configure the Deployment Center in the App Service to connect to GitHub

D.Enable Application Insights

E.Add a custom domain to the App Service

AnswersB, C

Build provider handles the build and deployment steps.

Why this answer

B is correct because to enable continuous deployment from GitHub, you need a build provider that compiles your code and deploys it to Azure App Service. GitHub Actions is a modern CI/CD solution that can build and deploy your application, while Kudu is the legacy deployment engine that can also handle build and sync operations. Without a build provider, the source code cannot be transformed into a runnable application on App Service.

Exam trap

The trap here is that candidates often think creating an App Service plan (Option A) is a required step for continuous deployment, but the plan is a separate prerequisite for hosting the web app, not for the deployment pipeline itself.

Practice this question →

184

MCQmedium

A booking backend uses Azure Functions with HTTP triggers. The developer wants to reject unauthenticated calls before function code executes. Which feature should be configured?

A.Application Insights sampling

B.App Service Authentication / Easy Auth with Microsoft Entra ID

C.Deployment slots

D.Function timeout

AnswerB

Built-in authentication validates requests before they reach application code.

Why this answer

App Service Authentication (Easy Auth) with Microsoft Entra ID allows the developer to reject unauthenticated calls before the function code executes by configuring the 'Action to take when request is not authenticated' to 'Log in with Microsoft Entra ID' or 'Return HTTP 401 Unauthorized'. This is enforced at the App Service platform layer, meaning the function trigger code never runs for unauthenticated requests, which is exactly the requirement.

Exam trap

The trap here is that candidates may think authentication must be handled inside the function code using attributes like [Authorize] or manual token validation, overlooking the platform-level Easy Auth feature that rejects calls before any code runs.

How to eliminate wrong answers

Option A is wrong because Application Insights sampling is a telemetry feature that reduces the volume of data collected for monitoring and diagnostics; it has no capability to authenticate or reject HTTP requests. Option C is wrong because deployment slots are used for staging, swapping, and testing different versions of the function app; they do not provide any authentication or authorization mechanism. Option D is wrong because function timeout controls the maximum execution duration for a function (default 5 minutes for Consumption plan); it cannot reject unauthenticated calls before code execution.

Practice this question →

185

MCQeasy

You are deploying a containerized application to Azure Container Instances. The application requires a custom domain name and SSL/TLS termination. You need to configure these features. Which resource should you create alongside the container group?

A.Azure Front Door

B.Azure Application Gateway

C.Azure Container Registry

D.Azure DNS zone

AnswerB

Azure Application Gateway can terminate SSL, route traffic based on host names, and assign a custom domain to the container group.

Why this answer

Azure Application Gateway provides Layer 7 load balancing with SSL/TLS termination and custom domain support. By associating a custom domain with the Application Gateway's frontend IP and uploading an SSL certificate, you can terminate HTTPS connections at the gateway and forward traffic to the container group over HTTP. This meets the requirement without exposing the container group directly.

Exam trap

The trap here is that candidates often confuse Azure Front Door's global SSL termination with the regional, direct SSL termination needed for a single container group, or mistakenly think a DNS zone alone can handle SSL termination.

How to eliminate wrong answers

Option A is wrong because Azure Front Door is a global, anycast-based load balancer and CDN that terminates SSL at the edge, but it is designed for HTTP/S traffic distribution across regions, not for direct SSL termination and custom domain binding to a single container group in a specific region. Option C is wrong because Azure Container Registry is a private Docker registry for storing and managing container images; it does not provide networking features like custom domains or SSL termination. Option D is wrong because Azure DNS zone is used for hosting DNS records and resolving domain names to IP addresses, but it does not terminate SSL/TLS or route traffic to the container group; it only provides name resolution.

Practice this question →

186

MCQmedium

You are developing a solution that uses Azure Container Instances to run a batch job. The job requires 8 GB of memory and 4 vCPUs. You need to minimize costs. Which container group configuration should you choose?

A.Linux containers split into two containers (4 GB each) in the same group

B.Linux container with 8 GB and 4 vCPUs in a single container group

C.Windows container with 8 GB memory and 4 vCPUs

D.Linux container with 8 GB and 4 vCPUs, but using two separate container groups

AnswerB

Linux is cheaper, single group minimizes overhead.

Why this answer

Option B is correct because Azure Container Instances bills per container group, not per container within the group. A single Linux container with 8 GB and 4 vCPUs in one container group meets the job's requirements with the lowest cost, as it avoids the overhead of multiple containers or groups. Splitting resources across containers or using separate groups would increase costs without benefit.

Exam trap

The trap here is that candidates may think splitting resources across multiple containers or groups reduces cost, but Azure bills per container group as a whole, so consolidating into a single group with the required resources is the most cost-effective approach.

How to eliminate wrong answers

Option A is wrong because splitting the job into two containers (4 GB each) in the same group does not reduce cost—the group still requires the sum of resources (8 GB, 4 vCPUs) and is billed as a single unit, so there is no savings. Option C is wrong because Windows containers in Azure Container Instances are more expensive than Linux containers for the same resource allocation, increasing cost without technical necessity. Option D is wrong because using two separate container groups incurs billing for each group independently, doubling the cost compared to a single group with the same total resources.

Practice this question →

187

MCQmedium

Refer to the exhibit. You deploy this ARM template to create an Azure App Service. After deployment, the application stops responding after a few minutes. The application is a .NET 6 web API that runs in a Linux container. What is the most likely cause?

A.The ARM template is missing the 'dependsOn' element.

B.The 'linuxFxVersion' is set incorrectly for .NET 6.

C.The 'alwaysOn' setting is enabled but the App Service plan is on a tier that does not support Always On.

D.The 'WEBSITE_RUN_FROM_PACKAGE' app setting is incorrectly set to '1'.

AnswerC

Free/Shared tiers ignore Always On; app may be unloaded.

Why this answer

Option B is correct. The template sets 'alwaysOn' to true, which keeps the app loaded even when idle. However, the Free and Shared pricing tiers do not support Always On; the feature is only available in Basic, Standard, Premium, and Isolated tiers.

If the hosting plan is on a tier that doesn't support Always On, the setting is ignored, but more importantly, the app might be recycled due to idle timeout. The app stops responding, indicating that the app pool recycles. Option A is wrong because 'WEBSITE_RUN_FROM_PACKAGE' is valid.

Option C is wrong because 'linuxFxVersion' is correct for .NET 6. Option D is wrong because the template is valid JSON.

Practice this question →

188

MCQmedium

An App Service application uses a staging deployment slot connected to a staging database and a production slot connected to a production database. Both use an app setting called 'DbConnectionString'. After a slot swap, the production slot starts using the staging database connection string. What configuration change prevents this?

A.Mark the 'DbConnectionString' app setting as a deployment slot setting (sticky) so it remains bound to its slot across all swaps

B.Store the connection string in Azure Key Vault and reference it via a Key Vault reference in both slots

C.Use different app setting names for each slot (e.g., 'StagingDbConnectionString' and 'ProductionDbConnectionString') and swap code manually

D.Disable slot swaps and use a CI/CD pipeline to deploy directly to production instead

AnswerA

Sticky settings are slot-specific. When slots swap, the code moves but sticky settings stay with the slot they were defined in. The staging slot retains its staging DbConnectionString and the production slot retains its production DbConnectionString permanently, regardless of how many swaps occur.

Why this answer

Option A is correct because marking the 'DbConnectionString' app setting as a deployment slot setting (also called a sticky setting) ensures that the setting remains bound to its slot during a swap. When a slot swap occurs, Azure App Service automatically moves non-sticky app settings and connection strings to the target slot, but sticky settings are excluded from the swap and stay with their original slot. This prevents the production slot from accidentally picking up the staging database connection string after the swap.

Exam trap

The trap here is that candidates often think Key Vault references or different naming conventions solve the swap issue, but they overlook that the fundamental problem is the setting being non-sticky and moving with the swap, which only the 'deployment slot setting' flag can prevent.

How to eliminate wrong answers

Option B is wrong because storing the connection string in Azure Key Vault and referencing it via a Key Vault reference does not prevent the setting from being swapped; the reference itself is an app setting that is non-sticky by default and will move with the swap. Option C is wrong because using different app setting names for each slot and manually swapping code defeats the purpose of automated slot swaps and introduces human error; it does not leverage the built-in slot swap mechanism. Option D is wrong because disabling slot swaps and using a CI/CD pipeline to deploy directly to production avoids the issue but eliminates the benefits of slot swapping (e.g., zero-downtime deployment, easy rollback); it is a workaround, not a configuration change that prevents the problem.

Practice this question →

189

Multi-Selecthard

You are deploying a critical application on Azure App Service. The application must be highly available across two Azure regions. You need to implement a disaster recovery strategy that meets the following requirements: automatic failover with minimal data loss, and the ability to test failover without affecting production. Which THREE actions should you perform?

Select 3 answers

A.Use deployment slots to test failover before making it active.

B.Configure the app to use active-passive database replication.

C.Configure Azure Traffic Manager with priority routing to fail over automatically.

D.Deploy both instances in the same App Service Plan.

E.Deploy the app to two Azure App Service instances in paired regions.

AnswersA, C, E

Slots allow you to swap and test without affecting production.

Why this answer

Option A is correct because deployment slots in Azure App Service allow you to create separate environments (e.g., staging) that can be swapped to production. This enables testing failover scenarios (like pointing Traffic Manager to the staging slot) without affecting the live production traffic, meeting the requirement for non-disruptive failover testing.

Exam trap

The trap here is that candidates often confuse deployment slots with actual cross-region failover, but slots are for in-place staging/testing within a single region, not for disaster recovery across regions—however, they are correctly used here to test the failover behavior before making it active.

Practice this question →

190

MCQmedium

Your company runs a critical web application on Azure App Service (Windows) that experiences intermittent high CPU usage. The application uses the Standard tier with auto-scaling based on CPU percentage. During auto-scale events, there is a delay of several minutes before new instances become available, causing temporary performance degradation. You need to reduce the latency of scaling out. What should you do?

A.Configure auto-scaling to use HTTP queue length as the metric.

B.Enable the 'Always On' setting in the App Service application settings.

C.Upgrade the App Service plan to the Premium tier.

D.Change the auto-scale metric to memory percentage instead of CPU.

AnswerB

Always On prevents the app from being unloaded, reducing cold start time.

Why this answer

The 'Always On' setting prevents the App Service from being unloaded after periods of inactivity, which reduces the cold-start latency when new instances are added during auto-scale events. Without 'Always On', idle instances may be recycled, causing delays of several minutes as the application re-initializes on new VMs.

Exam trap

The trap here is that candidates often assume upgrading the tier or changing the metric will solve scaling latency, but the real bottleneck is the cold-start time of the application itself, which 'Always On' directly mitigates.

How to eliminate wrong answers

Option A is wrong because HTTP queue length measures pending requests, not CPU usage, and does not address the latency of instance provisioning during scale-out. Option C is wrong because upgrading to Premium tier improves performance and features but does not directly reduce the delay in scaling out; the cold-start issue persists unless 'Always On' is enabled. Option D is wrong because changing the metric to memory percentage does not affect the time it takes for new instances to become available; it only changes the trigger for scaling.

Practice this question →

191

MCQhard

You run the command above to create an Azure Container Instance. The container exits with a non-zero exit code. You need to check the logs to debug the issue. Which command should you use next?

A.az container attach --resource-group myRG --name mycontainer

B.az container logs --resource-group myRG --name mycontainer

C.az container exec --resource-group myRG --name mycontainer --exec-command /bin/sh

D.az container show --resource-group myRG --name mycontainer --query containers[0].instanceView.currentState.exitCode

AnswerB

This command retrieves the logs of the container, even after it has exited.

Why this answer

The correct command is `az container logs` because it retrieves the stdout and stderr logs from a container that has exited, which is essential for debugging exit code failures. Since the container has already exited with a non-zero exit code, you need to inspect its logged output to understand the cause of the failure, and this command directly fetches those logs without requiring an active container.

Exam trap

The trap here is that candidates confuse `az container attach` (for live streaming of a running container) with `az container logs` (for retrieving historical logs from a stopped container), leading them to choose option A even though the container has already exited.

How to eliminate wrong answers

Option A is wrong because `az container attach` attaches your local console to a running container's output streams, but it requires the container to be currently running; it will not work for an already exited container. Option C is wrong because `az container exec` executes a command in a running container, but it cannot be used if the container has exited, as there is no active process to attach to. Option D is wrong because `az container show` with the query for exit code only returns the numeric exit code (e.g., 1), which does not provide the detailed log output needed to debug the root cause of the failure.

Practice this question →

192

MCQmedium

Refer to the exhibit. You run the Azure CLI command shown for an Azure Function app. What is the effect of this setting?

A.The function app uses the latest runtime version.

B.Remote debugging is enabled for the function app.

C.The function app scales out to multiple instances.

D.The function app runs from a deployment package in Azure Storage.

AnswerD

This setting enables run-from-package mode.

Why this answer

The `--run-from-package` flag in the Azure CLI command `az functionapp config appsettings set` sets the `WEBSITE_RUN_FROM_PACKAGE` app setting to `1`. This configures the function app to run from a deployment package (a .zip file) stored in Azure Blob Storage, which improves cold-start performance and ensures all files are consistent across instances. Option D correctly identifies this behavior.

Exam trap

Microsoft often tests the distinction between app settings that affect runtime behavior (like `FUNCTIONS_EXTENSION_VERSION` for version control) versus those that affect deployment and file serving (like `WEBSITE_RUN_FROM_PACKAGE`), leading candidates to confuse `--run-from-package` with runtime version or scaling settings.

How to eliminate wrong answers

Option A is wrong because the `--run-from-package` setting does not control the runtime version; runtime version is managed via the `FUNCTIONS_EXTENSION_VERSION` app setting or the `--functions-version` parameter during creation. Option B is wrong because remote debugging is enabled by setting `WEBSITE_REMOTE_DEBUGGING_ENABLED` to `1` and specifying a debugger version, not by `--run-from-package`. Option C is wrong because scaling out to multiple instances is controlled by the function app's plan (e.g., Consumption, Premium, or App Service plan) and scaling rules, not by the `WEBSITE_RUN_FROM_PACKAGE` setting.

Practice this question →

193

Multi-Selecthard

A document rendering job in Azure App Service must safely access Key Vault secrets without connection strings in configuration. Which two steps are required?

Select 2 answers

A.Enable a managed identity for the web app

B.Enable anonymous access on the vault

C.Grant the identity permission to read the required secrets

D.Store the Key Vault access key in app settings

AnswersA, C

A managed identity gives the app an Azure AD identity without stored credentials.

Why this answer

A managed identity provides an automatically managed Azure AD identity for the web app, eliminating the need to store credentials in code or configuration. By enabling a system-assigned or user-assigned managed identity, the App Service can authenticate to Azure Key Vault without any connection strings or secrets in app settings. This is the foundational step for secure, identity-based access to Key Vault.

Exam trap

The trap here is that candidates might think storing the Key Vault access key in app settings (Option D) is acceptable because it's 'in the portal,' but the question explicitly requires 'without connection strings in configuration,' and any key stored in app settings is still a connection string in configuration.

Practice this question →

194

MCQhard

You are developing an Azure Function that runs on a Consumption Plan. The function calls an external API that enforces a rate limit of 10 requests per second. When the function scales out to multiple instances, you must ensure the rate limit is not exceeded. Which pattern should you implement?

A.Use a singleton attribute on the function to ensure only one instance runs.

B.Use a static SemaphoreSlim in the function code to limit concurrent calls.

C.Configure the function's host.json to limit concurrency to 1.

D.Use a queue-based load leveling pattern with an Azure Storage Queue.

AnswerD

Messages are queued, and a function processes them at a controlled rate (e.g., using a timer or batching) to respect the API's rate limit, regardless of the number of instances.

Why this answer

Option D is correct because a queue-based load leveling pattern uses an Azure Storage Queue to buffer incoming requests, allowing the function to process them at a controlled rate. This decouples the function's scaling from the external API's rate limit, ensuring that even with multiple function instances, the total request rate does not exceed 10 requests per second. The queue acts as a buffer, and the function can be configured to dequeue and process messages at a fixed rate, effectively smoothing out spikes in demand.

Exam trap

The trap here is that candidates often confuse concurrency control within a single instance (Options B and C) with global rate limiting across scaled-out instances, leading them to overlook the need for a distributed coordination mechanism like queue-based load leveling.

How to eliminate wrong answers

Option A is wrong because using a singleton attribute forces the function to run on only one instance, which defeats the purpose of scaling out on a Consumption Plan and can lead to throttling or cold start issues; it does not inherently control the request rate to the external API. Option B is wrong because a static SemaphoreSlim limits concurrent calls within a single process, but on a Consumption Plan, multiple instances run in separate processes, so the semaphore is not shared across instances and cannot enforce a global rate limit. Option C is wrong because configuring host.json to limit concurrency to 1 only restricts the number of concurrent function executions within a single instance, but multiple instances can still run in parallel, potentially exceeding the rate limit across instances.

Practice this question →

195

MCQeasy

You are developing a web application that allows users to upload images. The application runs on Azure App Service. You need to ensure that uploaded images are stored in Azure Blob Storage and that the application remains responsive. What should you use?

A.Upload the image to the App Service and then copy it to Blob Storage.

B.Generate a SAS token for the user to upload directly to Blob Storage.

C.Use Azure Files for image storage.

D.Make the Blob container public for anonymous uploads.

AnswerB

SAS tokens allow secure, direct uploads without burdening the app server.

Why this answer

Option B is correct because generating a SAS token allows the user's browser to upload images directly to Azure Blob Storage without routing the data through the App Service. This keeps the web application responsive by offloading the upload workload to Azure Storage, avoiding blocking the App Service's limited HTTP request threads and reducing latency.

Exam trap

The trap here is that candidates assume all uploads must go through the App Service (Option A) because they think the app must 'own' the data first, missing the SAS-based direct upload pattern that Azure Blob Storage explicitly supports for offloading work.

How to eliminate wrong answers

Option A is wrong because uploading to the App Service first and then copying to Blob Storage introduces an unnecessary intermediary hop, consuming App Service resources (CPU, memory, network bandwidth) and blocking request threads, which degrades responsiveness and scalability. Option C is wrong because Azure Files is designed for SMB file shares (e.g., legacy app migration, shared configs), not for direct user uploads to a scalable object store; it lacks the built-in SAS-based direct upload pattern and is less optimized for high-throughput image ingestion. Option D is wrong because making the Blob container public for anonymous uploads removes all access control and authentication, creating a severe security risk where anyone can upload arbitrary content without restriction; SAS tokens provide time-limited, permission-scoped access.

Practice this question →

196

Multi-Selectmedium

You are developing a serverless application using Azure Functions. The application processes orders from a queue and writes results to Azure Cosmos DB. You need to ensure that the function scales out automatically to handle sudden spikes in order volume. Which two actions should you take? (Choose two.)

Select 2 answers

A.Configure the function app to use the Premium plan with Always Ready instances enabled.

B.Use the Consumption plan with a max instance count of 200.

C.Implement a retry policy in the queue trigger to handle throttling.

D.Set the function's WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT app setting to 500.

E.Deploy the function app to an App Service plan with multiple instances pre-allocated.

AnswersA, E

Premium plan supports Always Ready instances and can scale out quickly to handle spikes.

Why this answer

Option A is correct because the Premium plan supports Always Ready instances, which pre-warm a specified number of instances to eliminate cold start latency and ensure the function can handle sudden spikes in order volume without delay. This is critical for serverless applications that require consistent performance under load.

Exam trap

The trap here is that candidates often confuse the Consumption plan's max instance count with the ability to handle spikes instantly, overlooking the cold start issue that the Premium plan's Always Ready instances solve.

Practice this question →

197

MCQmedium

You develop an Azure Functions app that processes images triggered by blob uploads. You need to ensure the function can process images in parallel and handle high upload volumes without missing events. Which trigger and plan combination is recommended?

A.Event Grid trigger on Premium plan

B.Blob Storage trigger on Consumption plan

C.Event Grid trigger on Consumption plan

D.Blob Storage trigger on Premium plan

AnswerA

Correct. Event Grid provides built-in retry and high throughput, and Premium plan ensures sufficient resources and supports dynamic concurrency.

Why this answer

The Event Grid trigger on a Premium plan is recommended because Event Grid provides reliable, high-throughput event delivery with built-in retry and dead-lettering, ensuring no blob upload events are missed. The Premium plan offers dedicated instances and VNET connectivity, which avoids cold starts and allows parallel processing of multiple images concurrently, unlike the Consumption plan which has scaling limitations and potential for event loss under high volume.

Exam trap

The trap here is that candidates often assume the Blob Storage trigger is the natural choice for blob uploads, overlooking that Event Grid provides superior reliability and performance for high-volume scenarios, and that the Consumption plan's scaling limitations can lead to missed events or throttling.

How to eliminate wrong answers

Option B is wrong because the Blob Storage trigger on a Consumption plan uses a polling-based mechanism that can miss events under high upload volumes due to its reliance on Azure Storage logs, which have inherent latency and potential for data loss. Option C is wrong because while Event Grid is reliable, the Consumption plan has a maximum execution time of 10 minutes and limited concurrency, which can cause timeouts or throttling when processing many images in parallel. Option D is wrong because the Blob Storage trigger, even on a Premium plan, still uses the same polling-based approach that is less efficient and less reliable than Event Grid for high-volume, event-driven scenarios.

Practice this question →

198

MCQeasy

You are developing a web app that processes images uploaded by users. The processing can take up to 30 seconds per image. You need to ensure that the web app remains responsive and can handle spikes in traffic. Which Azure service should you use to offload the image processing?

A.Azure Cosmos DB

B.Azure Queue Storage

C.Azure Event Grid

D.Azure SignalR Service

AnswerB

Decouples processing and provides buffering for spikes.

Why this answer

Option A is correct because Azure Queue Storage decouples the web frontend from the processing backend, allowing the web app to remain responsive and scale independently. Option B is wrong because Event Grid is for event notifications, not long-running queue-based work. Option C is wrong because Azure Cosmos DB is a database.

Option D is wrong because SignalR Service is for real-time messaging.

Practice this question →

199

Multi-Selecteasy

Which TWO Azure services can be used to trigger an Azure Function when a new blob is added to an Azure Storage container? (Choose two.)

Select 2 answers

A.Azure Event Grid trigger

B.Azure Queue Storage trigger

C.Azure Blob Storage trigger

D.Azure Cosmos DB trigger

E.HTTP trigger

AnswersA, C

Event Grid can be set up with a Blob Created event to trigger the function.

Why this answer

Option A is correct because Azure Event Grid trigger enables an Azure Function to be invoked automatically when a new blob is created in a Storage account. Event Grid provides a reliable, low-latency event-driven architecture that supports blob created events, making it a valid trigger for this scenario.

Exam trap

The trap here is that candidates often assume only the Blob Storage trigger can react to blob creation, overlooking Event Grid as a valid alternative, or they mistakenly think Queue Storage or Cosmos DB triggers can be repurposed for blob events.

Practice this question →

200

MCQhard

Your company has a multi-tier application running on Azure Virtual Machines. The application experiences high CPU usage during peak hours. You need to implement autoscaling for the virtual machine scale set based on CPU usage. The scaling should be aggressive when CPU exceeds 80% and conservative when CPU drops below 30%. Which scaling rule configuration should you use?

A.Scale out when CPU > 50%, scale in when CPU < 20%

B.Scale out when CPU > 90%, scale in when CPU < 10%

C.Scale out when CPU > 70%, scale in when CPU < 70%

D.Scale out when CPU > 80%, scale in when CPU < 30%

AnswerD

High scale-out threshold ensures scaling only when truly needed; low scale-in threshold prevents premature scale-in.

Why this answer

Option D is correct because the question explicitly requires aggressive scaling when CPU exceeds 80% and conservative scaling when CPU drops below 30%. The scale-out threshold of 80% triggers rapid addition of instances to handle high load, while the scale-in threshold of 30% ensures instances are removed only when utilization is consistently low, preventing premature scale-in and thrashing. This matches the exact thresholds specified in the requirement.

Exam trap

The trap here is that candidates may choose Option C because it seems 'balanced' with a single threshold, not realizing that identical scale-out and scale-in thresholds cause autoscale flapping, and that the question explicitly demands distinct aggressive (80%) and conservative (30%) values.

How to eliminate wrong answers

Option A is wrong because it scales out at 50% and scales in at 20%, which does not match the required aggressive 80% scale-out and conservative 30% scale-in thresholds, leading to unnecessary scaling actions. Option B is wrong because it scales out at 90% and scales in at 10%, which is too aggressive on scale-in and too conservative on scale-out, failing to meet the specified 80% and 30% thresholds. Option C is wrong because it uses the same threshold (70%) for both scale-out and scale-in, which would cause constant oscillation (flapping) as the metric hovers around 70%, violating the requirement for distinct aggressive and conservative behaviors.

Practice this question →

201

MCQhard

You are developing an Azure Functions app that processes orders. Each order triggers a function that writes to Azure Cosmos DB. You notice occasional throttling (429 errors) from Cosmos DB during peak hours. The function app uses the Consumption plan. What is the most cost-effective way to reduce throttling?

A.Increase the provisioned throughput (RU/s) of the Cosmos DB container.

B.Upgrade the function app to the Premium plan for dedicated instances.

C.Increase the function app's instance count by scaling out.

D.Implement retry logic with exponential backoff in the function code.

AnswerD

Retries handle transient throttling without additional cost.

Why this answer

Option D is correct because implementing retry logic with exponential backoff is the most cost-effective way to handle transient 429 errors from Cosmos DB. The Azure Cosmos DB SDK already includes built-in retry policies, but custom retry logic in the function code can be tuned to match the workload, allowing the function to wait and retry during peak throttling without incurring additional costs from scaling or increasing throughput.

Exam trap

The trap here is that candidates often assume scaling the function app (Option C) or increasing Cosmos DB throughput (Option A) are the only ways to handle throttling, but they overlook that retry logic is a zero-cost, built-in mechanism that directly addresses the transient nature of 429 errors in a Consumption plan environment.

How to eliminate wrong answers

Option A is wrong because increasing provisioned throughput (RU/s) directly increases monthly costs, and it does not address the root cause of throttling during peak hours—it simply raises the ceiling, which is not cost-effective for sporadic bursts. Option B is wrong because upgrading to the Premium plan adds fixed costs for dedicated instances and always-on benefits, which are unnecessary when the Consumption plan already scales automatically; the throttling is on the Cosmos DB side, not the function app's compute capacity. Option C is wrong because scaling out the function app increases the number of concurrent function instances, which can actually increase the request rate to Cosmos DB and worsen throttling, not reduce it.

Practice this question →

202

MCQeasy

You are deploying a background processing job that reads messages from an Azure Storage Queue. The job must run on the same compute resources as the main web application and must not require additional deployment or monitoring overhead. Which solution should you use?

A.Deploy an Azure Function with a Queue trigger on the Consumption plan.

B.Add an Azure WebJob to the App Service that hosts the main application.

C.Create a separate Azure Container Instance to run a continuous job.

D.Use Azure Logic Apps with a recurrence trigger to poll the queue.

AnswerB

WebJobs are deployed as part of the App Service and run in the same process or as background processes, sharing the same plan and scaling without extra services.

Why this answer

Option B is correct because Azure WebJobs run in the same App Service plan as the main web application, sharing compute resources without requiring separate deployment or monitoring. A WebJob with a continuous trigger can read from an Azure Storage Queue using the QueueTrigger attribute, meeting the requirement of no additional overhead.

Exam trap

The trap here is that candidates often choose Azure Functions for queue processing without considering the requirement to share compute resources with the main web application, overlooking that WebJobs are the native background processing solution within App Service.

How to eliminate wrong answers

Option A is wrong because an Azure Function on the Consumption plan runs on separate, serverless compute resources, not on the same resources as the main web application, and introduces additional deployment and monitoring overhead. Option C is wrong because a separate Azure Container Instance requires its own compute resources, deployment pipeline, and monitoring, contradicting the requirement to run on the same resources as the main app. Option D is wrong because Azure Logic Apps with a recurrence trigger is a separate, managed service that runs independently of the web application's compute resources, adding deployment and monitoring overhead.

Practice this question →

203

MCQeasy

You need to deploy a containerized application to Azure Container Instances (ACI) with a public IP address and a DNS name label. Which YAML property should you configure for the DNS name?

A.dnsNameLabel

B.containerGroupName

C.ipAddress

D.ports

AnswerA

Correct property for DNS name.

Why this answer

The `dnsNameLabel` property in the Azure Container Instances YAML definition is used to assign a custom DNS prefix to the container group's public IP address. When combined with the Azure region's default domain suffix (e.g., `eastus.azurecontainer.io`), this creates a fully qualified domain name (FQDN) like `<dnsNameLabel>.eastus.azurecontainer.io`, allowing clients to resolve the container group via DNS without needing the raw IP address.

Exam trap

The trap here is that candidates often confuse `dnsNameLabel` with `containerGroupName` or `ipAddress`, mistakenly thinking the container group name or the IP address property itself controls the DNS label, when in fact `dnsNameLabel` is a nested property under `ipAddress` in the YAML schema.

How to eliminate wrong answers

Option B is wrong because `containerGroupName` is the logical name of the container group within Azure Resource Manager, not a DNS-related property; it does not influence the DNS label or FQDN. Option C is wrong because `ipAddress` defines the type (e.g., Public or Private) and the assignment of the IP address itself, but the DNS name label is a separate sub-property under `ipAddress` (specifically `ipAddress.dnsNameLabel`). Option D is wrong because `ports` specifies the container ports to expose (e.g., 80, 443) and their protocol (TCP/UDP), but it has no role in configuring the DNS name label.

Practice this question →

204

MCQeasy

Your company runs a web application on Azure App Service that uses a custom domain. The application must be accessible only via HTTPS. You have already uploaded an SSL certificate for the custom domain. However, users can still access the site via HTTP. You need to enforce HTTPS redirection. What should you do?

A.Set the 'Minimum TLS Version' to 1.2.

B.Add a rewrite rule in the web.config file to redirect HTTP to HTTPS.

C.Configure the App Service to require client certificates.

D.Enable the 'HTTPS Only' setting in the App Service's TLS/SSL settings blade.

AnswerD

This setting enforces HTTPS redirection at the platform level.

Why this answer

The 'HTTPS Only' setting in the App Service's TLS/SSL settings blade enforces that all incoming requests are redirected from HTTP to HTTPS at the platform level, before any application code runs. Since you have already uploaded an SSL certificate, enabling this setting ensures that users cannot access the site via HTTP, meeting the requirement without modifying application code.

Exam trap

The trap here is that candidates may think a web.config rewrite rule (Option B) is sufficient, but Azure explicitly recommends the platform-level 'HTTPS Only' setting because it is simpler, more reliable, and works regardless of the application stack (e.g., .NET, Node.js, Python).

How to eliminate wrong answers

Option A is wrong because setting 'Minimum TLS Version' to 1.2 only enforces that incoming HTTPS connections use TLS 1.2 or higher; it does not redirect HTTP traffic to HTTPS. Option B is wrong because while a rewrite rule in web.config can redirect HTTP to HTTPS, it is an application-level solution that may not cover all scenarios (e.g., requests that bypass the rewrite module) and is less reliable than the platform-level 'HTTPS Only' setting. Option C is wrong because requiring client certificates is for mutual TLS authentication, not for enforcing HTTPS redirection.

Practice this question →

205

MCQmedium

You are migrating an on-premises .NET Framework app to Azure. The app uses Windows authentication and requires persistent storage. You want to minimize rework. Which Azure compute service should you choose?

A.Azure Spring Apps

B.Azure Functions

C.Azure Container Instances

D.Azure App Service on Windows

AnswerD

App Service supports Windows authentication and persistent storage with Azure Files.

Why this answer

Azure App Service on Windows (D) supports Windows authentication natively via its built-in integration with Azure Active Directory and on-premises Active Directory through Azure AD Domain Services or hybrid identity setups. It also provides persistent storage options like Azure Files or blob storage attached to the web app, minimizing rework by allowing the existing .NET Framework app to run with minimal code changes in a Platform-as-a-Service (PaaS) environment.

Exam trap

The trap here is that candidates often choose Azure Functions or Container Instances for their 'modern' appeal, overlooking the specific requirement for Windows authentication and minimal rework, which Azure App Service on Windows uniquely satisfies without forcing a rewrite or containerization.

How to eliminate wrong answers

Option A is wrong because Azure Spring Apps is designed for Java Spring Boot microservices, not for .NET Framework apps, and does not support Windows authentication natively. Option B is wrong because Azure Functions is a serverless compute service optimized for event-driven, stateless workloads; it lacks native support for Windows authentication and persistent storage without significant rework (e.g., using external storage accounts). Option C is wrong because Azure Container Instances runs containers on Linux or Windows but requires containerizing the app, which introduces rework, and does not provide built-in Windows authentication or persistent storage without manual configuration.

Practice this question →

206

MCQeasy

A company deploys a web application to Azure App Service. They want to deploy a new version of the app with zero downtime and the ability to quickly roll back if needed. Which deployment feature should they use?

A.Auto-scaling

B.Deployment slots

C.Traffic Manager

D.Application Insights

AnswerB

Deployment slots enable staging, warm-up, and swapping with immediate rollback, providing zero-downtime deployments.

Why this answer

Deployment slots are separate, live environments within Azure App Service that allow you to stage a new version of your app, perform validation, and then swap it into production with zero downtime. The swap operation ensures all traffic is redirected instantly, and if issues arise, you can immediately swap back to the previous slot for a quick rollback.

Exam trap

The trap here is that candidates often confuse Traffic Manager (a global load balancer) with deployment slots, thinking DNS-level routing provides the same zero-downtime swap within a single App Service, but Traffic Manager cannot swap application versions or configurations within the same app.

How to eliminate wrong answers

Option A is wrong because auto-scaling adjusts the number of instances based on load, not the version of the application being deployed; it does not provide zero-downtime deployment or rollback capabilities. Option C is wrong because Traffic Manager is a DNS-based traffic routing service that distributes traffic across different regions or endpoints, not a feature for deploying new versions of an app within a single App Service instance with zero downtime and rollback. Option D is wrong because Application Insights is a monitoring and diagnostics service that tracks application performance and usage, not a deployment mechanism.

Practice this question →

207

MCQmedium

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

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

B.Deploy directly to production during business hours

C.Disable health checks

D.Restart the App Service plan before each deployment

AnswerA

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

Why this answer

Deploying to a staging slot allows the new version of the app to be fully initialized and validated via health checks before traffic is routed to it. The swap operation in Azure App Service moves the production traffic to the staging slot without any downtime, as the slots share the same front-end and the swap is atomic. This directly addresses the 502 errors caused by incomplete deployments and ensures zero-downtime release with validation.

Exam trap

The trap here is that candidates may think disabling health checks or restarting the plan solves intermittent errors, but the real issue is the lack of a safe staging environment for validation, which deployment slots directly provide.

How to eliminate wrong answers

Option B is wrong because deploying directly to production during business hours does not provide any validation before traffic hits the new code, and it risks exposing users to 502 errors if the deployment is incomplete or unhealthy. Option C is wrong because disabling health checks removes the ability to detect that the new deployment is returning 502 errors, which would allow unhealthy instances to serve traffic and worsen the issue. Option D is wrong because restarting the App Service plan before each deployment does not provide a staging environment for validation, and it causes downtime for all apps in the plan, contradicting the zero-downtime requirement.

Practice this question →

208

MCQhard

A team develops an Azure Functions app that processes IoT telemetry. They notice cold start latency is impacting performance. The function uses the Consumption plan. Which action reduces cold starts most effectively?

A.Use Durable Functions for long-running workflows

B.Change to Premium plan with pre-warmed instances

C.Increase the function timeout to maximum

D.Use a dedicated App Service plan

AnswerB

Premium plan keeps instances warm, eliminating cold starts.

Why this answer

Premium plan keeps instances warm, reducing cold starts. Option A is wrong because using durable functions adds orchestration overhead. Option B is wrong because increasing timeout doesn't affect cold start.

Option D is wrong because App Service plan also reduces cold starts but Premium plan is more cost-effective for variable load.

Practice this question →

209

Multi-Selectmedium

You are developing a solution that uses Azure Functions to process events from Azure Event Grid. The function must handle events reliably. Which TWO options should you implement?

Select 2 answers

A.Use Durable Functions for orchestration.

B.Enable retry policy on the Event Grid subscription.

C.Implement manual checkpointing in the function code.

D.Configure a dead-letter destination for undelivered events.

E.Use a queue trigger instead of an Event Grid trigger.

AnswersB, D

Retry policy helps handle transient failures.

Why this answer

Option B is correct because Event Grid subscriptions support automatic retry policies that can be configured to retry event delivery on transient failures, ensuring reliable processing. Option D is correct because a dead-letter destination (e.g., a storage blob) captures events that cannot be delivered after exhausting retries, preventing data loss and enabling later analysis.

Exam trap

The trap here is that candidates often confuse Event Grid's built-in retry and dead-lettering with Durable Functions or manual checkpointing, assuming they need to implement custom reliability mechanisms when Azure already provides them natively.

Practice this question →

210

Multi-Selecthard

You are deploying a critical web application on Azure App Service that must handle sudden traffic spikes. The application stores session data in memory. You need to ensure session state is preserved across scale-out events. Which THREE actions should you take?

Select 3 answers

A.Enable sticky sessions (ARR affinity) in the App Service configuration.

B.Configure the application to use Azure Cache for Redis for session state.

C.Disable ARR affinity to allow any instance to handle requests.

D.Set the session state mode to 'InProc' in the web.config.

E.Use a SQL Server session state provider to store session data.

AnswersA, B, E

Sticky sessions route requests to the same instance, reducing session loss during scale-out.

Why this answer

Option A is correct because enabling sticky sessions (ARR affinity) ensures that all requests from a client session are routed to the same App Service instance. This preserves in-memory session state during scale-out events, as the load balancer uses the ARR cookie to maintain affinity. Without this, requests could be distributed to different instances, losing session data.

Exam trap

The trap here is that candidates may think disabling ARR affinity (Option C) or using InProc mode (Option D) is sufficient, but they fail to recognize that in-memory session state is inherently tied to a single instance and requires both sticky sessions and a shared external store for true scale-out resilience.

Practice this question →

211

MCQhard

Refer to the exhibit. You run this KQL query in Azure Resource Graph Explorer. The query returns no results. What is the most likely reason?

A.The 'contains' operator is case-sensitive.

B.The query must specify a subscription filter.

C.The 'where' clause must use '== ' instead of '=='.

D.The resource type is incorrect; it should be 'microsoft.insights/components' in lowercase.

AnswerD

Resource types in ARG are case-sensitive and must match exactly.

Why this answer

The KQL query uses the resource type 'Microsoft.Insights/Components' with mixed case, but Azure Resource Graph Explorer requires resource types to be specified in all lowercase. The correct type is 'microsoft.insights/components'. When the case does not match, the query returns no results because Azure Resource Graph performs a case-sensitive match on the 'type' property.

Exam trap

The trap here is that candidates often assume Azure resource types are case-insensitive in queries, but Azure Resource Graph enforces exact lowercase matching for the 'type' property, leading to empty results when mixed case is used.

How to eliminate wrong answers

Option A is wrong because the 'contains' operator in KQL is case-insensitive by default, so case sensitivity is not the issue here. Option B is wrong because Azure Resource Graph queries do not require a subscription filter; they can run across all accessible subscriptions without explicit filtering. Option C is wrong because the '==' operator is the correct equality operator in KQL; the syntax '== ' (with a trailing space) is not valid and would cause a syntax error, not a silent empty result.

Practice this question →

212

MCQmedium

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

A.Deployment slots

B.Backup and restore

C.App Service access restrictions

D.Always On only

AnswerA

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

Why this answer

Deployment slots are the correct Azure App Service feature for staging and production environments with traffic swapping. They allow you to deploy a new version to a staging slot, warm it up (e.g., by sending requests or using auto-swap with warm-up), and then swap the slot's traffic with the production slot, ensuring zero-downtime deployment and validation before going live.

Exam trap

The trap here is that candidates might confuse 'Always On' with keeping the app warm for swapping, but Always On only prevents idle shutdown and does not provide separate environments or traffic management.

How to eliminate wrong answers

Option B (Backup and restore) is wrong because it is designed for disaster recovery and data preservation, not for staging or traffic swapping between environments. Option C (App Service access restrictions) is wrong because it controls inbound network access via IP rules or service endpoints, not environment separation or deployment swapping. Option D (Always On only) is wrong because it keeps the app loaded to prevent cold starts, but it does not provide separate environments or the ability to warm up a new version before swapping traffic.

Practice this question →

213

MCQmedium

A checkout API uses Azure Functions with HTTP triggers. The developer wants to reject unauthenticated calls before function code executes. Which feature should be configured?

A.Deployment slots

B.App Service Authentication / Easy Auth with Microsoft Entra ID

C.Application Insights sampling

D.Function timeout

AnswerB

Built-in authentication validates requests before they reach application code.

Why this answer

App Service Authentication (Easy Auth) with Microsoft Entra ID allows the developer to reject unauthenticated calls before the function code executes by configuring the authentication provider at the App Service platform level. This ensures that the HTTP trigger function only receives requests with valid tokens, without requiring custom authorization logic in the function code.

Exam trap

The trap here is that candidates might think authentication must be handled inside the function code (e.g., using custom middleware or token validation), but Azure Functions provides a built-in platform-level authentication feature (Easy Auth) that rejects unauthenticated calls before execution.

How to eliminate wrong answers

Option A is wrong because deployment slots are used for staging, swapping, and testing different versions of the app, not for authentication or rejecting unauthenticated calls. Option C is wrong because Application Insights sampling controls the volume of telemetry data collected, not authentication or request filtering. Option D is wrong because function timeout controls the maximum execution duration for a function, not the ability to reject unauthenticated requests before code runs.

Practice this question →

214

MCQmedium

The internal API team is deploying a containerized .NET API that receives sporadic requests — sometimes none for hours, then bursts of activity. Cost is a priority. The team wants the container to stop running when idle and start automatically when a request arrives, with no server management overhead. Which Azure service is the best fit?

A.Azure Container Apps with scale-to-zero enabled on the HTTP ingress

B.Azure Kubernetes Service with the cluster autoscaler set to a minimum node count of zero

C.Azure App Service on a B1 (Basic) plan with Always On disabled

D.Azure Virtual Machine Scale Sets with scheduled scaling to zero instances overnight

AnswerA

Container Apps scales to zero replicas when idle. The first request after an idle period incurs a cold-start delay (typically seconds) while a replica starts. Subsequent requests in the burst are served by the running replica. Billing is consumption-based — zero replicas means zero compute cost during idle periods.

Why this answer

Azure Container Apps with scale-to-zero enabled on the HTTP ingress is the best fit because it allows the container to scale down to zero replicas when idle, automatically stopping the container to save costs, and scales back up to handle incoming HTTP requests with no server management overhead. This serverless platform abstracts Kubernetes infrastructure, meeting the team's requirement for minimal operational burden and cost efficiency.

Exam trap

The trap here is that candidates often confuse 'scale to zero' with 'autoscaling to a minimum of zero nodes' in AKS, but AKS cannot scale to zero nodes due to system pod requirements, whereas Azure Container Apps supports scale-to-zero at the replica level without managing nodes.

How to eliminate wrong answers

Option B is wrong because Azure Kubernetes Service (AKS) with the cluster autoscaler set to a minimum node count of zero is not supported; AKS requires at least one node to run system pods, and scaling to zero nodes would break cluster functionality. Option C is wrong because Azure App Service on a B1 (Basic) plan with Always On disabled still incurs costs for the reserved instance and cannot scale to zero; the plan is always running, and idle behavior only stops the app process, not the underlying VM. Option D is wrong because Azure Virtual Machine Scale Sets with scheduled scaling to zero instances overnight does not provide automatic, request-driven scaling; it relies on a fixed schedule and cannot react to sporadic bursts, plus VMs incur costs even when deallocated if the underlying resources are not released.

Practice this question →

215

Multi-Selecthard

A company deploys a containerized application on Azure Kubernetes Service (AKS). They need to ensure high availability and disaster recovery across regions. Which THREE actions should they take?

Select 3 answers

A.Use Azure Front Door for global load balancing

B.Configure Pod Disruption Budgets

C.Use Azure Traffic Manager to route traffic

D.Deploy AKS clusters in multiple regions

E.Enable Cluster Autoscaler

AnswersB, C, D

PDBs ensure application availability during node updates.

Why this answer

Pod Disruption Budgets (PDBs) are correct because they ensure that a minimum number of pods remain available during voluntary disruptions, such as node maintenance or cluster upgrades. In a multi-region AKS deployment for high availability and disaster recovery, PDBs protect application uptime by preventing too many replicas from being taken down simultaneously, which is critical for maintaining service continuity across regional failovers.

Exam trap

The trap here is that candidates often confuse Cluster Autoscaler (which only scales nodes within a region) with cross-region disaster recovery solutions, overlooking that true high availability across regions requires deploying multiple AKS clusters and using a global traffic router like Azure Traffic Manager.

Practice this question →

216

MCQeasy

You are developing a background job that runs every hour to process data. You choose Azure Functions with a timer trigger. What is the correct format for the cron expression to run at the start of every hour?

A.0 * * * * *

B.* 0 * * * *

C.0 0 * * * *

D.0 0 0 * * *

AnswerC

Runs at the start of every hour.

Why this answer

In Azure Functions timer triggers, the cron expression uses six fields: {second} {minute} {hour} {day} {month} {day-of-week}. To run at the start of every hour (i.e., at minute 0 and second 0 of every hour), the expression must be '0 0 * * * *'. Option C correctly sets second to 0, minute to 0, and hour to '*' (every hour), with the remaining fields as '*' (every day, every month, every day-of-week).

Exam trap

The trap here is that candidates often confuse the six-field Azure Functions cron format with the standard five-field UNIX cron format, leading them to pick '0 * * * * *' (which runs every minute) or '* 0 * * * *' (which runs every second during minute 0).

How to eliminate wrong answers

Option A is wrong because '0 * * * * *' runs at second 0 of every minute (i.e., once per minute), not at the start of every hour. Option B is wrong because '* 0 * * * *' runs every second during minute 0 of every hour (i.e., 60 times at the start of the hour), not once at the start. Option D is wrong because '0 0 0 * * *' runs at midnight (00:00:00) every day, not at the start of every hour.

Practice this question →

217

MCQmedium

You have an Azure App Service web app that experiences fluctuating traffic. During peak hours, the CPU usage reaches 90% and response times increase. You want to automatically scale out the number of instances when CPU usage exceeds 75% and scale in when it drops below 25%. The scaling should be gradual to avoid thrashing. Which configuration should you use?

A.Enable 'Always On' and configure manual scale based on scheduled times.

B.Configure autoscale rules on the App Service plan scale-out setting, using CPU percentage as the metric with appropriate thresholds and cool-down periods.

C.Use Azure Functions with the Consumption Plan to handle the web app logic.

D.Deploy the web app to Azure Container Instances and use the scale-on-CPU feature.

AnswerB

This is the standard approach. In the Azure portal, under the App Service plan's 'Scale out' (App Service plan settings), you can add autoscale conditions with rules based on CPU percentage.

Why this answer

Option B is correct because Azure App Service autoscale rules allow you to scale out (increase instance count) when CPU percentage exceeds 75% and scale in (decrease instance count) when it drops below 25%, with configurable cool-down periods (e.g., 5–10 minutes) to prevent thrashing. This directly addresses the fluctuating traffic pattern and gradual scaling requirement using the App Service plan's scale-out blade.

Exam trap

The trap here is that candidates confuse 'Always On' (which keeps the app warm) with autoscaling, or mistakenly think Azure Functions or Container Instances are drop-in replacements for App Service autoscale, ignoring the specific requirements for gradual, metric-based scaling with cool-down periods.

How to eliminate wrong answers

Option A is wrong because 'Always On' prevents the app from being unloaded after idle periods but does not provide any autoscaling capability; manual scale based on scheduled times cannot react to real-time CPU fluctuations. Option C is wrong because Azure Functions with the Consumption Plan is designed for event-driven, stateless workloads, not for hosting a full web app with persistent connections or complex routing; it lacks the autoscale granularity and CPU-based rules required here. Option D is wrong because Azure Container Instances scale-on-CPU feature is limited to container groups and does not integrate with App Service web app deployment; it also lacks the gradual scale-in/out cool-down periods needed to avoid thrashing.

Practice this question →

218

MCQeasy

You are building a serverless image-processing solution using Azure Functions. The function must automatically run whenever a new image is uploaded to a blob container and must scale out to handle high upload volumes. Which trigger and hosting plan should you use?

A.Timer trigger with Consumption plan

B.Blob trigger with Consumption plan

C.HTTP trigger with Premium plan

D.Queue trigger with App Service plan

AnswerB

The blob trigger runs when a new blob is created, and the Consumption plan automatically scales out to handle high volumes.

Why this answer

The Blob trigger is designed to automatically execute a function when a blob is created or updated in Azure Blob Storage, making it the correct choice for an image-processing solution that must run on new uploads. The Consumption plan provides automatic scaling to handle high upload volumes by allocating resources on demand, which aligns with the serverless, event-driven requirement.

Exam trap

The trap here is that candidates may confuse the Blob trigger with other triggers (like Timer or Queue) that can indirectly process blobs, but only the Blob trigger directly and automatically responds to blob creation events without additional infrastructure.

How to eliminate wrong answers

Option A is wrong because a Timer trigger runs on a fixed schedule, not in response to blob uploads, so it cannot automatically process new images as they arrive. Option C is wrong because an HTTP trigger requires an explicit HTTP request to invoke the function, which is not suitable for an automatic, event-driven workflow triggered by storage events. Option D is wrong because a Queue trigger processes messages from a queue, not blob uploads directly, and the App Service plan does not provide the same automatic, fine-grained scaling as the Consumption plan for event-driven workloads.

Practice this question →

219

MCQeasy

You are developing an Azure Functions app that uses Durable Functions to orchestrate a long-running workflow. The workflow involves calling multiple external APIs. You need to ensure that the orchestration can survive a function app restart. Which feature should you use?

A.Use the default checkpointing and replay mechanism.

B.Log orchestration state to Application Insights.

C.Implement retry policies on the activity functions.

D.Set a high timeout on the orchestration.

AnswerA

Durable Functions persists state for survival across restarts.

Why this answer

Option A is correct because Durable Functions inherently use a checkpointing and replay mechanism to persist the orchestration state to a storage backend (Azure Storage queues, tables, and blobs). This ensures that after a function app restart, the orchestrator function can replay from the last checkpoint, restoring the exact execution context and continuing the workflow without data loss.

Exam trap

The trap here is that candidates confuse logging (Application Insights) with state persistence, or assume retry policies or timeouts are sufficient for durability, when only the built-in checkpointing and replay mechanism guarantees survival across restarts.

How to eliminate wrong answers

Option B is wrong because logging orchestration state to Application Insights is for monitoring and diagnostics, not for persisting the execution state required to survive a restart; it does not provide the replay capability needed for durability. Option C is wrong because implementing retry policies on activity functions handles transient failures of individual API calls, but does not preserve the overall orchestration state across a function app restart. Option D is wrong because setting a high timeout on the orchestration only extends the maximum execution duration, but does not provide any mechanism to recover the orchestration state after a restart.

Practice this question →

220

MCQmedium

You are developing an Azure Function that processes messages from an Azure Service Bus queue. The function uses a Service Bus queue trigger and runs on a Consumption Plan. The queue receives a high volume of messages in bursts. You need to ensure that the function scales out to handle the load but does not exceed 10 concurrent instances. Which configuration should you apply?

A.Set the 'maxConcurrentCalls' property to 10 in the host.json file.

B.Set the 'WEBSITE_MAX_INSTANCES' application setting to 10 in the function app.

C.Set the 'maxMessageBatchSize' property to 10 in the host.json file.

D.Restrict the Service Bus queue to have a maximum concurrency of 10 at the namespace level.

AnswerB

Correct. The WEBSITE_MAX_INSTANCES setting limits the maximum number of instances that the function app can scale out to. This is the correct way to cap the number of concurrent instances.

Why this answer

Option B is correct because the 'WEBSITE_MAX_INSTANCES' application setting is the proper way to limit the number of concurrent instances (scale-out) for a function app running on a Consumption Plan. This setting caps the maximum number of instances the platform can allocate, ensuring that even under high burst loads, the function does not exceed 10 concurrent instances. The Service Bus trigger's 'maxConcurrentCalls' controls per-instance concurrency, not instance count, and 'maxMessageBatchSize' controls batch size, not scaling.

Exam trap

The trap here is confusing per-instance concurrency settings (maxConcurrentCalls) with instance-level scaling limits (WEBSITE_MAX_INSTANCES), leading candidates to incorrectly choose A when the question explicitly asks about limiting concurrent instances, not per-instance message processing.

How to eliminate wrong answers

Option A is wrong because 'maxConcurrentCalls' in host.json controls the number of messages processed concurrently within a single function instance, not the number of instances; setting it to 10 limits per-instance parallelism but does not cap the total number of instances, which can still scale out beyond 10. Option C is wrong because 'maxMessageBatchSize' defines the maximum number of messages retrieved in a single batch from the Service Bus queue, not the number of concurrent instances; it affects throughput per invocation, not scaling limits. Option D is wrong because Azure Service Bus does not have a 'maximum concurrency' setting at the namespace level that limits function app instances; concurrency is managed at the client/trigger level, and namespace-level throttling is not a configurable property for this purpose.

Practice this question →

221

MCQeasy

You need to execute a PowerShell script every night to clean up unused resources in your Azure subscription. The script should run with a specific service principal identity that has the necessary permissions. You want a serverless solution with minimal management overhead. Which Azure service should you use?

A.Azure Functions with a timer trigger running PowerShell.

B.Azure Automation with a scheduled runbook.

C.Azure Logic Apps with a recurrence trigger running a PowerShell action.

D.Set up a scheduled task on an Azure VM to run the script.

AnswerB

Azure Automation allows you to create PowerShell runbooks, link them to a schedule, and use a Run As account (Microsoft Entra ID service principal) for authentication. This provides a low-management, serverless solution.

Why this answer

Azure Automation with a scheduled runbook is the correct choice because it is designed specifically for running PowerShell scripts on a recurring schedule using a service principal identity, with built-in support for Azure authentication via managed identities or Run As accounts. This provides a serverless solution with minimal management overhead, as Azure Automation handles the scheduling, execution, and identity management without requiring you to maintain any infrastructure.

Exam trap

The trap here is that candidates often choose Azure Functions (Option A) because it is a popular serverless compute option, but they overlook that Azure Automation is the dedicated service for scheduled PowerShell administration in Azure, with built-in identity management and longer execution time limits.

How to eliminate wrong answers

Option A is wrong because Azure Functions with a timer trigger can run PowerShell, but it is not optimized for long-running administrative scripts (default timeout of 5-10 minutes) and requires more manual setup for service principal authentication and module management compared to Azure Automation. Option C is wrong because Azure Logic Apps with a recurrence trigger can orchestrate workflows but does not natively run PowerShell scripts; it would require an Azure Function or Hybrid Worker to execute PowerShell, adding complexity and defeating the 'minimal management overhead' requirement. Option D is wrong because setting up a scheduled task on an Azure VM is not serverless—it requires provisioning, patching, and managing a VM, which contradicts the 'serverless solution with minimal management overhead' requirement.

Practice this question →

222

MCQmedium

You are deploying a Node.js application to Azure Web Apps for Containers. The application needs to read configuration settings from Azure App Configuration. What is the recommended method to securely connect the app to the configuration store?

A.Store connection string in environment variables.

B.Use Key Vault references in App Settings.

C.Use managed identity.

D.Hardcode the connection string.

AnswerC

Correct. Managed identity provides secure authentication without secrets.

Why this answer

Option C is correct because using a managed identity allows the Node.js application running in Azure Web Apps for Containers to authenticate to Azure App Configuration without storing any secrets. Managed identities provide an automatically managed service principal in Azure AD, enabling secure, code-free access to the configuration store via Azure AD authentication, which is the recommended approach for production workloads.

Exam trap

The trap here is that candidates often confuse Key Vault references (which are for retrieving secrets from Key Vault) with the method to connect to App Configuration, leading them to choose Option B, but managed identity is the recommended and most secure way to authenticate to App Configuration directly.

How to eliminate wrong answers

Option A is wrong because storing the connection string in environment variables still exposes a secret (the connection string) in the app settings, which can be leaked or misconfigured, and it does not leverage Azure AD authentication. Option B is wrong because Key Vault references in App Settings are used to reference secrets stored in Azure Key Vault, not to directly connect to Azure App Configuration; they solve a different problem (retrieving secrets) and still require a connection string or managed identity for the App Configuration client. Option D is wrong because hardcoding the connection string is a severe security anti-pattern that exposes credentials in source code, violates security best practices, and is never recommended.

Practice this question →

223

MCQhard

You are developing a microservices application deployed on Azure Kubernetes Service (AKS). You need to ensure that service-to-service communication is encrypted using mutual TLS (mTLS) without modifying application code. What should you do?

A.Deploy Azure Service Mesh and enable mTLS.

B.Use Azure Application Gateway Ingress Controller with mTLS.

C.Enable Azure Kubernetes Service (AKS) pod-to-pod encryption.

D.Configure Azure Network Security Groups to enforce encryption.

AnswerA

Service Mesh provides transparent mTLS.

Why this answer

Azure Service Mesh (e.g., Open Service Mesh or Istio-based) provides a transparent infrastructure layer that can automatically inject sidecar proxies into pods and enforce mTLS for all service-to-service communication without requiring any changes to application code. This meets the requirement of encrypting traffic with mutual TLS while keeping the application code untouched.

Exam trap

The trap here is that candidates may confuse ingress-level mTLS (option B) with internal service-to-service mTLS, or assume that AKS has a built-in pod encryption feature (option C) when it does not.

How to eliminate wrong answers

Option B is wrong because Azure Application Gateway Ingress Controller handles ingress traffic from outside the cluster, not internal service-to-service communication, and its mTLS feature applies to client-to-ingress, not pod-to-pod. Option C is wrong because AKS does not have a native 'pod-to-pod encryption' feature; encryption between pods must be implemented via a service mesh or other overlay network. Option D is wrong because Network Security Groups (NSGs) filter traffic based on IP/port rules and cannot enforce encryption or mTLS at the application layer.

Practice this question →

224

MCQeasy

You need to deploy a containerized application to Azure Container Instances (ACI) with a public IP address and DNS name label. The container must restart automatically if it exits unexpectedly. Which configuration should you use?

A.Deploy the container into an Azure Virtual Network.

B.Set restart policy to Never and configure a public IP.

C.Set restart policy to OnFailure and use a private IP address.

D.Set restart policy to Always and assign a DNS name label.

AnswerD

Always restarts on any exit, and DNS name label provides public access.

Why this answer

Option D is correct because setting the restart policy to Always ensures the container automatically restarts if it exits unexpectedly, which is the required behavior. Assigning a DNS name label to the container group makes it accessible via a public IP address and a fully qualified domain name (FQDN) in the format <dns-name-label>.<region>.azurecontainer.io, meeting the requirement for a public IP address and DNS name label.

Exam trap

The trap here is that candidates may confuse the restart policy options, thinking OnFailure covers all unexpected exits, or assume that a virtual network is required for public IP assignment, when in fact ACI assigns a public IP by default unless configured otherwise.

How to eliminate wrong answers

Option A is wrong because deploying the container into an Azure Virtual Network does not affect the restart policy or the assignment of a public IP address and DNS name label; it only provides network isolation. Option B is wrong because setting the restart policy to Never means the container will not restart automatically if it exits unexpectedly, which directly contradicts the requirement. Option C is wrong because setting the restart policy to OnFailure only restarts the container if it exits with a non-zero exit code, not for all unexpected exits, and using a private IP address does not provide public accessibility or a DNS name label.

Practice this question →

225

MCQeasy

You are deploying an application to Azure App Service that requires a custom startup script to initialize the environment. Where should you place the startup script in the application code?

A.In the 'web.config' file

B.In a 'docker-compose.yml' file

C.In the root of the application code as 'startup.sh'

D.As a startup command in the App Service configuration

AnswerD

You can set the startup command (e.g., 'dotnet myapp.dll' or a script path) in the Azure portal or CLI.

Why this answer

Option D is correct because Azure App Service allows you to specify a custom startup command or script in the App Service configuration (under 'General settings' or via the Azure CLI with `--startup-file`). This startup command runs before the application starts, enabling you to initialize the environment, run pre-deployment tasks, or set up dependencies. Placing the startup script in the configuration ensures it is executed by the App Service platform, which handles the runtime environment (Windows or Linux) and integrates with the application lifecycle.

Exam trap

The trap here is that candidates assume placing a script file in the application root is sufficient for execution, but Azure App Service requires explicit configuration to designate a startup file or command, as the platform does not automatically scan for or execute arbitrary scripts.

How to eliminate wrong answers

Option A is wrong because the 'web.config' file is used for configuring IIS settings and ASP.NET modules, not for executing custom startup scripts; it cannot run shell commands or scripts. Option B is wrong because 'docker-compose.yml' is used for multi-container Docker applications, but Azure App Service does not natively support Docker Compose; it uses single-container deployments or App Service on Linux with a Dockerfile, not a compose file. Option C is wrong because placing 'startup.sh' in the root of the application code does not automatically cause Azure App Service to execute it; the platform requires explicit configuration to run a startup script, and simply having the file present does not trigger execution.

Practice this question →