Courseiva

CCNA Develop Azure compute solutions Questions

75 of 230 questions · Page 3/4 · Develop Azure compute solutions · Answers revealed

Practice these questionsDomain overviewAll questions
151
MCQmedium

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

A.Adjust the sampling rate in the Application Insights configuration to 100%.
B.Change the function app to the Premium plan to get more CPU and memory.
C.Create a separate Application Insights resource for the function app.
D.Disable sampling in the function's host.json.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
152
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

The Internal LoadBalancer service type, specifically configured with the `service.beta.kubernetes.io/azure-load-balancer-internal: "true"` annotation, is the correct solution. This configuration provisions an Azure Internal Load Balancer with a private IP address within the AKS Virtual Network. Consequently, the microservice becomes securely accessible only to other resources residing within that VNet or peered VNets, without any public exposure.

Why this answer

An Internal LoadBalancer with the `service.beta.kubernetes.io/azure-load-balancer-internal: "true"` annotation creates a load balancer with a private IP address from the cluster's virtual network, making the service accessible only within that VNet. This is the correct choice for exposing an internal service exclusively within the AKS cluster virtual network.

Exam trap

The trap here is that candidates often confuse ClusterIP with internal-only access, but ClusterIP is limited to within the cluster itself, whereas an Internal LoadBalancer extends accessibility to the entire virtual network, which is the requirement in this question.

How to eliminate wrong answers

Option A is wrong because NodePort exposes the service on a static port on each node's IP address, which is accessible from outside the cluster if the node IPs are routable, and it does not restrict traffic to the cluster virtual network. Option C is wrong because a standard LoadBalancer creates a public-facing Azure load balancer with a public IP, exposing the service to the internet, not just within the virtual network. Option D is wrong because ClusterIP exposes the service on a cluster-internal IP, which is only reachable within the cluster itself (via pod-to-pod communication) and not from other resources within the virtual network that are outside the cluster.

Practice this question →
153
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

This pattern is specifically designed for scenarios requiring parallel execution of multiple tasks followed by aggregation of their results. An orchestrator function initiates multiple activity functions concurrently (fan-out), often using Task.WhenAll in C# to asynchronously wait for all of them to complete. Once all parallel activities have finished, the orchestrator then collects and processes their individual outputs (fan-in) to produce a single, consolidated result. This perfectly matches the requirement for parallel API calls and subsequent data aggregation.

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 →
154
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 →
155
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

The correct matches are: Azure Functions for serverless event-driven code, Azure App Service for hosting web apps/APIs, Azure Logic Apps for workflow automation, and Azure Cosmos DB for globally distributed NoSQL database. Common confusions involve swapping the purposes of Azure Functions and Azure App Service.

Practice this question →
156
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

When connection strings are configured in Azure App Service settings, the platform automatically injects them into the application's process as environment variables. App Service prefixes these variables based on the connection string type, such as "SQLAZURECONNSTR_" for SQL Database connections. Therefore, accessing Environment.GetEnvironmentVariable("SQLAZURECONNSTR_MyConn") is the direct and recommended method for the application to retrieve these pre-configured secrets.

Why this answer

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 →
157
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 Azure Functions Premium plan is the correct choice as it offers robust support for longer execution durations, extending function timeouts up to 60 minutes by default, and configurable even longer. It provides pre-warmed instances to eliminate cold starts, ensures consistent performance, and includes VNet integration for secure access to other Azure resources, making it ideal for a 30-minute image resize worker.

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 →
158
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

Configuring pre-warmed instances is a key feature of the Azure Functions Premium plan designed to mitigate cold start latency. By specifying a number of pre-warmed instances, the platform ensures that these instances are always running and ready to process incoming requests, significantly improving the responsiveness of your function app, especially after periods of inactivity. This is a direct and effective scaling strategy.

Why this answer

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 →
159
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

A dedicated App Service plan provides consistent, allocated resources for your function app, eliminating the variability inherent in consumption-based hosting. Enabling "Always On" ensures that the function host process remains active and responsive, completely preventing cold starts and guaranteeing immediate execution for incoming requests. This plan also supports significantly longer execution timeouts (up to 30 minutes by default, configurable to an hour), making it ideal for tasks requiring sustained processing without interruption.

Why this answer

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 or best way to address cold starts, overlooking that a Dedicated App Service plan with Always On provides a stronger guarantee of cold start elimination and a sufficient default timeout (30 minutes, same as Premium), often at a lower cost for predictable, continuous 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 →
160
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

The "OnFailure" restart policy is optimal for ensuring application resilience by automatically restarting a container only if it terminates with a non-zero exit code, indicating an error or crash. This prevents manual intervention for transient failures while avoiding unnecessary restarts for successful completions. Deploying within a single container group represents the simplest and most cost-effective architecture in Azure Container Instances, as it minimizes resource overhead and management complexity.

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 →
161
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

The 'dnsConfig' property is a specific configuration setting within Azure Container Instances (ACI) that allows administrators to define custom DNS servers and search domains for an entire container group. When this property is used, ACI injects these specified DNS settings directly into the `/etc/resolv.conf` file of each container within that group. This ensures that all DNS queries originating from any container in the group will use the custom servers, effectively overriding the default Azure-provided DNS resolution.

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 →
162
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

Setting up a build provider like GitHub Actions or Kudu is a correct step because a build provider is essential for automating the continuous integration and continuous deployment process. It is responsible for compiling source code, running tests, packaging the application, and then deploying the artifacts to the Azure App Service. GitHub Actions offers a robust external CI/CD platform, while Kudu is the built-in deployment engine for App Service, providing capabilities for source code synchronization, build automation, and deployment scripts directly within the service.

Why this answer

Option B is correct because continuous deployment from GitHub requires a build provider to detect commits and run the build/deploy pipeline — either GitHub Actions (workflow YAML in the repo) or the built-in Kudu (App Service build engine) that App Service uses to pull and build the source. Option C is correct because the Deployment Center in the App Service blade is where you authorize the GitHub connection, select the repository and branch, and choose the build provider, which wires up the deployment source. Option A is not required because an App Service plan is the underlying compute resource that is created or already exists when you create the web app; it is not part of configuring continuous deployment.

Option D is not required because Application Insights is an APM/monitoring service and has nothing to do with source control deployment. Option E is not required because a custom domain is a DNS/hostname binding for user access, not a deployment mechanism.

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 →
163
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

App Service Authentication, often referred to as Easy Auth, provides a built-in, declarative authentication and authorization layer for Azure App Services, including Azure Functions. When configured with Microsoft Entra ID, it intercepts HTTP requests *before* they reach the function's application code, validating caller identity against Entra ID and injecting user claims into the request headers. This effectively secures the HTTP trigger by ensuring only authenticated and authorized users can invoke the function.

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 →
164
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

This configuration represents the most cost-effective and efficient solution for a workload requiring 8 GB of memory and 4 vCPUs. Utilizing a Linux container is inherently more economical in Azure Container Instances compared to Windows containers, as it avoids additional licensing costs. Furthermore, consolidating the entire workload into a single container within a single container group minimizes operational overhead and ensures that resources are allocated directly to the application without the complexities or additional billing associated with multiple groups or inter-container communication.

Why this answer

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 →
165
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

This is the correct answer because the 'alwaysOn' setting, when enabled, is designed to keep an application loaded in memory to prevent cold starts and ensure continuous availability. However, this feature is only supported on specific App Service plan tiers, typically Basic, Standard, Premium, or Isolated, which guarantee dedicated resources. On Free or Shared tiers, the 'alwaysOn' setting is silently ignored by the Azure platform, meaning the application can still be unloaded due to inactivity, leading to performance issues and unexpected delays for users. While the deployment won't fail, the desired functionality won't be achieved.

Why this answer

The 'alwaysOn' setting keeps the app loaded even after periods of inactivity, but it is only supported on Basic, Standard, Premium, and Isolated tiers. If the App Service plan is on a Free or Shared tier, enabling 'alwaysOn' causes the app to stop responding after a few minutes because the platform forcibly unloads idle apps, leading to timeouts or crashes.

Exam trap

The trap here is that candidates assume 'alwaysOn' is a harmless performance setting, but Azure enforces it only on paid tiers, and enabling it on an unsupported tier silently breaks the app after idle timeouts.

How to eliminate wrong answers

Option A is wrong because the 'dependsOn' element is used for deployment ordering and does not affect runtime behavior; missing it would not cause the app to stop responding after a few minutes. Option B is wrong because 'linuxFxVersion' for .NET 6 on Linux should be set to 'DOTNETCORE|6.0', and if it were incorrect, the app would fail to start immediately, not after a few minutes. Option D is wrong because 'WEBSITE_RUN_FROM_PACKAGE' set to '1' is a valid setting for running an app from a deployment package; it would not cause the app to stop responding after a few minutes unless there is a package corruption, which is not indicated.

