Microsoft Azure Developer Associate AZ-204 AZ-204 Questions 526–600 | Page 8/12

526

MCQeasy

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

A.Azure Logic Apps.

B.Azure Batch.

C.Azure Functions (Consumption plan).

D.Azure Container Instances.

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

527

MCQmedium

You have an App Service web app with Application Insights configured. You want to create an alert that fires when the server response time exceeds 2 seconds for a rolling 10-minute window. Which type of alert rule should you create?

A.Log alert

B.Metric alert

C.Activity log alert

D.Smart detection alert

AnswerB

Metric alerts are the most appropriate and efficient mechanism for monitoring specific performance indicators, such as server response time, directly from Application Insights. They evaluate a numerical metric against a predefined static or dynamic threshold over a specified aggregation period and frequency. This direct integration with Azure Monitor metrics ensures low latency and cost-effective detection of performance degradation.

Why this answer

Metric alerts in Azure Monitor evaluate resource-level performance counters at regular intervals, making them ideal for threshold-based conditions like server response time. Application Insights automatically collects server response time as a pre-aggregated metric, so a metric alert can check whether the average exceeds 2 seconds over a rolling 10-minute window without needing to query raw log data.

Exam trap

The trap here is that candidates confuse log-based queries (Log Analytics) with metric-based thresholds, assuming that any Application Insights data must be queried via logs, when in fact common performance counters like server response time are exposed as metrics for simpler and faster alerting.

How to eliminate wrong answers

Option A is wrong because log alerts run Kusto queries against log data (e.g., requests table) and are better suited for complex patterns or correlation across multiple signals, not for simple, low-latency threshold checks on a single metric. Option C is wrong because activity log alerts fire only on Azure resource management events (e.g., create, delete, scale) and cannot monitor application performance metrics like server response time. Option D is wrong because smart detection alerts use machine learning to automatically detect anomalies in telemetry patterns (e.g., sudden failure spikes) and cannot be configured with a fixed threshold of 2 seconds.

Full explanation →

528

MCQmedium

You are developing an API that processes sensitive personal data. The API is exposed via Azure API Management (APIM). You need to ensure that only authorized applications can call the API, and you want to validate the token at the APIM gateway without modifying the backend code. What is the most efficient approach?

A.Implement token validation in the backend API code

B.Use APIM's OAuth 2.0 authorization server

C.Use subscription keys in APIM

D.Configure a validate-jwt policy in APIM inbound processing

AnswerD

Configuring a `validate-jwt` policy within APIM's inbound processing is the most effective and recommended approach for validating JSON Web Tokens. This policy allows the API Management gateway to cryptographically verify the token's signature, check its expiration, validate issuer and audience claims, and ensure its overall integrity *before* the request even reaches the backend API. This offloads security responsibilities from the backend, centralizes validation logic, and enhances performance by rejecting invalid requests early in the request pipeline.

Why this answer

The validate-jwt policy in APIM's inbound processing validates the OAuth 2.0 token at the gateway level, ensuring only authorized applications can call the API without modifying backend code. This is the most efficient approach because it offloads token validation to APIM, reducing backend complexity and centralizing security enforcement.

Exam trap

The trap here is that candidates confuse APIM's OAuth 2.0 authorization server (which issues tokens) with the validate-jwt policy (which validates tokens), leading them to choose Option B instead of D.

How to eliminate wrong answers

Option A is wrong because implementing token validation in the backend API code requires modifying the backend, which contradicts the requirement to avoid backend changes. Option B is wrong because APIM's OAuth 2.0 authorization server is used to issue tokens, not to validate them at the gateway; validation is done via policies like validate-jwt. Option C is wrong because subscription keys provide API-level access control but do not validate token claims or enforce OAuth 2.0 authorization; they are not suitable for validating sensitive personal data access.

Full explanation →

529

MCQmedium

You are building an Azure Logic App that must send email notifications via Office 365 when a new order is placed. You need to securely store the Office 365 credentials and reference them in the Logic App. Which approach should you use?

A.Store the credentials in a variable within the Logic App designer

B.Use an Azure Key Vault action with a connection that uses a username and password

C.Use an Azure Key Vault connector with a managed identity assigned to the Logic App

D.Store the credentials in an Azure Storage table and fetch them in the Logic App

AnswerC

Using an Azure Key Vault connector with a managed identity assigned to the Logic App is the most secure and recommended approach. The Logic App receives an identity from Azure Active Directory, which is then granted specific access policies on Key Vault. This eliminates the need for any developer-managed secrets or connection strings for Key Vault authentication, establishing a secure, credential-less connection to retrieve the Office 365 credentials at runtime.

Why this answer

Using an Azure Key Vault connector with a managed identity assigned to the Logic App allows you to securely store Office 365 credentials in Key Vault and authenticate to it without hardcoding secrets or managing credentials. The managed identity provides an Azure AD-backed identity for the Logic App, eliminating the need for username/password in connection strings and enabling secure, auditable access to secrets.

Exam trap

The trap here is that candidates often confuse using a Key Vault action with a username/password connection (Option B) as secure, when in fact the connection itself still stores credentials, whereas a managed identity eliminates credential storage entirely.

How to eliminate wrong answers

Option A is wrong because storing credentials in a variable within the Logic App designer exposes them in plain text in the workflow definition and logs, violating security best practices. Option B is wrong because using an Azure Key Vault action with a connection that uses a username and password still requires you to store and manage those credentials in the connection definition, defeating the purpose of Key Vault and introducing a security risk. Option D is wrong because storing credentials in an Azure Storage table is insecure (data is not encrypted at rest by default unless client-side encryption is used) and introduces unnecessary complexity and latency when fetching secrets at runtime.

Full explanation →

530

MCQmedium

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

A.Horizontal Pod Autoscaler

B.Virtual Node

C.Vertical Pod Autoscaler

D.Cluster Autoscaler

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

531

MCQhard

Refer to the exhibit. The exhibit shows an Azure Event Grid subscription configuration. You notice that the webhook endpoint is not receiving events when a .png file is uploaded to the 'images' container. What is the most likely reason?

A.The subscription is disabled

B.The destination endpoint type is incorrect

C.The webhook endpoint requires authentication

D.The subject filter excludes .png files

AnswerD

The filter 'subjectEndsWith' is '.jpg', so .png files are filtered out.

Why this answer

The exhibit shows an Event Grid subscription with a subject filter configured to only include events where the subject ends with '.jpg'. Since a .png file upload would have a subject ending in '.png', the filter excludes it, preventing the event from being sent to the webhook endpoint. Therefore, the subject filter is the most likely reason the webhook is not receiving .png file events.

Exam trap

The trap here is that candidates often overlook subject filtering as the cause of selective event delivery, assuming instead that the webhook endpoint is misconfigured or that authentication is the issue, when in fact the filter is silently discarding events based on the subject string.

How to eliminate wrong answers

Option A is wrong because if the subscription were disabled, no events would be received for any file type, not just .png files. Option B is wrong because the destination endpoint type (Webhook) is correct for receiving events at an HTTP endpoint; the issue is not about the endpoint type but about filtering. Option C is wrong because if the webhook endpoint required authentication, the event delivery would fail with a 401 or 403 error, but the question states the endpoint is 'not receiving events'—this could be due to validation handshake failure, but the exhibit shows no authentication configuration, and the most common cause for selective file type exclusion is subject filtering.

Full explanation →

532

MCQmedium

An Azure web app is experiencing high memory usage. You want to collect memory dumps periodically to analyze the issue without restarting the app. Which Azure App Service diagnostic feature should you use?

A.Application Insights Profiler

B.Diagnostic Settings

C.Application Snapshot Debugger

D.Auto-healing

AnswerC

The Application Snapshot Debugger, integrated with Application Insights, is specifically engineered to capture a full memory snapshot or dump of a running application process. It can be triggered on demand or automatically upon specific exception occurrences, allowing developers to inspect the application's state, including its entire memory heap, without requiring an application restart. This capability is crucial for analyzing high memory usage by examining object allocations, identifying memory leaks, and understanding object retention paths in detail.

Why this answer

The Application Snapshot Debugger captures memory dumps (snapshots) of a production web app when an exception occurs or when configured to trigger on specific conditions, such as high memory usage, without restarting the app. It is specifically designed for debugging memory leaks and high CPU/memory issues in Azure App Service by providing detailed snapshots of the process state, including the heap, at the point of interest. While not strictly time-based periodic, if the high memory condition occurs repeatedly, the debugger can be configured to capture multiple snapshots over time for analysis.

Exam trap

The trap here is that candidates confuse Application Insights Profiler (which profiles CPU/request timing) with the Snapshot Debugger (which captures memory dumps), or they assume Diagnostic Settings can collect in-process memory dumps when it only handles log streaming.

How to eliminate wrong answers

Option A is wrong because Application Insights Profiler is a performance tracing tool that captures CPU and request execution time profiles, not memory dumps; it does not capture heap snapshots. Option B is wrong because Diagnostic Settings is used to stream platform logs and metrics to destinations like Log Analytics or Storage, not to collect in-process memory dumps. Option D is wrong because Auto-healing is a recovery feature that restarts or recycles the app based on conditions like memory thresholds, but it does not collect memory dumps for analysis and would restart the app, which contradicts the requirement to avoid restarting.

Full explanation →

533

MCQhard

You are using Azure Logic Apps to orchestrate a workflow that calls a third-party API. The API occasionally returns HTTP 429 (Too Many Requests). How should you handle this to ensure the workflow completes successfully without manual intervention?

A.Increase the timeout value for the HTTP request.

B.Change the concurrency setting to 1 to avoid multiple requests.

C.Use a webhook action instead of HTTP.

D.Configure a retry policy on the HTTP action with exponential backoff.

AnswerD

Configuring a retry policy on the HTTP action with exponential backoff is the correct and most robust solution for handling transient errors like HTTP 429 (Too Many Requests). This policy automatically reattempts the failed request after a calculated delay, which increases with each subsequent retry, preventing the Logic App from overwhelming the target service further. Exponential backoff allows the external service time to recover from the high load, significantly improving the workflow's resiliency.

Why this answer

Azure Logic Apps supports configuring a retry policy on HTTP actions, and using exponential backoff is the standard approach to handle HTTP 429 responses. The retry policy automatically waits for increasing intervals between attempts, respecting the 'Retry-After' header if present, which allows the third-party API to recover from rate limiting without manual intervention.

Exam trap

The trap here is that candidates often confuse concurrency control (Option B) with retry logic, mistakenly thinking limiting parallel requests prevents 429 errors, but 429 can still occur from a single request if the API's rate limit is per-request or per-account, not per-concurrent-call.

How to eliminate wrong answers

Option A is wrong because increasing the timeout value only extends how long the Logic App waits for a single HTTP response; it does not address the rate-limiting error (429) and will still result in failure if the request is rejected. Option B is wrong because changing concurrency to 1 limits the number of parallel requests but does not retry failed requests; a single request that receives a 429 will still fail without a retry mechanism. Option C is wrong because a webhook action is used for asynchronous callbacks, not for handling retries or rate-limiting responses; it does not automatically retry on 429 errors.

Full explanation →

534

MCQmedium

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

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

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

C.Use Azure App Configuration with feature flags.

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

535

MCQeasy

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

A.Azure Functions with Event Hubs trigger

B.Azure Batch with Event Hubs input

C.Azure Logic Apps with Event Hubs connector

D.Azure WebJobs with Event Hubs SDK

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

536

MCQeasy

You are monitoring an Azure App Service with Application Insights. You need to create a custom dashboard that shows the number of requests over time and the average server response time. Which Application Insights feature should you use to create this dashboard?

A.Live Metrics Stream

B.Metrics Explorer

C.Analytics (Logs)

D.Availability Tests

AnswerB

Metrics Explorer is the primary tool within Application Insights for visualizing aggregated metric data over custom time ranges. It allows users to select standard or custom metrics, apply various aggregation types like sum, average, or count, and filter results to create insightful charts. These customizable charts can then be easily pinned to Azure dashboards, providing continuous historical monitoring and performance trend analysis.

Why this answer

Metrics Explorer is the correct feature because it allows you to create custom charts and dashboards by selecting specific metrics like 'Requests' and 'Server response time' from your Application Insights resource. You can aggregate these metrics over time and pin them to an Azure dashboard for monitoring. Live Metrics Stream shows real-time data but cannot be used for historical charting or dashboard pinning, while Analytics (Logs) requires Kusto queries for custom visualizations and is not optimized for simple metric dashboards.

