Microsoft Azure Developer Associate AZ-204 AZ-204 Questions 601–675 | Page 9/12

601

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 →

602

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 →

603

Multi-Selecthard

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

Select 2 answers

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

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

C.Set minimum and maximum instance counts.

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

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

AnswersB, C

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

Why this answer

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

Exam trap

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

Full explanation →

604

MCQhard

You are developing an application that uses Azure Queue Storage. The application processes messages and must ensure that a message is not lost if the processing fails. Which visibility timeout setting should you use?

A.Set a short visibility timeout like 30 seconds

B.Set visibility timeout to 1 hour

C.Set visibility timeout to infinite

D.Set visibility timeout to 0 seconds

AnswerA

Setting a short visibility timeout, such as 30 seconds, is optimal because it provides sufficient time for a message consumer to process the message under normal operating conditions. If the consumer fails or crashes before completing processing and deleting the message, the message quickly becomes visible again in the queue. This allows another available worker to pick up and reprocess the message with minimal delay, ensuring high availability and fault tolerance for transient processing issues.

Why this answer

Setting a short visibility timeout (e.g., 30 seconds) ensures that if message processing fails, the message becomes visible again quickly for retry, preventing permanent loss. Azure Queue Storage uses a visibility timeout to hide a dequeued message from other consumers; if the processing fails and the message is not deleted, it reappears after the timeout expires. A short timeout balances retry speed with processing time, avoiding indefinite hiding that could lead to message loss if the consumer crashes.

Exam trap

The trap here is that candidates may think a longer visibility timeout provides more safety, but it actually risks message loss by hiding the message indefinitely if the consumer fails, whereas a short timeout ensures quick retries and eventual processing.

How to eliminate wrong answers

Option B is wrong because a 1-hour visibility timeout would hide the message for too long, delaying retries and potentially causing message loss if the consumer crashes without deleting the message. Option C is wrong because an infinite visibility timeout (maximum 7 days) would permanently hide the message, effectively losing it if processing fails and the message is never deleted. Option D is wrong because a visibility timeout of 0 seconds makes the message immediately visible to other consumers, defeating the purpose of ensuring processing without loss and risking duplicate processing.

Full explanation →

605

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

The trap here is that candidates often assume the Premium plan with pre-warmed instances is the only or best way to address cold starts, overlooking that a Dedicated App Service plan with Always On provides a stronger guarantee of cold start elimination and a sufficient default timeout (30 minutes, same as Premium), often at a lower cost for predictable, continuous workloads.

How to eliminate wrong answers

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

Full explanation →

606

MCQmedium

You are reviewing an ARM template that deploys an Azure App Service. The template sets an app setting 'MyApiKey' that references a Key Vault secret. However, the deployment fails with an error that the app service cannot access the secret. What is the most likely cause?

A.The Key Vault reference syntax '@Microsoft.KeyVault(SecretUri=...)' is incorrect.

B.The ARM template cannot use Key Vault references in app settings.

C.The secret name in the URI does not match the actual secret name.

D.The App Service does not have a managed identity enabled and the Key Vault access policy is missing.

AnswerD

For an Azure App Service to successfully retrieve a secret using a Key Vault reference, it must first be configured with a system-assigned or user-assigned managed identity. Subsequently, this managed identity requires an explicit access policy within the target Azure Key Vault, granting it 'Get' permissions on secrets. Without both the enabled managed identity and the corresponding Key Vault access policy, the App Service lacks the necessary authentication and authorization to resolve the secret, leading to a runtime failure.

Why this answer

An Azure App Service must have a managed identity enabled and the Key Vault must have an access policy granting that identity the 'Get' permission for secrets. Without these, the App Service cannot authenticate to Key Vault, causing the deployment to fail with an access error.

Exam trap

The trap here is that candidates often assume the Key Vault reference syntax is the issue, when in reality the error message 'cannot access the secret' points directly to an authentication or authorization failure, not a syntax or naming problem.

How to eliminate wrong answers

Option A is wrong because the correct Key Vault reference syntax is '@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)', and if it were incorrect, the error would be about parsing, not access. Option B is wrong because ARM templates can use Key Vault references in app settings; this is a supported feature for secure secret injection. Option C is wrong because a mismatched secret name would produce a 'SecretNotFound' error, not an access error.

Full explanation →

607

MCQmedium

A company is developing an application that processes orders. The application uses Azure Service Bus queues to decouple order submission from processing. During peak hours, some messages are not processed within the required time, causing order delays. The team needs to increase throughput without changing the existing message processing logic. What should they do?

A.Use Azure Event Hubs instead of Service Bus.

B.Increase the number of concurrent listeners on the queue.

C.Enable sessions on the queue to group related messages.

D.Increase the lock duration on messages.

AnswerB

Increasing the number of concurrent listeners on an Azure Service Bus queue directly enhances the application's ability to process messages in parallel. Each additional listener can fetch and process messages independently, allowing multiple messages to be consumed simultaneously from the queue. This parallel processing significantly boosts the overall message throughput, reducing the backlog and improving the responsiveness of the order processing application by distributing the workload across more consumer instances.

Why this answer

Increasing the number of concurrent listeners on the Service Bus queue allows multiple message receivers to process messages in parallel, directly increasing throughput without altering the existing message processing logic. This leverages the competing consumers pattern, where each listener independently receives and processes messages from the same queue, effectively scaling out the processing capacity.

Exam trap

The trap here is that candidates often confuse increasing lock duration (a reliability setting) with increasing throughput, or they assume that enabling sessions or switching to Event Hubs will magically improve performance without understanding the fundamental scalability mechanism of competing consumers.

How to eliminate wrong answers

Option A is wrong because Azure Event Hubs is designed for high-throughput event ingestion and telemetry streaming, not for decoupled order processing with guaranteed delivery and transactional support; it does not support message lock, deferral, or dead-lettering, which are required for reliable order processing. Option C is wrong because enabling sessions on a queue groups related messages and ensures ordered processing per session, but it does not increase throughput; in fact, it can reduce parallelism because all messages in a session must be processed by a single receiver. Option D is wrong because increasing the lock duration on messages gives more time to process a message before it becomes available to other consumers, but it does not increase throughput; it only prevents premature message abandonment and can actually delay processing if a message is locked for too long.

Full explanation →

608

MCQeasy

The mobile app team needs to send push notifications to 10 million devices running both iOS and Android. On iOS, notifications go through Apple Push Notification service (APNs); on Android, through Firebase Cloud Messaging (FCM). The team wants a single Azure service that abstracts platform differences and scales without managing separate APNs and FCM integrations per platform. Which service should they use?

A.Azure Notification Hubs with APNs and FCM credentials configured in the hub namespace

B.Azure Service Bus with topics — one subscription per platform, each subscription delivering to APNs or FCM

C.Azure Event Grid with a custom endpoint handler per platform that calls APNs or FCM directly

D.Azure Communication Services email with HTML-formatted alerts sent to device email addresses

AnswerA

Notification Hubs is the Azure service designed for exactly this use case. Configure your APNs certificate and FCM server key once. The backend then calls Notification Hubs with a unified API, specifying templates or platform-specific payloads. The hub routes and delivers to the appropriate PNS for each device's platform.

Why this answer

Azure Notification Hubs is the correct choice because it is a fully managed push notification service designed to abstract platform-specific notification systems like APNs (iOS) and FCM (Android). By configuring the APNs and FCM credentials in the hub namespace, the team can send a single notification that is automatically routed to the correct platform service, scaling to millions of devices without managing separate integrations.

Exam trap

The trap here is that candidates may confuse Azure Service Bus or Event Grid as viable push notification services, but neither provides direct, platform-abstracted push notification delivery to mobile devices like Notification Hubs does.

How to eliminate wrong answers

Option B is wrong because Azure Service Bus Topics are a message broker for decoupling applications, not a push notification service; they lack native integration with APNs or FCM and cannot directly deliver push notifications to mobile devices. Option C is wrong because Azure Event Grid is an event routing service that requires custom endpoint handlers to call APNs or FCM, which defeats the purpose of abstracting platform differences and adds complexity. Option D is wrong because Azure Communication Services email is designed for sending emails, not push notifications, and cannot reach mobile devices via APNs or FCM.

Full explanation →

609

MCQeasy

You are developing a web application that uses Azure Cosmos DB for NoSQL. You need to perform a point read by document ID and partition key. Which API method should you use to achieve the best performance and lowest cost?

A.Call ReadItemAsync with the partition key and document ID.

B.Call QueryAsync with a SQL query that filters by ID.

C.Call CreateItemAsync and check for conflict.

D.Call ReadManyAsync with a list of IDs.

AnswerA

Calling ReadItemAsync with the partition key and document ID is the most efficient and cost-effective method for retrieving a single item in Azure Cosmos DB. This operation is known as a point read, which directly accesses the physical partition where the item resides, bypassing the more resource-intensive query engine. It consumes the fewest Request Units (RUs) because it's a direct key-value lookup, making it ideal for scenarios requiring high performance and low latency for single-item retrieval.

Why this answer

The `ReadItemAsync` method is the most efficient way to perform a point read in Azure Cosmos DB for NoSQL because it directly accesses the document by its partition key and ID, using the resource ID (self-link) for a single request unit (RU) cost of exactly 1 RU for a 1 KB document. This bypasses the query engine entirely, providing the lowest latency and cost.

Exam trap

The trap here is that candidates often assume a SQL query with a filter by ID is equivalent to a point read, but they overlook that the query engine always adds extra RU overhead and latency compared to the direct `ReadItemAsync` method.

How to eliminate wrong answers

Option B is wrong because `QueryAsync` with a SQL query, even if filtered by ID, incurs additional RU overhead (minimum 2-3 RU) and higher latency due to query parsing, indexing, and execution, making it less performant and more expensive than a direct point read. Option C is wrong because `CreateItemAsync` is designed to insert a new document, not read an existing one, and checking for conflict would be an incorrect and costly workaround for a read operation. Option D is wrong because `ReadManyAsync` is intended for batch reading multiple items by their IDs and partition keys, which is overkill for a single document and may incur higher RU costs due to the batch operation overhead.

Full explanation →

610

MCQeasy

You need to upload a large file (500 MB) to Azure Blob Storage from a .NET application with high throughput and resilience to network interruptions. Which approach should you use?

A.Use the Azure Storage SDK for .NET with the UploadAsync method that automatically splits the file into blocks

B.Use HTTP PUT with the entire file in a single request

C.Use the Azure Portal to upload the file

D.Use AzCopy with a single command

AnswerA

The Azure Storage SDK for .NET's UploadAsync method is specifically designed for efficient and resilient large file uploads to block blobs. It automatically divides the 500 MB file into smaller blocks, uploads them in parallel, and manages retries for transient failures. This approach significantly enhances throughput and ensures data integrity, making it the recommended programmatic solution for substantial data transfers within a .NET application.

Why this answer

The Azure Storage SDK's UploadAsync method automatically uses block blob staging, splitting the 500 MB file into multiple blocks that are uploaded in parallel. This provides high throughput and resilience: if a network interruption occurs, only the failed blocks need to be retried, not the entire file. The SDK handles block management and final commit, making it ideal for large file uploads.

Exam trap

The trap here is that candidates may choose AzCopy (Option D) because it is a well-known high-performance tool, but the question explicitly requires a .NET application approach, making the SDK's UploadAsync the correct integrated solution.

How to eliminate wrong answers

Option B is wrong because HTTP PUT with the entire file in a single request is limited to 256 MB (or 64 MB for older API versions) and offers no retry granularity; a network interruption would require re-uploading the entire file. Option C is wrong because the Azure Portal upload is designed for small files (typically under 256 MB) and lacks programmatic control, parallelization, or resilience to interruptions. Option D is wrong because while AzCopy is a robust tool for bulk transfers, it is a command-line utility, not a .NET SDK approach; the question specifies using a .NET application, making AzCopy an external dependency rather than an integrated solution.

Full explanation →

611

Multi-Selecthard

Which FOUR of the following are true regarding Microsoft Entra ID authentication for Azure Storage?

Select 4 answers

A.SAS tokens are not supported when using Microsoft Entra ID authentication.

B.RBAC roles can be used to grant permissions to a user or service principal.

C.When Microsoft Entra ID authentication is enabled, Shared Key authorization is still allowed by default.

D.Managed identities can authenticate to Azure Storage without storing credentials.

E.The authentication process uses OAuth 2.0 access tokens.

AnswersB, C, D, E

Azure RBAC roles assign storage data-plane permissions to a user or service principal through Microsoft Entra ID, satisfying the stem's requirement that Entra ID authentication governs access. Role assignments scope to subscription, resource group, storage account, or container, letting the same identity receive least-privilege access without sharing account keys.

