Courseiva

Microsoft Azure Developer Associate AZ-204 (AZ-204) — Questions 226–300

997 questions total · 14pages · All types, answers revealed

Take a mock examExam hub
Page 3

Page 4 of 14

Page 5
226
MCQhard

You manage an API in Azure API Management. You need to cache API responses such that different responses are returned based on the product subscription key used by the caller. Which set of policies should you implement?

A.Set a 'cache-lookup' policy in the inbound section and a 'cache-store' policy in the outbound section, using the subscription key as a cache vary-by parameter.
B.Set a 'cache-store' policy in the inbound section and a 'cache-lookup' policy in the outbound section.
C.Set both 'cache-lookup' and 'cache-store' policies in the inbound section.
D.Set only a 'cache-store' policy in the backend section.
AnswerA

This is the correct pattern: lookup cache on request, store on response, varying by subscription key.

Why this answer

Option A is correct because caching API responses based on the subscription key ensures that each caller receives a cached response unique to their subscription. The 'cache-lookup' policy in the inbound section checks the cache before forwarding the request, and the 'cache-store' policy in the outbound section stores the response after it is generated. By specifying the subscription key as a vary-by parameter, the cache key includes the subscription key, so different keys produce different cached entries.

Exam trap

The trap here is that candidates often assume caching policies must both be in the inbound section, not realizing that 'cache-lookup' must run before the backend call and 'cache-store' must run after the response is generated, requiring them in inbound and outbound respectively.

How to eliminate wrong answers

Option B is wrong because it reverses the policy placement: 'cache-store' in the inbound section would attempt to store a response before it is generated, and 'cache-lookup' in the outbound section would check the cache after the response is already produced, defeating the purpose of caching. Option C is wrong because placing both policies in the inbound section would attempt to store a response before it is created, and the 'cache-lookup' would not have a response to cache from the outbound flow. Option D is wrong because a 'cache-store' policy alone in the backend section does not include a 'cache-lookup' to retrieve cached responses, and the backend section is not the correct location for response caching; caching policies must be paired in inbound/outbound sections.

Full explanation →
227
Multi-Selecthard

You are developing a serverless application using Azure Functions. The function needs to scale to zero when idle and handle high traffic spikes. Which THREE features should you implement?

Select 3 answers
A.Use a Consumption hosting plan
B.Use a queue trigger for processing
C.Configure the function to use the built-in scaling controller
D.Enable the 'Always On' setting
E.Use a Premium hosting plan
AnswersA, B, C

Correct: Consumption plan scales to zero when idle.

Why this answer

A Consumption hosting plan is correct because it provides automatic scaling and can scale down to zero instances when the function is idle, meaning you only pay for execution time. This is essential for a serverless application that needs to handle high traffic spikes while minimizing costs during idle periods.

Exam trap

The trap here is that candidates often confuse the 'Always On' setting (which prevents scaling to zero) with a necessary feature for serverless apps, or they mistakenly choose the Premium plan thinking it is required for high traffic, when in fact the Consumption plan with queue triggers and built-in scaling is the correct serverless approach.

Full explanation →
228
MCQmedium

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

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

Durable Functions allows you to specify retry options for activity function calls, including max retry count and backoff.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
229
MCQhard

A developer is building a microservices application on Azure Kubernetes Service (AKS). One service needs to consume messages from an Azure Service Bus queue. The solution must minimize cost and automatically scale based on the number of messages. Which approach should the developer choose?

A.Use KEDA to scale the pods based on the Service Bus queue length
B.Use Azure Event Grid to route messages to the microservice
C.Use Azure Functions with a Service Bus trigger on a dedicated App Service plan
D.Use the Azure Service Bus SDK in the pod code and manually scale pods
AnswerA

KEDA provides event-driven autoscaling for Kubernetes based on queue length, optimizing cost.

Why this answer

Option A is correct because KEDA (Kubernetes Event-Driven Autoscaling) can scale pods based on Service Bus queue length, and it's cost-effective. Option B is incorrect because the Service Bus SDK with manual scaling doesn't provide automatic scaling. Option C is incorrect because Azure Functions running on a dedicated plan would incur cost even when idle.

Option D is incorrect because Azure Event Grid is for event routing, not queue consumption.

Full explanation →
230
MCQmedium

Your company uses Azure App Service to host a web application. You need to allow only authenticated users from your Microsoft Entra ID tenant to access the app, without writing any authentication code. Which feature should you configure?

A.Azure App Service Authentication (EasyAuth) with Microsoft Entra ID as identity provider.
B.IP restrictions in the app’s web.config.
C.Client certificate authentication.
D.Shared access signatures (SAS) for the app URL.
AnswerA

EasyAuth integrates with Microsoft Entra ID and other providers, automatically handling token validation and session management, requiring no code changes.

Why this answer

Azure App Service Authentication (EasyAuth) is the correct feature because it provides a built-in, code-free way to authenticate users by integrating with Microsoft Entra ID (formerly Azure AD). When configured, the App Service automatically validates tokens and redirects unauthenticated users to the identity provider, enforcing authentication at the platform level without requiring any changes to the application code.

Exam trap

The trap here is that candidates often confuse network-level access controls (like IP restrictions) with identity-based authentication, or mistakenly think SAS tokens can secure a web app URL, when in fact SAS are strictly for Azure Storage access and have no role in user authentication for App Service.

How to eliminate wrong answers

Option B is wrong because IP restrictions in web.config control network-level access based on source IP addresses, not user authentication; they cannot verify a user's identity or enforce Entra ID authentication. Option C is wrong because client certificate authentication requires the application to explicitly validate the certificate in code and does not integrate with Microsoft Entra ID for user authentication. Option D is wrong because Shared Access Signatures (SAS) are used to grant delegated access to Azure Storage resources (e.g., blobs, queues), not to authenticate users accessing a web application URL.

Full explanation →
231
MCQmedium

You are troubleshooting an Azure Function that intermittently throws exceptions. You have enabled Application Insights. You need to capture the exact line of code that caused the exception, even for exceptions that occur during high load. Which feature should you use?

A.Snapshot Debugger
B.Application Insights Profiler
C.Live Metrics Stream
D.SQL Insights
AnswerA

Correct. Snapshot Debugger automatically collects debug snapshots on exceptions, providing the call stack and local variables at the moment of failure.

Why this answer

Snapshot Debugger is the correct choice because it captures a point-in-time snapshot of the call stack and local variables at the exact line where an exception occurs, even under high load. This allows you to see the precise line of code and state that caused the failure, which is essential for diagnosing intermittent exceptions. Application Insights integrates Snapshot Debugger to automatically collect these snapshots for thrown exceptions without requiring manual instrumentation.

Exam trap

The trap here is that candidates confuse Profiler (performance tracing) with Snapshot Debugger (exception debugging), assuming both capture code-level details, but only Snapshot Debugger provides the exact line of code and variable state at the moment of failure.

How to eliminate wrong answers

Option B is wrong because Application Insights Profiler traces performance bottlenecks by sampling CPU and request durations, not capturing exception call stacks or line-level details. Option C is wrong because Live Metrics Stream provides real-time monitoring of metrics like request rate and failure count, but it does not capture snapshots or line-of-code details for individual exceptions. Option D is wrong because SQL Insights focuses on diagnosing database query performance and deadlocks, not application-level exception line numbers.

Full explanation →
232
MCQeasy

A business process requires sending an approval email, waiting up to 48 hours for a manager's response, and then updating a SharePoint list based on the decision. The process owner has no programming experience and wants to build this without writing code. Which Azure service is the most appropriate?

A.Azure Logic Apps with the Office 365 Outlook approval action and the SharePoint connector
B.Azure Durable Functions with the Human Interaction pattern using a timer and event listener
C.Azure Data Factory with a Copy Activity pipeline triggered by an Azure Function
D.Azure Event Grid with a custom webhook handler that calls the SharePoint REST API
AnswerA