Practice this question →
166
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

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 →
167
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

Deployment slots in Azure App Service provide a robust mechanism for staging new application versions, including configuration changes, in a non-production environment. Before swapping the staged slot into production, you can thoroughly test its functionality and performance, effectively simulating a failover scenario for the new version. This enables validation of the application's behavior in the new deployment without impacting the live user experience, ensuring a smooth transition and reducing downtime risk.

Why this answer

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 →
168
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

Enabling the 'Always On' setting in Azure App Service ensures that the web application process is kept loaded and running, even during periods of inactivity. By preventing the application from being unloaded or idled out due to lack of traffic, it significantly reduces or eliminates the "cold start" latency that occurs when the application needs to be reloaded from scratch. This keeps the application immediately responsive to incoming requests, which is crucial for critical web applications.

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 →
169
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

The az container logs command is the correct utility for retrieving the complete historical standard output and standard error logs generated by an Azure Container Instance. Azure persists these logs even after the container has exited, enabling crucial post-mortem analysis and debugging of application failures. This command effectively fetches the accumulated log data, providing comprehensive insight into the container's execution lifecycle and any termination events.

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 →
170
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

Setting `WEBSITE_RUN_FROM_PACKAGE` to a URL pointing to a zip file in Azure Blob Storage instructs the Azure Functions host to mount this package as a read-only file system. This "run-from-package" mode eliminates the need for file synchronization during deployment, significantly reducing cold start times and preventing file locking issues. It ensures the function app's code is executed directly from the specified deployment package, improving consistency and reliability across all instances.

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 →
171
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

Enabling a system-assigned managed identity gives the App Service an identity in Microsoft Entra ID, so the app authenticates to Key Vault without storing credentials. This directly satisfies the stem's constraint of eliminating connection strings from configuration, since Key Vault access is then granted via RBAC or access policy to that identity.

Why this answer

Option A is correct because enabling a managed identity on the App Service web app creates an Azure AD service principal that the app can use to authenticate to Key Vault without embedding any credentials or connection strings in configuration. Option C is correct because the managed identity must be granted permission to read the required secrets, typically via a Key Vault access policy with the 'get' secret permission or an Azure RBAC role such as 'Key Vault Secrets User', otherwise authentication succeeds but authorization fails. Option B is wrong because enabling anonymous access on the vault would expose secrets to anyone and defeats the purpose of secure, identity-based access.

Option D is wrong because storing a Key Vault access key in app settings reintroduces exactly the connection-string/secret-in-configuration problem the scenario is trying to eliminate.

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 →
172
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

The queue-based load leveling pattern is ideal for managing external API rate limits. Incoming requests are placed into an Azure Storage Queue, decoupling the ingestion rate from the processing rate. A separate function, triggered by the queue, then processes these messages at a controlled pace, implementing throttling mechanisms like deliberate delays between API calls or batch processing with pauses, ensuring the external API's rate limit is consistently respected regardless of the function app's scale.

Why this answer

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 →
173
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

Generating a Shared Access Signature (SAS) token is the most secure and efficient method for direct client-to-storage uploads. The web application can generate a time-limited SAS token with specific write permissions for a particular blob or container, which the client then uses to upload the image directly to Azure Blob Storage. This approach offloads the data transfer burden from the App Service, improving scalability, reducing latency, and minimizing resource consumption on the application server.

Why this answer

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 →
174
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

This is the correct choice because an Event Grid trigger provides a robust, push-based event delivery system, ensuring immediate notification and built-in retry logic for image processing events. Pairing this with an Azure Functions Premium plan guarantees pre-warmed instances, eliminating cold starts, and offers dedicated compute resources with dynamic concurrency, which is essential for handling high-throughput image processing workloads with consistent low latency and reliability.

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 →
175
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

Azure Queue Storage provides a robust, scalable, and durable message queuing service ideal for decoupling components of an application. It enables the web app to quickly enqueue image processing requests without waiting for completion, significantly improving responsiveness and resilience. This buffering capability effectively handles spikes in demand, ensuring that backend workers can process images asynchronously at their own pace, preventing system overload and ensuring reliable task execution.

Why this answer

Azure Queue Storage is correct because it provides a durable, asynchronous message queue that can decouple the web app's frontend from the long-running image processing task. By placing a message for each image onto a queue, the web app can immediately return a response to the user, while a background worker (e.g., an Azure Function or WebJob) polls the queue and processes images as capacity allows. This pattern ensures the web app remains responsive under traffic spikes, as the queue acts as a buffer that scales independently.

Exam trap

The trap here is that candidates often confuse Azure Event Grid's event-driven architecture with a queueing mechanism, overlooking that Event Grid does not provide message persistence or retry for long-running processing, whereas Queue Storage is explicitly designed for asynchronous work offloading.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB is a NoSQL database designed for storing and querying structured data, not for queuing or offloading asynchronous tasks; using it for image processing would introduce unnecessary latency and cost without providing the decoupling needed. Option C is wrong because Azure Event Grid is a publish-subscribe event routing service that delivers events in near-real-time to subscribers, but it does not provide a persistent queue for buffering messages when processing takes up to 30 seconds—events are delivered once and lost if not processed immediately, making it unsuitable for long-running tasks with traffic spikes. Option D is wrong because Azure SignalR Service is used for real-time web functionality (e.g., push notifications, live updates) via WebSockets, not for offloading background processing; it cannot buffer or queue work items.

Practice this question →
176
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

An Azure Event Grid trigger enables an Azure Function to react to events published by various Azure services, including Azure Blob Storage. When configured, Event Grid subscribes to specific events, such as a "Blob Created" event from a storage account, and then pushes that event to the function endpoint. This provides a highly scalable, low-latency, and reliable event-driven architecture, allowing the function to process the new blob almost instantaneously.

Why this answer

Option A (Azure Event Grid trigger) is correct because Azure Storage integrates with Event Grid to publish a BlobCreated event when a new blob is uploaded, and an Azure Function with an Event Grid trigger subscribes to that event to fire in near real time. Option C (Azure Blob Storage trigger) is correct because it is the native Azure Functions binding that monitors a specified storage container and invokes the function whenever a new or updated blob is detected. Option B (Azure Queue Storage trigger) is not correct because it fires on messages placed in a queue, not on blob creation, unless additional code writes such messages.

Option D (Azure Cosmos DB trigger) is not correct because it reacts to changes in a Cosmos DB container's change feed, not to Azure Storage blobs. Option E (HTTP trigger) is not correct because it requires an inbound HTTP request and does not natively detect new blobs.

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 →
177
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

A scale-out threshold of 80% CPU utilization provides an optimal balance, ensuring that new instances are added proactively to maintain performance without over-provisioning for transient spikes. The scale-in threshold of 30% CPU creates a sufficient buffer, preventing premature de-provisioning of instances when demand temporarily dips. This significant delta between thresholds is crucial for maintaining system stability, preventing 'autoscale thrashing,' and optimizing both application responsiveness and cloud costs.

Why this answer

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 →
178
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

Implementing retry logic with exponential backoff is a highly effective and recommended pattern for handling transient faults, including throttling, in distributed systems. When a downstream service like Cosmos DB temporarily throttles a request, the function can automatically retry the operation after progressively longer delays. This approach allows the throttled service time to recover, reduces the immediate load, and ensures eventual success without incurring additional infrastructure costs, making the function more resilient.

Why this answer

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 →
179
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

Azure WebJobs are designed to run background tasks directly within an existing Azure App Service instance, sharing the same App Service Plan's compute, memory, and network resources. This tight integration means the WebJob scales automatically with the web app's instances and incurs no additional compute costs beyond the App Service Plan itself, simplifying management and cost tracking by leveraging existing infrastructure.

Why this answer

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 →
180
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

The "dnsNameLabel" property is the correct configuration element used to assign a public, human-readable DNS name to an Azure Container Instance (ACI) container group. When specified, Azure automatically registers a DNS record in the format `dnsNameLabel.region.azurecontainer.io`, enabling external clients to access the containerized application via a stable, memorable FQDN rather than just an IP address. This is crucial for public internet accessibility.

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 →
181
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

Enabling the 'HTTPS Only' setting in the App Service's TLS/SSL settings blade is the recommended and most efficient method for enforcing HTTPS. This platform-level configuration automatically redirects all incoming HTTP requests to their HTTPS equivalents before they even reach the application code. This ensures that all traffic is encrypted, simplifies application development by removing the need for in-app redirection logic, and provides a robust, managed solution directly from the Azure infrastructure.

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 →
182
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