Why this answer

Option B is correct because Azure Storage supports Azure RBAC roles such as Storage Blob Data Reader, Storage Blob Data Contributor, and Storage Blob Data Owner, which can be assigned to users, groups, service principals, or managed identities to grant data-plane permissions. Option C is correct because enabling Microsoft Entra ID authentication does not disable Shared Key authorization; unless the storage account is explicitly configured to disallow Shared Key access (for example, by setting AllowSharedKeyAccess to false), Shared Key remains enabled by default. Option D is correct because managed identities for Azure resources let applications authenticate to Azure Storage without storing credentials in code or configuration, since the identity is managed by the Microsoft Entra ID and Azure platform.

Option E is correct because Microsoft Entra ID authentication to Azure Storage uses OAuth 2.0 access tokens issued by Microsoft Entra ID, which are presented to the storage service to authorize data-plane requests. Option A is not correct because SAS tokens are still supported alongside Microsoft Entra ID authentication; SAS is a separate authorization mechanism, and user delegation SAS can even be secured with Microsoft Entra ID credentials.

Exam trap

Candidates may mistakenly think that enabling Microsoft Entra ID authentication automatically disables Shared Key authorization, but in fact Shared Key access remains enabled by default unless explicitly disabled via the 'AllowSharedKeyAccess' property.

Full explanation →

612

MCQeasy

You need to monitor the CPU and memory usage of an Azure Virtual Machine (VM) over the last 30 days. Which Azure service should you use?

A.Azure Service Health

B.Azure Advisor

C.Azure Monitor Metrics

D.Azure Log Analytics

AnswerC

Azure Monitor Metrics is specifically designed to collect numerical data from Azure resources, including virtual machines, at regular intervals. It stores time-series data for key performance counters such as CPU utilization, memory usage, disk I/O, and network traffic. This service provides the necessary infrastructure for storing, visualizing, and alerting on these granular performance metrics, making it the correct and primary tool for monitoring VM CPU and memory usage.

Why this answer

Azure Monitor Metrics is the correct service because it collects and stores numerical performance data (such as CPU and memory utilization) from Azure resources, including VMs, at near-real-time intervals and retains it for up to 93 days. This allows you to query and visualize metrics over the last 30 days using the Azure portal, REST API, or CLI, directly meeting the requirement without additional configuration.

Exam trap

The trap here is that candidates often confuse Azure Monitor Metrics with Azure Log Analytics, mistakenly thinking that all monitoring data must go through Log Analytics, when in fact Metrics is the dedicated service for numerical performance data and provides built-in retention for the required 30-day period without extra setup.

How to eliminate wrong answers

Option A is wrong because Azure Service Health provides information about service-level incidents, planned maintenance, and health advisories affecting Azure services, not granular VM performance metrics like CPU or memory usage. Option B is wrong because Azure Advisor offers personalized recommendations for cost, security, reliability, and performance optimization based on telemetry, but it does not expose raw historical metric data for the last 30 days. Option D is wrong because Azure Log Analytics is designed for collecting and querying log data (e.g., text-based events, custom logs) and requires a diagnostic extension to send VM performance counters; it is not the primary service for out-of-the-box metric retention and visualization.

Full explanation →

613

Multi-Selecthard

An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request? The team wants the control to be enforceable during normal operations.

Select 2 answers

A.Issuer and signature are valid for the trusted tenant

B.The user's display name is present

C.Token audience matches the API application ID URI or client ID

D.The token was sent in a query string

AnswersA, C

Validating the issuer confirms the token was minted by the trusted Microsoft Entra ID tenant, while signature verification proves the token is authentic and untampered. Together these prevent forged or foreign-tenant tokens from being accepted, satisfying the requirement for an enforceable control during normal API operations.

Why this answer

Option A is correct because the API must verify that the JWT was issued by the trusted Microsoft Entra ID tenant (checking the iss claim against the tenant's issuer URL) and that its signature validates against Entra ID's published signing keys, which prevents forged or tampered tokens. Option C is correct because the API must confirm the aud claim matches its own expected audience — the Application ID URI or client ID — so that a token issued for a different resource cannot be replayed against this API. Option B is not a security control: a display name claim is optional, user-controlled in some flows, and does not prove the token's validity or intended recipient.

Option D is incorrect because tokens should be sent in the Authorization header as a Bearer token, not in a query string, which would expose them in logs and URLs and is not a validation property.

Exam trap

The trap here is that candidates may think validating the user's display name (Option B) is necessary for authorization, but token validation is about verifying the token's authenticity and intended audience, not user attributes.

Full explanation →

614

MCQmedium

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

A.var sasBuilder = new BlobSasBuilder { BlobContainerName = container.Name, Permissions = "rl", ExpiresOn = DateTimeOffset.UtcNow.AddHours(1) }; var sasUri = container.GenerateSasUri(sasBuilder);

B.var sasBuilder = new BlobSasBuilder { Permissions = "r", ExpiresOn = DateTimeOffset.UtcNow.AddHours(1) }; var sasUri = container.GenerateSasUri(sasBuilder);

C.var sasToken = container.GetSasToken(permissions: "rl", duration: TimeSpan.FromHours(1));

D.var sasBuilder = new BlobSasBuilder { Permissions = "rl", StartsOn = DateTimeOffset.UtcNow, ExpiresOn = DateTimeOffset.UtcNow.AddHours(1) }; var sasUri = container.GenerateSasUri(sasBuilder);

AnswerA

This code correctly instantiates a BlobSasBuilder and sets the essential BlobContainerName property to scope the SAS to the target container. It grants both read ('r') and list ('l') permissions, which are appropriate for accessing and enumerating documents, and defines a valid expiry time of one hour. Finally, the GenerateSasUri method on the BlobContainerClient correctly produces the full URI including the generated Shared Access Signature.

Why this answer

It creates a `BlobSasBuilder` with the container name, permissions set to "rl" (read and list), and an expiration time of exactly 1 hour from the current UTC time. The `GenerateSasUri` method then produces a SAS URI that grants the specified permissions for the container. This matches the requirement for a time-limited SAS that allows only read and list operations on blobs in the container.

Exam trap

The trap here is that candidates often think they must set `StartsOn` to the current time to make the SAS valid immediately, but Azure Storage automatically treats the SAS as valid from the time of generation if `StartsOn` is omitted, and including it can cause failures due to clock skew.

How to eliminate wrong answers

Option B is wrong because it sets permissions to "r" (read only) instead of "rl" (read and list), so it does not grant the required list permission. Option C is wrong because `GetSasToken` is not a valid method on `BlobContainerClient`; the correct approach is to use `BlobSasBuilder` and `GenerateSasUri`. Option D is wrong because it includes a `StartsOn` property set to the current time, which is unnecessary and can cause issues with clock skew; the SAS should start immediately without an explicit start time to avoid potential time synchronization problems.

Full explanation →

615

MCQmedium

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

A.Set restart policy to Always and use a private container registry

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

616

MCQhard

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

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

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

C.Set the restart policy to 'Always'

D.Configure the DNS server in the Dockerfile

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

617

MCQhard

Your company, Contoso Ltd., operates a global e-commerce platform. The platform stores product images in Azure Blob Storage. Currently, the images are stored in a single storage account in the West US region. The application uses HTTP to download images. Users in Europe report slow load times. You need to reduce latency for European users. The solution must minimize costs and administrative overhead. You also need to ensure that images are served over HTTPS. You have the following requirements: 1) Users in Europe must have low-latency access. 2) The solution must be cost-effective. 3) The solution must not require changes to the application code. 4) Images must be served over HTTPS. Which course of action should you recommend?

A.Use Azure Front Door with the storage account as a backend.

B.Create an Azure CDN profile and add a CDN endpoint that points to the storage account. Enable HTTPS on the CDN endpoint.

C.Create a secondary storage account in Europe and use asynchronous replication. Update the application to use the secondary endpoint for European users.

D.Enable geo-redundant storage (GRS) on the storage account.

AnswerB

Creating an Azure CDN profile and endpoint pointing to the storage account is the most effective solution for globally distributing static content. CDN caches content at geographically distributed edge locations, significantly reducing latency for users worldwide by serving data from the nearest point of presence. Enabling HTTPS on the CDN endpoint ensures secure communication, encrypting data in transit and maintaining user trust, which is crucial for an e-commerce platform.

Why this answer

Azure CDN provides a global, distributed network of edge servers that cache content closer to users, reducing latency for European users without requiring application code changes. Enabling HTTPS on the CDN endpoint ensures images are served securely over HTTPS, meeting the requirement. This solution is cost-effective as it uses a pay-as-you-go model and minimizes administrative overhead by leveraging a managed service.

Exam trap

The trap here is confusing Azure CDN with Azure Front Door or geo-replication, where candidates might think a global load balancer or storage replication is needed for latency reduction, but Azure CDN is the simplest and most cost-effective solution for static content caching without code changes.

How to eliminate wrong answers

Option A is wrong because Azure Front Door is primarily a global load balancer and application delivery controller optimized for HTTP/HTTPS traffic with advanced routing and WAF capabilities, but it is more expensive than Azure CDN for simple static content delivery and introduces unnecessary complexity for this use case. Option C is wrong because it requires application code changes to redirect European users to the secondary endpoint, violating the 'no changes to application code' requirement, and asynchronous replication adds cost and administrative overhead. Option D is wrong because geo-redundant storage (GRS) replicates data to a paired region for disaster recovery, not for low-latency content delivery; it does not serve content from the secondary region and does not provide HTTPS termination at the edge.

Full explanation →

618

Multi-Selecteasy

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

Select 2 answers

A.Create a new App Service plan

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

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

D.Enable Application Insights

E.Add a custom domain to the App Service

AnswersB, C

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

Why this answer

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

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

Exam trap

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

Full explanation →

619

MCQmedium

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

A.Application Insights sampling

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

C.Deployment slots

D.Function timeout

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

620

Multi-Selecthard

Which THREE factors should be considered when choosing between Azure Service Bus and Azure Event Hubs for a messaging solution? (Choose 3)

Select 3 answers

A.Event Hubs cannot be used with Apache Kafka client applications

B.Event Hubs is optimized for high-throughput telemetry ingestion

C.Service Bus supports topics and subscriptions for publish/subscribe patterns

D.Service Bus does not support the AMQP protocol

E.Both services can be used in a hybrid cloud architecture with on-premises systems

AnswersB, C, E

Azure Event Hubs is specifically engineered for ingesting millions of events per second from various sources, making it ideal for big data streaming scenarios like telemetry and log processing. Its partitioned consumer model allows multiple consumers to read from different partitions concurrently, ensuring high throughput and low latency for event streams. This optimization is crucial for real-time analytics and processing of massive volumes of data generated by IoT devices, applications, and infrastructure.

Why this answer

Option B is correct because Azure Event Hubs is a big-data streaming platform designed for high-throughput telemetry ingestion, capable of ingesting millions of events per second with low latency, making it the right choice for event streaming and telemetry scenarios. Option C is correct because Azure Service Bus natively supports topics and subscriptions, enabling publish/subscribe patterns with features like filters and rules, which Event Hubs does not provide in the same way. Option E is correct because both Event Hubs and Service Bus are cloud services that can be integrated with on-premises systems through hybrid architectures using VPN, ExpressRoute, or on-premises connectors, so hybrid cloud support is a valid consideration for either.

Option A is incorrect because Event Hubs provides a Kafka endpoint that is compatible with Apache Kafka client applications, so it can be used with Kafka clients. Option D is incorrect because Service Bus does support the AMQP 1.0 protocol, which is one of its primary messaging protocols alongside HTTP.

Exam trap

The trap here is that candidates often confuse the throughput capabilities of Event Hubs with Service Bus, assuming both can handle high-throughput telemetry equally, but Service Bus is limited to approximately 2000 messages per second per namespace and is not designed for massive data ingestion.

Full explanation →

621

MCQhard

Refer to the exhibit. You are creating an Azure Service Bus queue using an ARM template. The requirement is that messages should be automatically dead-lettered after 3 failed delivery attempts. Does this configuration meet the requirement?

A.No, because lockDuration should be shorter

B.Yes, because defaultMessageTimeToLive ensures messages expire

C.No, because maxDeliveryCount should be 3

D.Yes, because maxDeliveryCount is set

AnswerC

To ensure a message is automatically moved to the dead-letter queue after precisely three failed delivery attempts, the `maxDeliveryCount` property must be explicitly set to 3. This property directly controls the threshold for automatic dead-lettering due to repeated processing failures by incrementing with each delivery. With the current setting (implied to be 10 from the exhibit), messages would endure seven additional failed attempts before being dead-lettered, which does not meet the requirement of dead-lettering after three attempts.