Exam trap

The trap here is that candidates often confuse Live Metrics Stream (real-time) with Metrics Explorer (historical and dashboard-capable), or assume that Analytics (Logs) is the only way to create custom visualizations, overlooking the simpler and more appropriate Metrics Explorer for pre-aggregated metric dashboards.

How to eliminate wrong answers

Option A is wrong because Live Metrics Stream displays real-time telemetry with near-zero latency but does not support historical data aggregation or pinning to a persistent dashboard; it is designed for live debugging, not for creating a dashboard of requests over time. Option C is wrong because Analytics (Logs) uses Kusto Query Language (KQL) to query raw log data and can build charts, but it is not the primary feature for simple metric-based dashboards; Metrics Explorer is the dedicated tool for pre-aggregated metrics with built-in charting and dashboard integration. Option D is wrong because Availability Tests are used to monitor the uptime and responsiveness of your web application from multiple locations, generating test results and alerts, but they do not provide the request count or server response time metrics needed for the described dashboard.

Full explanation →

537

MCQhard

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

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

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

C.Use a timer trigger to schedule retries after failure

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

538

MCQeasy

Your organization has a custom application that stores customer data in Azure Cosmos DB. You need to encrypt the data at rest using a customer-managed key stored in Azure Key Vault. Which type of Cosmos DB encryption should you configure?

A.Enable Azure Disk Encryption on the Cosmos DB instance

B.Enable Transparent Data Encryption (TDE)

C.Use customer-managed keys (CMK) with Azure Key Vault

D.Implement client-side encryption using the SDK

AnswerC

Azure Cosmos DB inherently encrypts all data at rest using service-managed keys, but for enhanced security and compliance requirements, it supports customer-managed keys (CMK). By integrating with Azure Key Vault, customers can provide their own encryption keys, gaining full control over the key lifecycle, including rotation, revocation, and auditing. This ensures that even Microsoft cannot access the data without the customer's explicit key, fulfilling stringent data governance policies.

Why this answer

Azure Cosmos DB supports customer-managed keys (CMK) integrated with Azure Key Vault to encrypt data at rest. This allows you to bring your own key (BYOK) and control key rotation, revocation, and access policies, meeting the requirement for a customer-managed key stored in Azure Key Vault.

Exam trap

The trap here is confusing client-side encryption (which encrypts data before transmission) with server-side encryption at rest using CMK, leading candidates to select Option D instead of the correct server-side CMK configuration.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption is a feature for encrypting virtual machine disks, not for Cosmos DB, which is a PaaS database service. Option B is wrong because Transparent Data Encryption (TDE) is a SQL Server and Azure SQL Database feature, not applicable to Cosmos DB. Option D is wrong because client-side encryption encrypts data before it is sent to the database, not at rest; the requirement specifies encrypting data at rest using a customer-managed key, which is server-side encryption.

Full explanation →

539

MCQhard

Your team uses Azure DevOps to deploy a web app to Azure App Service. The deployment fails intermittently with a '500 Internal Server Error' after successful code upload. You want to capture a memory dump of the process when the error occurs. What should you configure?

A.Configure an autoscale rule in Azure Monitor

B.Use App Service Diagnostics to collect a memory dump

C.Set up Azure API Management policies

D.Enable Application Insights Snapshot Debugger

AnswerB

App Service Diagnostics is the correct and most direct tool within Azure App Service for troubleshooting and resolving application issues, including performance problems or crashes. It provides a suite of diagnostic tools, prominently featuring the ability to collect full or mini-memory dumps on demand. These dumps are crucial for in-depth post-mortem analysis, allowing developers to inspect the application's memory state and identify root causes of complex issues.

Why this answer

App Service Diagnostics provides a built-in 'Collect Memory Dump' tool that can be triggered on specific HTTP error codes, such as 500 Internal Server Error. This allows you to capture a full process dump of the web app when the error occurs, enabling offline analysis of the failure without modifying application code.

Exam trap

The trap here is that candidates confuse Application Insights Snapshot Debugger (which captures lightweight exception snapshots) with a full memory dump, leading them to choose option D, even though Snapshot Debugger does not provide the comprehensive process memory required for deep debugging of intermittent 500 errors.

How to eliminate wrong answers

Option A is wrong because autoscale rules in Azure Monitor adjust the number of instances based on metrics like CPU or memory, but they do not capture memory dumps or diagnose application-level errors. Option C is wrong because Azure API Management policies control API gateway behavior (e.g., rate limiting, transformation) and have no capability to collect memory dumps from an App Service. Option D is wrong because Application Insights Snapshot Debugger captures snapshots of exceptions in .NET applications, but it does not produce a full memory dump of the process; it only captures a partial snapshot of the call stack and variables at the point of an exception.

Full explanation →

540

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

541

Drag & Dropmedium

Arrange the steps to secure an Azure API Management API using OAuth 2.0 with Azure AD in the correct order.

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First register app in Azure AD, configure API Management with OAuth, add validate-jwt policy, configure product, test.

Full explanation →

542

MCQhard

You need to store billions of small log entries (each ~200 bytes) written in chronological order from multiple producers. The logs are read sequentially in bulk once per day. You need to maximize write throughput and minimize storage costs. Which Azure Storage solution should you choose?

A.Append Blob in Blob Storage

B.Block Blob in Blob Storage with high block count

C.Azure Data Lake Storage Gen2 with hierarchical namespace

D.Azure Files with SMB protocol

AnswerA

Append Blobs are specifically designed for append operations, making them ideal for logging scenarios where new data is continuously added to the end of a blob. Each 200-byte log entry can be atomically appended, ensuring data integrity and high write throughput for billions of sequential entries. This specialized blob type efficiently handles the scale and frequency of small, incremental writes without incurring significant overhead, providing a cost-effective and performant solution for continuous logging.

Why this answer

Append Blob in Blob Storage is optimized for append operations, making it ideal for writing small log entries in chronological order from multiple producers. It provides high write throughput because each append operation is atomic and can be performed concurrently, and it minimizes storage costs by storing data in a cost-effective blob tier without the overhead of indexing or metadata management required by other solutions.

Exam trap

The trap here is that candidates often confuse Append Blob with Block Blob, assuming high block count can achieve similar append performance, but Block Blob requires explicit block management and cannot guarantee atomic append operations, making Append Blob the only correct choice for this workload.

How to eliminate wrong answers

Option B is wrong because Block Blob with high block count is designed for uploading large files in parallel, not for frequent small appends; each block must be committed in a final block list, which adds overhead and does not support true append semantics. Option C is wrong because Azure Data Lake Storage Gen2 with hierarchical namespace is optimized for big data analytics workloads with directory-level operations and POSIX permissions, which adds unnecessary complexity and cost for simple sequential log storage. Option D is wrong because Azure Files with SMB protocol is a fully managed file share designed for shared access and SMB-based applications, not for high-throughput append-only log ingestion, and it incurs higher costs per GB compared to blob storage.

Full explanation →

543

MCQmedium

You develop an app that uses Azure Cosmos DB for NoSQL. The app requires reading a specific item by ID with low latency. You need to ensure the query is as fast as possible. What should you use?

A.Use a stored procedure that reads the item.

B.Use a SQL query filtering by ID without partition key.

C.Use a point read with the item's ID and partition key.

D.Use a SQL query with a composite index on ID.

AnswerC

Point reads are the fastest operation in Cosmos DB.

Why this answer

A point read by ID and partition key is the fastest operation in Cosmos DB, directly accessing the item without query engine overhead. Option A is wrong because stored procedures still involve query processing and are not as fast as point reads. Option B is wrong because cross-partition queries add latency.

Option D is wrong because even with a composite index, a SQL query requires query engine processing, whereas a point read is a direct lookup.

Full explanation →

544

MCQeasy

You need to store a large number of small files (each < 100 KB) that will be accessed frequently from a web application. The files are static assets (CSS, JavaScript, images). Which Azure storage option provides the best performance for serving these files directly to users?

A.Azure Queue Storage

B.Azure Blob Storage with Azure CDN

C.Azure Table Storage

D.Azure Files

AnswerB

Azure Blob Storage is the optimal choice for storing large numbers of small, static files, such as images, CSS, or JavaScript, due to its cost-effectiveness and scalability for unstructured data. Integrating with Azure CDN significantly enhances performance by caching these files at edge locations globally. This reduces latency for end-users worldwide and offloads traffic from the origin storage account.

Why this answer

Azure Blob Storage is optimized for storing large volumes of unstructured data, including small static files. By integrating Azure CDN, you cache these files at edge nodes closer to users, drastically reducing latency and offloading origin requests. This combination provides the best performance for frequently accessed static assets served directly to a web application's users.

Exam trap

The trap here is that candidates may choose Azure Files (Option D) because it resembles a traditional file server, but it lacks the global caching and low-latency edge delivery that CDN provides for static web assets.

How to eliminate wrong answers

Option A is wrong because Azure Queue Storage is a messaging service for asynchronous communication between application components, not designed for serving static files to users. Option C is wrong because Azure Table Storage is a NoSQL key-value store for structured data, not optimized for storing or serving binary files like CSS, JavaScript, or images. Option D is wrong because Azure Files provides SMB file shares primarily for lift-and-shift scenarios or shared file access, not for high-performance, direct-to-user serving of static web assets.

Full explanation →

545

MCQhard

You are developing a real-time analytics application that ingests IoT sensor data every second. The data is written to Azure Blob Storage as small JSON files (each ~1 KB). The application also needs to query the data based on device ID and timestamp. You need to design a storage solution that allows efficient querying without writing custom code for indexing. You have decided to use Azure Data Lake Storage Gen2. What should you do to optimize query performance?

A.Use Append Blobs to combine small writes into larger blobs.

B.Use a folder structure like /deviceid/yyyy/mm/dd/hh/ and set the device ID as the partition key.

C.Store all JSON files in a single folder and use Azure Data Lake Analytics to query.

D.Store the data in Azure SQL Database instead of Blob Storage.

AnswerB

This hierarchical folder structure, combined with setting the device ID as a partition key, is highly effective for real-time analytics. It enables query engines to perform partition pruning, skipping entire folders of data that do not match the query's criteria (e.g., specific device or time range). This significantly reduces the amount of data scanned, leading to faster query execution, lower computational costs, and improved performance for analytical workloads.

Why this answer

Azure Data Lake Storage Gen2 supports hierarchical namespaces, which allow you to organize data into folders and subfolders. By structuring the path as /deviceid/yyyy/mm/dd/hh/, you effectively partition the data by device ID and time, enabling efficient querying with tools like Azure Synapse or PolyBase without custom indexing. This leverages the directory structure as a natural partition key, minimizing the data scanned during queries.

Exam trap

The trap here is that candidates may confuse the need for efficient querying with data ingestion optimization (e.g., Append Blobs) or assume that a relational database is always required for querying, overlooking that Data Lake Storage Gen2's hierarchical namespace provides built-in partition elimination without custom indexing.

How to eliminate wrong answers

Option A is wrong because Append Blobs are designed for append-only operations (e.g., logging) and do not improve query performance; they still require scanning all blobs. Option C is wrong because storing all files in a single folder eliminates the benefits of partition elimination, forcing full scans even with Azure Data Lake Analytics. Option D is wrong because Azure SQL Database is a relational store that requires schema definition and indexing, contradicting the requirement to avoid custom indexing and to use Azure Data Lake Storage Gen2 as the chosen solution.

Full explanation →

546

MCQhard

Your team is migrating a legacy application to Azure. The application uses a proprietary database that is not supported by Azure SQL or Cosmos DB. You need to provide a managed database service with minimal rearchitecture. Which Azure service should you use?

A.Azure Virtual Machines with the database software installed

B.Azure Database for MySQL

C.Azure Database Migration Service

D.Azure SQL Database

AnswerA

Azure Virtual Machines (VMs) provide an Infrastructure-as-a-Service (IaaS) offering, granting complete control over the operating system and installed software. This flexibility is crucial when migrating legacy applications that rely on specific, potentially uncommon, or highly customized database software not available as a managed PaaS offering in Azure. By deploying a VM, your team can install and configure any required database engine, ensuring full compatibility with the existing application's data layer and operational requirements, thus minimizing refactoring efforts.