The Logic Apps approval action sends an email with Approve/Reject buttons and suspends the workflow run (using Azure's durable storage) until the response arrives or the timeout expires. The SharePoint connector's 'Update item' action then writes the outcome to the list. The entire workflow is configured without code using the Logic Apps Designer.

Why this answer

Azure Logic Apps is the correct choice because it provides a no-code/low-code designer that allows the process owner to visually build the approval workflow using the Office 365 Outlook 'Send approval email' action and the SharePoint connector to update the list. This fully meets the requirement of no programming experience while handling the 48-hour wait and conditional update.

Exam trap

The trap here is that candidates may over-engineer the solution by choosing Durable Functions (Option B) because they recognize the Human Interaction pattern, but they overlook the explicit 'no programming experience' constraint that makes Logic Apps the only viable choice.

How to eliminate wrong answers

Option B is wrong because Azure Durable Functions require writing code in C#, JavaScript, or Python to implement the Human Interaction pattern, which violates the 'no programming experience' requirement. Option C is wrong because Azure Data Factory is designed for data movement and transformation pipelines, not for human approval workflows or sending emails. Option D is wrong because Azure Event Grid is a pub/sub event routing service that requires a custom webhook handler (typically an Azure Function or web app) to process the approval logic and call the SharePoint REST API, which again requires coding.

Full explanation →
233
MCQeasy

You are designing a solution to store user-uploaded images. The images are accessed infrequently (a few times per month) and must be available for download within seconds when requested. You need to minimize storage costs while meeting the access requirements. Which Azure Blob Storage access tier should you choose for the container?

A.Hot tier
B.Cool tier
C.Cold tier
D.Archive tier
AnswerB

Cool tier is ideal for data accessed infrequently (a few times per month) with low storage cost and sub‑second latency.

Why this answer

The Cool tier is optimal because the images are accessed infrequently (a few times per month) but require immediate download within seconds. Cool tier offers lower storage costs than Hot tier while maintaining low-latency access (milliseconds), meeting the access requirement without incurring the higher storage cost of Hot tier.

Exam trap

The trap here is that candidates often confuse 'infrequent access' with 'cold storage' and choose Cold or Archive tiers, failing to recognize that 'available within seconds' eliminates any tier requiring rehydration (Archive) or having a 90-day minimum duration (Cold).

How to eliminate wrong answers

Option A is wrong because the Hot tier is designed for frequent access (multiple times per day) and has higher storage costs, which would unnecessarily increase costs for infrequently accessed images. Option C is wrong because the Cold tier is intended for data accessed at most once per quarter (every 90 days) and has a higher minimum storage duration (90 days) and early deletion fee, making it cost-inefficient for monthly access patterns. Option D is wrong because the Archive tier has the lowest storage cost but requires rehydration (taking hours, not seconds) before data can be downloaded, violating the requirement that images be available within seconds.

Full explanation →
234
Multi-Selectmedium

Which TWO approaches can you use to call an external REST API from an Azure Function while ensuring the API key is not exposed in the function code?

Select 2 answers
A.Store the API key in GitHub repository secrets.
B.Hardcode the API key in the function code.
C.Store the API key as an environment variable in the function app settings.
D.Pass the API key in an HTTP header and include it in the source code.
E.Store the API key in Azure Key Vault and retrieve it using Managed Identity.
AnswersC, E

Keeps key out of code.

Why this answer

B and D are correct. Storing the API key in Key Vault and using Managed Identity to access it ensures the key is not in code. Using environment variables in App Service (function app settings) also keeps the key out of code.

Option A is wrong because hardcoding is direct exposure. Option C is wrong because storing in GitHub Secrets is for CI/CD, not runtime. Option E is wrong because using HTTP headers with a hardcoded key still exposes it.

Full explanation →
235
MCQmedium

You are a developer for a company that runs a critical e-commerce application on Azure. The application consists of an Azure App Service web app, an Azure SQL Database, and an Azure Cache for Redis. The web app experiences occasional performance degradation that you suspect is due to inefficient database queries caused by caching issues. You have enabled Application Insights on the web app. You need to identify the root cause of the performance issues and optimize the solution. The solution must minimize cost and administrative overhead. You have the following options: Option A: Configure Azure SQL Database Intelligent Insights to automatically tune database queries. Option B: Use Application Insights Profiler to capture and analyze database query performance. Option C: Implement Redis cache-aside pattern and ensure that all database queries check the cache first. Option D: Enable Azure SQL Database Query Performance Insight to identify the most costly queries and then implement caching. Which option should you recommend?

A.Implement Redis cache-aside pattern and ensure that all database queries check the cache first.
B.Configure Azure SQL Database Intelligent Insights to automatically tune database queries.
C.Enable Azure SQL Database Query Performance Insight to identify the most costly queries and then implement caching.
D.Use Application Insights Profiler to capture and analyze database query performance.
AnswerC

Query Performance Insight identifies the most resource-intensive queries, allowing targeted optimization. Then implementing caching (like cache-aside) will reduce database load efficiently.

Why this answer

Option D is the recommended approach. Query Performance Insight provides detailed information about the most resource-intensive queries, helping to identify which queries are causing performance issues. Once identified, you can implement caching (e.g., Redis cache-aside) to reduce database load.

Option A (Intelligent Insights) is helpful but focuses on automatic tuning, not direct identification of costly queries. Option B (Application Insights Profiler) is useful for profiling but may not give specific database query details as effectively as Query Performance Insight. Option C (implement caching) is a general solution but without first identifying the problematic queries, you might not target the right ones, leading to inefficient use of cache and increased complexity.

Therefore, Option D provides the best path: first diagnose, then optimize.

Full explanation →
236
MCQhard

A company uses Azure API Management (APIM) to expose APIs to external partners. They need to enforce rate limiting per subscription key. Which APIM policy should be configured?

A.quota
B.rate-limit
C.ip-filter
D.throttling
AnswerB

rate-limit policy enforces a rate limit per subscription key, which is the requirement.

Why this answer

Option A is correct because the rate-limit policy enforces a fixed rate limit per subscription key. Option B (quota) is for a total number of calls over a period, not per time window; Option C (throttling) sets a rate limit per IP or per client, but not per subscription key; Option D (ip-filter) restricts by IP address.

Full explanation →
237
MCQmedium

You manage an API in Azure API Management. You need to enforce a rate limit of 200 requests per minute for each subscription key. Which policy should you include in the inbound policy section?

A.<rate-limit> policy
B.<quota> policy
C.<limit-concurrency> policy
D.<throttle> policy
AnswerA

The <rate-limit> policy limits call rates per subscription key (or other scope) over a sliding window.

Why this answer

The <rate-limit> policy in Azure API Management is specifically designed to enforce a per-subscription key rate limit, such as 200 requests per minute. It operates on a sliding window counter to smooth traffic and is applied in the inbound section to evaluate each request before it reaches the backend. This matches the requirement exactly.

Exam trap

The trap here is confusing <rate-limit> with <quota>, as both control request volume, but <quota> applies to total counts over days/months, not per-minute rate limiting.

How to eliminate wrong answers

Option B is wrong because the <quota> policy enforces a total number of requests over a longer period (e.g., 10,000 calls per month), not a per-minute rate limit. Option C is wrong because the <limit-concurrency> policy restricts the number of simultaneous connections, not the request rate over time. Option D is wrong because there is no <throttle> policy in Azure API Management; the correct term is <rate-limit> for per-key throttling.

Full explanation →
238
Drag & Dropmedium

Arrange the steps to create and use a shared access signature (SAS) for an Azure Storage blob in the correct order.

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

Steps
Order

Why this order

First create storage and container, upload blob, generate SAS, construct URL, then access.

Full explanation →
239
MCQhard

You develop a C# application that stores sensitive documents in Azure Blob Storage. You need to generate a time-limited shared access signature (SAS) that allows a client to only read and list blobs in a specific container. The SAS must be valid for exactly 1 hour from the current time. Which code snippet correctly creates the SAS? (Assume BlobServiceClient and BlobContainerClient are properly initialized.)

A.var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);
B.var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "b", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);
C.var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.All }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);
D.var sasBuilder = new BlobSasBuilder { BlobContainerName = containerName, Resource = "c", StartsOn = DateTimeOffset.UtcNow.AddDays(-1), ExpiresOn = DateTimeOffset.UtcNow.AddHours(1), Permissions = BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List }; Uri sasUri = containerClient.GenerateSasUri(sasBuilder);
AnswerA

This correctly sets resource to 'c' for container-level SAS, includes Read and List permissions, and generates the SAS URI using the container client.

Why this answer

Option A is correct because it sets the `Resource` property to "c" for container-level SAS, uses `StartsOn` as the current UTC time, `ExpiresOn` exactly 1 hour later, and specifies only `Read` and `List` permissions via the `BlobContainerSasPermissions` enum. This combination generates a time-limited SAS URI that allows a client to read and list blobs within the specified container for exactly one hour.

Exam trap

The trap here is confusing the `Resource` property value "c" (container) with "b" (blob), leading candidates to pick Option B, and overlooking that `StartsOn` must be set to the current time (or omitted) to achieve exactly 1 hour validity, not a past time as in Option D.

How to eliminate wrong answers

Option B is wrong because it sets `Resource = "b"`, which is intended for blob-level SAS, not container-level SAS; this would generate a SAS that applies to a single blob rather than the entire container, failing the requirement to list blobs. Option C is wrong because it uses `Permissions = BlobContainerSasPermissions.All`, which grants full control (including delete, write, etc.) instead of restricting to only Read and List permissions, violating the principle of least privilege. Option D is wrong because it sets `StartsOn = DateTimeOffset.UtcNow.AddDays(-1)`, making the SAS valid from 24 hours in the past; this means the SAS is already active for a full day before the current time, not exactly 1 hour from now as required.

Full explanation →
240
MCQmedium

You are building a serverless application that needs to react to insertions and updates in an Azure Cosmos DB container. You want to process these changes using an Azure Function. Which trigger should you configure for the function?

A.Cosmos DB trigger
B.Blob trigger
C.Event Grid trigger
D.Service Bus trigger
AnswerA

The Cosmos DB trigger uses the change feed to respond to inserts and updates in the container.

Why this answer

A Cosmos DB trigger is the correct choice because it is specifically designed to react to changes in a Cosmos DB container by leveraging the change feed. The Azure Function runtime polls the change feed for inserts and updates, invoking the function with batches of documents as they occur. This provides a native, serverless integration without needing additional services.

Exam trap

The trap here is that candidates may confuse the Cosmos DB trigger with the Event Grid trigger, thinking Event Grid can directly subscribe to Cosmos DB changes, but Event Grid requires a custom event publisher or a separate Azure service like Azure Functions to bridge the change feed.

How to eliminate wrong answers

Option B is wrong because a Blob trigger reacts to changes in Azure Blob Storage (blob creation or updates), not to changes in a Cosmos DB container. Option C is wrong because an Event Grid trigger handles events from various Azure services (e.g., resource creation, blob events) but does not natively subscribe to the Cosmos DB change feed; it would require custom event publishing. Option D is wrong because a Service Bus trigger processes messages from a Service Bus queue or topic, which is a messaging system unrelated to Cosmos DB data changes.

Full explanation →
241
MCQmedium

A company stores secrets (e.g., connection strings) in Azure Key Vault and needs them automatically rotated every 90 days. Which solution should they implement?

A.Configure Key Vault access policies to enforce rotation
B.Enable Key Vault firewall to limit access
C.Use Event Grid to trigger an Azure Function or Automation runbook that rotates the secret
D.Enable soft-delete on the vault
AnswerC

This is the recommended pattern; Event Grid can emit events when a secret is near expiration, invoking a rotation logic.

Why this answer

Option C is correct because Azure Key Vault does not natively support automatic secret rotation; you must implement a custom solution using Event Grid to detect expiration events and trigger an Azure Function or Automation runbook that generates a new secret and updates the vault. This pattern leverages Key Vault's eventing capabilities to automate the rotation workflow without manual intervention.

Exam trap

The trap here is that candidates assume Key Vault has a built-in rotation feature, but Azure Key Vault only stores secrets and requires an external automation trigger (Event Grid + Azure Function) to implement rotation logic.

How to eliminate wrong answers

Option A is wrong because Key Vault access policies control permissions (who can read/write secrets), not rotation logic; they cannot enforce a schedule or automate secret renewal. Option B is wrong because enabling the Key Vault firewall restricts network access to the vault for security, but does not implement any rotation mechanism. Option D is wrong because soft-delete protects against accidental deletion by retaining deleted secrets for a configurable retention period, but it does not automate rotation or renewal of secrets.

Full explanation →
242
MCQeasy

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

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

Queue Storage with function trigger offers automatic retries and poison message handling.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
243
MCQhard

You are deploying a batch processing application to Azure Container Instances (ACI). The application processes multiple files from an Azure Blob Storage container and writes results to another container. Each container instance processes a single file and then exits. The processing logic is written in a Docker image that reads input and output connection strings from environment variables. You need to configure the container group so that it writes the results to the output container durably and efficiently. The environment variables must be provided at runtime but must not be exposed in the ACI configuration. Which approach should you use?

A.Mount an Azure File Share volume for the output container and configure the application to write output files to a directory on that share. Store the connection string for the file share in a secure fashion using Key Vault and pass it as an environment variable.
B.Use a managed identity for the container group, grant the identity access to an Azure Key Vault secret that contains the storage account connection string. The application retrieves the secret at startup using the managed identity and then writes directly to Azure Blob Storage.
C.Embed the storage account connection string directly into the Docker image during build time and rely on the container's environment to provide the output blob container name.
D.Set the storage account connection string as an environment variable in the ACI container group definition (YAML or ARM template) and have the application use it at runtime.
AnswerB