Why this answer

The `maxDeliveryCount` property in Azure Service Bus determines the number of attempts to deliver a message before it is automatically moved to the dead-letter queue. The requirement specifies 3 failed delivery attempts, so `maxDeliveryCount` must be set to 3. The exhibit shows `maxDeliveryCount` set to 10, which does not meet the requirement.

Exam trap

The trap here is that candidates may see `maxDeliveryCount` is present and assume it meets the requirement, without checking that its value must be exactly 3 to match the specified number of failed delivery attempts.

How to eliminate wrong answers

Option A is wrong because `lockDuration` controls how long a message is locked for a receiver, not the number of delivery attempts; shortening it would not cause dead-lettering after 3 attempts. Option B is wrong because `defaultMessageTimeToLive` sets the time after which messages expire and are discarded or dead-lettered, not the number of delivery attempts. Option D is wrong because while `maxDeliveryCount` is set, its value is 10, not 3, so it does not satisfy the requirement of dead-lettering after exactly 3 failed delivery attempts.

Full explanation →

622

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 architecture review board prefers a managed Azure-native control.

A.Azure Blob Storage lifecycle policy

B.Azure Storage Queue

C.Azure Cache for Redis list only

D.Azure Service Bus topic

AnswerD

Service Bus topics implement publish/subscribe with independent subscriptions, so each subscriber receives its own copy and new subscribers can be added without publisher changes. Queues would deliver each message to only one consumer, breaking the fan-out requirement.

Why this answer

Azure Service Bus topics support a publish-subscribe pattern where multiple independent subscribers can process the same message. Subscribers can be added later without modifying the publisher, and each subscriber receives its own copy of the message through subscriptions. This matches the requirement for order events that must be processed by multiple independent subscribers.

Exam trap

The trap here is that candidates often confuse Azure Storage Queue (point-to-point) with Service Bus topics (pub-sub), failing to recognize that multiple independent subscribers require a topic-based pattern, not a queue.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage lifecycle policy is used to manage blob tiering and deletion based on age, not for messaging or event distribution. Option B is wrong because Azure Storage Queue implements a point-to-point queue pattern where a single consumer processes each message; it does not support multiple independent subscribers receiving the same message. Option C is wrong because Azure Cache for Redis list only provides a simple list data structure for FIFO operations, not a managed pub-sub messaging system with durable subscriptions and independent subscriber processing.

Full explanation →

623

MCQmedium

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

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

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

C.Windows container with 8 GB memory and 4 vCPUs

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

624

MCQmedium

A Cosmos DB container for session records receives hot-partition throttling because the partition key has only five possible values. What should the developer change? The design must avoid adding custom operational scripts.

A.Increase the default TTL

B.Enable analytical store only

C.Choose a partition key with higher cardinality and even request distribution

D.Use a stored procedure for every write

AnswerC

A hot partition arises when a single logical partition key value receives an excessive volume of requests, exhausting its allocated throughput and causing throttling. Choosing a partition key with higher cardinality ensures a greater number of distinct logical partitions, while ensuring even request distribution across these keys prevents any single partition from becoming a bottleneck. This strategy effectively spreads both data storage and request throughput across multiple physical partitions, resolving the hot partition issue and improving scalability.

Why this answer

Hot-partition throttling occurs when a partition key has low cardinality (few distinct values), causing uneven request distribution and exceeding the physical partition's throughput limits. Choosing a partition key with higher cardinality and even request distribution spreads operations across more physical partitions, eliminating throttling without custom scripts.

Exam trap

The trap here is that candidates confuse throughput scaling mechanisms (TTL, analytical store, stored procedures) with partition key design, which is the only way to resolve hot-partition throttling without custom scripts.

How to eliminate wrong answers

Option A is wrong because increasing the default TTL only affects document expiration and deletion, not partition-level throughput or request distribution. Option B is wrong because enabling analytical store only adds a columnar store for analytical queries; it does not affect transactional request routing or partition key design. Option D is wrong because using a stored procedure for every write does not change the partition key or distribution; it still writes to the same logical partition, so throttling persists.

Full explanation →

625

MCQmedium

You are developing a microservices application. Each microservice must authenticate to Azure SQL Database using its own identity. You need to minimize credential management overhead. What should you use?

A.System-assigned managed identities

B.User-assigned managed identities

C.Certificate-based authentication

D.Service principals with client secrets

AnswerA

System-assigned managed identities are automatically created and deleted with the Azure resource (e.g., an App Service, Azure Function, or AKS pod). They provide a unique identity for each specific microservice instance, enabling fine-grained access control to other Azure services without requiring developers to manage credentials. This approach simplifies the security posture by eliminating the need for manual secret rotation and ensuring identity isolation per service, aligning perfectly with microservice principles.

Why this answer

System-assigned managed identities enable each microservice to authenticate to Azure SQL Database without storing credentials in code or configuration. Azure automatically rotates the identity's service principal certificate and handles token acquisition via the Azure Instance Metadata Service (IMDS) endpoint, eliminating manual credential management. This is the simplest approach when each microservice has a one-to-one relationship with its Azure resource (e.g., App Service or Azure Function).

Exam trap

The trap here is that candidates often choose user-assigned managed identities thinking they offer more control, but the question specifically asks to minimize credential management overhead, and system-assigned identities are fully automated with zero manual setup beyond enabling the flag.

How to eliminate wrong answers

Option B is wrong because user-assigned managed identities require explicit assignment to each microservice resource and introduce additional management overhead for creating and maintaining the identity object, which contradicts the goal of minimizing credential management. Option C is wrong because certificate-based authentication requires manual certificate provisioning, renewal, and secure storage, adding significant operational burden compared to the fully managed token lifecycle of managed identities. Option D is wrong because service principals with client secrets require storing and rotating secrets in code, configuration, or a key vault, which increases credential management overhead and security risk.

Full explanation →

626

MCQmedium

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

627

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

628

MCQmedium

Backend APIs exposed through Azure API Management are consumed by multiple subscribers. The product owner wants to prevent any single subscriber from sending more than 100 requests per minute, while allowing subscribers with heavier plans to have higher limits configured separately. Which APIM policy implements per-subscriber rate limiting?

A.Apply the rate-limit-by-key policy using the subscription key as the counter key, with calls set to 100 and renewal-period to 60

B.Apply the quota policy to the product with a total of 100 calls per minute shared across all subscribers

C.Apply an ip-filter policy that blocks IP addresses making more than 100 requests per minute

D.Configure a backend circuit breaker policy to return cached responses after 100 calls

AnswerA

rate-limit-by-key with counter-key='@(context.Subscription.Id)' (or the subscription key header) creates a separate 100-calls/60-second counter per subscriber. When a subscriber's counter reaches 100, APIM returns 429 Too Many Requests for that subscriber while other subscribers continue at full rate.

Why this answer

The `rate-limit-by-key` policy in Azure API Management enforces a per-key rate limit, and using the subscription key as the counter key ensures each subscriber is limited individually. The `calls` parameter set to 100 and `renewal-period` to 60 seconds matches the requirement of 100 requests per minute per subscriber, while allowing different limits for different plans by applying separate policies with different call counts.

Exam trap

The trap here is confusing the `quota` policy (which sets a total limit shared across all subscribers of a product) with the `rate-limit-by-key` policy (which enforces per-subscriber limits), leading candidates to pick Option B when they see 'product' and 'per minute' without recognizing the shared vs. individual distinction.

How to eliminate wrong answers

Option B is wrong because the `quota` policy applied to a product with 100 calls per minute shared across all subscribers enforces a total limit for the entire product, not per subscriber, so a single subscriber could consume all 100 calls and block others. Option C is wrong because the `ip-filter` policy blocks or allows traffic based on IP addresses, but it cannot track request counts per minute or differentiate between subscribers sharing the same IP (e.g., behind a NAT), and it does not provide rate limiting based on subscription keys. Option D is wrong because a backend circuit breaker policy is used to protect the backend from overload by returning cached responses after a failure threshold, not to limit client request rates; it does not track per-subscriber request counts or enforce rate limits.

Full explanation →

629

MCQmedium

You are building an Azure Logic App that must consume messages from an Azure Service Bus queue. The queue messages are JSON payloads containing order information. The Logic App must process each message exactly once and in the order they are received. You need to configure the trigger in the Logic App. Which trigger type and property should you choose?

A.Use a Service Bus trigger with the 'PeekLock' mode and set the 'IsSessionsEnabled' property to false

B.Use a Service Bus trigger with the 'ReceiveAndDelete' mode

C.Use a Service Bus trigger with the 'PeekLock' mode and set the 'IsSessionsEnabled' property to true

D.Use an Event Grid trigger for Service Bus

AnswerC

The 'PeekLock' mode ensures 'at-least-once' delivery by requiring the Logic App to explicitly complete or abandon a message, allowing for reprocessing on failure. Crucially, enabling 'IsSessionsEnabled' on the Service Bus queue or topic guarantees First-In, First-Out (FIFO) ordering for messages within a specific session. Combining these features provides both reliable message processing with retry capabilities and strict message order, fulfilling the requirements for exactly-once processing and ordered consumption.

Why this answer

Service Bus sessions provide first-in-first-out (FIFO) ordering and exactly-once processing. By enabling sessions (IsSessionsEnabled = true) and using PeekLock mode, the Logic App can lock a message while processing, ensuring it is not delivered to other consumers, and sessions guarantee that messages with the same session ID are processed in order. This meets the requirement of processing each message exactly once and in the order received.

Exam trap

The trap here is that candidates often assume PeekLock mode alone guarantees ordering, but without sessions, multiple concurrent trigger instances can pick up messages from the same queue out of order, breaking the FIFO requirement.

How to eliminate wrong answers

Option A is wrong because PeekLock mode without sessions (IsSessionsEnabled = false) does not guarantee message ordering; messages may be processed out of order if multiple triggers fire concurrently. Option B is wrong because ReceiveAndDelete mode removes the message from the queue immediately upon retrieval, making it impossible to retry processing on failure and violating exactly-once semantics. Option D is wrong because an Event Grid trigger for Service Bus is designed for event-driven notifications (e.g., when a queue has messages) but does not provide built-in ordering or exactly-once processing guarantees; it also introduces potential duplicate deliveries.

Full explanation →

630

MCQeasy

You are building an Azure Logic App that must call an external REST API. The API requires an API key passed in the Authorization header. You need to store the API key securely and reference it in the Logic App without exposing it in the workflow definition. What should you do?

A.A

B.B

C.C

D.D

AnswerA

Azure Key Vault is the recommended service for securely storing secrets like API keys. It encrypts secrets at rest and in transit, and access is controlled via Azure RBAC or Key Vault access policies. By assigning a Managed Identity to the Logic App and granting it "Get" permissions on the secret in Key Vault, the Logic App can securely retrieve the API key at runtime using the built-in Key Vault connector, ensuring the key is never exposed in the Logic App's definition or logs.

Why this answer

Azure Logic Apps can securely reference API keys stored in Azure Key Vault using a managed identity. By configuring the Logic App with a system-assigned or user-assigned managed identity, you grant it access to retrieve the secret from Key Vault at runtime without hardcoding the key in the workflow definition or connection parameters. This approach ensures the API key is never exposed in the Logic App's JSON definition or source control.

Exam trap

The trap here is that candidates often confuse Azure App Configuration with Azure Key Vault, assuming App Configuration's encrypted storage is sufficient for secrets, but Key Vault is the only service designed for managing and auditing access to sensitive secrets like API keys.

How to eliminate wrong answers

Option B is wrong because storing the API key directly in the Logic App's connection parameters or workflow definition, even if marked as a secure string, still embeds the secret in the definition file and can be exposed through source control or runtime history. Option C is wrong because using an Azure App Configuration reference with a plain-text value does not provide encryption at rest or access control; it still requires the key to be stored in the configuration store without native secret management. Option D is wrong because passing the API key as a query parameter in the HTTP request URL exposes the secret in server logs, browser history, and network traces, violating security best practices.

Full explanation →

631

MCQmedium

You are building an integration solution that connects an on-premises SQL Server database to Azure Data Factory. The on-premises network does not allow direct inbound connections from Azure. You need to securely transfer data from the database to Azure Blob Storage. Which data factory component should you use?

A.Self-hosted Integration Runtime

B.Azure Integration Runtime

C.Azure-SSIS Integration Runtime

D.Azure Data Lake Storage connector

AnswerA