Azure App Service on Windows is an ideal platform for migrating existing .NET Framework web applications, offering a fully managed environment that natively supports IIS and the full .NET Framework runtime. It provides seamless integration with services like Azure Files for persistent storage, allowing applications to retain their file system dependencies without significant code changes. Furthermore, App Service on Windows inherently supports Windows authentication, which is crucial for many enterprise .NET Framework applications, making it a direct and efficient lift-and-shift target.

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 →
183
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 in Azure App Service provide distinct environments for different versions of your application, such as staging and production. They allow you to deploy a new version to a non-production slot, warm it up, and then instantly swap it with the production slot, effectively achieving zero-downtime deployments. If issues arise post-swap, an immediate rollback to the previous production version is possible by swapping back, making them ideal for safe, continuous delivery.

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 →
184
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

Deploying to a staging slot allows the new version of the document rendering job to be thoroughly tested and validated in an environment identical to production, without affecting live users. Once health checks pass and functional tests confirm stability, an atomic slot swap seamlessly redirects traffic to the pre-warmed staging slot. This process minimizes downtime, provides a quick rollback option, and ensures a robust, validated deployment before impacting production traffic.

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 →
185
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

The Azure Functions Premium plan is specifically engineered to eliminate cold starts by providing pre-warmed instances. This plan continuously keeps a specified number of instances active and ready to process requests, ensuring that new invocations do not incur the latency associated with starting up a new host or loading function code. It offers enhanced performance, VNet connectivity, and predictable scaling, making it ideal for latency-sensitive applications like IoT processing.

Why this answer

The Consumption plan for Azure Functions can cause cold start latency because the function app is deallocated after a period of inactivity. Changing to the Premium plan with pre-warmed instances keeps a specified number of instances always running and ready to handle requests, eliminating the cold start delay for those instances. This is the most effective action among the options to reduce cold starts.

Exam trap

The trap here is that candidates often confuse the function timeout setting (which controls execution duration) with the cold start issue, or they think that Durable Functions inherently solve performance problems, when in fact they are for workflow orchestration and do not address cold starts.

How to eliminate wrong answers

Option A is wrong because Durable Functions are designed for orchestrating long-running workflows and stateful processes, not for reducing cold start latency; they actually run on the same underlying plan and can themselves experience cold starts. Option C is wrong because increasing the function timeout (up to 10 minutes for the Consumption plan) only affects how long a function can run before being terminated, not the initial startup delay of a cold instance. Option D is wrong because while a dedicated App Service plan does eliminate cold starts by keeping the app always running, it is not the most effective choice compared to the Premium plan with pre-warmed instances, as the Premium plan offers the same benefit with additional features like virtual network integration and unlimited execution duration, and is specifically designed for this scenario.

Practice this question →
186
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

Enabling a retry policy on the Event Grid subscription is a fundamental mechanism for handling transient failures when delivering events to the Azure Function. This policy automatically reattempts delivery to the endpoint if the function returns an HTTP error (e.g., 4xx or 5xx), ensuring that temporary issues like network glitches or service unavailability do not result in lost events. Configuring appropriate retry attempts and backoff intervals significantly enhances the reliability of event processing.

Why this answer

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 →
187
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

Azure Resource Graph queries demand precise casing for resource types to ensure accurate identification and retrieval of resources. The correct and canonical resource type for Application Insights components is 'microsoft.insights/components', which is entirely in lowercase. If the query specifies a resource type with any deviation in casing, such as 'Microsoft.Insights/Components' or 'microsoft.insights/Components', it will fail to match any existing resources, resulting in an empty query output. This strict case-sensitivity is fundamental for correct resource targeting in ARG.

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 →
188
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

Azure App Service deployment slots are live apps with their own hostnames, providing distinct environments for different versions of your application. They enable staging new code, performing quality assurance, and warming up instances before swapping them into production. This mechanism facilitates zero-downtime deployments and allows for easy rollbacks by swapping back to a previous slot.

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 →
189
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

Configuring App Service Authentication with Microsoft Entra ID validates tokens at the platform's reverse proxy, so unauthenticated requests are rejected with 401 before the function's code ever runs. This satisfies the stem's requirement to block calls pre-execution, unlike in-code token validation, which only occurs once the function has already been invoked.

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 →
190
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 →
191
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
AnswersA, C, D

While Azure Front Door provides global load balancing and web application firewall capabilities, its primary role is optimizing global routing for web traffic and accelerating content delivery. It's not designed as a primary disaster recovery mechanism for backend Kubernetes clusters, especially for non-HTTP/S traffic or complex failover scenarios beyond simple endpoint health checks. Its focus is on edge acceleration and WAF, not orchestrating multi-region Kubernetes failover.

Why this answer

Option D is correct because deploying AKS clusters in multiple Azure regions is the foundational step for cross-region high availability and disaster recovery, ensuring the workload survives a regional outage. Option A is correct because Azure Front Door provides global HTTP/HTTPS load balancing with anycast, health probes, and failover across regional AKS endpoints, improving availability and latency for the containerized application. Option C is correct because Azure Traffic Manager is a DNS-based global traffic router that can distribute and fail over traffic between AKS clusters in different regions using priority, weighted, or performance routing methods.

Option B is not correct here because Pod Disruption Budgets only protect pod availability during voluntary disruptions such as node drains within a single cluster, not cross-region DR. Option E is not correct because Cluster Autoscaler only scales node pools within a cluster based on resource demand and does not provide regional redundancy or disaster recovery.

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 →
192
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

This cron expression precisely defines a schedule for a job to run at the very beginning of every hour. By setting both the second and minute fields to "0", it ensures the trigger occurs exactly at the 0th second of the 0th minute of any given hour. The wildcard "*" in the hour, day of month, month, and day of week fields ensures this execution pattern repeats consistently, once per hour, every hour of every day.

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 →
193
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

Autoscale rules on the App Service plan add or remove instances based on CPU percentage, with thresholds of 75% out and 25% in plus cool-down periods preventing rapid oscillation. This satisfies the fluctuating-traffic and gradual-scaling constraints, since scale-out and scale-in are metric-driven rather than manual.

Why this answer

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 →
194
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 is specifically designed to activate an Azure Function whenever a new or updated blob is detected in a specified Azure Storage container. This directly addresses the requirement for processing images upon upload. Coupled with the Consumption plan, the function automatically scales out to handle fluctuating volumes of image uploads, executing only when triggered and incurring costs solely based on execution time and memory usage, making it highly efficient and cost-effective for serverless workloads.

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 →
195
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 inherently provides state persistence and reliability through its default checkpointing and replay mechanism. It automatically saves the orchestration's execution history to a storage provider (typically Azure Storage) after each await point. In the event of an app restart or host failure, the Durable Task Framework replays this stored history to reconstruct the orchestration's state exactly as it was before the interruption, ensuring seamless continuation. This built-in functionality is fundamental to Durable Functions' "durable" nature.

Why this answer

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 →
196
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 'functionAppScaleLimit' 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

The functionAppScaleLimit application setting caps the maximum number of instances a Function App scales out to, so setting it to 10 preserves Consumption Plan burst scaling while enforcing the stated ceiling of 10 concurrent instances.

Why this answer

The 'functionAppScaleLimit' application setting controls the maximum number of instances for a function app running on the Consumption plan. Setting it to 10 ensures the app does not scale beyond 10 instances. The 'maxConcurrentCalls' property only limits per-instance concurrency.

Exam trap

The trap is confusing per-instance concurrency settings (like 'maxConcurrentCalls' in host.json) with the function app's instance-level scale limit ('functionAppScaleLimit'). The question specifically asks to cap the number of concurrent instances.

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 →
197
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 is purpose-built for executing PowerShell scripts (runbooks) on a schedule without managing underlying infrastructure. It natively supports PowerShell, allowing you to upload scripts, define schedules, and use Managed Identities or Run As accounts for secure authentication to Azure resources. This provides a truly serverless and low-management solution ideal for routine administrative tasks like nightly cleanup scripts.

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 →
198
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

Managed identities provide an Azure Active Directory identity for Azure resources, such as an Azure Web App for Containers. This allows the application to authenticate securely to other Azure services, like Azure App Configuration, without requiring any explicit credentials or connection strings to be stored in the application code or configuration. The Azure platform automatically manages the identity's lifecycle and authentication tokens, enabling secure, secret-less access based on assigned Azure RBAC roles.

Why this answer

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 →
199
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

Deploying an Azure Service Mesh, such as Open Service Mesh (OSM) or Istio on AKS, provides a robust solution for enabling mutual TLS (mTLS) transparently across microservices. A service mesh injects sidecar proxies alongside each application container, which intercept all network traffic. These proxies then handle certificate issuance, rotation, and the establishment of mTLS connections, ensuring all service-to-service communication is encrypted and authenticated without requiring application code changes.

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 →
200
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