This approach uses managed identity to securely access Key Vault, avoiding any credentials in the container configuration. The application then uses the connection string to write to Blob Storage via the SDK, which is efficient and durable.

Why this answer

Option B is correct because it uses a managed identity to securely retrieve the storage account connection string from Azure Key Vault at runtime, ensuring the secret is never exposed in the ACI configuration. The application writes directly to Azure Blob Storage, which is durable and efficient for blob output. This approach aligns with the requirement to avoid exposing environment variables in the ACI configuration while providing them at runtime.

Exam trap

The trap here is that candidates may choose Option A, thinking a file share mount is more durable or simpler, but the question explicitly requires writing to a blob container, and direct blob writes via a securely retrieved connection string are both more efficient and aligned with the requirement to avoid exposing secrets in the ACI configuration.

How to eliminate wrong answers

Option A is wrong because mounting an Azure File Share volume introduces additional latency and complexity compared to direct blob writes, and the file share connection string would still need to be securely passed (e.g., via Key Vault), but the question specifically requires writing to a blob container, not a file share. Option C is wrong because embedding the connection string in the Docker image violates security best practices and makes the secret static and exposed in the image layers, failing the requirement to provide secrets at runtime without exposure. Option D is wrong because setting the connection string as an environment variable in the ACI configuration directly exposes it in the YAML/ARM template and container logs, violating the requirement that secrets must not be exposed in the ACI configuration.

Full explanation →
244
MCQmedium

You need to store large files that are written once and then frequently read for the first 30 days. After 30 days, the files are rarely accessed (once or twice per year) but must remain available for 5 years. You want to minimize storage costs. Which storage tier and lifecycle management rule should you apply?

A.Hot tier with a lifecycle rule to move to Cool after 30 days
B.Cool tier with a lifecycle rule to move to Archive after 30 days
C.Hot tier with a lifecycle rule to move to Archive after 30 days
D.Archive tier with a lifecycle rule to move to Cool after 30 days
AnswerA

Hot tier provides low latency for frequent reads. After 30 days, moving to Cool reduces cost while maintaining reasonable access for rare reads.

Why this answer

Option A is correct because the Hot tier is optimized for frequent reads, and the lifecycle rule moves data to the Cool tier after 30 days when access drops, balancing performance and cost. After 30 days, the files are rarely accessed, so moving them to Cool (not Archive) keeps them available for occasional reads without the high retrieval costs and latency of Archive. This minimizes storage costs while meeting the 5-year retention requirement.

Exam trap

The trap here is that candidates assume Archive is always cheapest for long-term storage, ignoring the retrieval cost and latency for the rare but annual reads, and overlook the 30-day minimum billing period in Archive.

How to eliminate wrong answers

Option B is wrong because starting in the Cool tier incurs higher write costs and lower initial performance for the first 30 days of frequent reads, which is not cost-effective. Option C is wrong because moving directly to Archive after 30 days would impose a 30-day minimum billing period and high retrieval costs for the rare but annual reads, making it more expensive than Cool. Option D is wrong because starting in the Archive tier is designed for cold data with infrequent access, but the first 30 days have frequent reads, leading to unacceptable latency and high rehydration costs.

Full explanation →
245
MCQmedium

You are using Azure Logic Apps to integrate with a third-party CRM. The CRM API requires OAuth 2.0 authentication with a client secret. The secret must be stored securely and rotated automatically. What should you do?

A.Use a system-assigned managed identity without storing the secret
B.Store the secret in Azure Key Vault and use a managed identity to access it
C.Store the secret in the Logic App definition as a string parameter
D.Store the secret in Azure App Configuration with encryption
AnswerB

Key Vault provides secure storage and automatic rotation with access via managed identity.

Why this answer

Store the secret in Key Vault and reference it from the Logic App using a managed identity. Option A is wrong because storing secrets in Logic App definitions is insecure. Option C is wrong because storing in App Configuration is not designed for secrets.

Option D is wrong because managed identity alone does not store the secret.

Full explanation →
246
MCQmedium

You need to store millions of small JSON documents (each less than 1 KB) that are accessed by key. The data is read-heavy and requires low-latency access. Which Azure storage solution should you use?

A.Azure Files
B.Azure Table Storage
C.Azure Cosmos DB
D.Azure Blob Storage
AnswerC

NoSQL database with low-latency key-value access.

Why this answer

Azure Cosmos DB is the correct choice because it provides single-digit millisecond latency for point reads by key, supports automatic indexing of JSON documents, and offers a globally distributed, multi-model database service. For millions of small JSON documents accessed by key in a read-heavy workload, Cosmos DB's throughput-provisioned model and consistency levels optimize for low-latency access at scale.

Exam trap

The trap here is that candidates confuse Azure Table Storage's key-value nature with JSON document support, but Table Storage stores entities as flat rows with limited property types and no native JSON indexing, whereas Cosmos DB is purpose-built for JSON documents with automatic indexing and guaranteed low latency.

How to eliminate wrong answers

Option A is wrong because Azure Files provides SMB/NFS file shares with higher latency and is designed for shared file access, not key-value lookups on millions of small JSON documents. Option B is wrong because Azure Table Storage is a NoSQL key-value store but lacks native JSON support, automatic indexing, and single-digit millisecond latency guarantees; it is optimized for structured tabular data, not JSON documents. Option D is wrong because Azure Blob Storage is optimized for large binary objects (blobs) and has higher latency for small objects due to per-blob metadata overhead and lack of native indexing by key; it is not designed for high-throughput point reads on millions of tiny JSON documents.

Full explanation →
247
MCQmedium

An application stores customer invoices in Azure Blob Storage. Deleted blobs must be recoverable for 14 days. What should be enabled?

A.Blob soft delete with a 14-day retention period
B.Archive access tier
C.Static website hosting
D.Immutable blob legal hold
AnswerA

Blob soft delete retains deleted blobs for the configured retention period.

Why this answer

Blob soft delete protects against accidental deletion by retaining deleted blobs for a specified retention period. Enabling it with a 14-day retention period ensures that deleted invoices remain recoverable for exactly 14 days, meeting the requirement without additional cost or complexity.

Exam trap

The trap here is confusing soft delete (which recovers deleted blobs) with immutable storage (which prevents deletion or modification) or access tiers (which affect storage cost and retrieval speed, not recovery).

How to eliminate wrong answers

Option B is wrong because the Archive access tier is for cost-effective long-term storage with retrieval delays (hours), not for short-term recovery of deleted blobs. Option C is wrong because static website hosting serves web content from a container, not recover deleted blobs. Option D is wrong because an immutable blob legal hold prevents modification or deletion of blobs for legal purposes, but it does not provide a time-limited recovery window for already deleted blobs.

Full explanation →
248
Multi-Selecteasy

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

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

Scale in condition triggers when CPU drops below a threshold.

Why this answer

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

Exam trap

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

Full explanation →
249
MCQeasy

You need to allow a client application to read a specific blob from Azure Blob Storage for one hour, without exposing your storage account key. Which approach should you use?

A.Provide the storage account access key to the client
B.Generate a shared access signature (SAS) URI with read permission and expiry of one hour
C.Use Azure RBAC to grant the client the Storage Blob Data Reader role for one hour
D.Make the blob publicly accessible for one hour using a stored access policy
AnswerB

A SAS token provides secure, delegated access with controlled permissions and expiry, perfect for this scenario.

Why this answer

Option B is correct because a shared access signature (SAS) URI allows you to delegate limited access (read permission) to a specific blob for a defined time period (one hour) without exposing your storage account key. The SAS token is generated using the account key but does not reveal it, ensuring secure, time-bound access.

Exam trap

The trap here is that candidates may confuse RBAC with SAS, thinking RBAC can be used for temporary access, but RBAC does not support built-in expiry and requires manual revocation, whereas SAS provides precise time-bound delegation.

How to eliminate wrong answers

Option A is wrong because providing the storage account access key grants full administrative access to the entire storage account, not just a single blob, and violates the requirement to not expose the key. Option C is wrong because Azure RBAC role assignments (like Storage Blob Data Reader) are not designed for temporary, per-blob access with a one-hour expiry; they are persistent until changed and apply at the storage account, container, or blob level, but cannot be set to auto-expire after one hour without custom scripting. Option D is wrong because making the blob publicly accessible removes all access control, allowing anyone to read it indefinitely until manually changed, and does not provide a one-hour expiry mechanism.

Full explanation →
250
MCQhard

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

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

Correct approach to get token.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
251
MCQhard

Your Azure Functions app uses Durable Functions to orchestrate a workflow. The orchestration sometimes fails with a 'FunctionRuntimeException' due to a timeout. You need to increase the maximum orchestration time. What should you modify?

A.Add an app setting 'AzureFunctionsJobHost__functionTimeout'
B.Change the Azure Storage account to a Premium account
C.Increase the 'functionTimeout' in host.json
D.Set 'maxOrchestrationTimeout' in the host.json file
AnswerD

This setting controls the maximum duration of an orchestration.

Why this answer

Option A is correct because the max orchestration time is controlled by the 'maxOrchestrationTimeout' setting in host.json. Option B is wrong because functionTimeout is for individual functions, not orchestrations. Option C is wrong because the storage account connection is for state persistence, not timeout.

Option D is wrong because the app setting 'AzureFunctionsJobHost__functionTimeout' is not a standard setting.

Full explanation →
252
MCQhard

Your application writes millions of small log entries per hour to an Azure Storage account. You notice throttling errors (HTTP 503) during peak traffic. You need to minimize throttling without changing the application code. What should you do?

A.Request a storage account limit increase from Azure Support
B.Use a separate storage account for log data
C.Change the replication type to geo-redundant storage (GRS)
D.Enable soft delete on the blob container
AnswerB

Separate accounts increase aggregate limits and reduce throttling.

Why this answer

Option B is correct because using a separate storage account for log data isolates the high-volume write traffic from other workloads, distributing the request load across different storage account endpoints. Azure Storage accounts have scalability targets (e.g., up to 20,000 requests per second per account for blob storage), and splitting logs into a dedicated account prevents hitting those limits, reducing HTTP 503 throttling errors without requiring code changes.

Exam trap

The trap here is that candidates may think throttling can be resolved by increasing limits or changing replication settings, but Azure's scalability targets are fixed per account, and the only way to increase throughput without code changes is to distribute the load across multiple storage accounts.

How to eliminate wrong answers