The Self-hosted Integration Runtime is the correct choice because it is specifically designed to be installed on a machine within the on-premises network. This runtime acts as a secure, outbound-only gateway, initiating connections to Azure Data Factory via HTTPS. It allows Azure services to securely access on-premises data sources like SQL Server without requiring any inbound firewall ports to be opened, aligning perfectly with strict security requirements for hybrid data movement.

Why this answer

The Self-hosted Integration Runtime (SHIR) is required because the on-premises SQL Server database resides in a network that blocks direct inbound connections from Azure. SHIR acts as a bridge, running on a local machine or VM within the on-premises network, enabling Azure Data Factory to securely connect to the database via outbound HTTPS (port 443) or the Microsoft Service Bus. It handles data movement and transformation without exposing the on-premises network to inbound traffic.

Exam trap

The trap here is that candidates often confuse the Azure Integration Runtime (which works only for cloud-to-cloud scenarios) with the Self-hosted Integration Runtime, assuming Azure's built-in runtime can somehow tunnel into on-premises networks without explicit configuration.

How to eliminate wrong answers

Option B (Azure Integration Runtime) is wrong because it operates entirely within Azure's public cloud and cannot access on-premises resources behind a firewall that blocks inbound connections. Option C (Azure-SSIS Integration Runtime) is wrong because it is designed for lifting and shifting SQL Server Integration Services (SSIS) packages to Azure, not for direct data transfer between on-premises SQL Server and Azure Blob Storage via ADF pipelines. Option D (Azure Data Lake Storage connector) is wrong because it is a data sink or source connector, not a compute component for connectivity; it requires an Integration Runtime to actually move data.

Full explanation →

632

Multi-Selecthard

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

Select 3 answers

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

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

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

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

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

AnswersA, C, E

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

Why this answer

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

Exam trap

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

Full explanation →

633

MCQeasy

You need to deploy a web app that uses Azure SQL Database. The connection string must be securely stored and automatically rotated without application downtime. What should you use?

A.Store the connection string as an environment variable in the App Service.

B.Store the connection string in a web.config file with encrypted configuration.

C.Store the connection string in Azure App Configuration and use a managed identity.

D.Store the connection string in Azure Key Vault and configure automatic rotation.

AnswerD

Azure Key Vault is the recommended service for securely storing and managing sensitive information like connection strings, API keys, and certificates. It provides a centralized, highly secure repository with robust access control policies, auditing capabilities, and crucially, support for automatic secret rotation. By integrating Key Vault with an Azure App Service using a managed identity, the application can securely retrieve the connection string at runtime without ever exposing it in configuration files or environment variables, ensuring optimal security and compliance.

Why this answer

Azure Key Vault provides centralized, secure storage for secrets like connection strings, and its automatic rotation feature (via Key Vault rotation policies or integration with Azure SQL) allows secrets to be updated without requiring application restarts or downtime. The App Service can access the vault using a managed identity, ensuring the connection string is never exposed in code or configuration files.

Exam trap

The trap here is that candidates confuse Azure App Configuration (which is for app settings, not secrets) with Azure Key Vault, or assume that encrypted configuration files or environment variables are sufficient for automatic rotation, overlooking the need for a dedicated secret store with rotation capabilities.

How to eliminate wrong answers

Option A is wrong because environment variables in App Service are not automatically rotated and require manual updates or redeployments, which can cause downtime or configuration drift. Option B is wrong because encrypting a web.config file does not provide automatic rotation and still exposes the connection string at rest within the application package, violating security best practices for secret management. Option C is wrong because Azure App Configuration is designed for feature flags and application settings, not for secret storage; it lacks native automatic rotation capabilities and does not enforce access policies like Key Vault.

Full explanation →

634

MCQmedium

You are developing a serverless application using Azure Functions that processes sensitive data. The function needs to access Azure Key Vault to retrieve a secret. You want to use managed identity for authentication. What should you do first?

A.Enable the system-assigned managed identity on the function app and grant it the Key Vault Secrets User role.

B.Enable the system-assigned managed identity on the Key Vault.

C.Store the client ID and client secret of a service principal in the function app settings.

D.Create a user-assigned managed identity and assign it to the Key Vault.

AnswerA

Enabling a system-assigned managed identity on the Azure Function App automatically provisions a unique identity in Azure Active Directory, intrinsically linked to the function's lifecycle. Granting this identity the 'Key Vault Secrets User' role provides the necessary Azure Role-Based Access Control (RBAC) permissions for the function to securely retrieve secrets from Key Vault. This robust pattern eliminates the need for developers to manage credentials in code or configuration, significantly enhancing security and simplifying secret rotation.

Why this answer

To use managed identity for authentication with Azure Key Vault, the first step is to enable a system-assigned managed identity on the function app, which creates an identity in Azure AD tied to the resource. Then, you must grant that identity the appropriate role (e.g., Key Vault Secrets User) on the Key Vault to authorize secret retrieval. This eliminates the need for storing credentials in code or configuration.

Exam trap

The trap here is that candidates often confuse which resource gets the managed identity (the function app) versus where permissions are assigned (the Key Vault), leading them to incorrectly enable the identity on the Key Vault itself.

How to eliminate wrong answers

Option B is wrong because managed identity is enabled on the Azure resource (the function app), not on the Key Vault itself; Key Vault uses access policies or RBAC roles to grant permissions to identities. Option C is wrong because it describes using a service principal with client ID and secret, which contradicts the requirement to use managed identity and introduces credential management overhead. Option D is wrong because a user-assigned managed identity is created separately and assigned to the function app, not to the Key Vault; the identity must be assigned to the resource that needs to authenticate, and then granted permissions on the Key Vault.

Full explanation →

635

MCQmedium

You need to diagnose a slow-performing Azure Function. Application Insights shows that the function's dependency calls to an external API take an unusually long time. Which Application Insights feature should you use to visualize the end-to-end request flow?

A.Metrics Explorer

B.Live Metrics Stream

C.Application Map

D.Smart Detection

AnswerC

Application Map in Application Insights is specifically designed to visualize the logical architecture of your application, showing how different components interact and depend on each other. It automatically discovers and maps all application components, including Azure Functions, databases, and external services, displaying the call flow and highlighting performance metrics for each connection. This graphical representation makes it straightforward to identify bottlenecks, slow dependencies, and error rates across the entire distributed system, directly addressing the need to diagnose a slow performing Azure Function by pinpointing the exact problematic dependency.

Why this answer

Application Map is the correct feature because it provides a visual representation of the end-to-end request flow across distributed components, including dependency calls to external APIs. It shows the latency and failure rates for each dependency, allowing you to pinpoint where the slowdown occurs in the overall transaction.

Exam trap

The trap here is that candidates often confuse Live Metrics Stream (real-time monitoring) with Application Map (end-to-end flow visualization), or they think Metrics Explorer can trace individual requests when it only aggregates data over time.

How to eliminate wrong answers

Option A is wrong because Metrics Explorer is used to query and visualize aggregated metrics (e.g., request count, failure rate) over time, not to trace the flow of a single request through dependencies. Option B is wrong because Live Metrics Stream shows real-time telemetry (e.g., incoming requests, CPU usage) but does not provide a historical or dependency-level flow visualization. Option D is wrong because Smart Detection proactively identifies anomalies (e.g., sudden spikes in failures) using machine learning, but it does not offer a manual, interactive map of request paths.

Full explanation →

636

MCQmedium

Refer to the exhibit. You are reviewing an ARM template for a storage account. A security audit requires that all storage accounts enforce TLS 1.2 or higher. Does this configuration meet the requirement?

A.No, because supportsHttpsTrafficOnly does not enforce TLS version

B.Yes, because minimumTlsVersion is set to TLS1_2

C.No, because minimumTlsVersion is not a valid property

D.No, because the property should be minimumTlsVersion: "1.2"

AnswerB

Setting `minimumTlsVersion` to `TLS1_2` in the storage account's properties enforces TLS 1.2 as the floor, rejecting TLS 1.0 and 1.1 connections. This directly satisfies the audit constraint that all storage accounts enforce TLS 1.2 or higher, since the ARM template property governs the minimum accepted protocol version at the service endpoint.

Why this answer

The `minimumTlsVersion` property in the ARM template explicitly enforces the minimum TLS version for requests to the storage account. Setting it to `TLS1_2` ensures that only TLS 1.2 or higher connections are accepted, meeting the security audit requirement. The `supportsHttpsTrafficOnly` property only enforces HTTPS but does not control the TLS version, so it alone is insufficient.

Exam trap

The trap here is that candidates confuse `supportsHttpsTrafficOnly` (which only enforces HTTPS, not TLS version) with the `minimumTlsVersion` property, or they assume the property uses a version string like `"1.2"` instead of the correct enum value `TLS1_2`.

How to eliminate wrong answers

Option A is wrong because `supportsHttpsTrafficOnly` only redirects HTTP traffic to HTTPS but does not restrict the TLS version; the `minimumTlsVersion` property is required to enforce TLS 1.2 or higher. Option C is wrong because `minimumTlsVersion` is a valid property for Azure Storage accounts in ARM templates, with accepted values like `TLS1_0`, `TLS1_1`, and `TLS1_2`. Option D is wrong because the correct value for TLS 1.2 in the ARM template is `TLS1_2` (with an underscore), not `"1.2"`; the property expects a string matching the predefined enum values.

Full explanation →

637

MCQeasy

Refer to the exhibit. A developer is creating an Azure Data Factory pipeline to copy data from Azure Blob Storage to Azure SQL Database. The pipeline fails with a timeout error when copying large files. Which action should the developer take to resolve the issue?

A.Change the source type to DelimitedTextSource

B.Enable Data Integration Units (DIU) to increase throughput

C.Increase the timeout value in the copy activity settings

D.Use a staging copy with Azure Data Lake Storage Gen2

AnswerC

Increasing the timeout value directly addresses the problem of an activity failing because it exceeds its maximum allowed execution duration. For Azure Data Factory copy activities, this setting dictates how long the activity will attempt to run before being terminated. When dealing with large files, slow source/sink systems, or network latency, extending this timeout provides the necessary window for the entire data transfer operation to complete successfully, preventing premature termination errors.

Why this answer

The copy activity in Azure Data Factory has a default timeout of 7 days, but when copying large files, the activity may fail due to the default timeout for the underlying HTTP request to Blob Storage (which is 7 minutes for a single block). Increasing the timeout value in the copy activity settings allows more time for the entire file transfer to complete, especially for large files that require multiple retries or slower network conditions.

Exam trap

The trap here is that candidates often confuse increasing throughput (DIU) with increasing timeout, not realizing that the error is caused by a fixed time limit per request, not by insufficient parallelism or compute resources.

How to eliminate wrong answers

Option A is wrong because changing the source type to DelimitedTextSource does not affect the timeout behavior; it only changes how the data is parsed, not the underlying network or transfer timeout. Option B is wrong because Data Integration Units (DIU) control the parallelism and compute resources for the copy activity, not the timeout duration; enabling DIU increases throughput but does not prevent a timeout error caused by a fixed time limit. Option D is wrong because using a staging copy with Azure Data Lake Storage Gen2 is an optimization for cross-region or hybrid copies, but it does not inherently resolve a timeout error; the timeout issue would still apply to the staging copy operation.

Full explanation →

638

MCQeasy

Your application running on Azure App Service is experiencing intermittent high latency. You have enabled Application Insights and noticed that the 'Server response time' metric spikes during peak hours. What is the most likely cause of this issue?

A.Auto-scaling is configured too aggressively.

B.The application is using regional failover, causing delays.

C.The App Service plan is under-provisioned and hitting CPU limits.

D.The application is using too much memory.

AnswerC

When an App Service plan is under-provisioned, its allocated CPU resources may become fully saturated during periods of high demand, such as peak hours. Hitting CPU limits means the server cannot process new requests immediately, leading to a backlog in the request queue. This directly results in significantly increased application response times and observable latency spikes, as requests must wait for CPU cycles to become available, indicating a need for scaling up or out.

Why this answer

Intermittent high latency during peak hours, reflected in the 'Server response time' metric, typically indicates that the App Service plan is under-provisioned. When CPU usage hits the plan's limits, requests queue up and response times increase. Auto-scaling would mitigate this, but if the plan is under-provisioned (e.g., a B1 plan with limited cores), scaling out may not occur quickly enough or may be disabled, causing CPU saturation and latency spikes.

Exam trap

The trap here is that candidates confuse high memory usage with CPU saturation; memory pressure causes different symptoms (e.g., 500 errors, restarts) while CPU limits directly manifest as increased response times, making option D a distractor.

How to eliminate wrong answers