Why this answer

Azure Virtual Machines (IaaS) is the correct choice because the proprietary database is not supported by any Azure PaaS database service. By deploying the database software on a VM, you retain full control over the database engine and configuration, enabling a lift-and-shift migration with minimal rearchitecture. This approach avoids the need to rewrite application code or adapt to a different database schema.

Exam trap

The trap here is that candidates may confuse Azure Database Migration Service (a migration tool) with a managed database service, or assume that any database can be migrated to a PaaS offering like Azure SQL Database, ignoring the proprietary database constraint.

How to eliminate wrong answers

Option B is wrong because Azure Database for MySQL is a managed PaaS service for MySQL databases only, and it cannot run a proprietary database engine. Option C is wrong because Azure Database Migration Service is a tool for migrating supported databases (e.g., SQL Server, MySQL, PostgreSQL) to Azure PaaS services, not a managed database service itself. Option D is wrong because Azure SQL Database is a managed relational database service that supports only Microsoft SQL Server and its variants, not a proprietary database.

Full explanation →

547

MCQhard

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

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

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

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

D.The function does not handle poison messages correctly.

AnswerC

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

548

MCQmedium

An application publishes order events that multiple independent subscribers must process. Subscribers may be added later without changing the publisher. Which Azure messaging service should be used? The team wants the control to be enforceable during normal operations.

A.Azure Blob Storage lifecycle policy

B.Azure Storage Queue

C.Azure Cache for Redis list only

D.Azure Service Bus topic

AnswerD

Azure Service Bus Topics are purpose-built for enterprise-grade asynchronous messaging, specifically implementing the publish-subscribe pattern. Publishers send messages to a topic, and multiple independent applications can each create their own distinct subscriptions to that topic. Each subscription receives a copy of the messages published to the topic, enabling diverse consumers to process the same event concurrently and independently. This service provides robust features like message filtering, dead-lettering, and guaranteed delivery, making it ideal for distributing events to multiple systems.

Why this answer

Azure Service Bus topics support a publish/subscribe pattern where multiple independent subscribers can each receive a copy of every published message. Subscribers can be added later without modifying the publisher, and the team can enforce control during normal operations using topic-level authorization rules and subscription filters.

Exam trap

The trap here is that candidates often confuse Azure Storage Queue (point-to-point) with Service Bus topics (pub/sub), missing the requirement for multiple independent subscribers that can be added later without changing the publisher.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage lifecycle policies automate tiering or deletion of blobs based on age, not message delivery to multiple subscribers. Option B is wrong because Azure Storage Queue implements a point-to-point messaging model where each message is consumed by a single consumer, not broadcast to multiple independent subscribers. Option C is wrong because Azure Cache for Redis list only provides a simple list data structure for ordered storage, not a managed pub/sub messaging system with durable delivery and subscriber management.

Full explanation →

549

MCQhard

A Blob-triggered function processing audit documents fires multiple times for the same blob after retries. What should the function design include?

A.Disable all logging

B.Idempotent processing based on blob name/version or metadata

C.Assume each event is delivered exactly once

D.Use public blob access

AnswerB

Implementing idempotent processing is crucial for blob-triggered functions, as it ensures that processing the same blob multiple times yields the same result without causing unintended side effects. By using the blob's unique name, ETag (version), or custom metadata as a key, the function can check if the document has already been processed successfully before performing any state-changing operations. This pattern effectively handles the "at-least-once" delivery guarantee inherent in many event-driven systems, preventing data corruption or redundant actions.

Why this answer

Azure Blob Storage triggers can cause multiple function invocations for the same blob due to retries, internal queue processing, or event-driven architecture guarantees. Designing the function to be idempotent—using the blob name, version, or metadata as a unique identifier—ensures that duplicate processing does not produce side effects like duplicate audit records or data corruption. This aligns with the at-least-once delivery semantics of Azure Blob Storage triggers.

Exam trap

The trap here is that candidates assume Azure Blob Storage triggers guarantee exactly-once delivery, similar to some queue-based triggers, but they actually follow at-least-once semantics, making idempotency essential for correct processing.

How to eliminate wrong answers

Option A is wrong because disabling logging does not prevent duplicate invocations; it only hides the evidence of retries, violating observability and debugging best practices. Option C is wrong because Azure Blob Storage triggers do not guarantee exactly-once delivery; they operate with at-least-once semantics, meaning the same blob can trigger the function multiple times due to retries or internal queue delays. Option D is wrong because public blob access does not affect invocation behavior; it only controls anonymous read access and introduces security risks without addressing duplicate processing.

Full explanation →

550

MCQeasy

Refer to the exhibit. You created a custom RBAC role definition. A user assigned this role at the subscription scope. What can the user do?

A.Read any resource in the subscription

B.Write to Azure SQL Databases

C.Read Azure SQL Database configurations and data

D.Create new Azure SQL Databases

AnswerC

This custom RBAC role is designed to provide read-only access to Azure SQL Databases. This typically includes actions like "Microsoft.Sql/servers/databases/read" for general database properties, "Microsoft.Sql/servers/databases/metrics/read" for performance data, and potentially "Microsoft.Sql/servers/databases/transparentDataEncryption/read" for security settings. Such permissions allow users to view database configurations, monitor performance, and query data without the ability to modify the database or its underlying infrastructure.

Why this answer

The custom RBAC role definition includes the 'Microsoft.Sql/servers/databases/read' action, which grants read access to Azure SQL Database configurations and data at the subscription scope. This action allows the user to view database settings and query data, but does not permit write or create operations.

Exam trap

The trap here is that candidates often assume a 'read' action at the subscription scope implies read access to all resource types, but RBAC requires explicit action definitions for each resource provider, and Azure SQL Database read permissions are specific to the 'Microsoft.Sql' namespace.

How to eliminate wrong answers

Option A is wrong because the role only includes specific read actions for SQL and other resources, not a wildcard like '*/read' that would allow reading any resource in the subscription. Option B is wrong because the role lacks write actions such as 'Microsoft.Sql/servers/databases/write' or 'Microsoft.Sql/servers/databases/data/write' for Azure SQL Databases. Option D is wrong because creating new Azure SQL Databases requires the 'Microsoft.Sql/servers/databases/write' action, which is not included in the role definition.

Full explanation →

551

MCQhard

A company uses Azure Service Bus to receive order messages. Each order message must be processed exactly once, and duplicate messages are not tolerated due to financial transactions. However, the order processing system sometimes fails and retries, leading to potential duplicates. What Service Bus feature should be enabled on the message to support idempotent processing?

A.Scheduled delivery

B.Duplicate detection

C.Message sessions

D.Auto-forwarding

AnswerB

Azure Service Bus duplicate detection leverages a configurable history window to track MessageId values of all messages sent to a queue or topic. When a new message arrives with a MessageId that matches one within the detection window, Service Bus automatically discards the duplicate, ensuring that each message is processed exactly once by the consuming application. This feature is crucial for idempotent message processing, preventing unintended side effects from retries or network issues.

Why this answer

B is correct because Azure Service Bus's duplicate detection feature uses a user-defined MessageId to identify and discard duplicate messages within a specified time window (default 10 minutes, configurable up to 7 days). This ensures exactly-once processing by preventing the same order message from being processed multiple times, even if the sender retries due to failures.

Exam trap

The trap here is that candidates often confuse message sessions (which guarantee order and grouping) with duplicate detection, but sessions do not prevent duplicates—they only ensure FIFO delivery within a session.

How to eliminate wrong answers

Option A is wrong because scheduled delivery delays message availability until a specified time, which does not prevent duplicate processing. Option C is wrong because message sessions enable ordered processing and grouping of related messages, but they do not inherently detect or discard duplicates. Option D is wrong because auto-forwarding automatically moves messages from one queue or subscription to another, which does not provide any duplicate detection or idempotency guarantee.

Full explanation →

552

MCQmedium

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

A.Blob trigger + Consumption plan

B.HTTP trigger + Consumption plan

C.Queue trigger + Consumption plan

D.Timer trigger + Consumption plan

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

553

MCQmedium

You are developing an Azure Function that processes messages from an Azure Service Bus queue. The function must use a managed identity to authenticate to the Service Bus to avoid managing secrets. Which configuration step is essential for this setup?

A.Store the Service Bus connection string in the function app settings

B.Create a Key Vault reference to the connection string

C.Enable system-assigned managed identity on the function app and assign the 'Azure Service Bus Data Receiver' role to the identity

D.Use the Service Bus SDK with a SharedAccessSignatureToken

AnswerC

Enabling a system-assigned managed identity on the function app and assigning the 'Azure Service Bus Data Receiver' role is the most secure and recommended approach. This method allows the Azure Function to authenticate directly with Azure Active Directory (Azure AD) and subsequently authorize against Azure Service Bus without needing any connection strings, keys, or secrets stored within the function app or Key Vault. Azure automatically manages the identity's lifecycle, eliminating the burden of credential management and rotation for developers.

Why this answer

Using a managed identity eliminates the need to manage secrets or connection strings. By enabling a system-assigned managed identity on the function app and assigning the 'Azure Service Bus Data Receiver' role to that identity, the function can authenticate to Azure Service Bus via Azure AD (OAuth 2.0) without any stored credentials. This is the recommended approach for secure, secretless authentication in Azure Functions.

Exam trap

The trap here is that candidates often think storing secrets in Key Vault (Option B) is sufficient for secretless authentication, but Key Vault references still involve retrieving a secret at runtime, whereas managed identity completely removes the need for any secret.

How to eliminate wrong answers

Option A is wrong because storing the Service Bus connection string in function app settings reintroduces a secret that must be managed and rotated, defeating the purpose of using a managed identity for secretless authentication. Option B is wrong because a Key Vault reference still requires the function app to retrieve a connection string (a secret) at runtime, which does not eliminate secret management and adds dependency on Key Vault access policies. Option D is wrong because using a SharedAccessSignatureToken requires generating and managing a SAS token, which is a secret that must be stored and rotated, again contradicting the goal of avoiding secret management.

Full explanation →

554

MCQmedium

You are monitoring an e-commerce application with Application Insights. You need to analyze all exceptions that occurred in the last 24 hours, grouped by the exception type. You also need to include the URL where each exception was triggered and the number of times each type occurred. Which Log Analytics Kusto query should you use?

A.exceptions | where timestamp > ago(24h) | join kind=inner requests on operation_Id | extend exceptionType = tostring(innermostType) | summarize Count=count() by exceptionType, url

B.exceptions | where timestamp > ago(24h) | extend exceptionType = tostring(customDimensions.['ExceptionType']) | summarize Count=count() by exceptionType, url = tostring(customDimensions.['Url'])

C.requests | where timestamp > ago(24h) and success == false | extend exceptionType = tostring(resultCode) | summarize Count=count() by exceptionType, url

D.exceptions | where timestamp > ago(24h) | extend exceptionType = tostring(innermostType) | summarize Count=count() by exceptionType

AnswerA

This query joins the exceptions table with the requests table on operation_Id to get the URL (from requests table), then groups by exceptionType (innermostType) and url, counting occurrences.

Why this answer

It uses the `exceptions` table to filter exceptions from the last 24 hours, joins with the `requests` table on `operation_Id` to correlate each exception with the request URL, and then summarizes the count by exception type (extracted from `innermostType`) and URL. This meets all requirements: grouping by exception type, including the URL, and counting occurrences.

Exam trap

The trap here is that candidates might think exception details (like type and URL) are stored directly in the `exceptions` table, but the URL is only available via a join with the `requests` table, and the exception type is in `innermostType`, not custom dimensions.

How to eliminate wrong answers

Option B is wrong because it attempts to extract exception type and URL from `customDimensions`, but the standard Application Insights schema stores the exception type in `innermostType` (or `type`) and the request URL in the `requests` table, not in custom dimensions. Option C is wrong because it queries the `requests` table for failed requests (success == false) and uses `resultCode` as the exception type, which only gives HTTP status codes (e.g., 500) rather than actual exception types (e.g., NullReferenceException). Option D is wrong because it summarizes by exception type only, omitting the URL column that the question explicitly requires.

Full explanation →

555

MCQeasy

The team needs to receive an email when an App Service's HTTP 5xx error rate exceeds 5 percent for more than five consecutive minutes. No custom code should be written. What combination of Azure Monitor features implements this requirement?