Option A is wrong because requesting a storage account limit increase from Azure Support does not change the per-account scalability targets (e.g., ingress/egress limits, request rate limits) which are fixed by Azure's architecture; support can only increase quotas for specific resources like capacity, not throughput or request rates. Option C is wrong because changing replication type to geo-redundant storage (GRS) does not affect throttling; GRS provides durability and disaster recovery by replicating data to a secondary region, but it does not increase the request rate or throughput limits of the storage account. Option D is wrong because enabling soft delete on the blob container protects against accidental deletion by retaining deleted blobs for a retention period, but it has no impact on request throttling or storage account scalability limits.

Full explanation →
253
Multi-Selecteasy

Which TWO authentication mechanisms can be used to authenticate an Azure Function to Azure Storage?

Select 2 answers
A.Client certificate
B.Shared access signature (SAS) token
C.Storage account connection string with account key
D.Azure AD token acquired via client credentials flow
E.System-assigned managed identity
AnswersC, E

Connection strings with account key are a supported method.

Why this answer

Options A and D are correct. Managed identity and connection strings with account key are supported. Option B is wrong because SAS tokens are for delegated access, not function identity.

Option C is wrong because certificate authentication is not supported for Storage. Option E is wrong because Azure AD token is used with managed identity, not directly.

Full explanation →
254
MCQmedium

You are designing a cost-effective solution to store log files that are accessed infrequently after 30 days. The logs must be retained for 7 years for compliance. Data must be available within 1 hour of a request. Which Azure Blob Storage access tier and lifecycle management rule should you use?

A.Use Hot tier initially, then move to Archive after 30 days, and delete after 7 years.
B.Use Archive tier immediately and set a lifecycle rule to delete after 7 years.
C.Use Cool tier initially, then move to Archive after 30 days, and delete after 7 years.
D.Use Hot tier for 30 days, then Cool tier until 90 days, then Archive tier until deletion after 7 years.
AnswerD

This balances cost and retrieval time.

Why this answer

Option D is correct because it balances cost and compliance: the Hot tier handles initial frequent writes, Cool tier reduces cost for infrequent access after 30 days, and Archive tier provides the lowest-cost storage for long-term retention while still allowing rehydration within 1 hour (via High Priority rehydration). The lifecycle rule deletes the blobs after 7 years to meet compliance requirements.

Exam trap

The trap here is that candidates often overlook the 1-hour availability requirement and choose Archive tier immediately (Option B) or skip the Cool tier (Option A), not realizing that Archive rehydration can take up to 15 hours unless High Priority is explicitly used, and that Hot tier is more cost-effective for the initial high-write period.

How to eliminate wrong answers

Option A is wrong because moving directly from Hot to Archive after 30 days skips the Cool tier, which would incur higher costs for the infrequent access period (30–90 days) compared to using Cool tier. Option B is wrong because storing logs immediately in Archive tier prevents timely access (rehydration can take up to 15 hours, exceeding the 1-hour requirement) and does not address the initial 30-day period where logs are accessed frequently. Option C is wrong because it uses Cool tier initially, but the logs are accessed frequently in the first 30 days, making Hot tier more cost-effective for writes; Cool tier has higher write costs and lower availability for frequent access.

Full explanation →
255
MCQmedium

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

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

CORS allows listed origins, and supportCredentials: false prevents credentials.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
256
MCQmedium

A developer is implementing Key Vault certificate retrieval. The application runs on Azure App Service and must avoid stored credentials. Which design should be used?

A.Use a shared administrator account
B.Store a client secret in source control
C.Enable managed identity and grant least-privilege access to the target resource
D.Disable authentication for the target resource
AnswerC

Managed identity lets Azure-hosted apps authenticate without stored secrets.

Why this answer

Option C is correct because Azure App Service supports Managed Identity, which allows the application to authenticate to Key Vault without storing any credentials in code or configuration. By enabling a system-assigned or user-assigned managed identity and granting it least-privilege access (e.g., via an access policy with `Get` permission for secrets), the app can securely retrieve certificates using the Azure Identity SDK's `DefaultAzureCredential` class, which automatically obtains an access token from Azure AD.

Exam trap

The trap here is that candidates might think storing a client secret in source control is acceptable if the repo is private, but Azure explicitly forbids this in security best practices, and the question requires 'avoid stored credentials' entirely.

How to eliminate wrong answers

Option A is wrong because using a shared administrator account violates the principle of least privilege and introduces a security risk; credentials would need to be stored or hardcoded, defeating the goal of avoiding stored credentials. Option B is wrong because storing a client secret in source control exposes it to unauthorized access, breaches security best practices, and contradicts the requirement to avoid stored credentials. Option D is wrong because disabling authentication for the target resource (Key Vault) would allow anonymous access, which is a severe security vulnerability and not a valid design for production workloads.

Full explanation →
257
MCQmedium

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

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

Idempotent processing ensures same event handled once.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
258
MCQmedium

You are a developer for a healthcare company that stores patient diagnostic images in Azure Blob Storage. The images are uploaded by medical devices and must be retained for 7 years due to regulatory requirements. After 7 years, the data must be permanently deleted. The images are accessed infrequently after the first month. You need to design a storage lifecycle management policy to minimize costs while meeting compliance. The storage account uses general-purpose v2 with LRS. The container is named 'diagnostics'. Which of the following policies should you implement?

A.Move blobs to Cool tier after 30 days, and delete after 30 days.
B.Move blobs to Cool tier after 30 days, move to Archive tier after 90 days, and delete after 7 years.
C.Move blobs to Archive tier immediately after upload, and delete after 7 years.
D.Move blobs to Cool tier after 1 year, and delete after 7 years.
AnswerB

Optimizes cost by using Cool for infrequent access, Archive for long-term retention, and deletion after compliance period.

Why this answer

Option B is correct because it aligns with the access pattern: blobs are moved to the Cool tier after 30 days (when infrequent access begins), then to the Archive tier after 90 days for long-term, low-cost storage, and finally deleted after 7 years to meet regulatory retention and deletion requirements. This minimizes costs by using the most cost-effective tier for each stage of the data lifecycle.

Exam trap

The trap here is that candidates may choose Option C thinking Archive is cheapest immediately, but they overlook the early deletion penalty and the fact that data is accessed frequently in the first month, making Cool tier more appropriate initially.

How to eliminate wrong answers

Option A is wrong because deleting after 30 days violates the 7-year retention requirement. Option C is wrong because moving blobs immediately to Archive tier incurs early deletion fees if accessed within 180 days, and the data is accessed frequently in the first month, making Archive tier cost-ineffective. Option D is wrong because moving to Cool tier after 1 year misses the opportunity to reduce costs earlier (after 30 days of infrequent access), and the Cool tier is more expensive than Archive for long-term storage.

Full explanation →
259
MCQhard

You are designing a solution to securely store connection strings for an Azure Function app that connects to Azure Service Bus. The connection string contains a Shared Access Key. The company policy requires that secrets be rotated every 90 days and that no secret is stored in source code or configuration files. The solution should minimize operational overhead. What should you use?

A.Store the connection string in Azure Key Vault and use a managed identity to access it from the Function app.
B.Store the connection string in a JSON configuration file and use Azure Policy to enforce encryption.
C.Store the connection string in Azure App Configuration with encryption at rest using a customer-managed key.
D.Store the connection string as an environment variable in the Function app's application settings.
AnswerA

Key Vault with managed identity provides secure storage, rotation, and no secrets in code.

Why this answer

Azure Key Vault with managed identity allows secure storage and automatic rotation of secrets without managing credentials in code. Option A is correct because it uses managed identity to access Key Vault, and Key Vault can handle rotation. Option B is incorrect because App Configuration with encryption still requires managing the encryption key and does not provide built-in rotation.

Option C is incorrect because Environment variables in the Function app's app settings can be accessed by anyone with access to the portal, and rotation requires manual updates. Option D is incorrect because configuration files are explicitly against policy.

Full explanation →
260
Multi-Selectmedium

Which TWO actions should you take to securely store and retrieve secrets for an Azure App Service application? (Choose two.)

Select 2 answers
A.Configure a Key Vault access policy for the App Service managed identity
B.Store connection strings as plain text in the application code
C.Store secrets in Azure Key Vault
D.Generate SAS tokens in Key Vault
E.Store secrets in the App Service application settings
AnswersA, C

Access policies grant the managed identity permission to read secrets.

Why this answer

Option A is correct: Azure Key Vault is the recommended service for storing secrets. Option C is correct: Access policies in Key Vault control access to secrets. Option B is wrong because storing secrets in app settings is insecure.

Option D is wrong because connection strings should not be hardcoded; they should be retrieved from Key Vault. Option E is wrong because Key Vault does not generate SAS tokens; they are generated by the application.

Full explanation →
261
MCQeasy

You store application logs in Azure Blob Storage. The logs are accessed frequently for the first 7 days, then rarely. After 30 days, they must be deleted to minimize cost. Which approach should you use?

A.Manually move blobs to cool tier after 7 days and delete after 30 days using a script
B.Use blob snapshots and delete snapshots after 30 days
C.Configure a lifecycle management policy to tier to cool after 7 days and delete after 30 days
D.Use Azure Data Factory to copy old logs to archive storage and delete original
AnswerC

Lifecycle management policies automatically transition blobs between tiers and delete them based on rules, reducing cost and management overhead.

Why this answer

Option C is correct because Azure Blob Storage lifecycle management policies allow you to automatically transition blobs to a cooler tier (cool) after a specified number of days and then delete them after another period, all without manual intervention or additional services. This directly meets the requirement of frequent access for 7 days, rare access afterward, and deletion at 30 days, minimizing cost by leveraging tiered storage and automated rules.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing manual scripting (A) or a heavy orchestration tool (D), missing that Azure provides a native, policy-driven mechanism (lifecycle management) specifically designed for automated tiering and deletion based on age.

How to eliminate wrong answers

Option A is wrong because manually moving blobs with a script is error-prone, does not scale, and contradicts the principle of automation in Azure; lifecycle management provides a built-in, reliable alternative. Option B is wrong because blob snapshots are point-in-time copies used for versioning or backup, not for tiering or deletion based on age; they do not address the need to move logs to a cooler tier or delete them after 30 days. Option D is wrong because Azure Data Factory is an orchestration service for data movement and transformation, not designed for simple tiering or deletion of blobs; using it for this purpose adds unnecessary complexity and cost compared to a native lifecycle policy.

Full explanation →
262
MCQhard

A healthcare organization uses Azure API Management (APIM) to expose FHIR APIs to external partners. The FHIR backend is an Azure API for FHIR that requires OAuth 2.0 tokens from Microsoft Entra ID. APIM must validate tokens before forwarding requests to the backend. The organization also needs to rate-limit requests per subscription key and log all requests to Azure Monitor for audit. Which combination of APIM policies should be implemented?