Option A is wrong because auto-scaling configured too aggressively would actually reduce latency by adding instances preemptively; the issue here is latency spikes, which suggest scaling is insufficient or not triggered. Option B is wrong because regional failover is a disaster recovery mechanism that introduces latency only during failover events, not intermittently during peak hours; it would not cause recurring daily spikes. Option D is wrong because high memory usage typically causes out-of-memory exceptions or application restarts, not directly 'Server response time' latency spikes; CPU saturation is the primary driver of response time degradation.

Full explanation →

639

Multi-Selectmedium

You are designing a data archiving solution for compliance. Data must be stored for 7 years, with immediate deletion prohibited until the retention period expires. The solution must minimize storage costs while ensuring data is not modifiable. Which THREE Azure features should you combine?

Select 3 answers

A.Azure Blob Storage

B.Immutable storage with time-based retention policy

C.Azure Files

D.Cool or Archive access tier

E.Azure Backup

AnswersA, B, D

Azure Blob Storage is the foundational, highly scalable, and durable object storage service in Azure, making it the primary choice for storing large volumes of unstructured data like archives. Its inherent design supports massive scale, high availability, and cost-effectiveness, providing the essential platform upon which advanced archiving features like immutability and tiered storage are built for compliance solutions.

Why this answer

Azure Blob Storage is the correct foundational service because it supports immutable storage, which enforces a WORM (Write Once, Read Many) policy. This ensures data cannot be modified or deleted during the retention period, meeting compliance requirements. Combined with time-based retention policies and cool/archive tiers, it provides a cost-effective, unmodifiable archive solution.

Exam trap

The trap here is that candidates often confuse Azure Files or Azure Backup as viable archiving solutions, overlooking that only Blob Storage with immutable policies provides the WORM guarantee required for compliance-driven data retention.

Full explanation →

640

MCQeasy

You want to ensure that data in an Azure Storage account is replicated across multiple Azure regions to protect against regional outages. Which replication option should you choose?

A.Geo-redundant storage (GRS)

B.Locally-redundant storage (LRS)

C.Read-access geo-redundant storage (RA-GRS)

D.Zone-redundant storage (ZRS)

AnswerA

Geo-redundant storage (GRS) is the correct choice because it ensures data durability by asynchronously replicating data from the primary region to a secondary region hundreds of miles away. This strategy protects against regional outages or major disasters affecting the entire primary datacenter location. With GRS, Azure maintains three copies of your data within the primary region and three additional copies in the paired secondary region, offering 11 nines (99.999999999%) of durability over a given year. This robust replication guarantees that your data remains available even if the primary region becomes completely unavailable.

Why this answer

Geo-redundant storage (GRS) replicates your data synchronously three times within a primary region using LRS, then asynchronously replicates to a secondary region hundreds of miles away. This ensures data survives a complete regional outage because the secondary copy is available for read or write access after a failover, meeting the requirement for cross-region protection.

Exam trap

The trap here is that candidates often choose RA-GRS because they think read access is required for disaster recovery, but the question only asks for replication to protect against regional outages, making GRS the correct choice without the extra read-access feature.

How to eliminate wrong answers

Option B (LRS) is wrong because it replicates data only within a single datacenter in one region, providing no protection against a regional outage. Option C (RA-GRS) is wrong because while it does replicate across regions like GRS, it additionally provides read access to the secondary region during normal operations, which is not required by the question—the question only asks for replication to protect against regional outages, not read access. Option D (ZRS) is wrong because it replicates data synchronously across three availability zones within a single region, protecting against zone-level failures but not against a full regional outage.

Full explanation →

641

MCQmedium

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

642

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

643

MCQmedium

Your company stores backup files in an Azure Blob Storage account. These files are written once and then need to be retained for 7 years. During the first year, the files are accessed weekly. After the first year, they are accessed rarely (once per month). You want to minimize storage costs. Which combination of access tiers and lifecycle management should you apply?

A.Store in Hot tier and move to Cool after 1 year, then to Archive after 7 years.

B.Store in Cool tier and move to Archive after 1 year.

C.Store directly in Archive tier and rehydrate to Cool when needed for access.

D.Store in Hot tier and move to Archive after 90 days.

AnswerA

Moving to Cool after 1 year is too late; the data is already rarely accessed. Also moving to Archive after 7 years is unnecessary because the retention period ends. The data should be in Archive for most of the retention.

Why this answer

For data accessed weekly during the first year, the Hot tier is appropriate, or the Cool tier if storage cost savings significantly outweigh transaction costs. For data accessed monthly after the first year, the Cool tier is the most cost-effective choice, balancing lower storage costs with reasonable access costs without incurring rehydration fees or significant latency. The Archive tier is suitable only for data that is rarely accessed (e.g., less than once a year) and can tolerate significant retrieval latency and cost.

Therefore, the optimal strategy among the given options is to store in Hot for the first year, move to Cool for the subsequent years of monthly access, and then to Archive only after the 7-year retention period if access truly ceases.

Exam trap

The trap here is that candidates assume the Hot tier is always the best starting point for any access pattern, ignoring that Cool tier is cheaper for data accessed less than once a month, and that Archive tier is not suitable for data that requires regular access within the first year due to its high rehydration latency and cost.

How to eliminate wrong answers

Option A is wrong because moving files to the Archive tier after 7 years is unnecessary—the files are retained for exactly 7 years, so moving them to Archive at the end of retention provides no cost benefit and may incur deletion charges if deleted immediately. Option C is wrong because storing directly in the Archive tier would require rehydration (which can take up to 15 hours) for the weekly accesses during the first year, causing unacceptable latency and additional read/retrieval costs. Option D is wrong because moving files to the Archive tier after only 90 days ignores the first-year weekly access pattern, leading to frequent rehydration costs and latency; also, the Hot tier is more expensive than Cool for the initial storage.

Full explanation →

644

MCQmedium

An Azure Function processes events from Event Hubs. You need to monitor the number of events that were successfully processed and those that were dropped due to processing errors. Which approach should you use?

A.Custom metrics in Application Insights.

B.Event Hubs metrics.

C.Stream Analytics job.

D.Log Analytics query on function logs.

AnswerA

Custom metrics in Application Insights is the most appropriate solution because it allows developers to instrument their Azure Function code directly. By utilizing the Application Insights SDK, the function can explicitly send numerical data points, such as counts of successfully processed events or dropped events, to Application Insights. This provides real-time, granular visibility into the function's internal processing logic and operational health, enabling effective monitoring and alerting based on actual event outcomes.

Why this answer

Custom metrics in Application Insights allow you to track business-specific counters like successfully processed events and dropped events directly from your Azure Function code. By using the `TelemetryClient.TrackMetric()` API within the function's event processing logic, you can increment counters for success and failure scenarios, giving you precise, real-time monitoring of processing outcomes. This approach is more granular than built-in metrics because it reflects your application's custom error handling, not just infrastructure-level throughput.

Exam trap

The trap here is that candidates confuse infrastructure-level metrics (Event Hubs metrics) with application-level custom metrics, assuming that monitoring the Event Hubs output automatically reflects function processing success, when in fact the function's own error handling must be instrumented separately.

How to eliminate wrong answers

Option B is wrong because Event Hubs metrics (e.g., incoming messages, outgoing messages, throttled requests) measure the throughput at the Event Hubs namespace level, not the success or failure of downstream processing in the Azure Function. Option C is wrong because Stream Analytics is a real-time analytics service for processing streaming data, not a monitoring tool for tracking custom application-level events like processed vs. dropped counts. Option D is wrong because Log Analytics queries on function logs can retrieve logged events, but they require parsing unstructured log text and lack the real-time, aggregated metric capabilities that custom metrics in Application Insights provide for dashboards and alerts.

Full explanation →

645

MCQhard

Your company uses Azure File Sync to sync on-premises file shares to Azure Files. You notice that some files are not syncing to Azure. You need to diagnose the issue with minimal administrative effort. Which Azure service should you use?

A.Microsoft Sentinel

B.Azure Storage Insights

C.Azure Monitor

D.Azure Log Analytics

AnswerC

Azure Monitor is the comprehensive solution for collecting, analyzing, and acting on telemetry data from Azure and on-premises environments. For Azure File Sync, it offers built-in metrics, logs, and alerts specifically designed to monitor sync health, server endpoint status, cloud tiering activity, and common sync errors. Its integration provides a centralized platform for diagnosing and troubleshooting File Sync replication issues effectively through pre-built workbooks and diagnostic views.

Why this answer

Azure Monitor provides the Azure File Sync monitoring blade, which offers pre-built metrics and alerts for sync health, file-level errors, and sync session status. This allows you to diagnose sync failures with minimal administrative effort by directly viewing sync group health, per-server sync status, and error codes without needing to configure additional log queries or workbooks.

Exam trap

The trap here is that candidates confuse Azure Monitor (the overarching monitoring platform) with Azure Log Analytics (a component of Azure Monitor that requires manual query authoring), leading them to choose Log Analytics because they think they need to write custom queries, when in fact the pre-built Azure File Sync monitoring blade in Azure Monitor provides the quickest diagnosis path.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel is a SIEM (Security Information and Event Management) tool focused on security threat detection and response, not on diagnosing Azure File Sync sync issues. Option B is wrong because Azure Storage Insights provides monitoring for Azure Storage accounts (blobs, tables, queues) but does not include the Azure File Sync monitoring blade or sync-specific metrics. Option D is wrong because Azure Log Analytics is a log query and analysis service that requires you to write custom KQL queries to extract sync data, which involves more administrative effort than using the pre-built Azure Monitor sync monitoring blade.

Full explanation →

646

MCQmedium

You are developing a solution that must encrypt data before it is sent to Azure Blob Storage. You need to manage encryption keys yourself using Azure Key Vault. Which approach should you use?

A.Use Azure Information Protection to encrypt the files.

B.Use Azure Disk Encryption for the storage account.

C.Implement client-side encryption using the Azure Storage SDK and store the encryption keys in Azure Key Vault.

D.Enable Azure Storage Service Encryption (SSE) with customer-managed keys.

AnswerC

Implementing client-side encryption using the Azure Storage SDK ensures that data is encrypted by the application on the client machine *before* it is transmitted over the network and stored in Azure Storage. This approach provides the highest level of control over the encryption process and keys, directly addressing the requirement to encrypt data *before* storage. Storing the encryption keys securely in Azure Key Vault is a best practice, centralizing key management and enhancing security posture.

Why this answer

Client-side encryption with the Azure Storage SDK allows you to encrypt data before it leaves your application, ensuring it is never transmitted or stored in plaintext. By storing the encryption keys in Azure Key Vault, you maintain full control over key management, which aligns with the requirement to manage encryption keys yourself.

Exam trap

The trap here is that candidates often confuse server-side encryption (SSE) with client-side encryption, assuming that SSE with customer-managed keys satisfies the requirement to encrypt data before sending, when in fact SSE only encrypts data at rest after it arrives at Azure.

How to eliminate wrong answers

Option A is wrong because Azure Information Protection is a classification and labeling solution for documents and emails, not a mechanism for encrypting data before sending to Blob Storage. Option B is wrong because Azure Disk Encryption is used to encrypt virtual machine disks, not data being uploaded to Blob Storage. Option D is wrong because Azure Storage Service Encryption (SSE) with customer-managed keys encrypts data at rest on the server side, but the data is still transmitted in plaintext to Azure; it does not meet the requirement to encrypt data before it is sent.

Full explanation →

647

Multi-Selectmedium

Which TWO of the following are valid approaches to secure access to Azure Blob Storage?

Select 2 answers

A.Use a Shared Access Signature (SAS) token

B.Use Azure Front Door to restrict access

C.Assign RBAC roles like Storage Blob Data Contributor

D.Embed storage account keys in client code

E.Enable public blob access

AnswersA, C

Shared Access Signatures (SAS) tokens provide a secure, delegated way to grant time-limited access to specific Azure Storage resources, such as blobs or containers. They allow you to define granular permissions (read, write, delete, list) and a validity period, ensuring that clients only have the necessary access for a defined duration without exposing your storage account keys. This approach is highly effective for distributing access to external clients or web applications.

Why this answer

Option A is correct because a Shared Access Signature (SAS) is a signed URI token that grants time-limited, scoped, and permission-specific delegated access to Blob Storage resources (containers, blobs, or specific operations like read/write) without exposing the storage account keys. Option C is correct because Azure RBAC roles such as Storage Blob Data Contributor (and Storage Blob Data Reader/Owner) grant Microsoft Entra ID identities fine-grained, least-privilege access to blob data at the management and data-plane level, which is the recommended modern approach for securing Blob Storage. Option B is not a valid access-control mechanism for Blob Storage itself — Azure Front Door is a global HTTP load balancer/CDN that can front a storage endpoint but does not authenticate or authorize blob access.