A.Create a metric alert on the Http5xxErrors metric with a 5-percent threshold, a 5-minute evaluation window, and an action group that sends email

B.Create a log alert that queries the App Service diagnostic log table every 5 minutes and emails the team if the 5xx count exceeds a threshold

C.Enable Application Insights availability tests and configure an alert on test failure rate

D.Configure a diagnostic setting to stream logs to Azure Storage, then write a Function that reads the storage file and sends email when errors are found

AnswerB

A log alert querying every five minutes evaluates conditions within that specific interval, not sustained breaches over consecutive periods. This fails the "more than five consecutive minutes" requirement, which demands a stateful evaluation over time. Log alerts are suitable for detecting specific event patterns or simple aggregate counts in logs within a single evaluation window, making them tempting for error detection. They would be correct if the requirement was to alert on a 5xx rate exceeding a threshold in any given five-minute period, without needing to track consecutive violations.

Why this answer

The explanation incorrectly states that a 5% threshold on the 'Http5xxErrors' metric can directly represent a 5% error rate. This metric is a count, and standard metric alerts do not provide a built-in mechanism to calculate its percentage relative to total requests. To achieve the required 'rate' calculation, a log alert with a Kusto Query Language (KQL) query is necessary to compute the ratio of 5xx errors to total requests over the specified time window.

KQL queries within log alerts are considered configuration, not custom code, thus meeting all requirements.

Exam trap

The trap here is that candidates often confuse metric alerts (which work on platform metrics like Http5xxErrors) with log alerts (which require querying diagnostic logs), or mistakenly think Application Insights availability tests are the correct tool for server-side error monitoring.

How to eliminate wrong answers

Option B is wrong because log alerts query diagnostic logs, which are not real-time and incur additional ingestion costs; they also require custom KQL queries and are not as straightforward as metric alerts for simple threshold-based monitoring. Option C is wrong because Application Insights availability tests measure endpoint responsiveness (e.g., HTTP 200/404) and failure rates, not server-side HTTP 5xx errors from App Service; they are designed for synthetic transaction monitoring, not server error rate alerts. Option D is wrong because it requires writing a custom Azure Function to read storage blobs and send emails, violating the 'no custom code' requirement; it also introduces unnecessary complexity and latency compared to built-in metric alerts.

Full explanation →

556

MCQhard

You develop an IoT solution using Azure IoT Hub. Devices send telemetry data that must be processed by a custom Azure Function. You need to ensure that the Function processes messages in order per device and exactly once. Which IoT Hub feature should you use?

A.Use IoT Hub message routing to send messages to a Service Bus queue, and process from the queue.

B.Use IoT Hub direct methods to invoke the Function per device.

C.Use IoT Hub device twins to store telemetry and trigger the Function on twin changes.

D.Use IoT Hub's built-in Event Hub-compatible endpoint with a consumer group that has one partition per device.

AnswerD

IoT Hub's built-in endpoint is fully compatible with Azure Event Hubs, making it the ideal choice for high-throughput telemetry ingestion. By configuring devices to use their Device ID as the partition key, all messages from a specific device are guaranteed to be routed to the same Event Hub partition. This ensures message ordering *per device* within that partition, and processing with a dedicated consumer group per partition allows for scalable, ordered, and at-least-once delivery, with idempotent processing achieving exactly-once semantics.

Why this answer

IoT Hub's built-in Event Hub-compatible endpoint supports partitioning, and by using a consumer group with one partition per device, you can guarantee per-device ordering and exactly-once processing. The Event Hub model ensures that messages from the same device (same partition key) are delivered in order and can be checkpointed to avoid duplicates.

Exam trap

The trap here is that candidates often confuse IoT Hub's message routing (which can send to multiple endpoints) with the built-in Event Hub-compatible endpoint, not realizing that only the latter provides the partition-based ordering and checkpointing needed for per-device exactly-once processing.

How to eliminate wrong answers

Option A is wrong because IoT Hub message routing to a Service Bus queue does not guarantee per-device ordering across multiple partitions, and Service Bus queues do not natively support partition-based ordering per device without additional complexity. Option B is wrong because direct methods are synchronous request-reply operations for immediate device commands, not designed for processing telemetry streams with ordering and exactly-once guarantees. Option C is wrong because device twins are for state synchronization and desired/reported properties, not for telemetry streaming; triggering a function on twin changes does not provide ordered, exactly-once message processing.

Full explanation →

557

MCQhard

You are using Azure File Sync to sync on-premises file shares to Azure. You need to ensure that files are cached locally on the on-premises server for fast access, but only the most frequently accessed files should be cached. What should you configure?

A.Configure a caching rule using Azure File Sync's built-in cache size limit.

B.Configure a sync group with a custom server endpoint that filters files by last access time.

C.Enable cloud tiering on the server endpoint and set a volume free space policy.

D.Use the Invoke-AzStorageSyncFileRecall cmdlet to recall files on demand.

AnswerC

Enabling cloud tiering on the server endpoint and configuring a volume free space policy is the correct method to automatically manage the local cache. Cloud tiering intelligently moves infrequently accessed files to Azure Files, replacing them with reparse points (tiering stubs) locally. The volume free space policy ensures that a specified percentage of the local volume remains free, automatically recalling files as needed and tiering others to maintain the desired free space, effectively managing the local cache based on disk capacity and access patterns.

Why this answer

Cloud tiering on an Azure File Sync server endpoint allows you to keep only frequently accessed files cached locally while infrequently accessed files are tiered to Azure. By setting a volume free space policy, you control how much local disk space is reserved for frequently accessed files, ensuring that only the most accessed files remain cached. This directly meets the requirement of caching only the most frequently accessed files locally.

Exam trap

The trap here is that candidates often confuse cloud tiering with manual recall or think they can filter files by access time via sync group settings, but Azure File Sync's cloud tiering is the only built-in mechanism that automatically manages local caching based on access frequency.

How to eliminate wrong answers

Option A is wrong because Azure File Sync does not have a built-in 'caching rule' with a cache size limit; the correct mechanism is cloud tiering with a volume free space policy or date policy. Option B is wrong because sync groups and server endpoints do not filter files by last access time; cloud tiering uses last access time to determine which files to tier, but you cannot configure a custom filter on the server endpoint itself. Option D is wrong because Invoke-AzStorageSyncFileRecall is used to manually recall all tiered files to local storage, which would cache all files, not just the most frequently accessed ones, and is not a configuration for ongoing caching behavior.

Full explanation →

558

MCQhard

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

A.Stream the blob content directly to the processing logic

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

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

D.Increase the memory allocation of the function app

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

559

MCQhard

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

A.Azure Stream Analytics

B.Azure Data Factory

C.Azure Analysis Services

D.Azure Logic Apps

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

560

MCQmedium

An application calls a Service Bus topic through HTTP. The developer must implement retries without overwhelming the remote system during partial outages. Which retry pattern is best?

A.Disable all timeout settings

B.Immediate infinite retries

C.Retry only after restarting the application

D.Exponential backoff with jitter and a maximum retry limit

AnswerD

Backoff with jitter reduces retry storms and gives the remote service time to recover.

Why this answer

Exponential backoff with jitter and a maximum retry limit is the best pattern because it progressively increases the delay between retries, preventing the client from overwhelming the Service Bus topic during partial outages. The jitter randomizes the delay to avoid thundering herd problems, while the maximum retry limit ensures the system doesn't retry indefinitely, aligning with Azure's recommended retry guidance for HTTP-based calls to Service Bus.

Exam trap

The trap here is that candidates may confuse 'exponential backoff' with 'immediate retries' or 'infinite retries,' overlooking the critical need for jitter and a maximum retry limit to prevent overwhelming the remote system during partial outages.

How to eliminate wrong answers

Option A is wrong because disabling all timeout settings would cause the application to hang indefinitely on a single request, failing to handle partial outages and potentially exhausting resources. Option B is wrong because immediate infinite retries would flood the Service Bus topic with repeated requests during an outage, exacerbating the load and violating the principle of not overwhelming the remote system. Option C is wrong because retrying only after restarting the application introduces unnecessary downtime and delays recovery, as it doesn't leverage transient fault handling within the same application session.

Full explanation →

561

MCQhard

You have an Azure Storage account with hierarchical namespace enabled (Azure Data Lake Storage Gen2). You need to provide an application with delegated access to a specific directory and its contents, with the ability to list, read, and write files. The access must be scoped to the directory and not allow access to other parts of the storage account. Which approach should you use?

A.Generate a shared access signature (SAS) token for the directory.

B.Assign the 'Storage Blob Data Contributor' RBAC role to the application at the storage account level.

C.Configure access control lists (ACLs) on the directory and assign the application's managed identity.

D.Use the storage account access key in the application.

AnswerC

ACLs allow granular permissions scoped to the directory, and managed identities can be used for authentication.

Why this answer

Azure Data Lake Storage Gen2 supports POSIX-like access control lists (ACLs) that can grant granular permissions to a specific directory and its contents. By configuring ACLs on the target directory and assigning the application's managed identity, you can precisely scope list, read, and write access to that directory without affecting other parts of the storage account. This approach avoids the need for account-level keys or RBAC roles, which would grant broader permissions.

Exam trap

The trap here is that candidates often confuse RBAC roles (which are coarse-grained and account/container-wide) with ACLs (which are fine-grained and directory/file-specific), leading them to choose Option B or A when the requirement is strict directory-level scoping.

How to eliminate wrong answers

Option A is wrong because a shared access signature (SAS) token for a directory can only delegate access at the container or directory level, but it cannot enforce fine-grained POSIX-style permissions (e.g., separate read/write/execute) and is typically scoped to the entire container or a path prefix, not a specific directory with ACL-level control. Option B is wrong because assigning the 'Storage Blob Data Contributor' RBAC role at the storage account level grants permissions to all containers and directories in the account, violating the requirement to scope access to a single directory. Option D is wrong because using the storage account access key provides full administrative access to the entire storage account, including all data and management operations, which is far too broad and insecure for delegated directory-level access.

Full explanation →

562

MCQmedium

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

A.Secure environment variable

B.Container command-line argument

C.Public blob containing the password

D.Plain environment variable

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

563

MCQmedium

Your Azure Logic App needs to send emails using Microsoft Graph API on behalf of the signed-in user. The user is authenticated with Microsoft Entra ID. Which authentication method should you use in the Logic App?

A.Use OAuth 2.0 authorization code flow with delegated permissions

B.Use a system-assigned managed identity

C.Use client credentials flow with an app registration

D.Use Basic authentication with user credentials

AnswerA

The OAuth 2.0 authorization code flow with delegated permissions is the correct choice because it enables the Logic App to act on behalf of a specific signed-in user. This flow involves the user consenting to the application accessing their resources, granting the Logic App temporary, user-scoped permissions to send emails as that user via Microsoft Graph. It ensures that the email appears to originate from the user's mailbox, respecting their identity and permissions.

Why this answer

The OAuth 2.0 authorization code flow with delegated permissions is correct because the Logic App needs to act on behalf of the signed-in user, not as an application itself. This flow allows the user to authenticate via Microsoft Entra ID and grant the Logic App delegated permissions to call Microsoft Graph API (e.g., to send emails as the user). The authorization code is exchanged for an access token that includes the user's context, enabling the API to enforce user-level permissions.

Exam trap

The trap here is that candidates often confuse delegated permissions (user context) with application permissions (app-only context), leading them to choose client credentials flow (Option C) or managed identity (Option B) when the requirement explicitly says 'on behalf of the signed-in user'.

How to eliminate wrong answers

Option B is wrong because a system-assigned managed identity is used for application-level authentication (client credentials flow) and cannot act on behalf of a signed-in user; it represents the Logic App itself, not the user. Option C is wrong because the client credentials flow is designed for server-to-server scenarios without a user context, so it cannot send emails on behalf of a specific signed-in user. Option D is wrong because Basic authentication with user credentials is deprecated and insecure, and Microsoft Graph API does not support Basic authentication; it requires OAuth 2.0 tokens.

Full explanation →

564

MCQmedium

A developer needs to grant an Azure Function read access to secrets in Azure Key Vault without storing any credentials in the function code or configuration. Which approach should they use?

A.Service principal with a certificate

B.Managed identity