A.Use validate-jwt, set-header to add the subscription key, and log-to-event-hub.
B.Use check-header to verify the token, rate-limit to throttle requests, and log-to-event-hub to send logs.
C.Use validate-jwt to validate the token, rate-limit to throttle requests per subscription key, and log-to-event-hub to send logs.
D.Use validate-jwt to validate the token, quota to limit total requests, and log-to-event-hub.
AnswerC

This combination meets all requirements.

Why this answer

Option D is correct because validate-jwt ensures token validation, rate-limit enforces throttling per subscription key, and log-to-event-hub sends logs to Azure Monitor via Event Hubs. Option A is wrong because check-header is not for JWT validation. Option B is wrong because quota limits total calls, not rate.

Option C is wrong because set-header is not for validation.

Full explanation →
263
MCQhard

Three microservices collaborate on a single user transaction: an App Service API, an Azure Function that processes a Service Bus message, and a downstream storage service. Traces appear separately in Application Insights with no parent-child relationship. What is needed to correlate all three into a single end-to-end trace?

A.Install the Application Insights SDK on all three services and ensure W3C Trace Context header propagation is enabled for both HTTP calls and Service Bus messages
B.Use the same Application Insights instrumentation key for all three services — no additional configuration is needed
C.Add a custom x-correlation-id header in each service and log it with TelemetryClient.TrackEvent
D.Enable Azure Monitor cross-resource queries and write a KQL join across all three services' logs
AnswerA

The SDK propagates the traceparent header on outgoing HTTP requests automatically. For Service Bus, the SDK injects and reads correlation properties in the message's ApplicationProperties collection. With the same operation ID flowing through all three services, Application Insights assembles the calls into a single end-to-end trace in the Application Map and end-to-end transaction view.

Why this answer

Option A is correct because distributed tracing across HTTP and asynchronous messaging requires the Application Insights SDK on each service and propagation of the W3C Trace-Context standard (traceparent and tracestate headers). This ensures that the App Service API, Azure Function, and downstream storage service share a single trace ID, enabling Application Insights to correlate all telemetry into one end-to-end transaction view.

Exam trap

The trap here is that candidates assume sharing an instrumentation key is sufficient for correlation, overlooking the necessity of W3C Trace-Context header propagation across both synchronous HTTP and asynchronous messaging protocols.

How to eliminate wrong answers

Option B is wrong because sharing the same instrumentation key only sends telemetry to the same Application Insights resource but does not automatically correlate spans without trace context propagation; each service's traces remain disconnected. Option C is wrong because a custom x-correlation-id header and manual TrackEvent calls do not create parent-child span relationships; the SDK's built-in distributed tracing relies on standardized W3C headers and automatic telemetry correlation. Option D is wrong because cross-resource queries and KQL joins can combine logs after the fact but do not establish the real-time parent-child trace hierarchy needed for a single end-to-end view; they also require manual correlation logic.

Full explanation →
264
MCQhard

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

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

Duplicate detection ensures the queue removes duplicates based on the MessageId, enabling exactly-once processing.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
265
Multi-Selecthard

Which THREE of the following are true about Azure Blob Storage access tiers? (Choose THREE.)

Select 3 answers
A.Hot tier has lower storage cost than Cool tier.
B.Archive tier allows immediate read access to blobs.
C.You can change the access tier of a blob after it has been uploaded.
D.Cool tier is suitable for data that is accessed infrequently (30+ days).
E.Archive tier has the lowest storage cost.
AnswersC, D, E

Access tier can be changed after upload.

Why this answer

Option C is correct because Azure Blob Storage allows you to change the access tier of a blob after it has been uploaded, either by directly setting the tier on the blob or using lifecycle management policies. This flexibility enables you to optimize storage costs based on changing access patterns without re-uploading data.

Exam trap

The trap here is that candidates often confuse storage cost with access cost, assuming the Hot tier is cheaper overall, or mistakenly believe Archive blobs can be read immediately after tier change, ignoring the rehydration latency.

Full explanation →
266
MCQmedium

A developer is implementing least-privilege storage access. The application runs on Azure App Service and must avoid stored credentials. Which design should be used?

A.Use a shared administrator account
B.Disable authentication for the target resource
C.Store a client secret in source control
D.Enable managed identity and grant least-privilege access to the target resource
AnswerD

Managed identity lets Azure-hosted apps authenticate without stored secrets.

Why this answer

Managed identity in Azure App Service allows the application to authenticate to Azure Storage without storing any credentials in code or configuration. By enabling a system-assigned or user-assigned managed identity, the app obtains an Azure AD token automatically, which is used to access the storage resource. Granting the managed identity only the required permissions (e.g., 'Storage Blob Data Reader' for read-only access) enforces least-privilege access, eliminating the need for stored secrets.

Exam trap

The trap here is that candidates may think storing a client secret in a configuration file (Option C) is acceptable if it's encrypted or in a secure location, but the question explicitly requires avoiding stored credentials, making managed identity the only correct choice.

How to eliminate wrong answers

Option A is wrong because using a shared administrator account violates least-privilege principles and requires storing credentials, which contradicts the requirement to avoid stored credentials. Option B is wrong because disabling authentication for the target resource would expose the storage to anonymous access, breaking security and least-privilege requirements. Option C is wrong because storing a client secret in source control is a security anti-pattern; it exposes the secret to anyone with repository access and violates the 'no stored credentials' requirement.

Full explanation →
267
MCQhard

You are developing a web API that must authenticate requests using Microsoft Entra ID (Microsoft Entra ID) and OAuth 2.0 bearer tokens. You want to validate the token in your API code. Which library should you use?

A.Microsoft Authentication Library (MSAL)
B.Microsoft.Identity.Web
C.ADAL.NET
D.Azure.Identity
AnswerB

Microsoft.Identity.Web provides middleware and helper classes to validate Microsoft Entra ID tokens in ASP.NET Core APIs.

Why this answer

Microsoft.Identity.Web is the recommended library for integrating ASP.NET Core web APIs with Microsoft Entra ID. It provides built-in token validation, policy enforcement, and handles the OAuth 2.0 bearer token flow, including JWT validation, issuer signing keys, and audience checks, without requiring manual configuration of middleware.

Exam trap

The trap here is that candidates confuse token acquisition libraries (MSAL, Azure.Identity) with token validation libraries, leading them to pick MSAL because it is commonly associated with Entra ID authentication, even though it does not validate bearer tokens in an API.

How to eliminate wrong answers

Option A is wrong because MSAL is a client-side library used for acquiring tokens (e.g., from users or daemons), not for validating incoming bearer tokens in a web API. Option C is wrong because ADAL.NET is deprecated and uses the older Azure AD v1.0 endpoint; it lacks support for modern features like Microsoft Entra ID and the Microsoft identity platform. Option D is wrong because Azure.Identity is a credential abstraction library for authenticating to Azure services (e.g., DefaultAzureCredential), not for validating OAuth 2.0 bearer tokens in an API.

Full explanation →
268
MCQmedium

You develop an application that stores large binary files (up to 1 GB) in Azure Blob Storage. The application must minimize latency when reading these files from different geographic regions. The files are updated infrequently (once per month) and must be read-only for the application. You need to configure the storage account for optimal read performance and cost. What should you use?

A.Use Azure Blob Storage with Premium Block Blob Storage and enable geo-replication.
B.Use Azure Blob Storage with a Content Delivery Network (CDN) endpoint.
C.Use Azure Files with a Premium tier and geo-redundant storage.
D.Use Azure Blob Storage with read-access geo-redundant storage (RA-GRS) and serve reads from the secondary region.
AnswerD

RA-GRS provides low-latency reads from a secondary region for users worldwide, and the cost is acceptable for infrequent updates.

Why this answer

Option D is correct because read-access geo-redundant storage (RA-GRS) provides a secondary read-only endpoint in a paired region, allowing the application to read from the closest region to minimize latency. Since files are updated infrequently (once per month) and are read-only, RA-GRS offers cost-effective geo-distributed read performance without the premium cost of CDN or Premium Blob Storage.

Exam trap

The trap here is that candidates often confuse RA-GRS with GRS, forgetting that only RA-GRS provides a read-only secondary endpoint for active reads, while standard GRS requires a manual failover to access the secondary region.

How to eliminate wrong answers

Option A is wrong because Premium Block Blob Storage uses SSD-backed storage optimized for low-latency writes and high transaction rates, but it does not include geo-replication by default and is significantly more expensive than standard tiers, making it cost-inefficient for infrequently updated, read-heavy large files. Option B is wrong because a CDN endpoint caches content at edge nodes to reduce latency for repeated reads, but for large binary files up to 1 GB, CDN egress costs can be high, and the first read from each edge node still requires a full fetch from the origin, which does not minimize latency as effectively as reading directly from a geographically close secondary region. Option C is wrong because Azure Files with Premium tier is designed for SMB/NFS file shares with low-latency access for enterprise applications, not for large binary blob storage, and geo-redundant storage (GRS) does not provide a read-access secondary endpoint, so reads cannot be served from the secondary region without failover.

Full explanation →
269
MCQhard

A developer deleted a secret from Azure Key Vault with soft-delete and purge protection enabled (retention 90 days). After 50 days, the secret is needed again. What is the correct recovery method?

A.Purge the secret and then restore from a backup
B.Recover the secret using Azure CLI 'az keyvault secret recover'
C.Recreate the secret with the same name
D.Use an Azure Resource Manager template to undelete the secret
AnswerB

Correct. Soft-delete allows recovery within the retention period using the recover command.

Why this answer

Option B is correct because Azure Key Vault with soft-delete and purge protection enabled retains deleted secrets for the specified retention period (90 days in this case). Since only 50 days have passed, the secret is still in a soft-deleted state and can be recovered using the 'az keyvault secret recover' command, which restores the secret to its original state without data loss.

Exam trap

The trap here is that candidates may confuse soft-delete recovery with backup/restore or assume that recreating the secret with the same name is possible, not realizing that soft-deleted secrets block name reuse until purged or the retention period ends.

How to eliminate wrong answers

Option A is wrong because purging the secret permanently deletes it, making recovery impossible without a backup; the correct action is to recover the soft-deleted secret, not purge it. Option C is wrong because recreating the secret with the same name would fail due to a naming conflict with the soft-deleted secret, which still exists in a hidden state. Option D is wrong because Azure Resource Manager templates cannot undelete secrets; they are used for infrastructure deployment, not for recovering soft-deleted Key Vault objects.

Full explanation →
270
MCQeasy

You need to store terabytes of archival data that must be retained for 10 years. The data is accessed once or twice per year. You need to minimize storage costs. Which Azure Storage tier should you use?

A.Cool
B.Hot
C.Archive
D.Premium
AnswerC

Archive tier offers the lowest storage cost for long-term archival data with rare access.

Why this answer