Option D is incorrect because embedding storage account keys in client code exposes full administrative credentials to anyone who obtains the code, violating security best practices. Option E is incorrect because enabling public blob access allows anonymous unauthenticated reads of blobs, which directly weakens rather than secures access.

Exam trap

The trap here is that candidates often confuse Azure Front Door's traffic routing and WAF capabilities with actual blob-level authentication, or they mistakenly believe embedding storage account keys is acceptable for client-side applications, ignoring the severe security implications.

Full explanation →

648

MCQmedium

You have an Azure App Service web app that uses a system-assigned managed identity. The web app needs to authenticate to an Azure SQL Database to read and write data. You want to use the managed identity to avoid storing credentials in connection strings. Which steps are required to configure this access?

A.Assign the managed identity the 'SQL DB Contributor' RBAC role on the database, then use SQL authentication with the identity's client ID.

B.Create a contained database user in the SQL database mapped to the managed identity, grant required database roles, and use Microsoft Entra ID token-based authentication from the app.

C.Enable Microsoft Entra ID authentication on the SQL server, add the managed identity as an Microsoft Entra ID admin, and use integrated security in the connection string.

D.Configure the connection string with the managed identity's principal ID as the user ID and leave the password empty.

AnswerB

This is the correct procedure. The managed identity (an Microsoft Entra ID principal) must be added as a database user. The app then acquires an access token for Azure SQL Database using the managed identity and uses it to connect.

Why this answer

To use a system-assigned managed identity with Azure SQL Database, you must create a contained database user mapped to the managed identity in the SQL database, grant it the necessary database roles (e.g., db_datareader, db_datawriter), and then acquire an access token for Microsoft Entra ID (formerly Azure AD) from the managed identity endpoint to authenticate. This token-based approach avoids storing credentials and leverages the managed identity's automatic credential rotation.

Exam trap

The trap here is that candidates confuse Azure RBAC roles (which manage control-plane access) with SQL database-level permissions (which manage data-plane access), leading them to incorrectly select Option A or C instead of understanding that a contained database user and token-based authentication are required.

How to eliminate wrong answers

Option A is wrong because 'SQL DB Contributor' is an Azure RBAC role that controls management-plane operations (e.g., creating databases), not data-plane access to read/write data; SQL authentication with the identity's client ID is not supported—managed identities use token-based authentication, not SQL authentication. Option C is wrong because adding the managed identity as an Entra ID admin grants server-level administrative privileges, which is overly permissive and not the recommended least-privilege approach; 'integrated security' is a Windows Authentication concept and does not apply to managed identities in Azure App Service. Option D is wrong because connection strings cannot use the managed identity's principal ID as a user ID with an empty password; managed identity authentication requires acquiring a token from the Azure Instance Metadata Service (IMDS) endpoint and passing it as a password in the connection string or using a token-based library like Microsoft.Data.SqlClient.

Full explanation →

649

MCQmedium

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

A.The function app uses the latest runtime version.

B.Remote debugging is enabled for the function app.

C.The function app scales out to multiple instances.

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

650

Multi-Selecthard

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

Select 2 answers

A.Enable a managed identity for the web app

B.Enable anonymous access on the vault

C.Grant the identity permission to read the required secrets

D.Store the Key Vault access key in app settings

AnswersA, C

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

Why this answer

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

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

Exam trap

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

Full explanation →

651

MCQeasy

A company uses Azure Functions to process orders. The function needs to read messages from an Azure Service Bus queue. Which binding should the developer configure in the function.json?

A.serviceBus

B.eventHubTrigger

C.queueTrigger

D.serviceBusTrigger

AnswerD

The "serviceBusTrigger" binding is the correct and designated mechanism for an Azure Function to be invoked in response to messages arriving on an Azure Service Bus queue or topic. This trigger automatically handles message reception, deserialization, and completion, allowing the function to process messages reliably. It supports various Service Bus features, including peek-lock processing, message sessions, and dead-lettering, making it ideal for robust enterprise messaging scenarios like order processing.

Why this answer

The correct binding for reading messages from an Azure Service Bus queue in an Azure Functions app is `serviceBusTrigger`. This trigger binding listens to a Service Bus queue or topic subscription and invokes the function when a message arrives. Option D is correct because it specifically names the Service Bus trigger, which is designed for this purpose.

Exam trap

The trap here is that candidates confuse Azure Storage queues (`queueTrigger`) with Azure Service Bus queues (`serviceBusTrigger`), as both are messaging services but use different trigger bindings and have distinct features like sessions and topics in Service Bus.

How to eliminate wrong answers

Option A is wrong because `serviceBus` is not a valid binding type; the correct binding names are `serviceBusTrigger` for triggers and `serviceBus` for output bindings. Option B is wrong because `eventHubTrigger` is used to consume events from Azure Event Hubs, not Service Bus queues. Option C is wrong because `queueTrigger` is used for Azure Storage queues, not for Azure Service Bus queues.

Full explanation →

652

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

653

MCQeasy

Your application uses Azure Key Vault to store secrets. You need to ensure that the application can access secrets without storing any credentials in the application code or configuration files. What should you use?

A.Azure Managed Identity

B.Key Vault access policies

C.A connection string with the secret

D.A client certificate stored in the application

AnswerA

Azure Managed Identity gives the application a Microsoft Entra ID service principal whose credentials Azure manages and rotates automatically, so no secret is stored in code or configuration. Assigning it Key Vault access via RBAC or access policy satisfies the credential-free requirement directly.

Why this answer

Azure Managed Identity provides an automatically managed identity in Microsoft Entra ID for the application to authenticate to Azure Key Vault without any credentials in code or configuration. The application requests a token from the managed identity endpoint, and Key Vault validates that token against its access policy or RBAC role assignment. This eliminates secret storage entirely for the authentication step.

Exam trap

AZ-204 often tests credential-free authentication — candidates pick 'access policies' or 'client certificate' because they sound secure, missing that only managed identity removes credentials from code and configuration entirely.

How to eliminate wrong answers

Option B is wrong because Key Vault access policies define what an identity can do once authenticated — they do not provide the authentication mechanism itself, so credentials would still be needed. Option C is wrong because a connection string containing the secret is exactly the anti-pattern the question asks to avoid — it stores credentials in configuration. Option D is wrong because a client certificate stored in the application is still a credential that must be protected and rotated, defeating the goal of credential-free authentication.

Full explanation →

654

Multi-Selecthard

Which THREE tools can you use to diagnose performance issues in an Azure App Service? (Choose three.)

Select 3 answers

A.Application Insights

B.App Service diagnostics (Diagnose and Solve Problems)

C.Azure Monitor for VMs

D.Azure SQL Analytics

E.Kudu console for logging and debugging

AnswersA, B, E

Application Insights, a component of Azure Monitor, provides comprehensive Application Performance Management (APM) for live web applications. It automatically collects telemetry data such as request rates, response times, failure rates, and dependency calls, enabling developers to detect and diagnose performance anomalies, exceptions, and bottlenecks within the application code itself. Its distributed tracing capabilities are invaluable for understanding the flow of requests across different services and identifying slow components.

Why this answer

Application Insights is a feature of Azure Monitor that provides application performance management (APM) and telemetry for live web applications. It automatically detects performance anomalies, includes powerful analytics tools to help diagnose issues, and allows you to understand how an app is performing and being used. For an Azure App Service, you can enable Application Insights with just a few clicks to start collecting request rates, response times, failure rates, and dependency tracking.

Exam trap

The trap here is that candidates often confuse Azure Monitor for VMs with the general Azure Monitor platform, mistakenly thinking it applies to all Azure resources, when in fact it is VM-specific and cannot diagnose PaaS-level App Service issues.

Full explanation →

655

MCQeasy

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

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

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

C.Use Azure Files for image storage.

D.Make the Blob container public for anonymous uploads.

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

656

MCQeasy

You are using Application Insights to monitor a web application. You need to create an alert that triggers when the server response time exceeds 5 seconds for more than 10% of requests in a 5-minute window. Which type of Azure Monitor alert should you create?

A.Metric alert

B.Log alert

C.Activity log alert

D.Application Insights smart detection alert

AnswerB

Log alerts leverage Kusto Query Language (KQL) to execute custom queries against your Application Insights logs. This powerful capability allows you to filter requests by duration, count them, and then calculate the precise percentage of requests exceeding a specific threshold (e.g., 5000 ms) relative to the total requests within the evaluation period. The alert then triggers when this calculated percentage surpasses the defined custom threshold, making it ideal for complex, ratio-based performance monitoring.

Why this answer

A log alert is correct because the condition involves querying Application Insights trace data to calculate the percentage of requests with a server response time exceeding 5 seconds within a 5-minute window. Log alerts run a Kusto query against the `requests` table, allowing aggregation and threshold evaluation (e.g., >10% of requests), which is not possible with simple metric thresholds.

Exam trap

The trap here is that candidates often assume a metric alert can handle percentage-based conditions, but metric alerts only support simple aggregations (e.g., average, count, max) and cannot compute a ratio of requests meeting a custom condition without a log query.

How to eliminate wrong answers

Option A is wrong because a metric alert can only monitor a single metric value (e.g., average server response time) and cannot calculate a percentage of requests exceeding a threshold; it lacks the query capability to count requests and compute ratios. Option C is wrong because an activity log alert monitors Azure resource management events (e.g., VM creation, configuration changes), not application performance metrics like response times. Option D is wrong because Application Insights smart detection alerts use built-in machine learning models to detect anomalies automatically, but they do not allow you to define custom thresholds like '>10% of requests exceeding 5 seconds'.

Full explanation →

657

MCQmedium

Refer to the exhibit. You deploy this ARM template to an App Service named 'myapp'. After deployment, users report they are able to access the app without being prompted to log in. What is the most likely reason?

A.The Azure Active Directory registration is missing the client secret.

B.The redirect URI is not configured in the Azure AD app registration.

C.The issuer URL is incorrect; it should include the tenant ID.

D.The client ID is from a different tenant.

AnswerA

Azure App Service's Easy Auth, when configured with Azure AD, operates as a confidential client. This means it needs to securely authenticate itself to Azure AD to exchange authorization codes for access tokens and refresh tokens. A client secret (or certificate) serves as this credential, and its absence prevents the App Service from establishing a trusted connection and completing the OAuth 2.0 authorization code flow, leading to authentication failures because the identity provider cannot verify the client's identity.

Why this answer

The ARM template configures the `identityProviders` section with Azure Active Directory settings, but without a `clientSecret` property. The EasyAuth middleware requires a valid client secret to complete the OAuth 2.0 authorization code flow; without it, the authentication provider is effectively disabled, allowing unauthenticated access.

Exam trap

The trap here is that candidates assume a missing client secret causes a deployment error or a login failure, but Azure App Service silently disables the identity provider when the secret is absent, allowing unauthenticated access.

How to eliminate wrong answers

Option B is wrong because the redirect URI is automatically generated by App Service when using EasyAuth, and its absence in the app registration does not cause unauthenticated access—it would cause a redirect mismatch error only when authentication is enforced. Option C is wrong because the issuer URL in the template uses the `issuer` property with a placeholder `{tenantid}`, which App Service resolves to the correct tenant ID at runtime; an incorrect issuer URL would cause token validation failures, not silent unauthenticated access. Option D is wrong because if the client ID were from a different tenant, the authentication flow would fail with a tenant mismatch error, but the app would still prompt for login; it would not allow unauthenticated access.

Full explanation →

658

MCQhard

You have a multi-tenant application that uses Azure AD (Microsoft Entra ID) for authentication. You want to allow only specific tenants to access your app. What is the recommended approach?

A.In the application code, validate the 'tid' claim against a list of allowed tenant IDs.

B.Configure the app manifest to require user assignment and assign users from allowed tenants.

C.Validate the 'iss' claim to ensure it matches one of your allowed tenant issuer URLs.

D.Use Azure AD tenant restrictions to block all tenants except the allowed ones.

AnswerA

For multi-tenant applications, the 'tid' (tenant ID) claim in the incoming JWT token explicitly identifies the Azure AD tenant that issued the token. By implementing a server-side validation check, the application can compare this 'tid' against a pre-defined whitelist of authorized tenant IDs. This programmatic approach ensures that only users from approved organizational tenants can access the application, effectively enforcing tenant-level isolation and security policies directly within the application's trust boundary.

Why this answer

The 'tid' claim in the Azure AD-issued token uniquely identifies the tenant. By validating this claim against a hardcoded list of allowed tenant IDs in your application code, you can enforce multi-tenant access control without relying on Azure AD tenant-level restrictions or issuer URL validation, which can be less precise.

Exam trap