The 'Always' restart policy ensures that the container instance continuously runs, automatically restarting the container whenever it stops, regardless of the exit code. This is crucial for maintaining application availability for long-running services. Assigning a DNS name label to the public IP address provides a user-friendly, resolvable hostname (e.g., myapp.eastus.azurecontainer.io), making the containerized application easily accessible and discoverable from the internet.

Why this answer

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

Candidates might consider 'OnFailure' for unexpected exits, which is a valid policy for that scenario. However, 'Always' also fulfills the requirement and is correctly paired with the public IP/DNS name label in option D. A common mistake is also assuming a virtual network is required for public IP assignment, when 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 →
201
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

Azure App Service provides a dedicated configuration setting to specify the exact command or script that should be executed when the application instance starts. This can be configured through the Azure portal under 'Configuration' -> 'General settings' -> 'Startup Command,' or programmatically via Azure CLI using `az webapp config set --startup-file`. This mechanism allows for executing custom shell scripts (e.g., `./startup.sh`) or direct application commands (e.g., `npm start`, `gunicorn app:app`) to properly initialize the application environment.

Why this answer

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 →
202
MCQmedium

You are developing an application that runs on Azure App Service. The application needs to store session state. The session state must be shared across multiple instances of the app and survive restarts. You need to choose a session state provider. What should you use?

A.Use Azure Table Storage for session state.
B.Use a SQL Database to store session data.
C.Use the in-memory session state provider.
D.Use Azure Redis Cache as a session state provider.
AnswerD

Azure Redis Cache is an in-memory data store based on the open-source Redis project, specifically designed for high-performance caching and session state management. It offers extremely low-latency access, supports data persistence (optional), and provides built-in features like automatic expiration (Time-To-Live) for session keys. Its distributed nature allows session data to be shared across multiple application instances, ensuring scalability and high availability, making it an ideal choice for robust and performant web applications.

Why this answer

Azure Redis Cache provides a distributed, in-memory data store that can be shared across multiple instances of an App Service application and persists data through restarts. It is the recommended session state provider for Azure App Service when high availability and scalability are required, as it stores session data externally from the application's memory.

Exam trap

The trap here is that candidates often choose the in-memory provider (Option C) because it is the simplest default in ASP.NET, forgetting that it fails the cross-instance sharing and restart survival requirements explicitly stated in the question.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a NoSQL key-value store designed for structured, non-relational data and does not provide the low-latency, in-memory access required for session state; it also lacks built-in expiration and eviction policies for session data. Option B is wrong because SQL Database, while persistent and shareable, introduces higher latency and overhead for session state operations compared to an in-memory cache, and is not optimized for the high-throughput, short-lived nature of session data. Option C is wrong because the in-memory session state provider stores session data within the memory of a single application instance, so it is not shared across multiple instances and is lost when the app restarts or scales out.

Practice this question →
203
MCQhard

You are deploying a Java application to Azure App Service on Linux. The application requires a specific JDK version not available in the built-in stack. You need to provide the JDK without creating a custom container. What should you do?

A.Mount an Azure Files share containing the JDK
B.Use the Azure App Service Windows stack with a custom JDK
C.Use a startup script to download and set JAVA_HOME
D.Create a custom Docker container and deploy to App Service
AnswerC

Azure App Service on Linux allows you to specify a custom startup command or script that executes before your application starts. This script provides a robust mechanism to download a specific JDK version (e.g., from a trusted URL or Azure Blob Storage), install it into the container's file system, and then correctly configure critical environment variables such as JAVA_HOME and PATH. This approach offers significant flexibility to use a precise JDK version not pre-installed on the base image, ensuring application compatibility without the overhead of a full custom Docker image.

Why this answer

Azure App Service on Linux allows you to use a startup script to download a custom JDK and set the JAVA_HOME environment variable before the application starts. This approach avoids the need for a custom container while providing the specific JDK version required by the application.

Exam trap

The trap here is that candidates may think mounting a file share (Option A) is the simplest way to provide custom binaries, but they overlook that App Service on Linux does not support mounting Azure Files for executable files, and the startup script approach is the documented method for custom runtimes.

How to eliminate wrong answers

Option A is wrong because mounting an Azure Files share containing the JDK would require the JDK to be accessible at runtime, but App Service on Linux does not support mounting Azure Files shares for custom executables in the same way as Windows; the JDK must be installed in the container's file system. Option B is wrong because the question specifies deploying to Azure App Service on Linux, and using the Windows stack would change the underlying OS, which is not allowed per the requirement. Option D is wrong because creating a custom Docker container is unnecessary and contradicts the requirement to avoid a custom container; the startup script approach achieves the same result without containerization overhead.

Practice this question →
204
MCQmedium

You are deploying a containerized application to Azure Container Instances. The application requires writing temporary files to a local filesystem. You need to ensure that the files persist if the container restarts. What should you do?

A.Mount an Azure Files share as a volume in the container group.
B.Use the container's writable layer to store files.
C.Use Azure Blob Storage and mount it as a volume.
D.Configure a Docker volume in the container image.
AnswerA

Mounting an Azure Files share as a volume within an Azure Container Instance (ACI) container group provides a robust solution for persistent and shared storage. This approach leverages the Server Message Block (SMB) or Network File System (NFS) protocol to connect the container to a managed file share, ensuring that data persists across container restarts and can be accessed by multiple containers within the same group or even different container groups. It is the recommended method for stateful applications requiring durable storage in ACI.

Why this answer

Azure Container Instances (ACI) supports mounting Azure Files shares as volumes. When a container restarts, its writable layer is ephemeral and lost, but an Azure Files share persists independently. By mounting the share, temporary files written to the mount point survive container restarts, meeting the persistence requirement.

Exam trap

The trap here is that candidates confuse Azure Blob Storage (object storage) with Azure Files (SMB file share) and assume both can be mounted as volumes in ACI, but only Azure Files is supported for volume mounts in container groups.

How to eliminate wrong answers

Option B is wrong because the container's writable layer is ephemeral and is destroyed when the container restarts, so files stored there do not persist. Option C is wrong because Azure Blob Storage cannot be mounted as a volume in ACI; only Azure Files (SMB) shares are supported for volume mounts. Option D is wrong because Docker volumes are configured at the container runtime level, not in the container image, and ACI does not support Docker volumes; it uses its own volume mounting mechanism.

Practice this question →
205
Multi-Selecthard

A report export service 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 anonymous access on the vault
B.Store the Key Vault access key in app settings
C.Grant the identity permission to read the required secrets
D.Enable a managed identity for the web app
AnswersC, D

After an identity (such as a managed identity) is established for the Azure App Service, it must be explicitly authorized to perform specific operations within Azure Key Vault. This authorization is achieved by assigning appropriate permissions, typically through Azure Role-Based Access Control (RBAC) roles like "Key Vault Secrets User" or by configuring an access policy directly on the Key Vault, granting "Get" and "List" secret permissions to the service principal. This ensures the principle of least privilege is followed.

Why this answer

Granting the managed identity permission to read secrets in Key Vault via Azure RBAC or access policies ensures that the App Service can authenticate without storing any secrets in configuration. This follows the principle of least privilege and eliminates the risk of credential leakage from app settings or connection strings.

Exam trap

The trap here is that candidates often think storing the Key Vault URI or a reference in app settings is sufficient, but the question explicitly requires 'without connection strings in configuration,' so the correct path is to use managed identity plus granting permissions, not storing any key material.

Practice this question →
206
MCQhard

A workflow must process 500 customer records in parallel and then aggregate all results into a single summary report. The team wants to use Azure Durable Functions so the orchestration state is durable and the solution can resume after a Function App restart. Which Durable Functions pattern matches this requirement?

A.Fan-out/fan-in: start 500 activity functions in parallel with Task.WhenAll inside the orchestrator, then aggregate all returned results
B.Function chaining: call each activity function sequentially, collecting each result before starting the next
C.Async HTTP API: start the workflow with an HTTP trigger, return a 202 with a status URL, and have the client poll for completion
D.Monitor: use a Durable timer loop that checks a status table every 60 seconds until all records are marked processed
AnswerA

Task.WhenAll fires all 500 activities simultaneously (constrained by the configured max concurrency). The orchestrator yields at the await statement, checkpointing its state. When all activities complete, the orchestrator resumes and aggregates results. Durable state management handles host restarts transparently.

Why this answer

The fan-out/fan-in pattern in Durable Functions is specifically designed to execute multiple activity functions in parallel using Task.WhenAll inside an orchestrator, then aggregate their results. This matches the requirement to process 500 customer records concurrently and produce a single summary report, while the orchestration state is durably persisted and can resume after a Function App restart.

Exam trap