The Archive tier is designed for data that is rarely accessed (a few times per year or less) and has a flexible retrieval latency of several hours, making it ideal for long-term retention of terabytes of archival data for 10 years at the lowest storage cost. It offers the lowest per-GB storage price among Azure Blob Storage tiers, directly meeting the requirement to minimize costs for infrequently accessed data.

Exam trap

The trap here is that candidates often confuse 'infrequent access' with 'archival access' and pick the Cool tier, forgetting that the Archive tier is specifically designed for data accessed only a few times per year and offers significantly lower storage costs for long-term retention.

How to eliminate wrong answers

Option A is wrong because the Cool tier is optimized for data that is accessed infrequently (about once per month) and has higher storage costs than Archive, making it more expensive for data accessed only once or twice per year. Option B is wrong because the Hot tier is designed for frequently accessed data with the highest storage cost, which would be wasteful for archival data that is rarely accessed. Option D is wrong because the Premium tier uses SSD-based storage for low-latency, high-performance scenarios (e.g., interactive workloads) and has the highest cost, making it unsuitable for minimizing storage costs for archival data.

Full explanation →
271
MCQmedium

You are deploying a microservices application to Azure Kubernetes Service (AKS). One service needs to retrieve configuration values from Azure App Configuration. The configuration includes sensitive values that must be stored in Azure Key Vault. The solution should not require application code changes to reference Key Vault. What should you use?

A.Store the configuration values as Key Vault references in Azure App Configuration.
B.Use Azure AD managed identity to access Key Vault directly from the service.
C.Store the secrets in Kubernetes Secrets and mount them as environment variables.
D.Use the Azure Key Vault SDK directly in the service to retrieve secrets.
AnswerA

Key Vault references are resolved by App Configuration automatically.

Why this answer

Azure App Configuration has a Key Vault references feature that allows you to store references to secrets in Key Vault. The application retrieves configuration normally, and App Configuration resolves the reference by fetching the secret from Key Vault. Option A is correct.

Option B is incorrect because direct Key Vault SDK calls require code changes. Option C is incorrect because Kubernetes Secrets do not integrate with Key Vault natively. Option D is incorrect because managed identity alone does not automatically resolve references.

Full explanation →
272
MCQmedium

A company uses Azure App Service to host a web application. They need to ensure that only authenticated users from their Microsoft Entra ID tenant can access the app. They also want to prevent unauthenticated requests from reaching the app code. Which configuration should they implement?

A.Configure IP restrictions in the web.config to allow only the company's office IP range.
B.Implement a custom middleware in the app to validate tokens from Microsoft Entra ID.
C.Assign users to Microsoft Entra ID App Roles and check roles in the app.
D.Enable App Service Authentication with Microsoft Entra ID as the identity provider and set 'Action to take when request is not authenticated' to 'Log in with Microsoft Entra ID'.
AnswerD

This configuration ensures all unauthenticated requests are redirected to login, and the authentication module validates tokens before the request reaches the app.

Why this answer

Option B is correct because the App Service Authentication feature, when configured to require authentication (e.g., 'Log in with Microsoft Entra ID'), blocks unauthenticated requests before they reach the app code. Option A is wrong because IP restrictions only block based on IP, not authentication. Option C is wrong because the built-in Microsoft Entra ID authentication module in App Service (EasyAuth) is specifically designed to offload authentication and reject unauthenticated requests.

Option D is wrong because Microsoft Entra ID App Roles are for authorization, not authentication enforcement at the gateway.

Full explanation →
273
MCQmedium

A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required? The architecture review board prefers a managed AWS-native control.

A.Password hash synchronization
B.Delegated permissions only
C.Device code flow
D.Application permissions with client credentials flow
AnswerD

Application permissions allow daemon apps to act as themselves without a user context.

Why this answer

For a background service calling Microsoft Graph without a signed-in user, the application must authenticate as itself, not on behalf of a user. Application permissions, combined with the client credentials flow (OAuth 2.0), allow the service to obtain an access token using its own identity (client ID and client secret or certificate), without any user interaction. This is the only model that supports non-interactive, daemon-style access to Microsoft Graph.

Exam trap

The trap here is that candidates confuse 'no signed-in user' with 'no user at all' and incorrectly choose delegated permissions or device code flow, forgetting that application permissions with client credentials flow are the only way to authenticate a service identity without user interaction.

How to eliminate wrong answers

Option A is wrong because password hash synchronization is an Azure AD Connect feature for syncing user password hashes for hybrid identity, not a permission model for calling Microsoft Graph. Option B is wrong because delegated permissions require a signed-in user to delegate authority to the app; they cannot be used for background services that run without a user context. Option C is wrong because the device code flow is designed for devices with limited input capabilities (e.g., IoT, CLI) and still requires a signed-in user to complete the authentication interactively; it does not support unattended background service scenarios.

Full explanation →
274
MCQeasy

A developer needs to store session state for a web app that runs on multiple instances behind a load balancer. The state must be persisted across restarts. Which Azure service should they use?

A.Azure Table Storage
B.Azure SQL Database
C.Azure Blob Storage
D.Azure Cache for Redis
AnswerD

Fast, distributed, supports session state providers.

Why this answer

Azure Cache for Redis (option B) provides a distributed cache for session state. Azure Table Storage (A) is slower. Azure Blob Storage (C) is not designed for session state.

Azure SQL Database (D) is overkill and slower.

Full explanation →
275
Multi-Selecthard

A production API needs proactive alerting for failed dependency calls. Which two elements are required for a useful Azure Monitor alert?

Select 2 answers
A.A manually exported CSV report
B.A signal or metric/log query that detects the condition
C.A public IP address on the app
D.An action group for notification or automation
AnswersB, D

The alert rule must evaluate a metric or query that represents the problem.

Why this answer

Option B is correct because Azure Monitor alerts require a signal—either a metric, log query, or activity log event—to define the condition that triggers the alert. For failed dependency calls, you would use a log query (e.g., from Application Insights) or a custom metric to detect when the dependency failure rate exceeds a threshold. Without a signal, the alert has no basis to evaluate or fire.

Exam trap

The trap here is that candidates confuse the alert's detection mechanism (the signal) with the response mechanism (the action group), often thinking a static report or network configuration is sufficient for proactive alerting.

Full explanation →
276
MCQmedium

Your team monitors Azure Functions with Application Insights. After a recent deployment, cold start latency increased. Which feature should you enable to mitigate this?

A.Set FUNCTIONS_WORKER_RUNTIME to 'dotnet-isolated'
B.Migrate from Consumption plan to Premium plan
C.Enable Azure Monitor alerts on function execution count
D.Enable Always On in the function app configuration
AnswerB

Premium plan keeps instances warm.

Why this answer

Option C is correct because Premium plan keeps instances warm, reducing cold starts. Option A is wrong because Always On is for App Service, not Functions. Option B is wrong because it's a general setting, not specifically for cold starts.

Option D is wrong because it's a debugging tool, not a mitigation for cold starts.

Full explanation →
277
MCQhard

You are developing an application that writes telemetry data to Azure Table Storage. Each telemetry event is about 5 KB in size, and the application writes up to 10,000 events per second. The data is queried by device ID and timestamp range. What is the most efficient partitioning strategy to maximize write throughput and query performance?

A.Use timestamp as the partition key and device ID as the row key.
B.Use device ID as the partition key and timestamp as the row key.
C.Use device type as the partition key and timestamp as the row key.
D.Use a single partition key for all events and use timestamp as the row key.
AnswerB

This distributes writes across partitions and allows efficient range queries.

Why this answer

Option B is correct because using device ID as the partition key distributes writes across multiple partitions, avoiding throttling from a single partition's scalability limit (up to 20,000 operations per second per partition). Using timestamp as the row key enables efficient range queries for a specific device within a time window, leveraging the table's natural sort order on row key.

Exam trap

The trap here is that candidates often choose timestamp as the partition key (Option A) because they think it naturally supports time-range queries, but they overlook the severe write throttling caused by a hot partition at each timestamp second.

How to eliminate wrong answers

Option A is wrong because using timestamp as the partition key would cause all writes at the same second to hit the same partition, creating a hot partition that throttles throughput and fails to meet the 10,000 events/second requirement. Option C is wrong because device type likely has low cardinality (e.g., a few types), leading to uneven load distribution and poor query performance when filtering by device ID. Option D is wrong because a single partition key for all events creates a single partition bottleneck, severely limiting write throughput (max ~2,000 ops/sec per partition) and making queries by device ID inefficient without a secondary index.

Full explanation →
278
MCQeasy

You are developing an application that reads data from Azure Table Storage. The application must retrieve all entities for a specific partition key. Which query approach is the most efficient?

A.Query with a filter on RowKey only.
B.Query with a filter on both PartitionKey and RowKey.
C.Query all entities and filter in application code.
D.Query with a filter on PartitionKey only.
AnswerD

Querying by PartitionKey targets a single partition efficiently.

Why this answer

In Azure Table Storage, the PartitionKey is the primary index for partitioning data. Querying with a filter on PartitionKey only allows the service to perform a partition scan, which is the most efficient way to retrieve all entities within a single partition because it avoids cross-partition queries and leverages the partition-level index directly.

Exam trap

The trap here is that candidates often assume filtering on both PartitionKey and RowKey is the most efficient, but that retrieves only a single entity, not all entities for a partition, while filtering on PartitionKey alone is the correct and most efficient approach for retrieving all entities in a partition.

How to eliminate wrong answers

Option A is wrong because filtering on RowKey only forces a full table scan across all partitions, which is inefficient and incurs higher latency and cost. Option B is wrong because filtering on both PartitionKey and RowKey is overly restrictive; it retrieves only a single entity (or a small range) rather than all entities for the partition. Option C is wrong because querying all entities and filtering in application code transfers unnecessary data over the network and wastes compute resources, violating the principle of server-side filtering.

Full explanation →
279
Multi-Selecthard

Your company is deploying a multi-tier application on Azure. The application consists of a web front end, an API layer, and a database. You need to ensure secure communication between tiers. Which TWO actions should you take? (Choose two.)

Select 2 answers
A.Enable HTTPS on the web front end
B.Enable Azure Storage encryption at rest
C.Use TLS for all internal service-to-service communication
D.Use managed identities to authenticate between tiers
E.Configure network security groups (NSGs) to allow only the web layer to access the API layer, and only the API layer to access the database
AnswersC, E

TLS ensures encryption between API and database, and between web and API.

Why this answer

Option C is correct because TLS (Transport Layer Security) encrypts data in transit between application tiers, preventing eavesdropping and man-in-the-middle attacks. For internal service-to-service communication, using TLS ensures that sensitive data passed between the web front end, API layer, and database remains confidential and tamper-proof, which is a fundamental security best practice for multi-tier applications.

Exam trap