C.Access policy with a client secret

D.Shared access signature (SAS)

AnswerB

Managed identity is the optimal solution as it completely eliminates the need for developers to manage any credentials for their Azure Function. Azure automatically provisions and manages an identity in Azure Active Directory for the Function App. This identity can then be granted specific access policies or RBAC roles on the Azure Key Vault, allowing the Function to securely obtain tokens and access secrets without storing any secrets, certificates, or connection strings within the application code or configuration.

Why this answer

Managed identity (B) is the correct approach because it allows the Azure Function to authenticate to Azure Key Vault without storing any credentials in code or configuration. Azure automatically manages the identity, and the function can obtain an access token from Azure AD to read secrets, eliminating the need for secrets, certificates, or keys in the application.

Exam trap

The trap here is that candidates may confuse managed identity with a service principal, thinking a certificate or client secret is always required, but managed identity eliminates the need for any stored credentials by leveraging Azure's automatic identity management.

How to eliminate wrong answers

Option A is wrong because a service principal with a certificate still requires the certificate to be stored or deployed with the function code or configuration, which violates the requirement of not storing any credentials. Option C is wrong because an access policy with a client secret requires the client secret to be stored in the function's configuration or code, directly contradicting the no-credentials requirement. Option D is wrong because a shared access signature (SAS) is used for granting delegated access to Azure Storage resources, not for authenticating to Azure Key Vault, and it would still need to be stored in the function.

Full explanation →

565

MCQmedium

A developer needs to run a Kusto query against application request data to identify 95th percentile latency by operation. Where should the query be run? The design must avoid adding custom operational scripts.

A.Logs in Application Insights or the associated Log Analytics workspace

B.Microsoft Entra audit logs

C.Azure Key Vault diagnostic settings

D.Azure Resource Graph only

AnswerA

Logs in Application Insights, or its integrated Log Analytics workspace, are the definitive source for application request data. Application Insights automatically collects comprehensive telemetry, including details about incoming HTTP requests, such as their duration, success status, and URL. This data is stored in dedicated tables, like `requests`, within the Log Analytics workspace, enabling powerful analysis using Kusto Query Language (KQL) to identify performance trends and troubleshoot issues.

Why this answer

Application Insights and its associated Log Analytics workspace store application request data and support Kusto Query Language (KQL) queries. Running a Kusto query against the `requests` table in the Logs workspace allows you to calculate percentile latency (e.g., using the `percentiles()` function) without custom operational scripts, as this is a built-in capability.

Exam trap

The trap here is that candidates may confuse Azure Resource Graph (which queries resource metadata) with Log Analytics (which queries telemetry data), leading them to choose Option D despite its inability to handle application performance queries.

How to eliminate wrong answers

Option B is wrong because Microsoft Entra audit logs contain sign-in and directory activity, not application request latency data. Option C is wrong because Azure Key Vault diagnostic settings capture vault access and management events, not application request performance metrics. Option D is wrong because Azure Resource Graph is designed for querying Azure resource inventory and configuration across subscriptions, not for analyzing application telemetry like request latency.

Full explanation →

566

MCQeasy

You have an Azure Function app that needs to retrieve a secret from Azure Key Vault at runtime. You want to avoid storing any credentials in code or configuration. Which mechanism should you use?

A.Service principal with client secret

B.Managed identity

C.Access key

D.Shared access signature (SAS)

AnswerB

Managed identities provide an automatically managed identity in Azure Active Directory for Azure services, including Function Apps. When enabled, the Function App can obtain an Azure AD token from the Azure Instance Metadata Service (IMDS) endpoint, which it then uses to authenticate to other Azure services like Azure Key Vault. This eliminates the need for developers to manage any credentials, as Azure handles the lifecycle of the identity and its authentication to Azure AD, making it the most secure and recommended approach for service-to-service authentication.

Why this answer

Managed identity (B) is the correct mechanism because it allows the Azure Function app to authenticate to Azure Key Vault without storing any credentials in code or configuration. Azure automatically manages the identity and provides a token from Azure AD that the function can use to access the vault, eliminating the need for secrets or keys in the application.

Exam trap

The trap here is that candidates may confuse managed identity with a service principal, thinking a client secret is required, or incorrectly assume that an access key or SAS can be used for Key Vault authentication.

How to eliminate wrong answers

Option A is wrong because a service principal with client secret requires storing the client secret in code or configuration, which violates the requirement to avoid storing credentials. Option C is wrong because an access key is used for authenticating to Azure Functions itself, not for retrieving secrets from Key Vault. Option D is wrong because a shared access signature (SAS) is a token for granting limited access to Azure Storage resources, not for authenticating to Key Vault.

Full explanation →

567

MCQmedium

An application needs to upload large thumbnail metadata to Blob Storage reliably over unstable networks. Which upload approach should be used?

A.Block blob staged block upload with commit

B.Page blob only

C.Append blob only

D.Table Storage batch operation

AnswerA

Block blobs are the standard for storing general-purpose large binary objects, and their staged block upload mechanism is specifically designed for reliable and efficient handling of large files. This process involves uploading individual blocks of data independently using 'Put Block', which can be done in parallel and retried if necessary, before finally committing the entire blob using 'Put Block List'. This method ensures data integrity, supports resumable uploads, and optimizes performance for large file transfers like thumbnail metadata, making it the most suitable choice.

Why this answer

Block blob staged block upload with commit is the correct approach because it allows uploading large thumbnails in smaller, independent blocks that can be retried individually if a network failure occurs. This method uses the Put Block and Put Block List REST APIs, enabling reliable uploads over unstable networks by committing only successfully uploaded blocks. It is specifically designed for large files and provides fine-grained control over upload progress and error recovery.

Exam trap

The trap here is that candidates may confuse blob types (block, page, append) and choose page blobs due to their 'reliability' reputation for VHDs, but fail to recognize that block blobs are the correct choice for large file uploads with retry logic over unstable networks.

How to eliminate wrong answers

Option B (Page blob only) is wrong because page blobs are optimized for random read/write operations (like VHD disks), not for uploading large sequential data like thumbnails, and they lack the staged block upload mechanism for reliable transfer over unstable networks. Option C (Append blob only) is wrong because append blobs are designed for append-only operations (e.g., logging), not for uploading large files with retry capability; they do not support staged block uploads. Option D (Table Storage batch operation) is wrong because Table Storage is for structured NoSQL data (entities), not for binary large objects like thumbnails, and batch operations are for transactional entity updates, not file uploads.

Full explanation →

568

MCQeasy

Your company uses Azure API Management to expose APIs to external partners. You need to enforce throttling limits per subscription key. Which policy should you add?

A.rate-limit by key policy with @(context.Subscription.Id) as counter key

B.rate-limit policy with IP address filtering

C.rate-limit by key policy with no counter key

D.validate-jwt policy with claims check

AnswerA

The `rate-limit by key` policy in Azure API Management is the correct choice for applying throttling based on specific caller identifiers. By using `@(context.Subscription.Id)` as the counter key, the policy effectively tracks and limits the number of requests originating from each unique API subscription. This ensures that each subscriber adheres to their allocated quota, preventing any single subscription from monopolizing API resources and maintaining service stability.

Why this answer

The `rate-limit by key` policy in Azure API Management allows you to enforce throttling limits based on a specific counter key. Using `@(context.Subscription.Id)` as the counter key ensures that each subscription key is tracked individually, enabling per-subscription throttling as required.

Exam trap

The trap here is confusing the `rate-limit` policy (global) with `rate-limit by key` (scoped), leading candidates to pick Option B without realizing it lacks the per-subscription granularity required by the question.

How to eliminate wrong answers

Option B is wrong because the `rate-limit` policy without a key applies a global rate limit to all requests, not per subscription key, and IP address filtering is unrelated to subscription-based throttling. Option C is wrong because omitting the counter key in `rate-limit by key` would cause the policy to fail or apply a default behavior, not enforce per-subscription limits. Option D is wrong because `validate-jwt` is used for token validation and claims checking, not for throttling or rate limiting.

Full explanation →

569

Multi-Selecthard

A function consumes messages from Azure Service Bus. Which two settings help handle transient failures safely?

Select 2 answers

A.Configure max delivery count with a dead-letter queue

B.Make message processing idempotent

C.Disable lock renewal for long processing

D.Use anonymous sender access

AnswersA, B

Dead-lettering isolates messages after repeated delivery failures.

Why this answer

Configuring max delivery count with a dead-letter queue is correct because it allows the function to handle transient failures safely by automatically moving messages that exceed the maximum number of delivery attempts to a dead-letter queue. This prevents infinite retries and ensures that problematic messages are isolated for manual inspection, while the function can continue processing other messages without blocking. The max delivery count setting in Azure Service Bus controls how many times a message is delivered before being dead-lettered, which is essential for managing transient failures without losing data.

Exam trap

The trap is that candidates often think idempotent processing is about preventing duplicate messages from the Service Bus side, but it actually ensures safe handling of transient failures on the consumer side. They may also mistakenly believe that disabling lock renewal is a valid transient failure strategy.

Full explanation →

570

MCQmedium

You are using Application Insights to monitor a web app. You want to automatically analyze and alert on sudden increases in request failure rates, without manually setting static thresholds. Which Application Insights feature should you use?

A.Smart Detection

B.Application Insights Profiler

C.Live Metrics Stream

D.Continuous Export

AnswerA

Azure Application Insights Smart Detection leverages machine learning algorithms to automatically identify and alert on unusual patterns in your web app's telemetry, such as sudden increases in failure rates, performance degradation, or memory leaks. It proactively analyzes incoming data without requiring manual configuration of thresholds, providing immediate insights into critical operational issues. This intelligent capability helps teams quickly pinpoint and address problems before they significantly impact users, enhancing overall application reliability.

Why this answer

Smart Detection in Application Insights automatically analyzes telemetry from your web app to detect anomalies, such as sudden increases in request failure rates, without requiring manual static thresholds. It uses machine learning models to adapt to your app's normal behavior and alert on deviations, making it ideal for dynamic monitoring scenarios.

Exam trap

The trap here is that candidates often confuse Live Metrics Stream (real-time but no analysis) with Smart Detection (which provides automatic anomaly detection and alerting), leading them to choose the wrong option for failure rate analysis.

How to eliminate wrong answers

Option B (Application Insights Profiler) is wrong because it is designed for performance profiling and tracing slow requests, not for analyzing failure rates or setting alerts. Option C (Live Metrics Stream) is wrong because it provides real-time monitoring of metrics but does not include automatic anomaly detection or alerting on failure rate changes. Option D (Continuous Export) is wrong because it exports telemetry data to storage for long-term analysis, but it does not analyze data or generate alerts for sudden failure rate increases.

Full explanation →

571

MCQmedium

You are building an event-driven solution that processes orders from an Azure Storage Queue. Each order triggers an Azure Function. To improve reliability, you need to automatically retry processing if an exception occurs, but only up to 3 times. You must also preserve the original order message in a poison queue after max retries. Which configuration should you use in the function's host.json?

A.Set 'prefetchCount' to 3

B.Set 'newBatchThreshold' to 3

C.Set 'maxDequeueCount' to 3

D.Set 'batchSize' to 3

AnswerC

The 'maxDequeueCount' is a critical property of an Azure Storage Queue message that directly governs its retry mechanism and eventual dead-lettering. Each time a message is retrieved from the queue, its 'DequeueCount' property increments. If message processing fails and the message is not deleted within its visibility timeout, it becomes visible again, and its 'DequeueCount' further increases upon subsequent retrieval. Once this 'DequeueCount' reaches the 'maxDequeueCount' value (e.g., 3 in this scenario), the Azure Storage Queue service automatically moves the message to a designated poison message queue, preventing infinite retries and allowing for manual inspection.

Why this answer

The 'maxDequeueCount' setting in the host.json for an Azure Storage Queue-triggered function controls the number of times a message is dequeued for processing before it is moved to the poison queue. Setting it to 3 ensures that after three failed processing attempts (due to exceptions), the message is automatically redirected to the poison queue, preserving the original message for later inspection.

Exam trap

The trap here is that candidates often confuse 'maxDequeueCount' with 'batchSize' or 'prefetchCount', thinking they control retries, when in fact they control concurrency and throughput, not poison queue behavior.

How to eliminate wrong answers