The trap here is that candidates may confuse the fan-out/fan-in pattern with the Async HTTP API pattern, thinking that the HTTP trigger and status polling are required for parallel processing, but the key distinction is that fan-out/fan-in handles the parallel execution and aggregation within the orchestrator itself, not via external polling.

How to eliminate wrong answers

Option B is wrong because function chaining executes activity functions sequentially, which would not process 500 records in parallel and would be inefficient for this workload. Option C is wrong because the Async HTTP API pattern is about starting a workflow and providing a status endpoint for polling, not about parallel execution and aggregation of results. Option D is wrong because the Monitor pattern uses a timer loop to check a status table periodically, which is designed for polling external state changes, not for parallel processing and aggregation of customer records.

Practice this question →
207
MCQmedium

You have an Azure Web App that uses Azure SQL Database. You need to securely connect to the database using Managed Identity. Which connection string setting should you use?

A.Server=tcp:myserver.database.windows.net;Database=mydb;User Id=myadmin;Password=mypassword;
B.Server=tcp:myserver.database.windows.net;Database=mydb;Integrated Security=True;
C.Server=tcp:myserver.database.windows.net;Database=mydb;Authentication=Active Directory Password;User Id=myuser@domain.com;Password=...;
D.Server=tcp:myserver.database.windows.net;Database=mydb;Authentication=Active Directory Managed Identity;User Id=myapp;
AnswerD

This is the correct and recommended connection string for an Azure Web App to connect to Azure SQL Database using a managed identity. The `Authentication=Active Directory Managed Identity` parameter instructs the client library to automatically acquire an access token for the web app's assigned managed identity. This eliminates the need for any secrets in the connection string, enhancing security and simplifying credential management.

Why this answer