The trap here is that candidates often confuse authentication (managed identities) with encryption (TLS), thinking that authenticating between tiers automatically secures the communication channel, when in fact encryption is required to protect data in transit.

Full explanation →
280
MCQhard

Your company has a storage account with a hierarchical namespace enabled (Azure Data Lake Storage Gen2). You need to authorize an application to write data to a specific container using a managed identity. The application runs on an Azure VM with a system-assigned managed identity. Which role assignment should you use?

A.Assign the 'Storage Blob Data Contributor' role on the container to the managed identity.
B.Assign the 'Contributor' role on the storage account to the managed identity.
C.Assign the 'Storage Blob Data Reader' role on the container to the managed identity.
D.Assign the 'Owner' role on the storage account to the managed identity.
AnswerA

This role grants write access to the container's data.

Why this answer

Option A is correct because the 'Storage Blob Data Contributor' role grants read, write, and delete permissions to blob data at the container scope. For Azure Data Lake Storage Gen2 with a hierarchical namespace, this role provides the necessary ACL-based access for a managed identity to write data to a specific container, without granting control plane permissions.

Exam trap

The trap here is that candidates often confuse Azure RBAC roles (like 'Contributor' or 'Owner') with data plane roles, mistakenly thinking control plane permissions automatically grant data access, but for Azure Storage, data plane and control plane permissions are separate and require specific role assignments like 'Storage Blob Data Contributor'.

How to eliminate wrong answers

Option B is wrong because the 'Contributor' role is an Azure RBAC role that grants full management access to the storage account resource itself (control plane), but does not grant any data plane permissions to write blobs or files. Option C is wrong because the 'Storage Blob Data Reader' role only allows read access to blob data, not write access, so the application cannot write data. Option D is wrong because the 'Owner' role grants full control plane access to the storage account, including managing role assignments, but does not grant data plane write permissions by itself; it also violates the principle of least privilege by providing excessive permissions.

Full explanation →
281
MCQmedium

A company uses Azure Functions with an HTTP trigger and Azure Cosmos DB. They need to securely store connection strings for Cosmos DB and rotate them automatically every 90 days. Which service should they use?

A.Azure Key Vault
B.Managed Identity
C.Azure App Configuration
D.Microsoft Entra ID
AnswerA

Key Vault securely stores secrets and supports automatic rotation.

Why this answer

Azure Key Vault is the correct choice for storing secrets like connection strings and supports automatic rotation. Option A is wrong because App Configuration is for feature flags and configuration settings, not secret rotation. Option B is wrong because Managed Identity provides identity but not secret rotation.

Option D is wrong because Azure AD is for authentication and authorization, not secret management.

Full explanation →
282
Multi-Selectmedium

Which TWO actions should you perform to configure autoscaling for an Azure App Service web app based on CPU usage?

Select 2 answers
A.Configure the minimum and maximum instance limits.
B.Enable manual scaling and set the instance count to 3.
C.Set the default instance count to 1.
D.Create a scale rule based on a specific date and time.
E.Define a scale rule that triggers when CPU percentage exceeds a threshold.
AnswersA, E

Instance limits define the boundaries for autoscaling.

Why this answer

Option A is correct because autoscaling in Azure App Service requires you to define the minimum and maximum instance limits to control the scaling range. These limits ensure the web app scales out or in within a safe boundary, preventing runaway costs or performance degradation. Without setting these limits, the autoscale engine cannot determine the operational range for scaling actions.

Exam trap

The trap here is that candidates often confuse the 'default instance count' (Option C) with the minimum instance limit, but the default count is only a starting point and does not define the scaling range, whereas the minimum and maximum limits are mandatory for autoscaling configuration.

Full explanation →
283
MCQmedium

Your application uses Azure Cosmos DB for NoSQL. You need to query items by a property that is not the partition key. The container has 10,000 RU/s. How can you optimize this query to minimize cost and latency?

A.Increase the RU/s to handle cross-partition queries.
B.Create a composite index that includes the property and the partition key.
C.Change the partition key to the property you query on.
D.Enable analytical store and use Synapse Link.
AnswerB

Allows efficient query without full scan.

Why this answer

Option B is correct because creating a composite index on the property and the partition key allows the query to be efficient without a full cross-partition scan. Option A is wrong because changing the partition key is a breaking change. Option C is wrong because increasing RU/s does not solve the indexing issue.

Option D is wrong because enabling analytical store is for analytical queries, not transactional.

Full explanation →
284
MCQhard

You need to analyze all exceptions that occurred in the last 24 hours from an application monitored by Application Insights. You want to group them by exception type, and for each type show the URL where it occurred and the count. Which Log Analytics Kusto query should you use?

A.exceptions | where timestamp > ago(24h) | summarize count() by type, cloud_RoleInstance
B.exceptions | where timestamp > ago(24h) | summarize count() by type, url
C.exceptions | where timestamp > ago(24h) | summarize count() by type, operation_Name
D.exceptions | where timestamp > ago(24h) | summarize count() by type
AnswerB

This query correctly filters the last 24 hours and groups by exception type and URL with a count of occurrences.

Why this answer

Option B is correct because the query filters exceptions from the last 24 hours using `timestamp > ago(24h)`, groups them by `type` (exception type) and `url` (the URL where the exception occurred), and then counts occurrences per group with `summarize count()`. This directly matches the requirement to show, for each exception type, the URL and the count.

Exam trap

The trap here is that candidates may confuse `url` with `operation_Name` or `cloud_RoleInstance`, thinking those columns also represent the URL, but only `url` directly captures the request URL where the exception occurred.

How to eliminate wrong answers

Option A is wrong because it groups by `cloud_RoleInstance`, which identifies the server or instance, not the URL where the exception occurred; this would show counts per server per exception type, not per URL. Option C is wrong because it groups by `operation_Name`, which is the name of the operation (e.g., a controller action), not the URL; this would show counts per operation per exception type, not per URL. Option D is wrong because it only groups by `type`, omitting the URL entirely; this would show total counts per exception type but not break them down by URL as required.

Full explanation →
285
Multi-Selecthard

You are developing a serverless application using Azure Functions that processes sensitive data. The function is triggered by an Azure Storage queue. You need to ensure that data in transit between the function and the storage account is encrypted using a customer-managed key (CMK) and that the storage account's firewall only allows access from the function's virtual network. Which two actions should you take? (Choose two.)

Select 2 answers
A.Configure a customer-managed key in Azure Key Vault and associate it with the storage account.
B.Configure the storage account firewall to allow access only from the function's virtual network.
C.Enable 'Secure transfer required' on the storage account.
D.Enable VNet integration on the function app to route traffic through a virtual network.
AnswersB, C

Restricts network access to the storage account.

Why this answer

To enforce CMK for data in transit, you need to use HTTPS and also require secure transfer. However, CMK for data in transit is not supported; CMK is for data at rest. The question asks for data in transit encryption using CMK, but that is not a standard feature.

The best interpretation is to ensure encryption in transit (HTTPS) and restrict network access. Option A is correct: enable 'Secure transfer required' on the storage account to enforce HTTPS. Option C is correct: configure the storage account firewall to allow access only from the function's virtual network (via service endpoint or private endpoint).

Option B is wrong because configuring CMK in Key Vault does not encrypt data in transit. Option D is wrong because VNet integration for the function app does not directly restrict storage access.

Full explanation →
286
MCQmedium

You are implementing a custom API that calls a downstream API secured with OAuth 2.0. The downstream API requires a client credentials grant flow. You need to securely store the client secret and obtain an access token. What should you use?

A.Azure App Configuration to store the secret and the Azure Identity SDK to obtain the token
B.Managed identity to access the downstream API directly
C.Azure Key Vault to store the secret and MSAL to obtain the token
D.Azure Certificate Manager to store the secret and the HttpClient to obtain the token
AnswerC

Key Vault securely stores secrets; MSAL obtains tokens using client credentials flow.

Why this answer

Option B is correct because Azure Key Vault securely stores the client secret, and the Microsoft Authentication Library (MSAL) can be used to obtain an access token using the client credentials flow. Option A is wrong because App Configuration is for feature flags and configuration, not for secrets. Option C is wrong because managed identity is for Azure resources, but the downstream API may not support managed identity authentication; client credentials flow requires a client secret.

Option D is wrong because Certificate Manager is not an Azure service.

Full explanation →
287
Multi-Selectmedium

Which TWO authentication methods can be used to authorize access to Azure Blob Storage without requiring shared keys?

Select 2 answers
A.Shared access signature (SAS) token
B.Microsoft Entra ID (formerly Azure AD) authentication
C.Storage account access keys
D.Client certificate-based authentication
E.Managed identities for Azure resources
AnswersB, E

Entra ID authentication does not use shared keys.

Why this answer

Microsoft Entra ID (formerly Azure AD) authentication and managed identities for Azure resources are both identity-based authentication methods that do not require shared keys. Entra ID authentication uses OAuth 2.0 tokens to authorize access to Blob Storage, while managed identities provide an automatically managed identity in Entra ID for Azure resources, eliminating the need for developers to manage credentials. Both methods support role-based access control (RBAC) for fine-grained permissions.

Exam trap

Microsoft often tests the misconception that a SAS token is a keyless method, but in reality, a SAS token is generated using a shared key (account key or user delegation key), so it does not meet the 'without requiring shared keys' condition.

Full explanation →
288
Multi-Selecthard

An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request? The design must avoid adding custom operational scripts.

Select 2 answers
A.Issuer and signature are valid for the trusted tenant
B.The user's display name is present
C.Token audience matches the API application ID URI or client ID
D.The token was sent in a query string
AnswersA, C

Issuer and signature validation confirms the token came from the expected identity provider.

Why this answer