Option A is wrong because 'prefetchCount' controls how many messages are fetched ahead of time to improve throughput, not retry or poison queue behavior. Option B is wrong because 'newBatchThreshold' is used with Service Bus triggers to control when a new batch is fetched, not with Storage Queue triggers. Option D is wrong because 'batchSize' determines the maximum number of messages processed simultaneously, not the retry count or poison queue handling.

Full explanation →

572

MCQmedium

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

A.Service Bus trigger with Table storage output binding

B.Blob trigger with Cosmos DB output binding

C.HTTP trigger with Cosmos DB input binding

D.Service Bus trigger with Cosmos DB output binding

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

573

MCQhard

A single-page app signs in users with Microsoft Entra ID and calls a protected API. The app cannot safely keep a client secret. Which OAuth flow should be used? The team wants the control to be enforceable during normal operations.

A.Implicit flow

B.Client credentials flow

C.Resource owner password credentials flow

D.Authorization code flow with PKCE

AnswerD

PKCE protects public clients that cannot store secrets and is recommended for SPAs.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth flow for single-page apps because it prevents the client secret from being exposed by using a dynamically generated code verifier and challenge. This flow ensures that even if the authorization code is intercepted, it cannot be exchanged for tokens without the original code verifier, making it secure for public clients that cannot safely store secrets.

Exam trap

The trap here is that candidates often confuse the deprecated implicit flow (Option A) with the authorization code flow with PKCE, mistakenly thinking the implicit flow is still acceptable for SPAs, but Microsoft and OAuth standards now mandate PKCE for all public clients.

How to eliminate wrong answers

Option A is wrong because the implicit flow was deprecated by OAuth 2.0 Security Best Current Practice (BCP) due to security risks like access token leakage in the URL fragment and lack of token binding; it should not be used for new applications. Option B is wrong because the client credentials flow is designed for server-to-server (confidential client) scenarios where the app authenticates with its own credentials, not for user authentication in a single-page app. Option C is wrong because the resource owner password credentials flow requires the user to provide their username and password directly to the app, which violates security best practices and is not suitable for modern single-page apps that delegate authentication to Microsoft Entra ID.

Full explanation →

574

MCQmedium

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

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

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

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

D.The connection string does not use HTTPS.

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

575

MCQmedium

You are developing an Azure Function that reads secrets from Azure Key Vault. The function must not use any static credentials in configuration files. You need to authenticate to Key Vault using the function's own identity. Which Azure service feature should you enable?

A.Use storage account access keys to authenticate to Key Vault

B.Assign a managed identity to the function app and grant it access to the Key Vault

C.Generate a shared access signature (SAS) token for the Key Vault

D.Create a service principal and store its certificate in the function app's local storage

AnswerB

Managed identities allow the function app to authenticate to Key Vault without any stored credentials. The identity is automatically managed by Microsoft Entra ID.

Why this answer

Azure Functions can use a system-assigned or user-assigned managed identity to authenticate to Azure Key Vault without storing any static credentials. When enabled, the function app obtains an Azure AD token from the Managed Identity endpoint (169.254.169.254) and uses it to access Key Vault secrets, eliminating the need for connection strings, keys, or certificates in configuration files.

Exam trap

The trap here is that candidates may confuse SAS tokens (which are for Storage) or service principals (which require manual certificate management) with the fully managed, credential-free authentication provided by managed identities.

How to eliminate wrong answers

Option A is wrong because storage account access keys are static credentials that must be stored in configuration files, violating the requirement to avoid static credentials, and they are used for Azure Storage, not for authenticating to Key Vault. Option C is wrong because shared access signature (SAS) tokens are used to delegate access to Azure Storage resources (blobs, queues, tables), not to authenticate to Key Vault; Key Vault uses Azure AD authentication or access policies, not SAS. Option D is wrong because creating a service principal and storing its certificate in the function app's local storage introduces a static credential (the certificate file) that must be managed and stored, contradicting the requirement to avoid static credentials; managed identities are the recommended approach for passwordless authentication.

Full explanation →

576

MCQmedium

A developer is configuring a web app to authenticate users with Microsoft Entra ID. The web app needs to call a downstream API that also uses Microsoft Entra ID for authentication. The developer must ensure that the web app can securely obtain access tokens for the downstream API. Which authentication flow should the developer implement?

A.OAuth 2.0 Client Credentials flow

B.OAuth 2.0 Implicit flow

C.OAuth 2.0 On-Behalf-Of flow

D.OAuth 2.0 Authorization Code flow

AnswerC

The OAuth 2.0 On-Behalf-Of (OBO) flow is precisely designed for multi-tier applications where a middle-tier service, such as a web app, needs to call a downstream API using the authenticated user's identity. The web app exchanges the initial access token (obtained during user authentication) for a new access token specifically scoped for the downstream API. This ensures that the downstream API receives a token representing the original user, allowing it to enforce user-specific permissions and maintain the user's context across service boundaries.

Why this answer

The OAuth 2.0 On-Behalf-Of (OBO) flow is the correct choice because the web app has already authenticated the user via Microsoft Entra ID and needs to exchange the user's access token for a new token to call the downstream API. This flow allows the web app to act on behalf of the authenticated user, maintaining the user's identity and consent context for the downstream API call.

Exam trap

The trap here is that candidates often confuse the On-Behalf-Of flow with the Authorization Code flow, not realizing that the Authorization Code flow only provides the initial user token and does not handle the downstream token exchange required for chained API calls.

How to eliminate wrong answers

Option A is wrong because the OAuth 2.0 Client Credentials flow is used for server-to-server authentication without a user context, which does not preserve the original user's identity for the downstream API. Option B is wrong because the OAuth 2.0 Implicit flow is deprecated and insecure for modern applications, as it returns tokens in the URL fragment and is not suitable for server-side web apps that need to call downstream APIs. Option D is wrong because the OAuth 2.0 Authorization Code flow is used to authenticate the user and obtain an initial access token for the web app, but it does not directly provide a mechanism to exchange that token for a downstream API token on behalf of the user.

Full explanation →

577

MCQmedium

An application publishes order events that multiple independent subscribers must process. Subscribers may be added later without changing the publisher. Which Azure messaging service should be used? The design must avoid adding custom operational scripts.

A.Azure Blob Storage lifecycle policy

B.Azure Storage Queue

C.Azure Cache for Redis list only

D.Azure Service Bus topic

AnswerD

Azure Service Bus Topics are specifically engineered for enterprise-grade publish-subscribe messaging scenarios, making them ideal for distributing order events to multiple independent applications. Publishers send messages to a topic, and each attached subscription receives a copy of the message, allowing for decoupled processing. This service provides advanced features like message filtering, durable message storage, and dead-lettering, ensuring reliable event distribution to all interested parties.

Why this answer

Azure Service Bus topics support a publish-subscribe pattern where multiple independent subscribers each receive a copy of every published message. This decouples the publisher from subscribers, allowing new subscribers to be added later without modifying the publisher. The built-in subscription entities eliminate the need for custom operational scripts.

Exam trap

The trap here is confusing a point-to-point queue (Storage Queue) with a publish-subscribe topic (Service Bus), where the requirement for multiple independent subscribers and future extensibility without scripts directly points to the topic's subscription model.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage lifecycle policies automate tiering or deletion of blobs based on age, not message delivery to multiple subscribers. Option B is wrong because Azure Storage Queues implement a point-to-point message queue where each message is consumed by a single worker, not broadcast to multiple independent subscribers. Option C is wrong because Azure Cache for Redis list only provides a simple list data structure; it lacks built-in publish-subscribe semantics and would require custom polling logic and scripts to distribute messages to multiple subscribers.

Full explanation →

578

MCQhard

You are designing a solution for a healthcare application that stores patient data in Azure Cosmos DB. The data must be encrypted at rest using a customer-managed key stored in Azure Key Vault. You need to ensure that the key can be rotated without downtime. Which approach should you recommend?

A.Configure Azure Security Center to automatically rotate the key.

B.After rotating the key in Key Vault, manually update the Cosmos DB account with the new key version.

C.Use the Cosmos DB account key rotation feature to regenerate the key.

D.Enable automatic key rotation on the Key Vault key and use the key's versionless identifier in Cosmos DB.

AnswerD

Versionless identifier allows Cosmos DB to automatically use the latest key version.

Why this answer

Using a versionless key identifier in Azure Cosmos DB allows the service to automatically use the latest version of the customer-managed key stored in Azure Key Vault. When the key is rotated in Key Vault, Cosmos DB picks up the new version without any manual intervention, ensuring zero downtime and continuous encryption at rest.

Exam trap

The trap here is confusing Cosmos DB account key rotation (for authentication) with customer-managed key rotation (for encryption at rest), leading candidates to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because Azure Security Center (now Microsoft Defender for Cloud) does not provide automatic key rotation for customer-managed keys used with Cosmos DB; key rotation must be configured on the Key Vault key itself. Option B is wrong because manually updating the Cosmos DB account with a new key version after rotation introduces a window of potential downtime or misconfiguration, and it defeats the purpose of seamless rotation. Option C is wrong because the Cosmos DB account key rotation feature is for regenerating the primary/secondary read-write or read-only keys used for authentication, not for rotating the customer-managed encryption key stored in Key Vault.

Full explanation →

579

MCQmedium

You are developing an API that uses managed identity to access Azure Key Vault. The API runs in an Azure App Service with system-assigned managed identity enabled. You need to retrieve a secret value. Which API endpoint should your code call?

A.https://vault.azure.net/secrets/{secret-name}

B.https://myvault.vault.azure.net/secrets/{secret-name}?api-version=7.0

C.https://login.microsoftonline.com/{tenant}/oauth2/token

D.https://management.azure.com/subscriptions/{sub}/...

AnswerB

This URL correctly specifies the Azure Key Vault data plane endpoint for retrieving a secret. It includes the unique `vault-name` as a subdomain, followed by the standard `vault.azure.net` domain, and then the `/secrets/{secret-name}` path to target a specific secret. The `?api-version=7.0` query parameter is a crucial best practice for specifying the desired API version, ensuring compatibility and access to specific features.

Why this answer

It uses the full Key Vault REST API endpoint with the specific vault name ('myvault'), the 'secrets' resource path, the secret name, and the required 'api-version' query parameter (7.0). The managed identity in the App Service authenticates via Azure AD, and the code must call this specific endpoint to retrieve the secret value, as the vault name is part of the DNS name and the API version is mandatory.

Exam trap

The trap here is that candidates often confuse the Key Vault REST API endpoint with the Azure AD token endpoint or the Azure Resource Manager endpoint, forgetting that the vault name is part of the DNS and that an API version is required.

How to eliminate wrong answers

Option A is wrong because 'vault.azure.net' is not a valid Key Vault DNS name; the vault name must be included (e.g., 'myvault.vault.azure.net'). Option C is wrong because it is the Azure AD OAuth2 token endpoint, which is used to obtain an access token, not to directly retrieve a secret from Key Vault. Option D is wrong because it points to the Azure Resource Manager endpoint for subscription-level operations, not to the Key Vault secrets REST API.

Full explanation →

580

MCQmedium

You are building an Azure Logic App that calls an external REST API secured with the OAuth 2.0 client credentials flow. You have registered an app in Microsoft Entra ID with client ID and client secret stored in Azure Key Vault. The Logic App uses a system-assigned managed identity with Get permission on the secret. Which action should you use in the Logic App designer to authenticate to the API?

A.HTTP action with 'Active Directory OAuth' authentication type, referencing the client ID and client secret

B.HTTP action with 'Managed Identity' authentication type

C.Invoke an API with OAuth predefined connector

D.HTTP action with 'Basic' authentication and pass the secret as password

AnswerA

This option correctly leverages the "Active Directory OAuth" authentication type within the Logic Apps HTTP action. This type is specifically designed for scenarios where a client application (like a Logic App) needs to obtain an access token from Microsoft Entra ID (formerly Azure AD) using its own identity, rather than on behalf of a user. By providing the client ID and client secret, the Logic App performs the OAuth 2.0 Client Credentials flow, allowing it to authenticate and acquire a token to call the external REST API securely.

Why this answer

The OAuth 2.0 client credentials flow requires a client ID and client secret to obtain an access token from Microsoft Entra ID. The HTTP action's 'Active Directory OAuth' authentication type directly supports this flow, allowing you to reference the client ID and the client secret stored in Azure Key Vault. The Logic App's system-assigned managed identity has Get permission on the secret, enabling it to retrieve the secret at runtime without exposing it in the workflow definition.