The trap here is that candidates often confuse the 'iss' claim (issuer) with the 'tid' claim (tenant ID), assuming issuer validation is sufficient, but the 'iss' claim can be less predictable in multi-tenant scenarios, especially when using the 'common' or 'organizations' endpoints, whereas 'tid' is the precise and recommended claim for tenant filtering.

How to eliminate wrong answers

Option B is wrong because requiring user assignment and assigning users from allowed tenants is designed for single-tenant or line-of-business apps, not for multi-tenant scenarios where you want to allow entire tenants without pre-provisioning individual users. Option C is wrong because the 'iss' claim (issuer) for Azure AD tokens is typically 'https://login.microsoftonline.com/{tenantid}/v2.0' and can vary by tenant type (e.g., common, organizations, consumers), making it unreliable for tenant-level filtering; the 'tid' claim is the standard and recommended claim for tenant identification. Option D is wrong because Azure AD tenant restrictions are a network-level policy enforced at the proxy or firewall level (e.g., via HTTP headers) to control access to all Azure AD-integrated apps, not a per-application code-level control, and they require infrastructure changes that are not the recommended approach for a single app.

Full explanation →

659

Multi-Selectmedium

Which TWO are valid ways to authenticate to Azure Service Bus from an application? (Choose two.)

Select 2 answers

A.Using an X.509 certificate directly in the connection string.

B.Using Azure AD and a managed identity.

C.Using a connection string with a SAS key from Azure Event Hubs.

D.Using a storage account access key.

E.Using a connection string with Shared Access Signature (SAS) key.

AnswersB, E

Using Azure AD and a managed identity is a valid and highly recommended authentication method. Managed identities provide an automatically managed identity in Azure Active Directory for Azure resources, eliminating the need to store or manage credentials. By assigning an appropriate Azure RBAC role (e.g., Azure Service Bus Data Sender) to the managed identity on the Service Bus namespace, the resource can securely authenticate and authorize operations using Azure AD tokens.

Why this answer

Option B is correct because Azure Service Bus supports Microsoft Entra ID (Azure AD) authentication, and an application running on an Azure resource can use its managed identity to obtain a token for the Service Bus data plane without handling secrets. Option E is correct because Service Bus natively supports Shared Access Signature (SAS) authentication, where the connection string contains a SAS key name and key value that authorize access to the namespace or specific entities. Option A is not valid because Service Bus does not accept an X.509 certificate directly in a connection string; certificate-based credentials are used with Microsoft Entra ID, not embedded in the connection string.

Option C is wrong because a SAS key from Azure Event Hubs is scoped to Event Hubs and cannot authenticate to Service Bus. Option D is wrong because a storage account access key authorizes access to Azure Storage services, not Service Bus.

Exam trap

The trap here is that candidates often confuse Shared Access Signature (SAS) keys with storage account access keys, or mistakenly think Event Hubs credentials are interchangeable with Service Bus, when in fact each service uses its own distinct SAS policy and scope.

Full explanation →

660

MCQmedium

You are developing a serverless function using Azure Functions that needs to write logs to a Log Analytics workspace. The function uses a managed identity. Which RBAC role should you assign to the function's managed identity?

A.Log Analytics Reader

B.Monitoring Contributor

C.Log Analytics Contributor

D.Storage Blob Data Contributor

AnswerC

The Log Analytics Contributor role provides comprehensive permissions to manage and write data to a Log Analytics workspace. This role includes the crucial `Microsoft.OperationalInsights/workspaces/write` and `Microsoft.OperationalInsights/workspaces/tables/write` actions, enabling an Azure Function to ingest its operational logs, custom metrics, and other telemetry directly into the workspace for analysis and visualization. This role is specifically tailored for scenarios requiring data ingestion into Log Analytics, aligning with the principle of least privilege.

Why this answer

The Log Analytics Contributor role is required because it grants the managed identity the necessary permissions to send data to a Log Analytics workspace, including the ability to create and manage data collection rules and write log data. This role is specifically designed for scenarios where an Azure resource, such as an Azure Function, needs to ingest logs into Log Analytics via the Data Collection API.

Exam trap

The trap here is that candidates often confuse the Log Analytics Contributor role with the Monitoring Contributor role, mistakenly thinking the latter covers log ingestion, but Monitoring Contributor lacks the specific write permissions to the Log Analytics workspace data plane.

How to eliminate wrong answers

Option A is wrong because Log Analytics Reader only allows read access to log data and monitoring settings, not the ability to write logs. Option B is wrong because Monitoring Contributor provides broader permissions to manage monitoring resources (e.g., alert rules, metrics) but does not include the specific permission to write data to a Log Analytics workspace. Option D is wrong because Storage Blob Data Contributor is for managing blob storage data, not for writing logs to Log Analytics.

Full explanation →

661

MCQhard

You are developing an ASP.NET Core web API that authenticates users via Microsoft Entra ID. The application needs to authorize access to resources based on custom roles (e.g., 'Admin', 'Editor') that are not present in Microsoft Entra ID. The role mappings are dynamic and stored in an application database. How should you implement authorization?

A.Define the roles as Microsoft Entra ID app roles and include them in the token claims.

B.Store the role mappings in an Azure SQL Database and use a custom authorization policy that queries the database after authentication.

C.Include the roles as claims in the Microsoft Entra ID token by using a custom claim mapping policy.

D.Store the role mappings in the web.config file and read them at runtime.

AnswerB

This is the most flexible and scalable solution for dynamic role management. After a user is authenticated by Microsoft Entra ID, a custom authorization handler, part of an ASP.NET Core policy, can query the Azure SQL Database to retrieve the user's current role assignments. This approach ensures that authorization decisions are always based on the most up-to-date role data from the database, without requiring token re-issuance or application manifest changes for role updates.

Why this answer

The custom roles are dynamic and stored in an application database, not in Microsoft Entra ID. After authentication, a custom authorization policy can query the database to retrieve the role mappings for the authenticated user and enforce access control. This approach decouples role management from the identity provider and supports dynamic role assignments.

Exam trap

The trap here is that candidates assume custom roles must be embedded in the token via claims, overlooking that dynamic roles from a database can be evaluated post-authentication using a custom authorization policy.

How to eliminate wrong answers

Option A is wrong because defining roles as Microsoft Entra ID app roles requires static role definitions in the app registration, which cannot be dynamically updated from an external database. Option C is wrong because a custom claim mapping policy in Microsoft Entra ID can only add claims based on directory attributes or static rules, not from an external database. Option D is wrong because storing role mappings in web.config is static, insecure, and not suitable for dynamic role management; it also violates the principle of externalizing configuration from code.

Full explanation →

662

MCQeasy

You need to store millions of small log entries (each <1 KB) per day from an IoT device. The logs are rarely read. Which storage solution is most cost-effective?

A.Azure Blob Storage Block Blob

B.Azure SQL Database

C.Azure Table Storage

D.Azure Files

AnswerA

Azure Blob Storage Block Blobs are the ideal choice for storing millions of small, unstructured log entries due to their massive scalability, cost-effectiveness, and support for tiered storage. They are optimized for handling billions of objects, allowing for efficient ingestion and retrieval of 1KB log files. Lifecycle management policies can automatically move older logs to cooler tiers (Cool or Archive), significantly reducing long-term storage costs while maintaining data availability.

Why this answer

Azure Blob Storage Block Blob is the most cost-effective solution for storing millions of small log entries (<1 KB) that are rarely read because it offers extremely low storage costs per GB, supports high-throughput ingestion, and is optimized for large-scale, append-oriented workloads. Block blobs can be stored in the 'Cool' or 'Archive' access tier to further reduce costs, and they can be efficiently batched into larger blocks (up to 100 MB per block) to minimize transaction costs.

Exam trap

The trap here is that candidates often choose Azure Table Storage because they think it is designed for small, structured log entries, but they overlook that Blob Storage's Cool/Archive tiers provide dramatically lower storage costs for rarely accessed data, making it the more cost-effective choice despite Table Storage's lower per-entity transaction cost.

How to eliminate wrong answers

Option B (Azure SQL Database) is wrong because it is a relational database designed for transactional workloads with high query performance, not for high-volume, low-cost storage of small log entries; its per-GB storage cost is significantly higher than Blob Storage, and it incurs additional costs for compute and IO. Option C (Azure Table Storage) is wrong because while it can store small entries, its cost per GB is higher than Blob Storage, and it is optimized for key-value lookups rather than bulk append-only logs; it also has a 1 MB entity size limit, which is not a problem here, but the overall cost for millions of entries is less efficient than block blobs in Cool/Archive tiers. Option D (Azure Files) is wrong because it is a fully managed file share for SMB protocol access, designed for shared file storage with low-latency access, not for high-volume, low-cost log archiving; its per-GB cost is higher than Blob Storage, and it lacks the tiering options (Cool/Archive) that make Blob Storage cost-effective for rarely accessed data.

Full explanation →

663

MCQmedium

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

A.Event Grid trigger on Premium plan

B.Blob Storage trigger on Consumption plan

C.Event Grid trigger on Consumption plan

D.Blob Storage trigger on Premium plan

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

664

MCQeasy

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

A.Azure Cosmos DB

B.Azure Queue Storage

C.Azure Event Grid

D.Azure SignalR Service

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

665

MCQhard

A .NET app performs point reads from Cosmos DB by id and partition key. The team wants the lowest latency and best throughput efficiency. Which API call pattern should be used?

A.ReadItemAsync with id and partition key

B.Stored procedure scanning all items

C.Change feed processor

D.SELECT * query without partition key

AnswerA

The ReadItemAsync method, when provided with both the item's unique identifier (id) and its partition key, represents the most efficient point-read operation in Azure Cosmos DB. This combination allows the Cosmos DB gateway to route the request directly to the specific physical partition containing the item, bypassing the need for index lookups or cross-partition fan-out. It minimizes Request Units (RUs) consumed and latency, making it ideal for single-item retrieval.

Why this answer

ReadItemAsync with id and partition key is the most efficient API call pattern for point reads in Cosmos DB because it directly accesses the document using the partition key and item ID, requiring only a single request to the exact partition and replica. This avoids the overhead of querying multiple partitions or scanning all items, resulting in the lowest latency and best throughput efficiency, as it consumes the minimum request units (RUs) possible for a read operation.

Exam trap

The trap here is that candidates may confuse efficient point reads with query-based approaches or event-driven patterns, mistakenly believing that stored procedures or change feed processors can achieve lower latency, when in reality they introduce unnecessary overhead for simple single-item lookups.

How to eliminate wrong answers

Option B is wrong because stored procedures are designed for transactional operations across multiple items within the same partition, not for efficient point reads; they incur higher RU costs and latency due to script execution and potential full partition scans. Option C is wrong because the Change feed processor is used for capturing and processing incremental changes (events) to items, not for performing point reads; it introduces additional latency and resource overhead for real-time read scenarios. Option D is wrong because a SELECT * query without partition key results in a cross-partition query that scans all physical partitions, dramatically increasing RU consumption and latency compared to a direct point read.

Full explanation →

666

MCQmedium

You are building a solution that uses Azure Cosmos DB for NoSQL. You need to implement a change feed processor to handle real-time updates. The application runs on multiple instances to ensure high availability. Which lease container configuration ensures that each instance processes a distinct set of partitions?

A.Set the partition key of the monitored container to /city

B.Configure the change feed to start from the beginning

C.Use a separate lease container with partition key /id

D.Set the lease container's throughput to 1000 RU/s

AnswerC

Using a separate lease container with a partition key of /id is the correct approach because the Change Feed Processor leverages this specific partitioning strategy. Each logical partition of the monitored container is assigned a unique "lease" document in the lease container. By partitioning the lease container by /id, the processor ensures that these lease documents are evenly distributed, allowing different consumer instances to acquire and manage leases for distinct logical partitions in parallel, thereby distributing the workload effectively.

Why this answer

The change feed processor uses a lease container to track which partitions each instance is processing. By setting the partition key to /id, each lease document is uniquely identified, allowing the processor to distribute partitions across instances. This ensures that each instance processes a distinct set of partitions, enabling horizontal scaling without duplication.

Exam trap

The trap here is that candidates confuse the partition key of the monitored container with the partition key of the lease container, assuming they must match or that throughput settings control distribution, when in fact the lease container's partition key must be /id for proper lease management.

How to eliminate wrong answers

Option A is wrong because the partition key of the monitored container (/city) does not affect lease distribution; the lease container's partition key controls how leases are distributed. Option B is wrong because starting from the beginning is a configuration for reading historical changes, not for ensuring distinct partition processing across instances. Option D is wrong because throughput (RU/s) on the lease container affects performance and throttling, not the logical distribution of partitions among instances.

Full explanation →

667

MCQeasy