Option A is correct because the API must validate that the JWT's issuer (iss claim) matches the trusted tenant's issuer URL (e.g., https://login.microsoftonline.com/{tenant-id}/v2.0) and that the token's cryptographic signature is valid using the public keys from the OpenID Connect discovery endpoint. This ensures the token was genuinely issued by Microsoft Entra ID for the expected tenant and has not been tampered with.

Exam trap

The trap here is that candidates often think validating the user's identity (e.g., display name or UPN) is a security requirement, but token validation is purely about cryptographic and structural checks (issuer, signature, audience, expiration) — not user attributes.

Full explanation →
289
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
290
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
291
MCQeasy

You need to monitor the performance of an Azure App Service web app. Which metric indicates high CPU usage?

A.Data In/Out
B.Requests per second
C.CPU Time
D.Memory working set
AnswerC

Directly measures CPU consumption.

Why this answer

Option C is correct because CPU Time measures the amount of CPU consumed by the app. Option A is wrong because it measures memory. Option B is wrong because it measures HTTP requests.

Option D is wrong because it measures network traffic.

Full explanation →
292
Multi-Selectmedium

Which THREE services can be used to implement a pub/sub messaging pattern in Azure?

Select 3 answers
A.Azure Service Bus Topics
B.Azure Notification Hubs
C.Azure Queue Storage
D.Azure Event Grid
E.Azure Event Hubs
AnswersA, D, E

Topics support multiple subscribers.

Why this answer

Options B, C, and E are correct. Service Bus Topics, Event Grid, and Event Hubs support pub/sub. Option A is wrong because Queue Storage is point-to-point.

Option D is wrong because Notification Hubs is for push notifications.

Full explanation →
293
MCQeasy

Refer to the exhibit. You are using Azure CLI to list blobs in a container. The command fails with an authorization error. The storage account has firewall rules enabled, and you are running the CLI from a machine that is not on the allowed network list. What is the most likely cause of the failure?

A.The storage account firewall is blocking the request because your IP is not in the allow list
B.You do not have the 'Storage Blob Data Reader' role assigned
C.The container name is misspelled
D.The storage account requires TLS 1.2 and your CLI uses an older version
AnswerA

Firewall rules explicitly deny traffic from non-allowed IPs, causing authorization failure.

Why this answer

Firewall rules deny access from non-allowed IPs. Option A is correct. Option B is for data plane operations that require RBAC? However, the CLI can use storage account key or SAS; the error is likely due to firewall.

Option C is about TLS, which would give a different error. Option D is about container level, but the command syntax is correct.

Full explanation →
294
MCQhard

A system receives high-volume event notifications from Azure resources and routes them to serverless handlers. Events are lightweight and should use native event routing. Which service should be used? The design must avoid adding custom operational scripts.

A.Azure DNS
B.Azure Event Grid
C.Azure Files
D.Azure Service Bus queue
AnswerB

Event Grid is designed for reactive event routing from Azure services and custom publishers.

Why this answer

Azure Event Grid is a fully managed event routing service that uses a publish-subscribe model to deliver lightweight, high-volume events from Azure resources to registered handlers like Azure Functions or webhooks. It supports native event routing without requiring custom polling scripts or infrastructure, making it ideal for serverless event-driven architectures.

Exam trap

The trap here is that candidates often confuse Azure Event Grid with Azure Service Bus, but Event Grid is designed for reactive event routing (push model) with no need for polling or custom scripts, whereas Service Bus is for message queuing with explicit consumer processing.

How to eliminate wrong answers

Option A is wrong because Azure DNS is a domain name resolution service that translates domain names to IP addresses; it does not route events or handle event notifications. Option C is wrong because Azure Files provides fully managed file shares in the cloud, used for storing and accessing files via SMB or NFS protocols, not for event routing. Option D is wrong because Azure Service Bus queue is a message broker designed for reliable, ordered message delivery with features like sessions and transactions, but it requires custom polling or message processing logic and is not optimized for lightweight, native event routing without operational scripts.

Full explanation →
295
MCQmedium

Your organization uses Azure Key Vault to store secrets. Developers need to retrieve secrets during application runtime. You want to minimize latency and avoid network overhead. Which approach should you recommend?

A.Enable the Key Vault firewall and allow only trusted Azure services.
B.Store the secrets directly in application configuration files.
C.Implement caching of secrets in the application with a short time-to-live (TTL) and use Key Vault as the source of truth.
D.Enable Key Vault soft-delete to ensure secrets are recoverable.
AnswerC

Caching reduces latency and load on Key Vault.

Why this answer

Option B is correct because Key Vault secret caching in the application (e.g., using IMemoryCache with expiration) reduces calls to Key Vault. Option A is wrong because storing secrets in app settings is insecure. Option C is wrong because Key Vault firewall does not reduce latency.

Option D is wrong because soft-delete is for recovery, not performance.

Full explanation →
296
MCQmedium

Refer to the exhibit. You run the Get-AzStorageAccount cmdlet and see the output above. You need to enable the hierarchical namespace feature for this storage account. What should you do first?

A.Change the replication to LRS.
B.Set the -EnableHierarchicalNamespace parameter to true on the existing account.
C.Change the access tier to Hot.
D.Delete the storage account and create a new one with -EnableHierarchicalNamespace $true.
AnswerD

HNS must be enabled at creation time.

Why this answer

The hierarchical namespace feature (which enables Azure Data Lake Storage Gen2) cannot be enabled on an existing storage account; it must be set at creation time. Therefore, you must delete the current account and create a new one with the `-EnableHierarchicalNamespace $true` parameter. Option D is correct because it follows this immutable requirement.

Exam trap

The trap here is that candidates assume `-EnableHierarchicalNamespace` is a settable property like `-AccessTier` or `-SkuName`, but Azure enforces it as a creation-only flag, making deletion and recreation the only path.

How to eliminate wrong answers

Option A is wrong because changing replication to LRS does not affect the ability to enable hierarchical namespace; replication is independent of the namespace feature. Option B is wrong because the `-EnableHierarchicalNamespace` parameter cannot be set on an existing account; it is a creation-only property and attempting to update it will fail. Option C is wrong because the access tier (Hot, Cool, Archive) is unrelated to hierarchical namespace; changing it does not enable the feature.

Full explanation →
297
MCQeasy

A company uses Azure Service Bus to decouple microservices. They need to ensure that messages are processed in the order they are received, and that each message is handled by exactly one consumer instance even when the system scales out. Which feature should they enable?

A.Sessions
B.Topics
C.Dead-letter queue
D.Duplicate detection
AnswerA

Correct. Sessions enable FIFO and lock a session to one consumer at a time, ensuring ordered and single-consumer processing.

Why this answer

Sessions in Azure Service Bus enforce first-in-first-out (FIFO) ordering and guarantee that all messages with the same session ID are processed by a single consumer instance. This ensures strict message ordering and exactly-once processing per session, even when multiple consumers are scaled out. Without sessions, competing consumers would break ordering because messages could be processed by different instances concurrently.

Exam trap

The trap here is that candidates often confuse topics (which support multiple subscribers) with the need for ordering and single-consumer processing, overlooking that sessions are the specific feature designed for FIFO and exclusive consumption in a competing-consumers pattern.

How to eliminate wrong answers

Option B (Topics) is wrong because topics implement a publish/subscribe pattern where each subscription receives a copy of every message, allowing multiple consumers to process the same message, which violates the 'exactly one consumer' requirement. Option C (Dead-letter queue) is wrong because dead-letter queues are used to hold messages that cannot be processed normally (e.g., due to exceeding max delivery count or TTL), not to enforce ordering or single-consumer processing. Option D (Duplicate detection) is wrong because duplicate detection prevents duplicate message delivery within a specified time window but does not guarantee message ordering or ensure single-consumer processing.

Full explanation →
298
MCQmedium

You are designing an Azure Table Storage table to store temperature readings from IoT devices. Each reading includes a device ID (string), timestamp (datetime), temperature value, and location. You need to optimize the table design for this query: "Retrieve all temperature readings for a specific device ID within a given one-hour time range." The query must be efficient and minimize partition scans. Which PartitionKey and RowKey combination should you use?

A.PartitionKey = device ID, RowKey = timestamp (formatted as inverted ticks)
B.PartitionKey = timestamp (rolled up to day), RowKey = device ID
C.PartitionKey = location, RowKey = device ID
D.PartitionKey = device ID + timestamp (composite), RowKey = empty
AnswerA

All readings for a device are in one partition; the sorted RowKey enables a point query range scan, minimizing partition scans.

Why this answer

Option A is correct because using device ID as the PartitionKey ensures all readings for a specific device are in the same partition, allowing efficient point queries. Using timestamp formatted as inverted ticks (e.g., DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks) as the RowKey enables range queries within a one-hour window by leveraging the lexicographic ordering of RowKey values, minimizing partition scans.

Exam trap

The trap here is that candidates often choose a composite key (Option D) thinking it uniquely identifies rows, but they overlook that Azure Table Storage requires RowKey for range queries, and an empty RowKey prevents efficient filtering within a partition.

How to eliminate wrong answers

Option B is wrong because rolling up timestamp to day as PartitionKey scatters readings for the same device across multiple partitions, requiring a partition scan for each day to retrieve data within a one-hour range, which is inefficient. Option C is wrong because using location as PartitionKey does not group readings by device ID, so querying for a specific device would require scanning all partitions, defeating the purpose of partition optimization. Option D is wrong because a composite PartitionKey of device ID + timestamp prevents efficient range queries on RowKey (empty), as Azure Table Storage requires RowKey for range filtering; without a meaningful RowKey, you cannot perform a range scan within a partition.

Full explanation →
299
MCQeasy

You are developing a solution that processes orders. Each order must be processed exactly once, in the order it was received. You need to choose an Azure service that guarantees FIFO delivery and at-least-once processing. Which service should you use?

A.Azure Service Bus Queue with sessions
B.Azure Event Hubs
C.Azure Event Grid
D.Azure Storage Queue
AnswerA

Azure Service Bus queues with sessions provide FIFO guarantee and duplicate detection.

Why this answer

Azure Service Bus Queue with sessions is correct because it provides FIFO (first-in, first-out) delivery by grouping related messages into sessions, ensuring messages within a session are processed in order. The at-least-once processing guarantee is inherent to Service Bus queues, as messages are not removed until the receiver completes them, and they can be redelivered if the processing fails or times out.

Exam trap

The trap here is that candidates often confuse Azure Storage Queue's 'first-in, first-out' appearance with true FIFO, but it does not guarantee order due to its visibility timeout and dequeuing behavior, making Service Bus sessions the only correct choice for strict FIFO with at-least-once processing.

How to eliminate wrong answers

Option B (Azure Event Hubs) is wrong because it is designed for high-throughput event ingestion and does not guarantee FIFO ordering across partitions; it only preserves order within a partition but lacks at-least-once processing guarantees without additional checkpointing logic. Option C (Azure Event Grid) is wrong because it provides at-least-once delivery but does not guarantee FIFO ordering; events are delivered in a best-effort order and can be retried, but the order is not preserved. Option D (Azure Storage Queue) is wrong because it guarantees at-least-once processing but does not guarantee FIFO delivery; messages can be dequeued out of order due to visibility timeouts and retries.

Full explanation →
300
MCQhard

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

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

Application Insights automatically captures orchestration lifecycle events (start, running, failed, etc.). You can use Kusto queries to monitor running orchestrations and create alerts on failed orchestrations with detailed context.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
Page 3

Page 4 of 14

Page 5

All pages

1234567891011121314

Practice AZ-204 by domain

Target a specific domain to shore up weak areas.

Develop Azure compute solutionsDevelop for Azure storageImplement Azure securityConnect to and consume Azure services and third-party servicesMonitor, troubleshoot, and optimize Azure solutions
See all domains with question counts →