It uses the 'Authentication=Active Directory Managed Identity' keyword, which tells the SQL client to acquire an access token from Azure AD via the managed identity endpoint. The 'User Id' is set to the name of the managed identity (the app's system-assigned or user-assigned identity), and no password is needed because the token is obtained automatically. This enables a passwordless, secure connection to Azure SQL Database without storing credentials.

Exam trap

The trap here is that candidates often confuse 'Integrated Security=True' (Windows auth) with Azure AD Managed Identity, or they think a password-based Azure AD option (like Active Directory Password) is sufficient, missing the key requirement of a passwordless, identity-based connection.

How to eliminate wrong answers

Option A is wrong because it uses a SQL admin username and password, which requires storing secrets and does not leverage Managed Identity at all. Option B is wrong because 'Integrated Security=True' is a Windows authentication mechanism for on-premises Active Directory and does not work with Azure SQL Database or Azure AD Managed Identity. Option C is wrong because 'Authentication=Active Directory Password' still requires a password and a user principal name, which defeats the purpose of using a managed identity and introduces credential management overhead.

Practice this question →
208
MCQmedium

Your company is developing a real-time dashboard that displays live metrics from IoT devices. The backend processes device data using Azure Functions with an Event Hubs trigger. The processed data is stored in Azure Cosmos DB. You need to ensure that the system can handle a sudden increase in device data without losing messages or overloading Cosmos DB. The solution must minimize latency and cost. What should you do?

A.Implement a buffer using Azure Blob storage: the Event Hubs triggered function writes raw data to blobs, and a separate timer-triggered function batches and writes to Cosmos DB at a controlled rate.
B.Configure the Event Hubs trigger to use a checkpointing strategy with a larger batch size to reduce the number of function invocations.
C.Use Azure Stream Analytics to process the Event Hubs data and write directly to Cosmos DB.
D.Increase the provisioned throughput (RU/s) on the Cosmos DB container to handle peak loads.
AnswerA

This strategy effectively decouples the high-ingestion rate of Event Hubs from the potentially lower write capacity of Cosmos DB. The Event Hubs triggered function rapidly writes raw, unbatched data to inexpensive Azure Blob storage, acting as a temporary buffer. A separate timer-triggered function then reads these blobs, aggregates data into larger batches, and writes them to Cosmos DB at a controlled, sustainable rate, preventing throttling and optimizing RU/s consumption. This approach ensures data durability and cost-efficiency by leveraging Blob storage for buffering and batching writes to Cosmos DB.

Why this answer

It decouples the ingestion rate from the write rate to Cosmos DB. By buffering raw data in Azure Blob storage and using a timer-triggered function to batch-write at a controlled rate, the system can absorb sudden spikes in device data without overwhelming Cosmos DB or losing messages. This approach minimizes latency by keeping the Event Hubs trigger processing fast (writing to blob) and reduces cost by avoiding the need to over-provision RU/s on Cosmos DB.

Exam trap

The trap here is that candidates often assume increasing throughput or batch size is the simplest solution, but the exam tests the understanding that decoupling ingestion from processing with a buffer is the correct way to handle sudden load spikes while minimizing cost and latency.

How to eliminate wrong answers

Option B is wrong because increasing the batch size in the Event Hubs trigger does not prevent Cosmos DB from being overloaded; it only reduces the number of function invocations but still writes the same volume of data per unit time, and larger batches can increase latency and risk of timeouts. Option C is wrong because Azure Stream Analytics writes directly to Cosmos DB without a built-in rate-limiting mechanism, so a sudden surge in data can still overwhelm the database or cause throttling, and it adds ongoing cost for the Stream Analytics job. Option D is wrong because simply increasing provisioned throughput (RU/s) on Cosmos DB addresses the symptom (throttling) but not the root cause (spiky load), leading to higher cost during normal operation and still risking message loss if the spike exceeds the provisioned RU/s.

Practice this question →
209
Multi-Selecthard

Which THREE are valid ways to authenticate an Azure Functions app to an Azure Service Bus namespace?

Select 3 answers
A.Using an Azure AD token obtained via DefaultAzureCredential
B.Using a connection string with shared access policy
C.Using a system-assigned managed identity
D.Using a client certificate
E.Using a SAS key stored in code
AnswersA, B, C

Azure Functions can authenticate to other Azure services (like Key Vault, Storage, Cosmos DB) using Azure AD tokens. DefaultAzureCredential is part of the Azure Identity client library, providing a chain of credential types that attempt to authenticate in various environments (local development, Azure deployment) using the most appropriate method, such as a developer's logged-in account, environment variables, or a managed identity, ultimately acquiring an Azure AD token. This enables secure, token-based access without hardcoding secrets.

Why this answer

DefaultAzureCredential from the Azure Identity library can authenticate to Azure Service Bus using Azure AD tokens. This credential chain attempts multiple authentication sources (environment variables, managed identity, Visual Studio, etc.) to obtain a token, which is then used to authorize requests to the Service Bus namespace via Azure RBAC.

Exam trap

The trap here is that candidates might think client certificates are a valid authentication method for Service Bus, but Service Bus only supports Azure AD, SAS tokens, and connection strings—not certificate-based authentication.

Practice this question →
210
MCQhard

You are designing a serverless application using Azure Functions that processes high-volume events from Azure Event Hubs. The events are then written to Azure Cosmos DB. The function must guarantee at-least-once delivery and be resilient to failures. The Cosmos DB account uses the SQL API and is configured with a single write region. You need to design the function to handle transient failures when writing to Cosmos DB without losing events. What should you do?

A.Increase the Event Hubs trigger's batch size to reduce the number of writes.
B.Implement a poison message queue to store failed events and reprocess them later.
C.In the function code, manually write to Cosmos DB and then manually checkpoint the Event Hubs partition.
D.Use the Cosmos DB output binding with built-in retry policy and configure the trigger to checkpoint only after successful writes.
AnswerD

Utilizing the Cosmos DB output binding provides built-in retry capabilities, automatically attempting to write data multiple times in case of transient failures, significantly improving reliability. Crucially, configuring the Event Hubs trigger to checkpoint only after successful writes ensures that an event is not marked as processed in Event Hubs until it has been durably persisted to Cosmos DB. This combination guarantees at-least-once delivery, preventing data loss even if the function encounters transient issues.

Why this answer

Using the Cosmos DB output binding with its built-in retry policy automatically handles transient failures by retrying writes. By configuring the Event Hubs trigger to checkpoint only after a successful write, you ensure that events are not acknowledged until they are durably stored in Cosmos DB, guaranteeing at-least-once delivery and resilience to failures.

Exam trap

The trap here is that candidates often think manual checkpointing gives them more control, but it actually introduces a window for data loss if the checkpoint occurs before the write is confirmed, whereas the output binding's built-in retry and automatic checkpointing on success provide a safer, more reliable pattern.

How to eliminate wrong answers

Option A is wrong because increasing the batch size does not address transient failures; it only processes more events per invocation, which can increase memory pressure and the risk of losing a larger batch if a failure occurs. Option B is wrong because a poison message queue is used for handling malformed or unprocessable events, not for transient failures that can be retried; it adds unnecessary complexity and does not leverage the built-in retry capabilities of the Cosmos DB output binding. Option C is wrong because manually writing to Cosmos DB and then manually checkpointing introduces a risk of checkpointing before the write succeeds, leading to potential data loss; it also bypasses the automatic retry and consistency guarantees provided by the output binding.

Practice this question →
211
Multi-Selecthard

You are developing a solution that uses Azure Container Apps to host a microservices application. The application consists of multiple services that need to communicate with each other. You need to configure the services to meet the following requirements: (1) Services must be able to discover each other by name, (2) Communication between services must be secure and encrypted, (3) You want to minimize the need for managing certificates. Which two actions should you perform? (Choose two.)

Select 2 answers
A.Deploy an Azure Application Gateway in front of the Container Apps environment to handle internal traffic.
B.Enable mutual TLS (mTLS) for the Container Apps environment.
C.Store service endpoints in Azure Key Vault and retrieve them at runtime.
D.Configure a custom DNS name for each container app and use it for service discovery.
E.Use Azure Container Apps' built-in service discovery by referring to other services using their app name.
AnswersB, E

Mutual TLS in Azure Container Apps provides automatic encryption and authentication between services within the environment. When enabled, each container app receives a certificate issued by the platform, and communication between apps is encrypted and authenticated without manual certificate management. This satisfies the requirement for secure, encrypted communication and minimizes certificate management because the platform handles certificate issuance and rotation. Enabling mTLS is a key step to secure service-to-service communication in a microservices architecture hosted on Container Apps.

Why this answer

To enable secure service-to-service communication with discovery by name and minimal certificate management, you should enable mutual TLS for the Container Apps environment and use the built-in service discovery. mTLS automatically encrypts and authenticates traffic between container apps, and the platform manages certificates. Built-in service discovery allows services to find each other using the app name without additional configuration. Together, these features provide a secure and simplified microservices communication setup.

Exam trap

The trap here is thinking that external load balancers or custom DNS are needed for internal service communication, when Container Apps provides native mTLS and service discovery.

Practice this question →
212
MCQmedium

You are deploying a web app to Azure App Service. The app uses environment-specific configuration (e.g., connection strings). You need to manage these settings without redeploying the app. Which feature should you use?

A.Azure App Configuration service
B.App Service application settings
C.ARM template parameters
D.Azure Key Vault references in App Service
AnswerB

App Service application settings are key-value pairs that are injected as environment variables into the application's runtime. They can be easily managed through the Azure portal, CLI, or PowerShell, allowing immediate updates without requiring a code redeployment. Changes to these settings automatically trigger an application restart, ensuring the new values are picked up promptly, making them the ideal and most straightforward solution for managing environment-specific configuration.

Why this answer

App Service application settings (option B) are the correct feature because they allow you to store environment-specific configuration (e.g., connection strings, app settings) as key-value pairs that are injected into the app at runtime. These settings can be changed in the Azure portal, CLI, or PowerShell without redeploying the application code, making them ideal for managing configuration across different environments (development, staging, production). The settings are automatically encrypted at rest and overridden for the specific App Service slot when using deployment slots.

Exam trap

The trap here is that candidates often confuse Azure App Configuration service (a premium, centralized config service) with the simpler, built-in App Service application settings, or they mistakenly think Key Vault references alone can replace application settings, not realizing that references are just a value source within an application setting.

How to eliminate wrong answers

Option A is wrong because Azure App Configuration service is a centralized configuration store for distributed applications, but it requires the app to explicitly pull configuration via its SDK or a provider, and it is not the simplest or most direct way to manage environment-specific settings without redeploying—App Service application settings are built-in and require no code changes. Option C is wrong because ARM template parameters are used to parameterize infrastructure deployments (e.g., resource names, SKUs) and are evaluated at deployment time; they cannot be changed after the app is deployed without redeploying the ARM template. Option D is wrong because Azure Key Vault references in App Service allow you to reference secrets stored in Key Vault from application settings, but they are a feature built on top of application settings—you still need to define the application setting (which is an App Service application setting) to point to the Key Vault secret, and the question asks for managing environment-specific configuration, not specifically secrets.

Practice this question →
213
MCQhard

You are designing a serverless application using Azure Functions. The function must process messages from an Azure Service Bus queue. The processing time for each message can vary from a few seconds to several minutes. You need to minimize costs while ensuring that messages are processed in a timely manner. Which hosting plan should you recommend?

A.Container Instances plan
B.Premium plan
C.App Service plan
D.Consumption plan
AnswerB

The Azure Functions Premium plan is the optimal choice for scenarios demanding predictable performance, extended execution durations, and elimination of cold starts. It provides pre-warmed instances to ensure immediate response to triggers, crucial for time-sensitive Service Bus message processing. Critically, the Premium plan supports configurable execution timeouts up to 60 minutes, making it suitable for long-running operations that exceed the limits of the Consumption plan, while still offering dynamic scaling.

Why this answer

The Premium plan is correct because it supports long execution times (up to 60 minutes by default, configurable to unlimited), always-warm instances to avoid cold starts, and virtual network integration—all while providing predictable pricing and scaling. This meets the requirement of processing messages that can take several minutes without incurring the cold-start penalties or execution-time limits of the Consumption plan.

Exam trap

The trap here is that candidates often assume the Consumption plan is always the cheapest option, but they overlook its 10-minute execution timeout and cold-start latency, which can cause message processing failures or delays for long-running tasks.

How to eliminate wrong answers

Option A is wrong because Container Instances is not a hosting plan for Azure Functions; it is a separate service for running containers directly, not a Functions hosting option. Option C is wrong because the App Service plan requires a dedicated, always-running VM, which incurs higher costs than necessary for a serverless workload and does not provide the automatic scale-to-zero benefit of serverless plans. Option D is wrong because the Consumption plan has a maximum execution timeout of 10 minutes (by default 5 minutes) and can suffer from cold starts, making it unsuitable for messages that may take several minutes to process.

Practice this question →
214
Multi-Selecteasy

Which TWO actions should you take to enable a user-assigned managed identity for an Azure App Service web app?

Select 2 answers
A.Create the managed identity resource in Microsoft Entra ID.
B.Configure the identity in each deployment slot separately.
C.Store the identity's client ID in an app setting.
D.Create the managed identity in the same resource group as the web app.
E.Assign the identity to the web app in the Azure portal or CLI.
AnswersA, E

Creating a user-assigned managed identity involves provisioning it as a standalone Azure resource, distinct from the consuming service. This resource is then registered with Microsoft Entra ID, establishing its unique identity principal. This initial creation step is fundamental, as it defines the identity that will subsequently be assigned to Azure services like web apps, making it a prerequisite for their use.

Why this answer

A user-assigned managed identity is a standalone Azure resource created in Microsoft Entra ID (formerly Azure AD). It must exist as an identity resource before it can be assigned to any Azure service, including an App Service web app. This identity is then tied to a specific tenant and can be used by multiple Azure resources.

Exam trap

The trap here is that candidates often confuse user-assigned managed identities with system-assigned managed identities, assuming the identity must be created in the same resource group as the web app or that its client ID must be manually stored in an app setting, when in fact user-assigned identities are independent resources that can be created anywhere and are automatically discoverable by the consuming service.

Practice this question →
215
MCQmedium

You are developing an Azure Functions app that processes orders. The function must scale out automatically during peak hours but should not incur costs when idle. Which hosting plan should you use?

A.Premium plan
B.Container Instances
C.App Service plan
D.Consumption plan
AnswerD

The Consumption plan is the quintessential serverless hosting option for Azure Functions, offering automatic scaling from zero instances and charging only for the compute resources consumed during function execution. It dynamically allocates and deallocates resources based on incoming events, meaning you pay nothing when your functions are idle. This pay-per-execution model makes it the most cost-effective choice for intermittent, event-driven, or highly variable workloads where minimizing idle costs is paramount.

Why this answer

The Consumption plan is correct because it automatically scales your function app based on demand, including scaling out to handle peak loads, and you only pay for execution time and resources consumed when your functions are running. When idle, there are no costs because the plan does not reserve any instances; it relies on a dynamic, event-driven scale model that can scale down to zero.

Exam trap

The trap here is that candidates often confuse the Premium plan's 'always ready' instances with the Consumption plan's true scale-to-zero capability, mistakenly thinking Premium is required for automatic scaling, when in fact Consumption provides automatic scaling and zero-cost idle behavior.

How to eliminate wrong answers

Option A is wrong because the Premium plan, while offering automatic scaling and no cold starts, incurs costs for pre-warmed instances and a minimum baseline of always-ready workers, so it does not scale to zero and will incur costs when idle. Option B is wrong because Container Instances are not a hosting plan for Azure Functions; they are a service for running containers directly, and while they can scale, they do not provide the built-in, event-driven scaling and pay-per-execution model of Azure Functions. Option C is wrong because the App Service plan runs on dedicated VMs that are always on, meaning you pay for the allocated resources (e.g., VM instances) even when the function app is idle, and it does not scale to zero.

Practice this question →
216
MCQeasy

You are reviewing an ARM template snippet for an Azure App Service. The exhibit shows the site configuration. You need to ensure that the app supports WebSocket connections for a real-time feature. Which setting must be added?

A.Set alwaysOn to false.
B.Set http20Enabled to false.
C.Change ftpsState to AllAllowed.
D.Add 'webSocketsEnabled': true to siteConfig.
AnswerD

For an Azure App Service to properly support and route WebSocket traffic, the "webSocketsEnabled" property must be explicitly set to "true" within the "siteConfig" section of the ARM template. This configuration instructs the underlying Azure platform to enable the necessary infrastructure for WebSocket connections, allowing the initial HTTP upgrade handshake to succeed and establish persistent, full-duplex communication channels between clients and the application. Without this setting, WebSocket connections will fail.

Why this answer

The 'webSocketsEnabled' property in the siteConfig of an Azure App Service ARM template explicitly enables WebSocket protocol support. WebSocket connections require a persistent, full-duplex communication channel over a single TCP connection, which is not enabled by default in Azure App Service. Setting this property to true allows the app to handle real-time features like chat or live notifications.

Exam trap

The trap here is that candidates often confuse 'webSocketsEnabled' with other networking or protocol settings like HTTP/2 or alwaysOn, assuming WebSockets are automatically supported or require a different configuration flag.

How to eliminate wrong answers

Option A is wrong because setting 'alwaysOn' to false would cause the app to unload after periods of inactivity, which would break WebSocket connections that need the app to remain active; alwaysOn should be true for WebSockets. Option B is wrong because 'http20Enabled' controls HTTP/2 support, which is unrelated to WebSocket functionality; disabling it does not affect WebSocket connections. Option C is wrong because 'ftpsState' controls FTP/FTPS access for file transfers, not WebSocket protocol support; changing it to AllAllowed has no impact on real-time features.

Practice this question →
217
MCQeasy

You deploy a containerized web application to Azure Container Instances (ACI). The application writes session data to a local directory. You need the data to persist across container restarts (e.g., after a crash or redeployment). Which storage configuration should you use?

A.Use an emptyDir volume within the container group.
B.Mount an Azure Files share as a volume in the container group.
C.Use the container's own filesystem and copy data to a blob storage on shutdown.
D.Enable Azure Disk Encryption on the container group.
AnswerB

Mounting an Azure Files share as a volume in an Azure Container Instances (ACI) container group is the correct approach for persistent storage. Azure Files offers fully managed, highly available file shares that can be accessed via the SMB protocol, ensuring data durability and availability even if the container group is stopped, restarted, or deleted. The data resides independently in Azure Storage, allowing new or restarted container instances to access the same persistent state.

Why this answer

Azure Files provides a fully managed SMB file share in the cloud that can be mounted as a volume in an Azure Container Instance. This allows session data written to the local directory to persist across container restarts, crashes, or redeployments, as the data lives on the share rather than in the ephemeral container filesystem.

Exam trap

The trap here is that candidates confuse 'emptyDir' (which is ephemeral and often used in Kubernetes for temporary storage) with a persistent volume, not realizing that ACI's emptyDir is also ephemeral and does not survive container group restarts.

How to eliminate wrong answers

Option A is wrong because an emptyDir volume is ephemeral and tied to the lifecycle of the pod or container group; its contents are deleted when the container group is restarted or redeployed, so it does not provide persistence across restarts. Option C is wrong because relying on the container's own filesystem means data is lost on restart or redeployment, and copying data to blob storage on shutdown is unreliable (shutdown may not be graceful) and adds unnecessary complexity. Option D is wrong because Azure Disk Encryption protects data at rest but does not provide a persistent storage volume; it is a security feature, not a storage solution for persisting session data across restarts.

Practice this question →
218
MCQmedium

You receive an error when deploying this ARM template: 'The serverFarmId property is required.' What is missing from the template?

A.The server farm resource (Microsoft.Web/serverfarms) is not defined in the template
B.The 'location' property is missing from the site resource
C.The apiVersion should be '2018-02-01'
D.The 'kind' property should be 'functionapp'
AnswerA

Azure Web Apps (Microsoft.Web/sites) require an underlying App Service Plan, also known as a server farm (Microsoft.Web/serverfarms), to define the compute resources, pricing tier, and scale settings. If the web app resource attempts to reference a server farm that is not explicitly defined within the same ARM template or does not already exist in the target resource group, the deployment will fail with a dependency error. The web app's `serverFarmId` property typically uses a `resourceId` function to link to this plan, making its prior definition crucial.

Why this answer

The error 'The serverFarmId property is required' indicates that the ARM template is missing a reference to an App Service Plan (Microsoft.Web/serverfarms) resource. In Azure, a web app or function app must be associated with an App Service Plan, which defines the compute resources and pricing tier. The template must define the server farm resource and link it via the 'serverFarmId' property on the site resource.

Exam trap

The trap here is that candidates often think the error is about a missing property on the site resource itself (like location or kind), rather than realizing the entire server farm resource definition is absent from the template.

How to eliminate wrong answers

Option B is wrong because the 'location' property is not related to the serverFarmId error; a missing location would cause a different error like 'The location property is required'. Option C is wrong because the apiVersion '2018-02-01' is a valid version for Microsoft.Web/sites and does not affect the serverFarmId requirement; the error is about a missing resource definition, not an API version mismatch. Option D is wrong because the 'kind' property set to 'functionapp' is used to specify the app type but does not resolve the missing server farm reference; the serverFarmId is still required regardless of the kind.

Practice this question →
219
Multi-Selecteasy

Which TWO conditions are required to use the 'Run from Package' feature in Azure App Service?

Select 2 answers
A.The package must be accessible via a URL if not deployed locally.
B.The package must be stored in Azure Blob Storage.
C.The package must be a ZIP file.
D.The package size cannot exceed 500 MB.
E.The App Service must have a managed identity to access the package.
AnswersA, C

When utilizing the "Run from Package" deployment method for an Azure App Service, if the application package is not directly uploaded to the App Service's local file system, it must be hosted at a URL that the App Service can access. For private storage locations, such as Azure Blob Storage, this URL typically requires a Shared Access Signature (SAS) token to provide secure, time-limited access without exposing the storage account's primary keys. This allows the App Service to mount the package remotely.

Why this answer

Option C is correct because 'Run from Package' requires the deployment artifact to be a ZIP archive (a .zip file), which App Service mounts as a read-only wwwroot; this is why the setting is exposed as WEBSITE_RUN_FROM_PACKAGE pointing to a .zip. Option A is correct because when the ZIP is not pushed locally via Zip Deploy/Kudu, it must be reachable through a URL that App Service can fetch, such as a SAS URL to Azure Blob Storage, OneDrive, or Dropbox, and the app runs directly from that external package. Option B is not required because the package URL can point to any accessible external location, not exclusively Azure Blob Storage.

Option D is not a stated requirement; there is no fixed 500 MB limit for Run from Package (limits relate to the hosting plan and deployment method, not this feature). Option E is not required because access to the package is granted via a SAS token or public URL, not a managed identity.

Exam trap

The trap here is that candidates often assume the package must be in Azure Blob Storage (Option B) or require a managed identity (Option E), but Azure App Service supports any accessible URL and uses SAS tokens for private storage, not managed identities.

Practice this question →
220
MCQhard

A company uses Azure Functions to process messages from Azure Service Bus. The function currently uses the Consumption plan. They notice that during high load, messages are processed slowly due to scaling latency. Which change would improve throughput most?

A.Switch to the Premium plan
B.Set the maximum instance count to 20
C.Increase the function's batch size to 100
D.Enable Service Bus sessions
AnswerA

Switching to the Premium plan directly addresses latency issues by providing pre-warmed instances, eliminating cold starts that often plague Consumption plan functions. This ensures that function apps are always ready to process messages immediately, leading to significantly faster response times and more predictable performance. Furthermore, Premium plans offer enhanced networking capabilities and dedicated resources, which contribute to more consistent and lower-latency message processing.

Why this answer

The Premium plan for Azure Functions provides pre-warmed instances and faster scaling, eliminating the cold start and scaling latency inherent in the Consumption plan. This directly addresses the bottleneck during high load by ensuring that new instances are allocated instantly, thereby improving message processing throughput from Service Bus.

Exam trap

The trap here is that candidates often assume increasing batch size or instance count will solve scaling latency, but they overlook that the fundamental issue is the cold start and provisioning delay inherent in the Consumption plan, which only the Premium plan resolves by providing pre-warmed instances and faster scaling.

How to eliminate wrong answers

Option B is wrong because setting the maximum instance count to 20 does not reduce scaling latency; it only caps the upper limit of instances, and the Consumption plan still suffers from cold start delays when scaling out. Option C is wrong because increasing the batch size to 100 may cause messages to be locked for longer periods, leading to increased message lock duration and potential duplicate processing, and it does not address the root cause of scaling latency. Option D is wrong because enabling Service Bus sessions does not improve throughput; sessions are used for message ordering and stateful processing, and they can actually reduce parallelism since all messages in a session must be processed by a single instance.

Practice this question →
221
MCQmedium

Your Azure Function app uses an event-driven architecture with Azure Event Hubs. You need to ensure that if the function fails to process an event, the event is retried up to three times and then sent to a dead-letter queue. What should you configure?

A.Use Durable Functions to orchestrate retries and dead-lettering.
B.Implement a try-catch block in the function code and manually re-queue the event.
C.Configure the retry policy in the function's host.json file.
D.Set the 'enableRetry' property on the Event Hub namespace.
AnswerC

Configuring the retry policy within the function's host.json file is the correct and most efficient approach for handling transient failures in event-driven Azure Functions. This declarative configuration allows you to define parameters like `maxRetryCount` and `retryStrategy` (e.g., fixed delay or exponential backoff) directly. For supported bindings like Event Hubs, it automatically integrates with dead-lettering mechanisms, ensuring events are moved to a dead-letter queue after the specified number of retries are exhausted.

Why this answer

Azure Functions for Event Hubs supports a built-in retry policy configured in the host.json file. This policy allows you to specify the maximum number of retries (e.g., 3) and, after exhausting those retries, the event is automatically sent to a dead-letter queue (DLQ) configured on the Event Hub. This approach is declarative and requires no custom code for retry or dead-lettering logic.

Exam trap

The trap here is that candidates often confuse the retry policy configuration location (host.json for the function app) with properties on the Event Hubs namespace itself, or they overcomplicate the solution by choosing Durable Functions when a simple declarative setting suffices.

How to eliminate wrong answers

Option A is wrong because Durable Functions are designed for orchestrating complex, long-running workflows and stateful processes, not for simple retry-and-dead-letter patterns on Event Hubs triggers; using them here would introduce unnecessary complexity and overhead. Option B is wrong because manually re-queuing the event in a try-catch block is error-prone, violates the event-driven architecture's decoupling principles, and does not provide a built-in dead-letter mechanism; it also requires custom code to manage retry counts and queue management. Option D is wrong because the 'enableRetry' property does not exist on the Event Hubs namespace; retry policies for Azure Functions are configured at the function app level (host.json), not on the Event Hubs resource itself.

Practice this question →
222
MCQeasy

You need to deploy a web application to Azure App Service. The application requires a custom domain name and SSL/TLS certificate. You want to automate the deployment using Azure CLI. Which command should you use to upload the SSL certificate to the App Service?

A.az appservice web config ssl upload
B.az appservice certificate import
C.az webapp config ssl upload
D.az webapp certificate upload
AnswerC

The `az webapp config ssl upload` command is the correct and designated method within the Azure CLI for uploading a local `.pfx` file, which contains both the public certificate and its corresponding private key, directly to an Azure App Service. Upon successful upload, this command also enables the binding of the newly uploaded certificate to a specific custom domain configured for the web app, thereby securing traffic with HTTPS. This is crucial for enabling SSL/TLS for custom domains.

Why this answer

The `az webapp config ssl upload` command is the Azure CLI command used to upload an SSL/TLS certificate (in .pfx format) to an existing Azure App Service web app. This command binds the certificate to the app, enabling HTTPS for custom domains.

Exam trap

The trap here is that candidates confuse the deprecated `az appservice` command group with the current `az webapp` group, or they misremember the exact command syntax (e.g., thinking `az webapp certificate upload` exists) because Azure CLI commands have evolved significantly across versions.

How to eliminate wrong answers

Option A is wrong because `az appservice web config ssl upload` uses the deprecated `az appservice` command group, which has been replaced by the `az webapp` group in modern Azure CLI versions. Option B is wrong because `az appservice certificate import` is used to import a certificate from Azure Key Vault or a local file into an App Service Certificate resource, not to upload it directly to a web app. Option D is wrong because `az webapp certificate upload` is not a valid Azure CLI command; the correct verb is `config ssl upload` within the `az webapp` group.

Practice this question →
223
MCQmedium

Your company runs a batch processing job on Azure Batch. The job processes large datasets and requires access to Azure Storage. You need to ensure that the compute nodes can securely access the storage account without exposing credentials. What should you configure?

A.Azure AD service principal
B.Storage account access keys
C.Managed identity for the Batch pool
D.Shared access signatures (SAS)
AnswerC

Assigning a managed identity to the Batch pool lets compute nodes authenticate to Azure Storage through Microsoft Entra ID and receive tokens automatically, so no credentials are stored or exposed on the nodes. This satisfies the requirement for secure access without embedding secrets.

Why this answer

Managed identities for Azure resources allow compute nodes to authenticate to Azure Storage without storing credentials. Option A is wrong because Azure AD service principals require managing credentials and are not the simplest approach for Batch compute nodes to access storage. Option B is wrong because storage account access keys are shared secrets that should not be exposed.

Option D is wrong because shared access signatures (SAS) tokens can be exposed and need to be managed.

Practice this question →
224
MCQmedium

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

A.Blob lifecycle management
B.Timer trigger only
C.Durable Functions orchestrator
D.Azure Policy remediation
AnswerC

Durable Functions orchestrator provides stateful workflow coordination through checkpointing and replay, directly satisfying the status tracking and replay-safe orchestration requirements. Its event-sourcing model persists each await to durable storage, so thousands of independent file tasks run reliably without losing progress after failures or restarts.

Why this answer

Durable Functions orchestrator is correct because it provides built-in support for status tracking, checkpointing, and replay-safe orchestration via the Event Sourcing pattern. The orchestrator function automatically saves execution history to a storage table, enabling reliable resumption after crashes or restarts, which is essential for processing thousands of independent files with long-running workflows.

Exam trap

The trap here is that candidates may confuse a simple trigger (like Timer or Blob trigger) with the orchestration capabilities needed for stateful, long-running workflows, overlooking that Durable Functions provides the necessary checkpointing and replay safety.

How to eliminate wrong answers

Option A is wrong because Blob lifecycle management is a storage policy for automatically tiering or deleting blobs based on age or last modification time; it does not provide orchestration, status tracking, or checkpointing for processing logic. Option B is wrong because a Timer trigger only invokes a function on a schedule and lacks any built-in mechanism for tracking individual file processing status, checkpoints, or replay safety across multiple independent executions. Option D is wrong because Azure Policy remediation is used to enforce compliance rules and automatically remediate non-compliant resources; it has no capability for orchestrating custom business logic or tracking file processing state.

Practice this question →
225
MCQmedium

You are developing an Azure Functions app that processes messages from an Azure Service Bus queue. The function must ensure that if processing fails, the message is retried automatically and, after a maximum number of attempts, moved to a dead-letter queue. You want to minimize custom code. What should you configure?

A.Enable the 'auto-dead-letter' setting on the function trigger binding and set the retry count in the function's application settings.
B.Set the maxDeliveryCount property on the Service Bus queue to the desired number of retries and enable dead-lettering on the queue.
C.Configure the function's host.json to set maxRetries to the desired number and enable dead-lettering in the function code.
D.Use a Durable Functions orchestrator to call the processing activity and implement a retry policy with a maximum attempt count.
AnswerB

Service Bus queues have a maxDeliveryCount property that controls how many times a message can be delivered before it is automatically dead-lettered. When the function fails to process a message and abandons it, the delivery count increments. Once it exceeds maxDeliveryCount, Service Bus moves the message to the dead-letter queue. This requires no custom retry logic in the function.

Why this answer

Service Bus queues natively support retry and dead-lettering through the maxDeliveryCount property. When a function fails to process a message and abandons it, the delivery count increases. After the maximum number of deliveries, Service Bus automatically moves the message to the dead-letter queue.

This requires no custom code in the function, directly meeting the requirement to minimize custom code.

Exam trap

The trap here is assuming that function-level retry settings in host.json control Service Bus dead-lettering, when dead-lettering is governed by the queue's maxDeliveryCount property.

Practice this question →
← PreviousPage 3 of 4 · 230 questions totalNext →

Ready to test yourself?

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

Start 20-question session