You are monitoring an Azure Web App with Application Insights. You notice a sudden spike in failed requests. You need to quickly identify which specific URL path is causing the most failures. Which blade in the Application Insights portal should you use?

A.Application Map

B.Failures blade

C.Performance blade

D.Live Metrics Stream

AnswerB

The Failures blade in Application Insights is specifically engineered for detailed analysis of failed requests and exceptions within your application. It automatically groups failures by operation name, response code, and URL path, providing metrics like failure count and impact. This functionality allows developers to quickly pinpoint the most problematic endpoints, view associated samples, and drill down into specific error details, making it the ideal tool for identifying the most failing URL path during a historical spike.

Why this answer

The Failures blade in Application Insights is specifically designed to analyze failed requests, including HTTP 4xx and 5xx errors, and provides a breakdown by URL path, response code, and failure count. This allows you to quickly identify the specific URL path causing the most failures, which directly addresses the need to pinpoint the problematic endpoint.

Exam trap

The trap here is that candidates often confuse the Failures blade with the Performance blade, assuming performance metrics (like slow requests) are the root cause of failures, but the question explicitly asks for identifying failed requests by URL path, which is the sole purpose of the Failures blade.

How to eliminate wrong answers

Option A is wrong because the Application Map visualizes the dependency flow and health of your application components, but it does not provide a granular breakdown of failed requests by URL path. Option C is wrong because the Performance blade focuses on request durations, throughput, and slow operations, not on failed request analysis. Option D is wrong because Live Metrics Stream shows real-time telemetry (e.g., request rate, CPU usage) but does not aggregate historical failure data or allow sorting by URL path.

Full explanation →

668

MCQeasy

You are developing a .NET console application that runs on a developer workstation and also in an Azure Container Instance. The application must read secrets from Azure Key Vault. During local development, the developer signs in with the Azure CLI. In Azure, the container uses a managed identity. You want a single code path that works in both environments without storing credentials. Which approach should you use?

A.Instantiate SecretClient with a ClientSecretCredential using a client secret from an environment variable.

B.Instantiate SecretClient with a ManagedIdentityCredential and rely on it working on the developer workstation.

C.Instantiate SecretClient with a DefaultAzureCredential and pass the Key Vault URI.

D.Instantiate SecretClient with an InteractiveBrowserCredential so the developer and the container can both prompt for sign-in.

AnswerC

DefaultAzureCredential chains multiple credential sources. On a workstation it picks up the Azure CLI sign-in, and in Azure Container Instances it uses the managed identity. This gives one code path that works in both environments without embedding secrets, exactly matching the requirement to avoid stored credentials in code or configuration.

Why this answer

DefaultAzureCredential is designed for code that must run in multiple environments. It tries developer tooling credentials first and falls back to managed identity in Azure, so the same SecretClient code works locally and in the container without any stored secret.

Exam trap

The trap here is choosing a credential type that only works in one environment, such as managed identity locally or interactive sign-in in a headless container.

Full explanation →

669

Multi-Selecthard

Which TWO actions should you take to secure an Azure Kubernetes Service (AKS) cluster that runs a critical workload? (Choose two.)

Select 2 answers

A.Store secrets as Kubernetes secrets without encryption

B.Enable SSH access to all nodes for troubleshooting

C.Enable Azure AD integration with Kubernetes RBAC

D.Deploy Azure Firewall in the cluster VNet

E.Use network policies to restrict pod-to-pod communication

AnswersC, E

Enabling Azure Active Directory (Azure AD) integration with Kubernetes Role-Based Access Control (RBAC) is a fundamental security measure for AKS, providing robust identity-based access control. This integration allows organizations to leverage their existing Azure AD identities and groups to define granular permissions within the Kubernetes cluster. It centralizes authentication and authorization, ensuring that only authorized users and service principals can perform specific actions, thereby enforcing the principle of least privilege.

Why this answer

Integrating Azure AD with Kubernetes RBAC provides centralized identity management and fine-grained access control for the AKS cluster. This allows you to authenticate users via Azure AD and authorize their actions using Kubernetes RBAC roles, ensuring that only authenticated and authorized users can perform operations on the cluster, which is critical for securing a production workload.

Exam trap

The trap here is that candidates often confuse network-level security (like Azure Firewall) with pod-level security (like network policies), or they mistakenly think that enabling SSH access is a valid troubleshooting method in AKS, ignoring the principle of least privilege and the availability of secure alternatives like `kubectl exec` or Azure Bastion.

Full explanation →

670

MCQeasy

You are debugging a performance issue in a live web application monitored by Application Insights. You need to see real-time metrics such as request rate, response times, and any exceptions as they occur, without waiting for the usual telemetry pipeline. Which Application Insights feature should you use?

A.Application Insights Analytics (Log Analytics)

B.Live Metrics Stream

C.Metrics Explorer

D.Application Insights Profiler

AnswerB

Live Metrics Stream provides a near real-time, low-latency view of your application's health and performance directly from the running instances. It displays critical metrics like request rates, response times, failures, CPU utilization, and memory usage within seconds of them occurring. This immediate feedback loop is specifically engineered for actively monitoring and debugging live performance issues, allowing developers to observe the impact of changes or identify anomalies instantly.

Why this answer

Live Metrics Stream (option B) is the correct feature because it provides real-time, low-latency telemetry directly from the Application Insights SDK, bypassing the usual ingestion pipeline. This allows you to monitor request rate, response times, and exceptions as they occur, which is exactly what the scenario requires for debugging a live performance issue without waiting for data to be processed.

Exam trap

The trap here is that candidates often confuse Live Metrics Stream with Metrics Explorer, assuming both provide real-time data, but Metrics Explorer relies on pre-aggregated metrics with a built-in delay, while Live Metrics Stream is the only feature designed for true sub-second live monitoring.

How to eliminate wrong answers

Option A is wrong because Application Insights Analytics (Log Analytics) is a query-based tool for analyzing historical telemetry data after it has been ingested and stored, not for real-time monitoring. Option C is wrong because Metrics Explorer displays pre-aggregated metrics with a delay (typically 1-2 minutes) and does not provide sub-second live data. Option D is wrong because Application Insights Profiler is used for tracing performance bottlenecks in specific requests via snapshots, not for continuous real-time monitoring of request rates and exceptions.

Full explanation →

671

Multi-Selecteasy

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

Select 2 answers

A.Azure Event Grid trigger

B.Azure Queue Storage trigger

C.Azure Blob Storage trigger

D.Azure Cosmos DB trigger

E.HTTP trigger

AnswersA, C

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

Why this answer

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

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

Exam trap

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

Full explanation →

672

MCQeasy

You need to ensure that an Azure Functions app can access a blob in Azure Storage using its system-assigned managed identity. What should you do first?

A.Configure CORS on the storage account

B.Enable the managed identity in the Function App

C.Assign the Storage Blob Data Reader role to the managed identity at the storage account scope

D.Generate a SAS token for the blob

AnswerB

Enabling a managed identity for an Azure Function App is a crucial first step, as it provisions a unique identity (a service principal) for the application within Azure Active Directory. However, this action alone only *creates* the identity; it does not automatically grant it any permissions to interact with other Azure resources. Without explicit authorization through role assignments, the newly created managed identity lacks the necessary privileges to perform operations like reading data from a storage account.

Why this answer

To use a system-assigned managed identity, it must first be enabled on the Azure Functions app. This action creates the identity in Azure Active Directory. Once the identity is enabled, you can then assign the necessary Azure RBAC role, such as 'Storage Blob Data Reader', to this identity at the storage account scope to grant it permissions to access the blob storage.

Therefore, enabling the managed identity is the foundational first step.

Exam trap

The trap here is that candidates might focus on the authorization step (RBAC role assignment) and overlook the prerequisite step of actually enabling the managed identity on the resource itself, which must happen first for the identity to exist and be assignable.

How to eliminate wrong answers

Option A is wrong because CORS (Cross-Origin Resource Sharing) is a browser security feature that controls which origins can make requests to the storage account from client-side code; it does not grant the Function App's managed identity any permissions to access blobs. Option B is wrong because while enabling the managed identity is a prerequisite, it alone does not grant any access to the storage account; the identity must be assigned an RBAC role to actually read blobs. Option D is wrong because generating a SAS token bypasses managed identity entirely and introduces key-based access, which contradicts the requirement to use the system-assigned managed identity.

Full explanation →

673

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

674

MCQhard

Your company has a microservices application deployed on Azure Kubernetes Service (AKS). One service, OrderProcessor, needs to read messages from an Azure Service Bus queue and write results to Azure Cosmos DB. The processing must be reliable: if the service crashes mid-processing, the message should not be lost and should be retried. You also need to ensure that messages are processed in order within a partition. The solution should minimize code changes and leverage platform features. Which approach should you use?

A.Use the Azure Service Bus SDK with ReceiveAndDelete mode in a background worker.

B.Use Azure Functions with a Service Bus trigger that uses sessions for ordered processing.

C.Use the Azure Service Bus SDK with PeekLock mode and manual message completion.

D.Use Azure Event Hubs with a consumer group and checkpointing.

AnswerB

Azure Functions with a Service Bus trigger provides a robust and scalable solution for processing messages reliably. Functions automatically leverage Service Bus's PeekLock mechanism, handling message retrieval, retries, and completion or dead-lettering without explicit developer code. Furthermore, utilizing Service Bus sessions ensures that related messages are processed in a guaranteed order by the same function instance, which is crucial for maintaining data consistency in microservices architectures.

Why this answer

Azure Functions with a Service Bus trigger using sessions provides exactly-once processing and ordered message delivery within a partition. The Service Bus trigger automatically uses PeekLock mode, ensuring messages are not lost if the function crashes, and sessions guarantee FIFO ordering within a session. This minimizes code changes by leveraging the platform's built-in retry and checkpointing mechanisms.

Exam trap

The trap here is that candidates often confuse ReceiveAndDelete mode with PeekLock mode, or assume that manual completion alone guarantees ordering, but they overlook that sessions are the only way to enforce FIFO ordering within a partition in Service Bus.

How to eliminate wrong answers

Option A is wrong because ReceiveAndDelete mode removes the message from the queue immediately upon retrieval, so if the service crashes mid-processing, the message is lost and cannot be retried. Option C is wrong because while PeekLock mode with manual completion ensures reliability, it does not guarantee ordered processing within a partition; sessions are required for that. Option D is wrong because Azure Event Hubs is designed for high-throughput event ingestion, not for reliable message processing with ordered delivery and retries; it lacks built-in message-level retry and session support like Service Bus.

Full explanation →

675

MCQmedium

You are using Azure File Storage to share configuration files across multiple virtual machines running a legacy application. The application requires SMB 3.0 protocol with encryption. You need to ensure the file share is accessible from all VMs without exposing it to the internet. Which configuration should you use?

A.Create a storage account with a shared access signature (SAS) token and mount using the SAS URL

B.Create a storage account with a public endpoint and use a VPN gateway to connect the VMs

C.Create a storage account with a public endpoint and configure the firewall to allow only the VNet

D.Create a storage account with a private endpoint and mount the file share using the private IP

AnswerD

Creating a storage account with a private endpoint establishes a network interface for the storage account directly within a specified virtual network subnet. This assigns a private IP address from the VNet's address space to the storage account, making it accessible only from within that VNet or peered networks. All traffic to the file share then flows entirely within the Azure backbone network, bypassing the public internet and ensuring secure, private connectivity using the private IP.

Why this answer

A private endpoint assigns the storage account a private IP address from your virtual network, allowing VMs to access the file share over SMB 3.0 with encryption without exposing the storage account to the public internet. This meets the requirement for secure, private connectivity while supporting the legacy application's SMB 3.0 protocol needs.

Exam trap

The trap here is that candidates often confuse network-level access controls (like firewalls or VPNs) with true private connectivity, mistakenly believing that restricting access via firewall rules or VPN gateways eliminates public endpoint exposure, when only a private endpoint achieves that.

How to eliminate wrong answers

Option A is wrong because a shared access signature (SAS) token provides time-limited delegated access but still uses the public endpoint, exposing the storage account to the internet; it does not eliminate public exposure. Option B is wrong because using a VPN gateway with a public endpoint still leaves the storage account's public endpoint accessible from the internet, and the VPN only secures the connection between the VMs and the gateway, not the storage endpoint itself. Option C is wrong because configuring the firewall to allow only the VNet still requires the storage account to have a public endpoint, which is inherently internet-facing; firewall rules restrict access but do not remove the public endpoint, leaving the storage account potentially discoverable and violating the 'not exposing it to the internet' requirement.

Full explanation →

Microsoft Azure Developer Associate AZ-204 (AZ-204) — Questions 601–675