Exam trap

The trap here is that candidates confuse 'Managed Identity' authentication (which works only for Azure resources like Azure SQL or Storage) with the need to authenticate to an external API using OAuth client credentials, leading them to incorrectly select Option B instead of the HTTP action with Active Directory OAuth.

How to eliminate wrong answers

Option B is wrong because the 'Managed Identity' authentication type is used to authenticate to Azure resources that support managed identity (e.g., Azure Storage, Azure SQL), not to external REST APIs secured with OAuth 2.0 client credentials; it cannot provide a client ID and client secret for token acquisition. Option C is wrong because 'Invoke an API with OAuth predefined connector' is not a built-in Logic App action; there is no generic 'OAuth predefined connector' that dynamically handles client credentials with Key Vault secrets—connectors are specific to services like Microsoft Graph or Salesforce. Option D is wrong because 'Basic' authentication sends the client ID and secret as a plaintext username:password pair in the HTTP Authorization header, which violates the OAuth 2.0 client credentials flow that requires a token endpoint exchange and does not support Basic auth for bearer token issuance.

Full explanation →

581

MCQhard

You are developing a solution that processes events from Azure Event Hubs and stores them in Azure Blob Storage. The processing must be idempotent and exactly-once. Which approach should you use?

A.Use EventProcessorHost with checkpointing and blob leases to track processed events

B.Use Azure Functions with Event Hubs trigger and store events in batches

C.Use a simple consumer group and delete events after reading from Event Hubs

D.Implement a transactional outbox pattern with Azure SQL Database

AnswerA

EventProcessorHost (or the modern EventProcessorClient) is the recommended pattern for robustly consuming events from Azure Event Hubs. It automatically manages partition ownership across multiple instances using blob leases in Azure Storage, ensuring that each partition is processed by only one consumer instance at a time. Checkpointing involves periodically recording the last successfully processed event's offset and sequence number to blob storage, allowing the consumer to resume processing from the correct point after failures or rebalancing, thereby achieving at-least-once delivery and enabling idempotent processing for effective exactly-once semantics.

Why this answer

The EventProcessorHost (EPH) pattern with checkpointing and blob leases provides the foundation for exactly-once processing in Event Hubs. Checkpointing records the offset of the last successfully processed event in Azure Blob Storage, while blob leases ensure partition ownership and prevent duplicate processing by competing consumers. This combination allows the processor to resume from the last checkpoint after a failure, guaranteeing that each event is processed exactly once.

Exam trap

The trap here is that candidates often confuse 'at-least-once' delivery (which is the default for Event Hubs and Azure Functions) with 'exactly-once' processing, and they overlook the critical role of checkpointing and lease management in achieving idempotent, exactly-once semantics.

How to eliminate wrong answers

Option B is wrong because Azure Functions with Event Hubs trigger does not natively guarantee exactly-once processing; it can result in at-least-once delivery due to retries and lack of built-in idempotency enforcement. Option C is wrong because deleting events after reading from Event Hubs is not supported (Event Hubs does not allow event deletion) and consumer groups do not provide idempotent or exactly-once guarantees. Option D is wrong because the transactional outbox pattern is designed for reliable message publishing from a database, not for idempotent consumption from Event Hubs, and it introduces unnecessary complexity and latency for this scenario.

Full explanation →

582

MCQeasy

Your company uses Azure Logic Apps to automate workflows. A workflow must call an external REST API that requires an API key in the header. You need to securely store the API key and reference it in the Logic App without exposing it in the workflow definition. What should you do?

A.Store the API key in plain text directly in the Logic App HTTP action header.

B.Store the API key in Azure Key Vault and use the Key Vault connector to retrieve it dynamically in the Logic App.

C.Store the API key in an App Service application setting and reference it using the 'appsetting' expression.

D.Create an Azure Function with the API key hardcoded as an environment variable and call it from the Logic App.

AnswerB

This securely stores the key in Key Vault and allows the Logic App to reference it at runtime without exposing it in the definition.

Why this answer

Azure Key Vault provides a secure, centralized store for secrets like API keys, and the Logic App Key Vault connector retrieves the key at runtime without exposing it in the workflow definition. This approach ensures the secret is never stored in plain text within the Logic App's JSON definition or source control, aligning with Azure security best practices for managed identities and access policies.

Exam trap

The trap here is that candidates may confuse App Service application settings (Option C) with Logic App environment variables, but Logic Apps do not support the 'appsetting' expression, and Azure Key Vault is the only secure, native way to inject secrets into Logic Apps without exposing them in the definition.

How to eliminate wrong answers

Option A is wrong because storing the API key in plain text directly in the HTTP action header exposes the secret in the workflow definition, which can be viewed by anyone with read access to the Logic App and is a severe security risk. Option C is wrong because App Service application settings are designed for App Service apps, not Logic Apps; the 'appsetting' expression is not supported in Logic Apps, and even if it were, the setting would be stored in plain text in the App Service configuration. Option D is wrong because hardcoding the API key as an environment variable in an Azure Function still stores the secret in plain text within the Function's configuration, and calling a separate Azure Function adds unnecessary complexity and latency without improving security over directly using Key Vault.

Full explanation →

583

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

584

MCQhard

You are developing a web application that relies on a third-party weather API. The API has a rate limit of 10 requests per second per API key. You need to ensure your application never exceeds this limit and also caches responses for 10 minutes to reduce call frequency. Which combination of Azure services should you implement?

A.Azure Functions with Durable Functions to throttle calls and a static in-memory cache.

B.Azure Logic Apps with a retry policy and a cache using Azure Redis Cache.

C.Azure API Management with rate-limit and caching policies.

D.Azure Traffic Manager to distribute requests and Azure Front Door for caching.

AnswerC

Azure API Management is specifically designed to act as a facade for APIs, offering robust, declarative policies for both rate limiting and caching. Its `rate-limit-by-key` or `rate-limit` policies can effectively throttle calls to the third-party API, preventing exceeding quotas, while its response caching policies significantly reduce latency and load by serving cached responses directly, improving overall application performance and resilience.

Why this answer

Azure API Management (APIM) provides built-in rate-limit and caching policies that directly address the requirements: the `rate-limit` policy enforces a per-key request quota (e.g., 10 calls/second), and the `cache-store`/`cache-lookup` policies cache responses for a configurable duration (e.g., 10 minutes). This eliminates the need for custom throttling logic or external caching services, making it the most straightforward and maintainable solution.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing a combination of services (e.g., Functions + Redis) when Azure API Management's single, purpose-built policy set directly solves both rate limiting and caching without custom code.

How to eliminate wrong answers

Option A is wrong because Durable Functions are designed for orchestrating long-running workflows, not for fine-grained per-second rate limiting, and a static in-memory cache in a serverless function app is not shared across instances, leading to cache inconsistency and potential rate-limit breaches. Option B is wrong because Azure Logic Apps' retry policy handles transient failures but does not provide proactive rate limiting, and Azure Redis Cache, while a valid distributed cache, adds unnecessary complexity and cost when APIM's built-in caching suffices. Option D is wrong because Azure Traffic Manager distributes traffic at the DNS level for global load balancing and does not enforce per-key rate limits, and Azure Front Door's caching is for static content at the edge, not for API response caching with per-key granularity.

Full explanation →

585

MCQmedium

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

A.NodePort

B.Internal LoadBalancer (with annotation)

C.LoadBalancer

D.ClusterIP

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

586

MCQmedium

Your application running on Azure App Service is experiencing intermittent timeouts. You have configured Application Insights to collect telemetry. Which metric should you analyze in the Azure portal to identify the slowest dependencies?

A.Request Duration

B.Failed Requests

C.Dependency Duration

D.Availability

AnswerC

Dependency Duration shows the time spent on external service calls.

Why this answer

The 'Dependency Duration' metric in Application Insights shows the duration of calls to external dependencies. Option A is wrong because 'Request Duration' only measures the total time for requests, not specific dependencies. Option B is wrong because 'Failed Requests' tracks errors, not duration.

Option D is wrong because 'Availability' measures uptime, not performance.

Full explanation →

587

MCQhard

An application uses Azure Event Hubs to ingest telemetry data. The team wants to process the data in near real-time and store aggregated results in Azure SQL Database. Which Azure service should they use?

A.Azure HDInsight

B.Azure Functions

C.Azure Stream Analytics

D.Azure Data Lake Storage Gen2

AnswerC

Azure Stream Analytics is a fully managed, real-time analytics service specifically designed for processing large volumes of streaming data from sources like Azure Event Hubs. It enables users to define complex event processing (CEP) queries using a SQL-like language to filter, aggregate, and transform data in motion, often incorporating windowing functions for time-based analysis. This service is ideal for scenarios requiring low-latency insights from telemetry, allowing direct output to various sinks, including Azure SQL Database, for immediate consumption or further analysis.

Why this answer

Azure Stream Analytics is the correct choice because it is a fully managed stream processing engine designed for real-time analytics on high-throughput data from sources like Event Hubs. It can ingest telemetry data, apply SQL-based queries for aggregation (e.g., tumbling windows), and output results directly to Azure SQL Database with exactly-once semantics, meeting the near-real-time requirement.

Exam trap

The trap here is that candidates often confuse Azure Functions as a real-time stream processor, but it lacks native windowed aggregation and state management, making Stream Analytics the correct choice for this specific near-real-time aggregation requirement.

How to eliminate wrong answers

Option A is wrong because Azure HDInsight is a big data batch/processing platform (Hadoop/Spark) that is overkill for simple near-real-time aggregation and introduces significant operational overhead; it is not optimized for low-latency stream processing from Event Hubs to SQL Database. Option B is wrong because Azure Functions can process Event Hubs events but lacks built-in windowed aggregation and stateful stream processing capabilities, making it unsuitable for computing aggregated results like sums or averages over time windows without complex custom code. Option D is wrong because Azure Data Lake Storage Gen2 is a hierarchical storage service for big data analytics, not a real-time processing engine; it cannot perform aggregations or write directly to Azure SQL Database.

Full explanation →

588

MCQmedium

You have an Azure App Service that uses a system-assigned managed identity. You need to grant it permission to read a secret from Azure Key Vault. Which RBAC role should you assign at the Key Vault scope?

A.Key Vault Reader

B.Key Vault Secrets User

C.Key Vault Contributor

D.Key Vault Certificate User

AnswerB

The Key Vault Secrets User role is specifically designed to grant data plane access for retrieving secrets. It provides permissions to perform actions like Microsoft.KeyVault/vaults/secrets/read and Microsoft.KeyVault/vaults/secrets/list, enabling the App Service to successfully fetch the actual secret values. This role adheres to the principle of least privilege by providing only the necessary permissions for secret retrieval without granting broader management capabilities.

Why this answer

The system-assigned managed identity needs to read a secret from Azure Key Vault. The 'Key Vault Secrets User' RBAC role grants exactly that permission — the ability to read secret contents. This is the least-privilege role that allows the 'Microsoft.KeyVault/vaults/secrets/read' action, which is required for reading secret values.

Exam trap

The trap here is that candidates often confuse 'Key Vault Reader' (a management-plane role) with the data-plane role needed to actually read secret values, or they over-provision by choosing 'Key Vault Contributor' thinking it includes read access.

How to eliminate wrong answers

Option A is wrong because 'Key Vault Reader' only allows listing vaults and reading metadata (e.g., vault properties, tags), but does not grant permission to read secret values. Option C is wrong because 'Key Vault Contributor' grants full management of the vault and its objects (including secrets, keys, certificates), which is excessive for a read-only secret access scenario and violates least-privilege principles. Option D is wrong because 'Key Vault Certificate User' only allows reading certificate contents and metadata, not secrets.

Full explanation →

589

MCQmedium

You have an Azure Storage account with a blob container. You need to grant a user read-only access to a specific blob for 24 hours without requiring them to authenticate with Microsoft Entra ID. What should you use?

A.Generate a user delegation SAS token

B.Provide the storage account access key

C.Assign the Storage Blob Data Reader role

D.Configure a stored access policy

AnswerA

Generating a user delegation SAS token is the most secure and recommended method for granting granular, time-limited access to Azure Blob Storage resources without exposing storage account keys. This type of SAS is signed using Azure Active Directory (Azure AD) credentials, allowing for precise control over permissions (e.g., read-only, write, list), the specific resources it applies to (container, blob), and its validity period. It integrates with Azure AD for auditing and adheres to the principle of least privilege.

Why this answer

A user delegation SAS token is the correct choice because it provides time-limited, delegated access to a specific blob using Microsoft Entra ID credentials without requiring the user to authenticate directly. The token is signed with the user's delegated key, granting read-only access for exactly 24 hours as specified, and it does not expose the storage account access key.

Exam trap

The trap here is that candidates often confuse a user delegation SAS with a stored access policy, thinking the policy alone grants access, or they incorrectly assume that assigning an RBAC role (Option C) can bypass authentication requirements, but RBAC always requires Entra ID authentication.

How to eliminate wrong answers

Option B is wrong because providing the storage account access key grants full administrative access to the entire storage account, not just read-only access to a specific blob, and it requires the user to manage a highly sensitive secret. Option C is wrong because assigning the Storage Blob Data Reader role requires the user to authenticate with Microsoft Entra ID, which contradicts the requirement of no authentication. Option D is wrong because a stored access policy defines constraints for SAS tokens but does not itself grant access; it must be combined with a SAS token, and it cannot eliminate the need for authentication.

Full explanation →

590

Multi-Selecteasy

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

Select 2 answers

A.Continuous deployment from GitHub.

B.Traffic Manager.

C.Deployment slots.

D.Auto-heal.

E.Slot swap with auto-swap.

AnswersC, E

Slots allow staging and swap with no downtime.

Why this answer

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

Exam trap

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

Full explanation →

591

MCQmedium

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

A.Function chaining

B.Fan-out/Fan-in

C.Monitor

D.Human interaction

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

592

MCQeasy

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

593

Matchingmedium

Match each Azure service to its primary purpose.

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

Concepts

Matches

NoSQL globally distributed database

Serverless compute for event-driven apps

Workflow automation and integration

Enterprise message broker with queues and topics

Event routing service for pub/sub

Why these pairings

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

Full explanation →

594

Multi-Selectmedium

You are monitoring an ASP.NET Core web API with Application Insights. You want to view the SQL queries being executed, including the command text and duration, in the Application Insights portal. Which actions must you take? (Select all that apply.) (Choose 2.)

Select 2 answers

A.Install the `Microsoft.ApplicationInsights.Profiler.AspNetCore` NuGet package.

B.Install the `Microsoft.ApplicationInsights.DependencyCollector` NuGet package.

C.Set `EnableSqlCommandTextInstrumentation` to `true` in the `DependencyTrackingTelemetryModule` configuration.

D.Enable adaptive sampling to ensure all SQL queries are collected.

AnswersB, C

The Microsoft.ApplicationInsights.DependencyCollector NuGet package is the foundational component for automatically tracking outgoing calls from your application to external services, including databases, HTTP services, and message queues. This package instruments common database clients to record dependency telemetry, such as the operation name, duration, and success status for SQL calls. While it collects the fact that a SQL dependency occurred, by default, it does not capture the full SQL command text itself without further configuration.

Why this answer

The `Microsoft.ApplicationInsights.DependencyCollector` NuGet package is required to automatically collect dependency telemetry, including SQL Server calls. Without this package, Application Insights will not capture SQL dependency data at all. Option C is correct because even with the dependency collector installed, SQL command text is not collected by default for security reasons; you must explicitly set `EnableSqlCommandTextInstrumentation` to `true` in the `DependencyTrackingTelemetryModule` configuration to view the actual SQL queries and their duration in the portal.

Exam trap

The trap here is that candidates often assume installing the dependency collector alone is sufficient to see SQL command text, but they overlook the explicit configuration flag (`EnableSqlCommandTextInstrumentation`) required to enable that specific data collection.

Full explanation →

595

MCQeasy

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

A.Call an HTTP endpoint on the App Service instance

B.Use Environment.GetEnvironmentVariable("SQLAZURECONNSTR_MyConn")

C.Use Azure.Identity.DefaultAzureCredential and Key Vault

D.Read from appsettings.json using IConfiguration

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

596

MCQeasy

You are developing a solution that requires multiple Azure virtual machines to access the same set of files concurrently. The files are updated frequently and must be accessible with low latency. You need to choose a shared storage solution that integrates with Microsoft Entra ID (Microsoft Entra ID) for authentication. Which Azure storage solution should you use?

A.Azure Blob Storage with a private container.

B.Azure NetApp Files.

C.Azure Files shares.

D.Azure Disk Storage with shared disks.

AnswerC

Azure Files shares provide fully managed cloud file shares that support industry-standard SMB and NFS protocols, enabling multiple Azure Virtual Machines to access the same files concurrently. This service integrates directly with Microsoft Entra ID for authentication and authorization, allowing for granular access control based on user identities. Its native file system capabilities, including file locking and consistent access, make it the ideal solution for shared file storage requirements across multiple VMs.

Why this answer

Azure Files shares provide fully managed SMB and NFS file shares that can be accessed concurrently by multiple Azure VMs with low latency. They support identity-based authentication using Microsoft Entra ID (formerly Azure AD) over SMB, enabling granular access control via RBAC and NTFS ACLs. This makes Azure Files the correct choice for a shared, frequently updated file store requiring Entra ID integration.

Exam trap

The trap here is that candidates often confuse Azure NetApp Files (which supports SMB/NFS but not native Entra ID auth) with Azure Files (which does support Entra ID auth), or they mistakenly think Blob Storage can serve as a file share with low-latency concurrent access.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage with a private container is an object storage solution, not a file system; it does not support SMB/NFS protocols for concurrent VM file access and lacks native Microsoft Entra ID authentication for file-level operations. Option B is wrong because Azure NetApp Files, while providing high-performance shared file storage, does not natively integrate with Microsoft Entra ID for authentication; it relies on Active Directory Domain Services (AD DS) or LDAP, not Entra ID. Option D is wrong because Azure Disk Storage with shared disks is a block-level storage solution that requires cluster-aware file systems (e.g., Scale-out File Server) and does not support Microsoft Entra ID authentication; it is designed for SAN-like scenarios, not direct file sharing with identity-based access.

Full explanation →

597

MCQmedium

Your company stores secrets in Azure Key Vault. You need to ensure that when a secret is disabled, it does not become accessible to applications that already have a cached copy. Which additional step must you take?

A.Rotate the secret immediately

B.Delete the secret

C.Enable soft-delete and purge protection

D.Use Key Vault access policies to deny access

AnswerA

Rotating a secret in Azure Key Vault creates a new version with an updated value, effectively marking the previous version as deprecated for general use. This action is crucial because applications are typically configured to retrieve the *latest* version of a secret. Upon their next scheduled refresh or explicit retrieval attempt, they will fetch the new value, thereby invalidating any previously cached copies of the older secret value and ensuring they operate with the most current credential. This directly addresses the need to force applications to use a new secret.

Why this answer

When a secret is disabled in Azure Key Vault, the vault itself will reject new access requests, but applications that have already retrieved and cached the secret can continue using it until the cache expires or is refreshed. To immediately invalidate the cached copy, you must rotate the secret (change its value) so that any subsequent attempt to use the old cached value fails because it no longer matches the secret stored in Key Vault. Disabling alone does not force applications to re-authenticate or re-fetch; rotation ensures the cached value becomes obsolete.

Exam trap

The trap here is that candidates assume disabling a secret immediately revokes all access, but they overlook the fact that applications may hold a cached copy that remains valid until the cache expires or the secret is rotated.

How to eliminate wrong answers

Option B is wrong because deleting the secret removes it permanently (or moves it to a soft-deleted state), but applications with a cached copy can still use the old value until they attempt to retrieve it again; deletion does not actively invalidate the cache. Option C is wrong because enabling soft-delete and purge protection only prevents accidental or malicious permanent deletion of secrets; it does not affect cached copies held by applications. Option D is wrong because Key Vault access policies control who can read or modify secrets, but they do not retroactively invalidate secrets already cached by authorized applications; once a secret is fetched, the cached copy remains usable regardless of policy changes.

Full explanation →

598

MCQmedium

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

A.App Service Free tier

B.Premium plan

C.Azure Batch pool

D.Consumption plan

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

599

MCQmedium

Audit logs are written daily as block blobs to an Azure Storage account. Logs older than 90 days must move to Cool tier automatically; logs older than 365 days must be deleted. The developer wants to implement this with no custom code and no recurring jobs. What is the correct solution?

A.Create a lifecycle management policy with two rules: tier to Cool after 90 days and delete after 365 days

B.Write an Azure Function with a Timer trigger that lists all blobs, checks last-modified dates, and tiers or deletes them via the SDK

C.Enable Blob versioning and set a version retention policy of 365 days

D.Configure a Logic App with a Recurrence trigger to enumerate and process blobs weekly

AnswerA

Lifecycle management policies are evaluated nightly by Azure. The two rules (tier after 90 days, delete after 365 days) are declared in JSON and applied to blobs matching the prefix filter. No code is required — the storage service acts on them automatically.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automate tier transitions and deletions based on blob age, without any custom code or recurring jobs. By defining a rule to tier blobs to Cool after 90 days and another rule to delete blobs after 365 days, the developer meets all requirements with a fully managed, no-code solution.

Exam trap

The trap here is that candidates may overlook the 'no custom code and no recurring jobs' constraint and choose a serverless compute option (Azure Function or Logic App) instead of the built-in lifecycle management policy, which is the only fully managed, no-code solution.

How to eliminate wrong answers

Option B is wrong because it requires custom code (Azure Function with Timer trigger) and a recurring job, violating the 'no custom code and no recurring jobs' constraint. Option C is wrong because Blob versioning with a retention policy only manages versions, not the base blobs, and it does not support tiering to Cool; it only retains or deletes versions, not the original blobs. Option D is wrong because a Logic App with a Recurrence trigger is a recurring job that requires custom logic to enumerate and process blobs, again violating the no-code and no-recurring-jobs requirement.

Full explanation →

600

MCQmedium

A company uses Azure Blob Storage to store sensitive documents. They want to ensure that data is encrypted at rest using customer-managed keys (CMK) stored in Azure Key Vault. They also need to be able to revoke access to the data immediately if a security breach is detected. Which feature should they enable?

A.Configure Azure Storage encryption with customer-managed keys in Azure Key Vault and enable soft delete and purge protection.

B.Enable infrastructure encryption for the storage account.

C.Use Azure Storage Service Encryption with Microsoft-managed keys.

D.Implement client-side encryption using Azure Key Vault.

AnswerA

This option correctly addresses the requirement for customer-managed keys (CMK) by integrating Azure Storage encryption with Azure Key Vault. Using CMK provides granular control over the encryption keys, allowing customers to revoke access and render data immediately inaccessible, which is crucial for sensitive data. Enabling soft delete and purge protection on the Key Vault further enhances security by preventing accidental or malicious deletion of these critical encryption keys, ensuring data recoverability while maintaining key control.

Why this answer

It combines customer-managed keys (CMK) in Azure Key Vault for encryption at rest with soft delete and purge protection, which allows immediate revocation of access by deleting or disabling the key in Key Vault. This ensures that the data becomes permanently inaccessible as Azure Storage relies on the CMK to encrypt/decrypt the data, and without the key, the data cannot be decrypted.

Exam trap

The trap here is that candidates may think enabling infrastructure encryption (Option B) or using Microsoft-managed keys (Option C) provides the same revocation capability, but only customer-managed keys with soft delete and purge protection allow the customer to immediately and permanently revoke access by controlling the key in Key Vault.

How to eliminate wrong answers

Option B is wrong because infrastructure encryption provides an additional layer of encryption at the storage infrastructure level using platform-managed keys, but it does not use customer-managed keys nor does it enable immediate revocation of access. Option C is wrong because Azure Storage Service Encryption with Microsoft-managed keys does not allow the customer to control or revoke the encryption keys, so immediate revocation of access is not possible. Option D is wrong because client-side encryption encrypts data before it is sent to Azure Storage, but it does not provide a mechanism to revoke access to data already stored; revocation would require deleting or disabling the key used at the client side, which is not integrated with Azure Storage's access control.

Full explanation →

Microsoft Azure Developer Associate AZ-204 (AZ-204) — Questions 526–600