Courseiva

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

881 questions total · 12pages · All types, answers revealed

Take a mock examExam hub
Page 3

Page 4 of 12

Page 5
226
MCQmedium

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

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

This option provides an optimal balance between cost efficiency and compliance for healthcare data. By transitioning to the Cool tier after 30 days and then to the Archive tier after 90 days, it intelligently aligns storage costs with decreasing access frequency over time. The final deletion after 7 years perfectly satisfies the long-term data retention mandates, making it the most suitable lifecycle policy.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
227
MCQhard

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

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

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

Why this answer

Azure Key Vault provides a centralized, secure store for secrets like connection strings, and using a managed identity allows the Azure Function app to authenticate to Key Vault without storing any credentials in code or configuration. This approach satisfies the rotation policy by enabling automatic or scheduled secret rotation in Key Vault, and it minimizes operational overhead by eliminating manual credential management.

Exam trap

The trap here is that candidates may confuse Azure App Configuration with Azure Key Vault, thinking App Configuration's encryption at rest is sufficient for secrets, but App Configuration lacks secret rotation and managed identity integration for secure access.

How to eliminate wrong answers

Option B is wrong because storing the connection string in a JSON configuration file, even with Azure Policy enforcing encryption, still places the secret in source code or configuration files, violating the policy that no secret be stored there. Option C is wrong because Azure App Configuration is designed for application configuration settings, not secrets; it lacks native secret rotation capabilities and does not provide the same level of security as Key Vault for sensitive data like connection strings. Option D is wrong because storing the connection string as an environment variable in the Function app's application settings still exposes the secret in the Azure portal and configuration, and it does not support automated rotation or managed identity-based access, increasing operational overhead.

Full explanation →
228
MCQeasy

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

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

Configuring a lifecycle management policy directly addresses the requirements by providing an automated, cost-effective, and serverless solution. These policies allow defining rules that automatically transition blobs between access tiers (e.g., Hot to Cool after 7 days) and delete them (e.g., after 30 days) based on conditions like blob age or last modified time. This native Azure Blob Storage feature eliminates manual scripting, reduces operational overhead, and optimizes storage costs by ensuring data resides in the most appropriate tier.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
229
MCQhard

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

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

This option correctly combines policies to meet all specified requirements. The `validate-jwt` policy is essential for securely verifying the authenticity, integrity, and claims of the incoming JWT, ensuring only legitimate requests proceed. The `rate-limit` policy effectively throttles requests on a per-subscription-key basis, preventing abuse and ensuring fair resource allocation. Finally, `log-to-event-hub` provides a robust mechanism for asynchronously sending detailed logs to Azure Event Hubs for monitoring, auditing, and analytics.

Why this answer

Validate-jwt is the appropriate policy to validate OAuth 2.0 tokens from Microsoft Entra ID before forwarding requests to the FHIR backend. The rate-limit policy enforces throttling per subscription key, which is the standard way to rate-limit based on API Management subscription keys. The log-to-event-hub policy sends logs to Azure Monitor via Event Hubs for audit purposes, meeting all requirements.

Exam trap

The trap here is confusing rate-limit (sliding window throttling per key) with quota (fixed total limit over a period), and assuming check-header can validate JWT tokens when it only checks for header existence, not cryptographic validity.

How to eliminate wrong answers

Option A is wrong because set-header to add the subscription key is unnecessary and does not perform token validation; the subscription key is already present in the request and is not used for OAuth token validation. Option B is wrong because check-header only verifies the presence of a header, not the validity of a JWT token; it cannot validate OAuth 2.0 tokens from Entra ID. Option D is wrong because quota limits total requests over a time period (e.g., daily/monthly) rather than rate-limiting per subscription key; the requirement specifically asks for rate-limiting per subscription key, which rate-limit handles by allowing a burst of requests within a sliding window.

Full explanation →
230
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
231
MCQhard

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

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

Enabling duplicate detection on an Azure Service Bus queue is the primary mechanism to ensure exactly-once message processing. When activated, Service Bus stores a history of message IDs for a configurable time window, typically up to seven days. If a producer attempts to send a message with an MessageId that matches one already processed within that window, Service Bus automatically rejects the duplicate, preventing its delivery to consumers and thus ensuring that each unique message is processed only once.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
232
Multi-Selecthard

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

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

Access tier can be changed after upload.

Why this answer

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

Exam trap

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

Full explanation →
233
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
234
MCQhard

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

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

Microsoft.Identity.Web is the recommended and most current library for integrating Microsoft identity platform authentication and authorization into ASP.NET Core web APIs and web applications. It provides a comprehensive set of middleware and helper classes that significantly simplify the process of validating incoming bearer tokens issued by Microsoft Entra ID. This includes automatically handling token signature verification, issuer and audience validation, lifetime checks, and extracting claims, thereby ensuring robust security for API endpoints.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
235
MCQmedium

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

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

Azure Blob Storage with Read-Access Geo-Redundant Storage (RA-GRS) is an excellent choice for this scenario. RA-GRS asynchronously replicates data to a secondary region and allows read access to the data in that secondary region, significantly reducing read latency for geographically dispersed users. Serving reads from the secondary region ensures global availability and improved performance for infrequent reads, while the cost remains acceptable given the infrequent update pattern and the critical need for data redundancy and global accessibility.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
236
MCQhard

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

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

Azure Key Vault's soft-delete feature retains deleted secrets for a specified retention period, typically 90 days by default, making them recoverable. The `az keyvault secret recover` command is specifically designed to transition a soft-deleted secret back into an active state within this retention window. This command restores the secret with all its original properties, versions, and access policies, effectively reversing the deletion operation.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
237
MCQeasy

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

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

The Archive access tier is specifically engineered for long-term data retention, offering the absolute lowest storage costs in Azure Blob Storage. It is ideal for data that can tolerate several hours of retrieval latency, making it perfect for terabytes of archival data that must be retained for a decade with infrequent access requirements. This tier provides the most cost-effective solution for meeting long-term compliance and backup needs.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
238
MCQmedium

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

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

Storing configuration values as Key Vault references in Azure App Configuration is the most robust solution for microservices. Azure App Configuration automatically resolves these references at runtime, fetching the actual secret value from Key Vault using its own managed identity. This centralizes configuration management, enhances security by keeping secrets out of application code, and allows for dynamic updates without redeploying microservices.

Why this answer

Azure App Configuration supports Key Vault references, which allow you to store a reference to a secret in Key Vault rather than the secret itself. When the application retrieves the configuration value, App Configuration automatically resolves the reference and fetches the secret from Key Vault, requiring no code changes. This satisfies the requirement of storing sensitive values in Key Vault while keeping the application code unchanged.

Exam trap

The trap here is that candidates often assume managed identity (Option B) is the correct answer because it avoids storing credentials, but they overlook that it still requires code changes to call Key Vault directly, whereas Key Vault references in App Configuration provide a code-free integration.

How to eliminate wrong answers

Option B is wrong because using Azure AD managed identity to access Key Vault directly from the service would require application code changes to call the Key Vault SDK or REST API, which violates the requirement of no code changes. Option C is wrong because storing secrets in Kubernetes Secrets and mounting them as environment variables does not use Azure App Configuration or Key Vault, and it introduces security risks such as base64-encoded secrets and lack of centralized management. Option D is wrong because using the Azure Key Vault SDK directly in the service requires explicit code changes to retrieve secrets, which contradicts the requirement that the solution should not require application code changes to reference Key Vault.

Full explanation →
239
MCQmedium

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

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

Enabling App Service Authentication (often called Easy Auth) with Microsoft Entra ID offloads authentication concerns to the platform. By setting 'Action to take when request is not authenticated' to 'Log in with Microsoft Entra ID', the App Service acts as a gateway, automatically redirecting all unauthenticated requests to the Microsoft Entra ID login page. This ensures that no unauthenticated requests reach the application code, as the platform handles token validation and user session management transparently, enhancing security and reducing application complexity.

Why this answer

Enabling App Service Authentication (EasyAuth) with Microsoft Entra ID as the identity provider and setting 'Action to take when request is not authenticated' to 'Log in with Microsoft Entra ID' ensures that all unauthenticated requests are redirected to Microsoft Entra ID for authentication before they reach the application code. This configuration blocks unauthenticated requests at the platform layer, preventing any unauthenticated traffic from hitting the app's runtime, which meets the requirement of keeping unauthenticated requests away from the app code.

Exam trap

The trap here is that candidates often confuse authentication (proving identity) with authorization (checking permissions) and incorrectly choose option C, thinking role assignment alone blocks unauthenticated users, but App Roles only work after authentication and do not prevent unauthenticated requests from reaching the app code.

How to eliminate wrong answers

Option A is wrong because IP restrictions in web.config only filter based on source IP addresses, not authentication; they do not validate Microsoft Entra ID tokens or ensure the user is from the correct tenant, and unauthenticated users from allowed IPs could still access the app. Option B is wrong because implementing custom middleware to validate tokens would require the app code to handle authentication, which contradicts the requirement to prevent unauthenticated requests from reaching the app code; the middleware runs within the app's process, so unauthenticated requests still reach the app. Option C is wrong because assigning users to App Roles and checking roles in the app only controls authorization after authentication, but does not prevent unauthenticated requests from reaching the app code; it assumes authentication is already handled elsewhere.

Full explanation →
240
MCQmedium

A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required?

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
241
MCQeasy

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

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

Azure Cache for Redis is an in-memory data store based on the open-source Redis project, providing extremely low-latency access to data. It is specifically designed for caching, session state management, and message brokering, offering high performance and scalability. Its native support for various session state providers in frameworks like ASP.NET makes it an ideal, efficient, and cost-effective solution for storing volatile session data.

Why this answer

Azure Cache for Redis is the correct choice because it provides a high-performance, in-memory data store that supports session state persistence across multiple web app instances behind a load balancer. It offers built-in session state providers for ASP.NET and ASP.NET Core, ensuring state is preserved across restarts and scale-out scenarios with low-latency access.

Exam trap

The trap here is that candidates often confuse durable storage (like Table Storage or SQL Database) with the need for fast, in-memory session state, overlooking that Azure Cache for Redis is the only service purpose-built for this exact scenario with built-in session providers and low-latency access.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a NoSQL key-value store designed for structured, non-relational data and lacks the low-latency, in-memory caching capabilities required for session state, making it unsuitable for high-throughput web apps. Option B is wrong because Azure SQL Database is a relational database that, while capable of persisting session state, introduces significant latency and overhead compared to an in-memory cache, and is not optimized for the frequent read/write patterns of session management. Option C is wrong because Azure Blob Storage is an object storage service for unstructured data like files and images, not designed for transactional, low-latency session state operations, and would result in poor performance and scalability issues.

Full explanation →
242
Multi-Selecthard

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

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

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

Why this answer

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

Exam trap

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

Full explanation →
243
MCQmedium

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

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

Migrating an Azure Function app from a Consumption plan to a Premium plan directly addresses cold start issues by provisioning pre-warmed instances. The Premium plan maintains a specified minimum number of active instances, ensuring that function apps are always ready to process requests without the initial latency associated with instance allocation, startup, and code loading. This significantly reduces the delay experienced during the first invocation after a period of inactivity.

Why this answer

Cold start latency occurs when a function app is idle and needs to be loaded from scratch. The Consumption plan can cause cold starts because it scales to zero when idle. Migrating to the Premium plan eliminates cold starts by keeping instances warm, as it provides pre-warmed workers and always-on instances, reducing latency after deployment.

Exam trap

The trap here is that candidates often confuse 'Always On' (an App Service setting for continuous web jobs) with Azure Functions cold start mitigation, but 'Always On' is not supported on Consumption or Premium plans, and the correct solution is to use the Premium plan's built-in warm instance support.

How to eliminate wrong answers

Option A is wrong because setting FUNCTIONS_WORKER_RUNTIME to 'dotnet-isolated' changes the process model but does not address cold start latency; it may even increase startup time due to the additional out-of-process overhead. Option C is wrong because enabling Azure Monitor alerts on function execution count only notifies you of execution patterns, it does not mitigate cold start latency. Option D is wrong because 'Always On' is a setting for App Service plans (e.g., Basic, Standard, Premium) and is not available or applicable to Azure Functions running on Consumption or Premium plans; it is a common misconception that it applies to Functions.

Full explanation →
244
MCQhard

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

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

This is the optimal design for telemetry data. Using the device ID as the partition key effectively distributes write operations across numerous partitions, as each unique device generates its own data stream. This prevents hot partitions and maximizes write throughput. Furthermore, using the timestamp as the row key within each device's partition ensures that data is stored in chronological order, enabling highly efficient range queries for a specific device's telemetry over a time period.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
245
MCQeasy

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

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

Filtering a query solely on the PartitionKey is the most efficient and recommended method for retrieving all entities within a specific partition in Azure Table Storage. This approach allows the service to directly access the targeted partition, which is stored contiguously, minimizing scan operations and maximizing read performance. It leverages the primary indexing mechanism, ensuring fast and cost-effective data retrieval for a partition's contents.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
246
MCQhard

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

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

The 'Storage Blob Data Contributor' role provides comprehensive permissions to read, write, and delete blob data within the specified scope. Assigning this role at the container level to the managed identity grants the necessary data plane access to create, modify, and manage blobs and directories within that container, aligning perfectly with the requirement to interact with a hierarchical namespace. This adheres to the principle of least privilege by granting only the required data operations, not broader management capabilities.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
247
MCQmedium

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

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

Azure Key Vault is the correct solution for securely storing secrets and managing their lifecycle, including automatic rotation. It provides a centralized, highly secure repository for cryptographic keys, certificates, and secrets like API keys or database connection strings. Azure Functions can securely retrieve these secrets at runtime, and Key Vault's integration capabilities allow for automated secret rotation, enhancing security posture by regularly changing sensitive credentials without manual intervention.

Why this answer

Azure Key Vault is the correct service because it provides a centralized, secure store for secrets like connection strings and supports automatic rotation policies. By storing the Cosmos DB connection string in Key Vault and configuring a rotation policy (e.g., every 90 days), the Azure Function can retrieve the latest secret at runtime via a Key Vault reference in its application settings, ensuring the secret is rotated without code changes or downtime.

Exam trap

The trap here is that candidates often confuse Managed Identity with a secret storage solution, thinking it can store and rotate connection strings, when in reality it only provides an identity for authentication and cannot manage or rotate secrets like a connection string.

How to eliminate wrong answers

Option B is wrong because Managed Identity provides an identity for the Azure Function to authenticate to Azure services without storing credentials, but it does not store or rotate connection strings—it only enables token-based access to resources like Cosmos DB via Azure RBAC, which is not the same as rotating a connection string. Option C is wrong because Azure App Configuration is designed for managing application configuration settings and feature flags, not for securely storing secrets with automatic rotation; it lacks built-in secret rotation policies and should not be used for sensitive connection strings. Option D is wrong because Microsoft Entra ID (formerly Azure AD) is an identity and access management service that provides authentication and authorization, but it does not store secrets like connection strings or offer automatic rotation capabilities—it can be used to grant access to Key Vault but is not the secret store itself.

Full explanation →
248
MCQmedium

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

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

Creating a composite index that includes both the queried property and the partition key is crucial for optimizing cross-partition queries. This index allows the Cosmos DB query engine to efficiently seek and filter documents within each partition based on the specified property, rather than performing a full scan of all documents across all partitions. This significantly reduces RU consumption and improves query latency by leveraging the index for efficient data retrieval.

Why this answer

Creating a composite index that includes the queried property and the partition key allows the query to be served efficiently from a single physical partition, avoiding a costly cross-partition fan-out. This reduces both RU consumption and latency, as the query can use the index without scanning all partitions.

Exam trap

The trap here is that candidates often assume increasing RU/s (Option A) is the only way to handle cross-partition queries, but the exam tests the understanding that indexing strategy—specifically composite indexes—can eliminate the need for cross-partition fan-out, which is a more cost-effective and latency-optimizing approach.

How to eliminate wrong answers

Option A is wrong because increasing RU/s does not optimize the query itself; it only increases throughput capacity, which may reduce throttling but does not address the root cause of cross-partition query overhead. Option C is wrong because changing the partition key to the queried property would require recreating the container and re-ingesting all data, which is disruptive and not an optimization for the existing schema. Option D is wrong because enabling analytical store and using Synapse Link is designed for large-scale analytical workloads (OLAP), not for optimizing point or small-range queries on operational data (OLTP); it adds cost and complexity without improving query latency or RU cost for the described scenario.

Full explanation →
249
MCQhard

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

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

This query accurately filters all exceptions that occurred within the last 24 hours using the `ago(24h)` function. By grouping the results using `summarize count() by type, url`, it provides a precise breakdown of how many times each exception `type` occurred at each specific `url`. This directly addresses the requirement to analyze exceptions 'from' their originating application endpoint, offering clear insight into problematic URLs.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
250
MCQmedium

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

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

Azure Key Vault is the recommended and secure service for storing cryptographic keys, certificates, and sensitive secrets like API client secrets. It provides robust access control, auditing, and encryption at rest and in transit, ensuring the secret's confidentiality. The Microsoft Authentication Library (MSAL) is the appropriate SDK for acquiring tokens from Microsoft identity platform, including implementing the client credentials flow where an application uses its own identity (client ID and secret retrieved from Key Vault) to obtain an access token for a downstream API.

Why this answer

Azure Key Vault provides secure, auditable storage for client secrets, and MSAL (Microsoft Authentication Library) is the recommended SDK for implementing OAuth 2.0 client credentials grant flows in Azure. MSAL handles token acquisition, caching, and renewal, while Key Vault ensures the secret is never exposed in code or configuration files.

Exam trap

The trap here is that candidates often confuse Azure App Configuration with Azure Key Vault, assuming App Configuration's encryption is sufficient for secrets, or they mistakenly believe managed identity can be used to authenticate to any OAuth 2.0-secured API, when in fact managed identity only works with Azure AD-integrated services and not arbitrary downstream APIs.

How to eliminate wrong answers

Option A is wrong because Azure App Configuration is designed for managing application settings and feature flags, not for securely storing secrets; it lacks the encryption-at-rest and access policy features of Key Vault, and the Azure Identity SDK is used for managed identity or default credential flows, not for client credentials grant with a stored secret. Option B is wrong because managed identity is intended for Azure resources to authenticate to Azure services without secrets, but the downstream API is a custom API secured with OAuth 2.0, not an Azure service that supports managed identity authentication directly. Option D is wrong because Azure Certificate Manager does not exist as an Azure service; the correct service for certificate management is Azure Key Vault, and using HttpClient directly to obtain a token would require manually implementing the OAuth 2.0 protocol, which is error-prone and not recommended over using MSAL.

Full explanation →
251
Multi-Selectmedium

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

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

Microsoft Entra ID (formerly Azure AD) authentication is a primary method for securing Azure Storage without relying on shared keys. It enables identity-based access control through Azure Role-Based Access Control (RBAC), where users, groups, or service principals are assigned specific roles to storage resources. This method leverages OAuth 2.0 tokens issued by Entra ID, providing a secure and auditable way to authorize requests without ever exposing or managing shared secrets like account keys.

Why this answer

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

Exam trap

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

Full explanation →
252
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
253
MCQhard

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

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

This is the correct approach for event-driven scaling in Azure Container Apps. KEDA (Kubernetes Event-driven Autoscaling) integrates directly with Container Apps, allowing it to monitor external event sources like Azure Storage Queues. A KEDA-based scale rule would specify the queue to monitor and define thresholds (e.g., messages per replica) that trigger scaling actions, ensuring the API scales out when queue length increases and scales in (potentially to zero) when the queue is empty. This efficiently handles fluctuating loads for a checkout API processing asynchronous requests.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
254
MCQeasy

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

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

The 'CPU Time' metric is a direct and highly accurate measure for monitoring the performance of an Azure App Service, as it quantifies the cumulative amount of time the application's processes spend actively utilizing the CPU cores. This metric directly reflects the computational resources consumed by the application, providing a clear indication of its processing load and efficiency. High CPU Time often signals inefficient code, complex operations, or insufficient compute capacity for the workload.

Why this answer

CPU Time is the correct metric for monitoring high CPU usage in an Azure App Service web app because it directly measures the total amount of CPU processing time consumed by the application. When CPU usage is high, the CPU Time metric will show elevated values, reflecting the actual seconds of processor time used, which is the most direct indicator of CPU load.

Exam trap

The trap here is that candidates may confuse 'Requests per second' (a throughput metric) with CPU usage, assuming more requests always mean more CPU, but Azure App Service can handle many requests with low CPU if the workload is I/O-bound or efficiently parallelized.

How to eliminate wrong answers

Option A is wrong because Data In/Out measures network throughput (bytes sent and received), not CPU utilization, so it cannot indicate high CPU usage. Option B is wrong because Requests per second measures the rate of incoming HTTP requests, which can correlate with CPU load but does not directly measure CPU consumption; a high request rate can be handled efficiently without high CPU usage. Option D is wrong because Memory working set measures the amount of physical memory (RAM) used by the app, not CPU usage; high memory usage does not imply high CPU usage.

Full explanation →
255
Multi-Selectmedium

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

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

Topics support multiple subscribers.

Why this answer

Azure Service Bus Topics supports a pub/sub pattern by allowing multiple subscriptions to receive copies of messages sent to a topic. Each subscription acts as a logical queue, and messages are automatically routed to all subscriptions that match the filtering rules, enabling decoupled communication between publishers and subscribers.

Exam trap

The trap here is that candidates often confuse Azure Queue Storage (point-to-point) with a pub/sub service, or mistakenly think Notification Hubs supports pub/sub because it broadcasts to many devices, but it lacks subscriber-managed subscriptions and message retention for independent consumption.

Full explanation →
256
MCQeasy

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

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

Azure Storage firewalls are configured to restrict network access to the storage account based on specific IP addresses or virtual networks. If the client's public IP address from which the Azure CLI command is executed is not explicitly included in the storage account's allowed IP ranges, the firewall will block the incoming request. This network-level denial often manifests as an "AuthorizationFailure" or "Forbidden" error (HTTP 403), as the storage service rejects the connection attempt before full authentication and authorization processing can occur for an unapproved source.

Why this answer

The storage account firewall explicitly blocks all traffic except from IP addresses or subnets in the allow list. Since the CLI is running from a machine whose IP is not on that list, the request is denied at the network layer before any authentication or authorization checks occur. This is the most direct cause of the authorization error.

Exam trap

The trap here is that candidates often confuse network-level firewall blocking with missing RBAC role assignments, but the firewall denies the request before any identity-based authorization is checked.

How to eliminate wrong answers

Option B is wrong because the 'Storage Blob Data Reader' role is an RBAC permission that controls access to data operations, but the firewall blocks the request at the network layer before RBAC is evaluated. Option C is wrong because a misspelled container name would result in a '404 Not Found' error, not an authorization error. Option D is wrong because TLS version mismatch would cause a connection failure or handshake error, not an authorization error; Azure CLI defaults to TLS 1.2 on modern systems.

Full explanation →
257
MCQhard

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

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

Azure Event Grid is a highly scalable, fully managed event routing service that enables reactive programming by delivering events from various sources to different handlers. It operates on a publish-subscribe model, allowing applications to subscribe to specific event types from Azure services like Storage Accounts, Resource Groups, or custom topics. Its design specifically caters to high-volume event notifications, providing low-latency delivery and robust filtering capabilities, making it ideal for scenarios requiring immediate processing of discrete events.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
258
MCQmedium

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

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

Implementing application-level caching for secrets, coupled with a short time-to-live (TTL), significantly reduces the frequency of direct calls to Azure Key Vault. This approach minimizes network latency associated with repeated Key Vault requests and decreases the operational load on the Key Vault service itself. Key Vault remains the authoritative source, ensuring secrets are eventually refreshed and updated, balancing performance with security and freshness.

Why this answer

It directly addresses the need to minimize latency and network overhead by caching secrets locally with a short TTL, while still using Azure Key Vault as the authoritative source. This pattern reduces the frequency of network calls to Key Vault, which is critical for high-throughput applications where every millisecond matters. The short TTL ensures that secret updates are eventually reflected without stale data persisting indefinitely.

Exam trap

The trap here is that candidates may confuse security features (like firewalls or soft-delete) with performance optimizations, or mistakenly think that storing secrets in config files is acceptable for minimizing latency, ignoring the critical security implications.

How to eliminate wrong answers

Option A is wrong because enabling the Key Vault firewall and allowing only trusted Azure services does not reduce latency or network overhead; it only restricts access and does not eliminate the need for network calls. Option B is wrong because storing secrets directly in application configuration files violates security best practices, as it exposes secrets in plaintext and bypasses Key Vault's access control and auditing. Option D is wrong because enabling soft-delete is a data protection and recovery feature, not a performance optimization; it does nothing to reduce latency or network overhead.

Full explanation →
259
MCQmedium

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

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

Enabling the Hierarchical Namespace (HNS) is a foundational configuration that dictates how data is organized and accessed within an Azure storage account, providing file system semantics essential for Azure Data Lake Storage Gen2. Since this property cannot be altered after an account has been provisioned, the only method to achieve HNS functionality is to delete the existing storage account. Subsequently, a brand new one must be created, explicitly specifying the `-EnableHierarchicalNamespace $true` parameter during its creation, which inherently requires migrating any data from the old account to the new one.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
260
MCQeasy

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

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

Azure Service Bus Sessions provide guaranteed ordered delivery (FIFO) and single-consumer processing for related messages. Messages belonging to the same session, identified by a `SessionId` property, are delivered exclusively to a single receiver. This receiver acquires an exclusive lock on the session, ensuring that all messages within that session are processed sequentially by only one consumer at a time, preventing out-of-order processing or concurrent handling of related messages.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
261
MCQmedium

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

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

This design is optimal for querying a specific device's temperature history. By using 'device ID' as the PartitionKey, all temperature readings for a single device are co-located within the same physical partition, enabling highly efficient queries for that device. The 'timestamp (inverted ticks)' as RowKey ensures that entries within that partition are sorted in reverse chronological order, allowing for rapid range queries (e.g., all readings for a device within a specific time window) without incurring costly cross-partition scans.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
262
MCQhard

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

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

Enabling Application Insights for the Functions app is the correct approach because it automatically captures comprehensive telemetry for Durable Functions, including orchestration lifecycle events (e.g., started, completed, failed, suspended, resumed) and activity function executions. This rich, structured data, accessible via Kusto Query Language (KQL), allows for detailed monitoring of individual orchestration instances, identification of bottlenecks, and the creation of precise alerts on failed orchestrations with full contextual information, enabling rapid diagnosis and resolution.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
263
MCQmedium

Your application stores user-generated content in Azure Blob Storage. You need to implement a shared access signature (SAS) that allows users to upload files to a specific container but not read or delete. The SAS must be valid for one hour. Which type of SAS should you use?

A.Account SAS
B.Service SAS
C.Stored access policy
D.User delegation SAS
AnswerB

A Service SAS is the most appropriate choice as it allows for highly granular control over access to a specific storage service, such as Azure Blob Storage. It can be precisely scoped to a particular container, defining exact permissions like "write-only," and setting an expiry time. This ensures that users can upload content to the designated container without gaining any other access, aligning perfectly with the principle of least privilege for this scenario.

Why this answer

A Service SAS is the correct choice because it allows you to delegate access to a specific Azure Blob Storage resource (in this case, a container) with granular permissions. You can generate a Service SAS scoped to the container with only the 'Create' and 'Write' permissions (no 'Read' or 'Delete'), and set its expiry to one hour. This meets the requirement of allowing uploads while preventing reads or deletes.

Exam trap

The trap here is that candidates often confuse 'Service SAS' with 'Account SAS' because both can be used for blobs, but the Account SAS applies to the entire storage account and cannot be restricted to a single container, whereas the Service SAS is resource-specific.

How to eliminate wrong answers

Option A is wrong because an Account SAS grants access to multiple services (blob, queue, table, file) and all resources under the storage account, making it too broad and not scoped to a single container. Option C is wrong because a stored access policy is not a type of SAS; it is a server-side policy that can be used to control SAS permissions and expiry, but the question asks for the type of SAS itself. Option D is wrong because a User delegation SAS is secured with Azure AD credentials and is used for operations like listing blobs or reading/writing with specific RBAC roles, but it is typically used for scenarios requiring finer-grained identity-based access, not for a simple time-limited upload-only SAS.

Full explanation →
264
MCQeasy

You are monitoring an Azure App Service using Application Insights. You want to alert when the average server response time exceeds 2 seconds over a 5-minute window. What should you create?

A.An availability alert
B.A log alert with a custom KQL query
C.A metric alert with 'Server response time' as the signal
D.An activity log alert
AnswerC

Metric alerts in Azure Monitor are specifically designed to monitor numeric values collected over time, such as performance counters or telemetry from Application Insights. 'Server response time' is a standard, pre-aggregated metric automatically collected by Application Insights, representing the time taken for the server to process a request. Configuring a metric alert with this signal allows for direct, efficient, and real-time thresholding to detect performance degradation or spikes in latency, making it the ideal choice for this scenario.

Why this answer

A metric alert is the correct choice because 'Server response time' is a pre-aggregated performance metric emitted by Azure App Service to Application Insights. Metric alerts evaluate this signal against a static threshold (e.g., >2 seconds) over a specified time window (e.g., 5 minutes) without needing custom queries, making them ideal for simple threshold-based monitoring of latency.

Exam trap

The trap here is that candidates confuse metric alerts (which use pre-aggregated metrics) with log alerts (which require custom KQL queries), assuming that any alert involving Application Insights must use logs, when in fact the 'Server response time' is a standard metric signal available directly in the metric alert creation flow.

How to eliminate wrong answers

Option A is wrong because availability alerts monitor endpoint availability (HTTP response codes) and latency from synthetic ping tests, not the average server response time of actual user requests. Option B is wrong because log alerts with custom KQL queries are used for complex, multi-dimensional analysis of raw log data (e.g., traces, exceptions) and are unnecessary for a simple threshold on a pre-aggregated metric like server response time. Option D is wrong because activity log alerts fire on Azure resource management events (e.g., create, delete, scale) and do not monitor application-level performance metrics like response time.

Full explanation →
265
MCQmedium

You are configuring an Azure Event Grid subscription to trigger an Azure Function when a blob is created in a storage account. However, the function is not being triggered. You have verified that the function endpoint is reachable and the storage account is in the same region. What is the most likely cause?

A.The storage account has public network access disabled.
B.The AzureWebJobsStorage connection string is missing from the function app settings.
C.Blob versioning is not enabled on the storage account.
D.The Event Grid subscription does not have the required RBAC role on the function.
AnswerD

For an Event Grid subscription to successfully deliver events to an Azure Function app, the Event Grid system topic's managed identity or service principal requires appropriate permissions on the target function. Specifically, the 'Event Grid Data Sender' role must be assigned to the function app or its containing resource group. Without this role, Event Grid lacks the necessary authorization to invoke the function's HTTP endpoint, resulting in delivery failures even if the endpoint is otherwise accessible. This RBAC assignment ensures secure communication and event delivery.

Why this answer

If the Azure Function app is secured with Azure AD authentication, and the Event Grid subscription is configured to use a managed identity for delivery, then that managed identity requires an appropriate RBAC role (e.g., 'Azure Function Data Sender' or a custom role allowing `Microsoft.Web/sites/functions/invoke/action`) on the function app to successfully invoke the function. Without this role, Event Grid cannot authorize its call to the function, even if the endpoint is network reachable. This is a common misconfiguration when the function is protected by Azure AD authentication.

Exam trap

The trap here is that candidates often focus on storage account networking or function app settings (like AzureWebJobsStorage) instead of recognizing that Event Grid requires explicit RBAC permissions when the function endpoint is secured with Azure AD authentication.

How to eliminate wrong answers

Option A is wrong because disabling public network access on the storage account affects data plane operations (e.g., blob read/write), not the Event Grid event delivery path; Event Grid uses its own internal HTTPS calls to the function endpoint, not the storage account's network. Option B is wrong because the AzureWebJobsStorage connection string is used by the function runtime for internal storage (e.g., checkpointing, logs), not for receiving Event Grid triggers; the trigger binding itself does not depend on this setting. Option C is wrong because blob versioning is a feature for preserving previous blob versions and is not required for Event Grid to detect a blob creation event; Event Grid uses storage account event notifications (e.g., BlobCreated) which work independently of versioning.

Full explanation →
266
MCQhard

Your application uses Azure Cosmos DB with the SQL API. You notice that read requests are being throttled (HTTP 429) during peak hours. You need to improve read performance without changing the application code. Which action should you take?

A.Add a composite index to the container
B.Increase the provisioned throughput (RU/s) for the container
C.Enable multi-region writes for the Cosmos DB account
D.Change the default consistency level to Strong
AnswerB

Increasing the provisioned throughput, measured in Request Units per second (RU/s), directly expands the total capacity available for all database operations, including reads and writes. Each operation consumes a certain number of RUs, and exceeding the provisioned RU/s results in throttling. By increasing RU/s, the application gains more headroom to execute a higher volume of operations concurrently without encountering rate limiting.

Why this answer

Throttling (HTTP 429) occurs when the consumed request units per second exceed the provisioned throughput. Increasing the provisioned RU/s for the container directly raises the capacity, allowing more read requests per second without any code changes. This is the simplest and most direct way to eliminate throttling under peak load.

Exam trap

The trap here is that candidates confuse performance optimization (indexing, consistency) with capacity management; throttling is always a throughput capacity problem, not a query or consistency problem.

How to eliminate wrong answers

Option A is wrong because composite indexes improve query performance for multi-field ORDER BY or filter operations, but they do not increase the overall throughput capacity; throttling is a capacity issue, not a query optimization issue. Option C is wrong because enabling multi-region writes improves write availability and latency but does not increase the read throughput limit for a single region; reads are still subject to the provisioned RU/s on each region. Option D is wrong because Strong consistency increases the RU cost per read (requiring quorum reads), which would worsen throttling, not improve it; weaker consistency levels reduce RU consumption for reads.

Full explanation →
267
MCQmedium

Your company uses Azure Blob Storage to store sensitive documents. You need to ensure that all access to the storage account is encrypted in transit and that clients must use TLS 1.2 or higher. Which configuration should you enforce?

A.Use a private endpoint for the storage account.
B.Set the 'Minimum TLS version' to 1.2 in the storage account's configuration.
C.Configure network rules to allow only from trusted IPs.
D.Enable 'Secure transfer required' (HTTPS only).
AnswerB

Setting the 'Minimum TLS version' to 1.2 in the storage account's configuration directly addresses the requirement to enforce a specific encryption standard. This configuration ensures that Azure Storage will reject any connection attempts that utilize older, less secure TLS versions (such as TLS 1.0 or TLS 1.1). Consequently, all data in transit to and from the storage account will be encrypted using the more robust and secure TLS 1.2 or later protocols, meeting compliance and security best practices.

Why this answer

Setting the 'Minimum TLS version' to 1.2 in the storage account's configuration explicitly enforces that all client connections must use TLS 1.2 or higher, rejecting any requests using older, less secure TLS versions. This directly addresses the requirement to ensure encryption in transit with a specific minimum TLS version, as Azure Blob Storage supports TLS 1.0, 1.1, and 1.2 by default, and this setting overrides that default to enforce the higher standard.

Exam trap

The trap here is that candidates often confuse 'Secure transfer required' (which only enforces HTTPS) with the 'Minimum TLS version' setting, mistakenly believing that enabling HTTPS alone guarantees a specific TLS version, when in fact HTTPS can be negotiated over TLS 1.0, 1.1, or 1.2 unless explicitly restricted.

How to eliminate wrong answers

Option A is wrong because using a private endpoint restricts network access to the storage account over a private IP within a virtual network, but it does not enforce encryption in transit or a specific TLS version; traffic over a private endpoint still uses HTTPS but the TLS version is not controlled by this configuration. Option C is wrong because configuring network rules to allow only from trusted IPs controls which source IP addresses can access the storage account, but it does not enforce encryption in transit or mandate TLS 1.2; traffic from allowed IPs could still use HTTP or older TLS versions. Option D is wrong because enabling 'Secure transfer required' (HTTPS only) ensures that all requests must use HTTPS, but it does not enforce a minimum TLS version; clients could still connect using TLS 1.0 or 1.1 over HTTPS, which does not meet the requirement for TLS 1.2 or higher.

Full explanation →
268
MCQhard

You have an Azure Container Apps environment running multiple microservices. One microservice is experiencing high CPU usage and slow response times. You need to configure autoscaling rules to scale based on HTTP requests. Which scaling rule should you add?

A.HTTP scaling rule (KEDA)
B.CPU percentage scaling rule
C.Memory percentage scaling rule
D.Custom scaling rule using Azure Monitor metrics
AnswerA

An HTTP scaling rule, powered by KEDA (Kubernetes Event-driven Autoscaling), is the most appropriate choice for web microservices in Azure Container Apps. This rule directly monitors the rate of incoming HTTP requests or the number of concurrent requests per replica, allowing the container app to scale out proactively as web traffic increases. This direct correlation ensures rapid and efficient response to fluctuating demand, maintaining optimal performance and availability for user-facing applications.

Why this answer

KEDA's HTTP scaling rule is specifically designed to scale Azure Container Apps based on the number of concurrent HTTP requests, which directly addresses high CPU usage and slow response times caused by request load. Unlike CPU or memory metrics, HTTP scaling reacts to incoming request volume proactively, allowing the microservice to handle spikes before resource saturation occurs.

Exam trap

The trap here is that candidates often choose CPU or memory scaling rules because they seem directly related to high CPU usage, but the question explicitly asks for scaling based on HTTP requests, which requires a request-based scaler like KEDA's HTTP scaler, not resource-based metrics.

How to eliminate wrong answers

Option B is wrong because CPU percentage scaling rule reacts to resource utilization after it has already increased, which is reactive and may not prevent slow response times during sudden request surges. Option C is wrong because memory percentage scaling rule is typically used for memory-bound workloads, not CPU-bound or request-driven scenarios, and memory often lags behind CPU as a scaling signal. Option D is wrong because custom scaling rules using Azure Monitor metrics require additional configuration and are not as straightforward or purpose-built as KEDA's HTTP scaler for request-based autoscaling in Container Apps.

Full explanation →
269
MCQmedium

You have an Azure App Service that runs a web API. The API is accessed by multiple client applications. You need to implement authentication and authorization using Microsoft Entra ID. The solution must allow client applications to obtain access tokens using the OAuth 2.0 client credentials flow. Which authentication setting should you configure in the App Service?

A.Enable the 'Token store' in the Authentication / Authorization blade.
B.Configure the app to use the Microsoft.Identity.Web library to validate tokens.
C.Use the built-in authentication module with Microsoft Entra ID as the identity provider.
D.Upload a client certificate and configure certificate-based authentication.
AnswerC

Easy Auth can validate tokens issued by Microsoft Entra ID.

Why this answer

Configuring the built-in authentication module in Azure App Service with Microsoft Entra ID as the identity provider allows the App Service to validate access tokens issued by Microsoft Entra ID. Client applications can use the OAuth 2.0 client credentials flow to obtain tokens from Microsoft Entra ID and then present them to the App Service. The built-in auth module does not perform token acquisition; it only validates tokens at the gateway level, simplifying the validation process for the app.

Exam trap

A common misconception is that the built-in authentication module handles the entire OAuth 2.0 client credentials flow, including token acquisition. In reality, the module only validates tokens; the client applications must independently obtain tokens from Microsoft Entra ID. Additionally, candidates may consider Microsoft.Identity.Web (Option B) as an App Service setting, but it is a library used within the application code for token validation and acquisition, not a configuration option in the App Service itself.

How to eliminate wrong answers

Option A is wrong because the 'Token store' is a feature that caches tokens for the authenticated user session, but it does not configure the identity provider or enable the client credentials flow; it is used for storing tokens after authentication is already set up. Option B is wrong because the Microsoft.Identity.Web library is a client-side library used within the application code to validate tokens and handle authentication, not a configuration setting in the App Service's Authentication / Authorization blade; the question asks for a setting to configure in the App Service, not code changes. Option D is wrong because certificate-based authentication is used for client certificate authentication (mutual TLS), which is a different mechanism than the OAuth 2.0 client credentials flow; it does not involve obtaining access tokens via Microsoft Entra ID.

Full explanation →
270
MCQeasy

You are deploying a web application to Azure App Service. The application needs to read configuration settings that vary by deployment environment (development, staging, production). You want to minimize application changes and leverage Azure services. What should you use?

A.Use Azure Key Vault secrets for configuration values.
B.Use Azure DevOps variable groups and inject them at build time.
C.Use Azure App Configuration with feature flags.
D.Use Azure App Service application settings.
AnswerD

Azure App Service application settings are key-value pairs that are exposed to the application as environment variables at runtime. These settings can be easily configured and managed directly within the Azure portal, Azure CLI, or PowerShell, and critically, they can be configured per deployment slot. This allows for seamless environment-specific configurations (e.g., development, staging, production) and dynamic updates without requiring code changes or redeployments, making them the most straightforward and effective solution for web application configuration.

Why this answer

Azure App Service application settings are the correct choice because they are natively supported by the App Service platform, allowing you to define key-value pairs that are injected as environment variables at runtime. This approach requires no application code changes, as the settings are automatically available via standard configuration APIs (e.g., `Environment.GetEnvironmentVariable` in .NET or `process.env` in Node.js), and you can configure different values per deployment slot (e.g., development, staging, production) without redeploying the application.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing Azure App Configuration or Key Vault for all configuration needs, forgetting that Azure App Service application settings are the simplest, most direct way to handle environment-specific, non-sensitive settings without additional code or services.

How to eliminate wrong answers

Option A is wrong because Azure Key Vault secrets are designed for storing sensitive data (e.g., passwords, connection strings) and require explicit code changes to retrieve them via SDK calls or a managed identity, adding complexity for non-sensitive configuration settings. Option B is wrong because Azure DevOps variable groups are a build-time mechanism that injects values during the CI/CD pipeline, not a runtime configuration service; this would require modifying the build process and does not leverage Azure App Service's native environment-based settings. Option C is wrong because Azure App Configuration with feature flags is a centralized configuration service for managing feature toggles and hierarchical settings, but it is overkill for simple environment-specific key-value pairs and requires additional SDK integration in the application code.

Full explanation →
271
MCQhard

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

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

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

Why this answer

KEDA (Kubernetes Event-Driven Autoscaling) is natively integrated with Azure Container Apps to enable event-driven scaling. By configuring a KEDA-based scale rule with an Azure Queue Storage trigger, the container app can scale to zero replicas when the queue is empty and scale out based on the queue length, meeting the requirement for idle scaling and queue-driven scaling.

Exam trap

The trap here is that candidates may confuse Azure Front Door health probes (used for traffic routing) with scaling triggers, or assume manual replica counts or Availability Sets are relevant to container scaling, when in fact KEDA is the specific technology for event-driven scaling in Azure Container Apps.

How to eliminate wrong answers

Option A is wrong because a manual replica count only sets a fixed number of replicas and cannot scale to zero or dynamically scale based on queue length. Option B is wrong because an Availability Set is a feature for virtual machine high availability within a region, not applicable to Azure Container Apps which uses replica-based scaling. Option C is wrong because an Azure Front Door health probe is used for load balancing and routing traffic based on backend health, not for scaling container replicas based on queue metrics.

Full explanation →
272
MCQmedium

Refer to the exhibit. The APIM policy is applied to an API. What is the effect of this policy?

A.Each subscription can make up to 10 calls per minute.
B.Each subscription can make up to 10 calls total.
C.Each IP address can make up to 10 calls per minute.
D.All calls from a single IP are blocked after 10 requests.
AnswerA

The `rate-limit` policy, when applied without a `by-key` attribute, defaults to limiting requests per subscription key. With `calls='10'` and `renewal-period='60'`, it precisely means that a single subscription is permitted to make a maximum of 10 API calls within any 60-second window. This ensures fair usage and prevents individual subscriptions from overwhelming the API backend.

Why this answer

The policy snippet uses the `rate-limit` policy, which enforces a per-subscription key rate limit. The `calls` attribute is set to 10 and the `renewal-period` is 60 seconds, meaning each subscription key is allowed up to 10 API calls within any 60-second sliding window. This matches option A exactly.

Exam trap

The trap here is confusing `rate-limit` (per-subscription, sliding window) with `rate-limit-by-key` (per-IP or custom key) or with a hard total quota, leading candidates to mistakenly choose IP-based or total-call options.

How to eliminate wrong answers

Option B is wrong because the `rate-limit` policy does not enforce a total lifetime cap; it resets every 60 seconds, so calls are not limited to a total of 10. Option C is wrong because the `rate-limit` policy operates on subscription keys, not IP addresses; IP-based rate limiting would use the `rate-limit-by-key` policy with a different context variable. Option D is wrong because the policy does not block calls after 10 requests; it allows up to 10 calls per minute and then returns a 429 Too Many Requests status for additional calls within that minute, but the counter resets after the renewal period.

Full explanation →
273
MCQhard

You need to store billions of small telemetry data entries (each ~100 bytes) from IoT devices. The data is written once and rarely updated. You need to run analytical queries on the last 30 days of data daily. The queries scan large ranges of data by timestamp and require sub-second response times. You need the lowest storage cost while meeting query latency requirements. Which Azure Storage solution should you use?

A.Azure Blob Storage with hot access tier and Data Lake Storage Gen2.
B.Azure Table Storage with a timestamp partition key.
C.Azure Cosmos DB with SQL API and automatic indexing.
D.Azure Blob Storage with cool access tier and Azure Data Lake Storage Gen2.
AnswerA

Blob Storage with Data Lake Storage Gen2 lacks native indexing for sub-second range scans over timestamped data, requiring full file scans that cannot meet the query latency requirement. It is tempting because its hot tier offers low-cost bulk storage for immutable telemetry, and it would be correct for archival or batch-processing workloads where sub-second analytical response is not demanded.

Why this answer

Azure Blob Storage with the hot access tier is suitable for data that is accessed frequently (daily queries on the last 30 days), providing lower transaction costs compared to the cool tier for active data. Azure Data Lake Storage Gen2, built on Blob Storage, enables hierarchical namespace and POSIX-like access, allowing efficient analytical queries on large timestamp-ranged data with sub-second response times via partitioning and parallel processing, meeting the performance and scalability requirements at a cost-effective price point for the storage of billions of small entries.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB (Option C) for its low-latency queries, overlooking that its cost model (RU/s) makes it prohibitively expensive for scanning billions of small records, while Blob Storage with Data Lake Storage Gen2 provides the required performance at a fraction of the cost when using proper partitioning and file formats.

How to eliminate wrong answers

Option A is wrong because the hot access tier has higher storage costs than cool tier, which is unnecessary for data that is rarely updated and only queried daily on the last 30 days. Option B is wrong because Azure Table Storage with a timestamp partition key can lead to hot partitions (all writes go to the same partition) and does not support sub-second analytical queries on large ranges of data efficiently due to lack of indexing and parallel scan capabilities. Option C is wrong because Azure Cosmos DB with SQL API and automatic indexing is optimized for transactional workloads with low-latency point reads, not for large-range analytical scans; it incurs high RU costs for scanning billions of small entries, making it far more expensive than Blob Storage for this use case.

Full explanation →
274
MCQmedium

You are developing a .NET application that needs to store and retrieve large binary objects (up to 4.7 TB) in Azure Blob Storage. The application requires the lowest possible latency for reads and must support object-level tiering. Which blob type should you use?

A.Block blob
B.Archive storage account
C.Page blob
D.Append blob
AnswerA

Block blobs are the standard choice for storing large amounts of unstructured object data, such as documents, images, and videos. They are optimized for streaming and parallel uploads, composed of individual blocks, and crucially support object-level tiering (Hot, Cool, Archive). This tiering capability allows for cost optimization based on access frequency, making them highly versatile for various data storage needs up to approximately 4.75 TB.

Why this answer

Block blobs are designed for storing large binary objects up to approximately 4.74 TB and support object-level tiering (Hot, Cool, Cold, Archive). They offer the lowest read latency among Azure blob types because they can be accessed directly via HTTP/HTTPS and are optimized for streaming and random read access. Object-level tiering allows you to change the access tier of individual blobs without moving the storage account, which meets the requirement for granular cost optimization.

Exam trap

The trap here is that candidates confuse storage account tiers (Hot, Cool, Archive) with blob types, or assume Page blobs are suitable for large binary objects because of their high maximum size, overlooking that Page blobs lack object-level tiering and are designed for VHDs, not general binary storage.

How to eliminate wrong answers

Option B (Archive storage account) is wrong because it is a storage account tier, not a blob type; it applies to the entire account and does not support object-level tiering—individual blobs cannot be moved between tiers within an Archive account. Option C (Page blob) is wrong because it is optimized for random read/write operations on virtual machine disks (VHDs) and has a maximum size of 8 TB, but it does not support object-level tiering and typically has higher latency for large binary object reads compared to block blobs. Option D (Append blob) is wrong because it is designed for append-only operations (e.g., logging) and does not support object-level tiering; it also has a maximum size of 195 GB, far below the 4.7 TB requirement.

Full explanation →
275
MCQmedium

You are developing a web application that allows users to upload images. The application is deployed on Azure App Service. After upload, the images must be processed to generate thumbnails and to extract metadata. The processing should happen asynchronously and must be resilient to failures. You need to design the solution using serverless components. The solution must minimize latency for the user during upload, and the processing must be retried automatically if it fails. You also need to ensure that the processing is idempotent, so that duplicate messages do not cause duplicate thumbnails. Which approach should you use? Option A: Use Azure Functions with a Blob Storage trigger to process each image as it is uploaded. The function generates thumbnails and stores metadata in Cosmos DB. Use the `leaseBlob` property to prevent duplicate processing. Option B: Use Azure Functions with an Event Grid trigger to process images. The function generates thumbnails and stores metadata in Cosmos DB. Use Event Grid's built-in retry policy and idempotent logic in the function. Option C: Use Azure Logic Apps with a Blob Storage connector to process images. The logic app generates thumbnails and stores metadata in Cosmos DB. Configure retry policy on the connector. Option D: Use Azure Functions with a Service Bus queue trigger. The web app sends a message to the queue after upload. The function processes the message, generates thumbnails, and stores metadata. Use message deduplication to ensure idempotency.

A.Azure Functions with Blob Storage trigger, using leaseBlob
B.Azure Logic Apps with Blob Storage connector
C.Azure Functions with Event Grid trigger
D.Azure Functions with Service Bus queue trigger and duplicate detection
AnswerD

Service Bus duplicate detection ensures idempotency; the queue separates upload from processing.

Why this answer

It uses a Service Bus queue with duplicate detection, which ensures idempotent processing by automatically discarding duplicate messages within a defined time window. The web app uploads the image and immediately sends a message to the queue, minimizing user latency. The Azure Function triggered by the queue processes the image asynchronously, and Service Bus's built-in retry policy (via dead-lettering and max delivery count) provides resilience against failures.

Exam trap

The trap here is that candidates often choose Event Grid (Option B) because it is serverless and has retry policies, but they overlook that Event Grid does not provide built-in message deduplication, which is critical for idempotent processing in this scenario.

How to eliminate wrong answers

Option A is wrong because Blob Storage triggers do not have a `leaseBlob` property for deduplication; blob leases are used for concurrency control, not for preventing duplicate processing of the same blob event, and Blob Storage triggers can miss events or fire duplicates without built-in deduplication. Option B is wrong because Event Grid triggers have a retry policy but lack built-in message deduplication; idempotency must be implemented manually in the function, and Event Grid does not guarantee exactly-once delivery, making duplicate handling error-prone. Option C is wrong because Logic Apps with a Blob Storage connector are not serverless in the same sense (they have higher latency and cost), and the connector does not provide message-level deduplication; retry policies on connectors do not ensure idempotent processing of duplicate blob events.

Full explanation →
276
MCQeasy

You are developing an Azure Function that uses a Service Bus queue trigger. You need to ensure that the function processes messages one at a time to guarantee order. Which configuration should you use?

A.Set the batchSize to 1 in host.json
B.Set the maxMessages to 1 in the ServiceBusTrigger attribute
C.Set the function to run on a Premium Plan
D.Set the maxDequeueCount to 1 in host.json
AnswerA

Setting the `batchSize` to `1` within the `host.json` file for the Service Bus trigger ensures that the Azure Function runtime processes only one message per function invocation. This configuration is crucial when strict message ordering or atomicity for individual messages is required, preventing the function from receiving multiple messages in a single batch. It directly controls the maximum number of messages the trigger will attempt to retrieve and process concurrently within one execution, effectively disabling batching.

Why this answer

Setting `batchSize` to 1 in `host.json` forces the Service Bus trigger to process only one message at a time from the queue. This ensures strict message ordering, as the function will not fetch or process the next message until the current one is completed (either successfully or moved to the dead-letter queue). The Service Bus trigger uses a message pump that respects the `batchSize` setting to control concurrency.

Exam trap

The trap here is that candidates often confuse `batchSize` (which controls how many messages are fetched at once) with `maxConcurrentCalls` (which controls how many parallel executions are allowed), and incorrectly assume that setting `maxConcurrentCalls` to 1 in the trigger attribute is the solution, but the attribute does not have a `maxMessages` property.

How to eliminate wrong answers

Option B is wrong because `maxMessages` is not a valid property of the `ServiceBusTrigger` attribute; the correct attribute property to control concurrency is `IsBatched` or `MaxConcurrentCalls`, but neither directly limits batch size to 1 for ordering. Option C is wrong because the Premium Plan provides higher throughput and predictable performance but does not inherently enforce single-message processing; ordering must be configured via `batchSize`. Option D is wrong because `maxDequeueCount` in `host.json` controls the number of times a message can be retried before being dead-lettered, not the concurrency or batch size.

Full explanation →
277
MCQeasy

A developer is building a solution that sends emails via SendGrid from Azure. Which Azure service should they use to integrate with SendGrid?

A.Azure Logic Apps
B.Azure API Management
C.Azure Functions
D.Azure Event Grid
AnswerA

Azure Logic Apps is a cloud-based service designed for automating workflows and integrating systems across various applications and services. It provides a rich gallery of pre-built connectors, including a dedicated one for SendGrid, which significantly simplifies the process of sending emails without requiring extensive custom code. This low-code/no-code approach makes Logic Apps an ideal choice for orchestrating email delivery as part of a larger business process or in response to specific events, directly handling the API interaction with SendGrid.

Why this answer

Azure Logic Apps provides a managed connector for SendGrid that simplifies integration by offering pre-built triggers and actions for sending emails. This allows developers to create automated workflows without writing custom code, making it the ideal choice for integrating SendGrid with Azure services.

Exam trap

The trap here is that candidates often choose Azure Functions because they think 'custom code is needed for email sending,' but the exam emphasizes using managed services with minimal code, making Logic Apps the correct choice for integration with third-party services like SendGrid.

How to eliminate wrong answers

Option B is wrong because Azure API Management is used to publish, secure, and analyze APIs, not to directly integrate with third-party email services like SendGrid. Option C is wrong because Azure Functions can send emails via SendGrid using custom code, but it requires manual implementation of HTTP calls or SDK usage, lacking the built-in connector and workflow automation that Logic Apps provides. Option D is wrong because Azure Event Grid is an event routing service that delivers events to subscribers, but it does not include native SendGrid integration or email-sending capabilities.

Full explanation →
278
MCQeasy

You are using Azure Monitor to collect logs from multiple Azure resources. You need to query logs to find all error events from the last 24 hours. Which query language should you use?

A.Transact-SQL (T-SQL)
B.PromQL
C.PowerShell
D.Kusto Query Language (KQL)
AnswerD

Kusto Query Language (KQL) is the powerful, read-only query language used to query and analyze data in Azure Data Explorer, Azure Monitor Logs (Log Analytics), and Azure Sentinel. It is specifically designed for querying large volumes of structured, semi-structured, and unstructured data, making it ideal for log and telemetry analysis. KQL provides rich capabilities for filtering, aggregating, joining, and visualizing data from various sources within Azure Monitor, making it the native and most efficient way to interact with log data.

Why this answer

Azure Monitor uses Kusto Query Language (KQL) as its native query language for log analytics. KQL is specifically designed for querying large volumes of structured and semi-structured data in Azure Data Explorer and Log Analytics workspaces, making it the correct choice for retrieving error events from the last 24 hours.

Exam trap

The trap here is that candidates may confuse Azure Monitor's query language with SQL-like syntax (T-SQL) due to familiarity, but KQL is the only language natively supported for log queries in Azure Monitor.

How to eliminate wrong answers

Option A is wrong because Transact-SQL (T-SQL) is used for querying relational databases like SQL Server or Azure SQL Database, not for Azure Monitor logs which require KQL. Option B is wrong because PromQL is the query language for Prometheus, a monitoring system for containerized environments, and is not supported in Azure Monitor Log Analytics. Option C is wrong because PowerShell is a scripting language for automation and configuration management, not a query language for log analytics; it can invoke KQL queries via cmdlets but cannot directly query logs.

Full explanation →
279
MCQmedium

You are developing an ASP.NET Core web app that uses Azure SQL Database. The SQL connection string contains a password that must be rotated every 30 days. The app runs on Azure App Service. You want to store the connection string securely and enable automatic rotation without redeploying the app. Which approach should you use?

A.Store the connection string in an App Setting and use Key Vault references. Configure a Key Vault policy to automatically rotate the secret.
B.Store the connection string in an App Setting as a plain text value and use deployment slots to swap when the password changes.
C.Use a managed identity to access the SQL database directly, bypassing the connection string entirely.
D.Store the connection string in Azure Key Vault and use an ARM template with a secret reference at deployment time.
AnswerA

This approach uses a Key Vault reference in the App Setting, which the runtime resolves automatically. The secret can have an expiration date, and you can automate its renewal using Azure automation or functions, enabling rotation without redeployment.

Why this answer

Azure App Service supports Key Vault references in App Settings, allowing you to securely store the connection string in Key Vault and reference it without exposing the password. By configuring a Key Vault policy to automatically rotate the secret (e.g., using a scheduled rotation or event-driven trigger), the password can be rotated every 30 days without redeploying the app, as the App Service runtime resolves the reference at runtime.

Exam trap

The trap here is that candidates often confuse Key Vault references with ARM template secret references, assuming both are resolved at runtime, but ARM template references are only evaluated during deployment, not dynamically.

How to eliminate wrong answers

Option B is wrong because storing the connection string as plain text in an App Setting exposes the password in the Azure portal and configuration files, violating security best practices, and deployment slots do not automate rotation—they only swap environments, requiring manual password updates. Option C is wrong because managed identity can authenticate to Azure SQL Database without a password, but it does not eliminate the need for a connection string entirely; the connection string still contains the server and database name, and managed identity does not support automatic rotation of a password (it uses certificate-based authentication). Option D is wrong because ARM template secret references are resolved at deployment time, not at runtime, so rotating the secret in Key Vault would require a new deployment to update the connection string, failing the requirement to avoid redeployment.

Full explanation →
280
MCQeasy

You are monitoring an Azure Function app that processes messages from an Event Hub. You want to be alerted if the function is failing to process messages (e.g., exceptions) and automatically restart the function host. Which Azure service should you use?

A.Azure Monitor alerts with a metric alert on exception count.
B.Application Insights availability tests.
C.Azure Service Health alerts.
D.Azure Advisor recommendations.
AnswerA

Azure Monitor allows configuring metric alerts based on telemetry collected from Azure Function Apps, often integrated with Application Insights. A metric alert on "Exceptions" can detect an abnormal increase in processing failures, indicating a problem with the function's execution logic or external dependencies. When triggered, this alert can activate an action group to perform automated remediation, such as restarting the function app host to clear transient issues and restore normal operation.

Why this answer

Azure Monitor metric alerts on exception count can trigger when the function app throws exceptions during message processing. By configuring an alert rule that fires on the 'Exceptions' metric, you can then set up an action group that includes an auto-remediation step, such as restarting the function app host via a webhook or Azure Automation runbook. This directly addresses the requirement to be alerted and automatically restart the host.

Exam trap

The trap here is that candidates often confuse Application Insights availability tests (which only check HTTP endpoint availability) with the need to monitor internal function exceptions, or they mistakenly think Azure Service Health alerts cover application-level errors instead of Azure platform issues.

How to eliminate wrong answers

Option B is wrong because Application Insights availability tests are designed to monitor the availability and responsiveness of HTTP endpoints, not to detect processing failures or exceptions within an Azure Function. Option C is wrong because Azure Service Health alerts notify you about service-level issues, outages, or planned maintenance affecting Azure services, not application-level exceptions in your function code. Option D is wrong because Azure Advisor provides proactive recommendations for best practices (e.g., performance, cost, reliability) but does not offer real-time alerting or automated restart capabilities based on exception metrics.

Full explanation →
281
MCQmedium

You are developing a .NET Core application that uploads large files (up to 50 GB) to Azure Blob Storage. The application must support resuming uploads that are interrupted due to network failures. Which approach should you use?

A.Use an append blob and append blocks in sequence.
B.Use a block blob and upload blocks in parallel, then commit the block list.
C.Use the Put Blob API to upload the entire file in a single request.
D.Use a page blob and upload pages in sequence.
AnswerB

Block blobs are the most suitable type for storing large files, as they allow a file to be broken down into smaller, manageable blocks. These blocks can be uploaded independently and in parallel using the `Put Block` operation, significantly accelerating the upload process. Once all blocks are successfully uploaded, the `Put Block List` operation commits them in the correct order, enabling robust resumable uploads by only re-uploading failed or missing blocks, which is critical for a 50 GB file.

Why this answer

Block blobs are designed for large files and support uploading blocks in parallel, which improves throughput and reliability. By uploading individual blocks and then committing the block list, you can resume an interrupted upload by re-uploading only the missing blocks, as each block is identified by a unique block ID. This approach is ideal for files up to 50 GB and aligns with Azure's recommended pattern for resumable uploads.

Exam trap

Microsoft often tests the misconception that append blobs are suitable for large file uploads because they support appending, but the trap is that append blobs lack the block-level granularity needed for resumable uploads, unlike block blobs which are explicitly designed for this scenario.

How to eliminate wrong answers

Option A is wrong because append blobs are optimized for append operations (e.g., logging) and do not support resumable uploads; if an append fails, you cannot easily resume without re-uploading the entire blob. Option C is wrong because the Put Blob API can only upload blobs up to 5 TB for block blobs, but it uploads the entire file in a single request, which is impractical for large files and does not support resumability; for files over 256 MB, Azure requires using block uploads. Option D is wrong because page blobs are designed for random read/write access (e.g., VHDs) and are not optimized for large file uploads; they do not provide a built-in mechanism for resuming interrupted uploads.

Full explanation →
282
MCQmedium

You develop a containerized application that runs on Azure Container Instances (ACI). The application needs to securely access Azure SQL Database using a connection string. You want to minimize administrative effort and avoid storing secrets in the container image. What should you do?

A.Embed the connection string in the container image as a configuration file.
B.Store the connection string in an environment variable in the container group.
C.Enable managed identity for the container group and use Microsoft Entra authentication to Azure SQL.
D.Mount a volume from Azure Key Vault using a secret volume.
AnswerC

Enabling managed identity for the container group and using Microsoft Entra authentication to Azure SQL is the most secure and recommended approach. A managed identity provides an automatic, Azure AD-managed identity for the container group, allowing it to authenticate to Azure SQL Database without any credentials needing to be stored in code or configuration. This eliminates the risk of secret leakage and simplifies credential rotation, as Azure handles the identity lifecycle.

Why this answer

Enabling a managed identity for the container group allows the application to authenticate to Azure SQL Database using Microsoft Entra ID (formerly Azure Active Directory) without storing any secrets. The application requests an access token from the Azure Instance Metadata Service (IMDS) endpoint at 169.254.169.254, then uses that token to connect to Azure SQL. This eliminates the need to manage connection strings or secrets, minimizing administrative effort and keeping secrets out of the container image.

Exam trap

The trap here is that candidates often confuse environment variables (Option B) as a secure alternative to embedding secrets, but environment variables are still plaintext and visible in the container's process list, whereas managed identity provides true secretless authentication.

How to eliminate wrong answers

Option A is wrong because embedding the connection string in the container image as a configuration file violates the requirement to avoid storing secrets in the image; anyone with access to the image can extract the secret. Option B is wrong because storing the connection string in an environment variable in the container group still exposes the secret in plaintext within the container's runtime environment and requires manual management of the secret value. Option D is wrong because mounting a volume from Azure Key Vault using a secret volume still requires the container to have a connection string (or secret) to access Key Vault initially, and it introduces additional complexity without leveraging the simpler managed identity approach.

Full explanation →
283
Multi-Selecthard

Which THREE Azure Storage features can be used to enforce immutability for compliance requirements?

Select 3 answers
A.Blob versioning with delete lock policy
B.Legal hold on a blob container
C.Blob immutability policy (time-based retention)
D.Soft delete for blobs
E.Storage account firewall rules
AnswersA, B, C

Versioning with delete lock can prevent permanent deletion.

Why this answer

Blob versioning with a delete lock policy prevents deletion of blob versions, effectively enforcing immutability by ensuring that once a version is created, it cannot be deleted or overwritten. This satisfies compliance requirements such as SEC 17a-4(f) or FINRA rules that mandate data preservation.

Exam trap

The trap here is that candidates may confuse soft delete with immutability, not realizing that soft delete only offers recovery, not prevention of deletion or modification, which is required for true compliance immutability.

Full explanation →
284
MCQhard

You are designing a solution that stores sensitive customer data in Azure Blob Storage. The data must be encrypted at rest using a customer-managed key (CMK) stored in Azure Key Vault. Additionally, the solution must support automatic key rotation every 90 days. You need to configure the encryption settings. Which combination of Azure services and features should you use?

A.Use Azure Information Protection to encrypt the blobs with a customer-managed key.
B.Use Azure Disk Encryption with Azure Key Vault to encrypt the storage account.
C.Use Azure Storage Service Encryption (SSE) with Microsoft-managed keys and enable automatic key rotation.
D.Use Azure Storage encryption with a customer-managed key stored in Azure Key Vault. Configure a key rotation policy in Key Vault to rotate the key every 90 days.
AnswerD

This option correctly leverages Azure Storage encryption with Customer-Managed Keys (CMK), providing the necessary control over the encryption key lifecycle. Storing the key in Azure Key Vault ensures secure key management and allows for configuring an automatic key rotation policy directly within Key Vault. This setup directly addresses the requirement for both data at rest encryption and scheduled key rotation, enhancing security and compliance without manual intervention.

Why this answer

Azure Storage Service Encryption (SSE) supports customer-managed keys (CMK) stored in Azure Key Vault for encrypting blob data at rest. Automatic key rotation every 90 days can be achieved by configuring a key rotation policy in Azure Key Vault, which allows you to define a rotation frequency (e.g., 90 days) and automatically generate a new key version. This meets both the CMK and automatic rotation requirements without additional services.

Exam trap

The trap here is that candidates confuse Azure Disk Encryption (for VMs) with Azure Storage encryption (for Blob Storage), or assume that Microsoft-managed keys can be configured to meet a customer-controlled rotation schedule, when in fact only customer-managed keys in Key Vault allow custom rotation policies.

How to eliminate wrong answers

Option A is wrong because Azure Information Protection is a classification and labeling service for data protection policies, not an encryption mechanism for Azure Blob Storage at rest; it does not integrate with Azure Storage SSE for CMK. Option B is wrong because Azure Disk Encryption encrypts virtual machine disks (OS and data disks) using BitLocker or DM-Crypt, not Azure Blob Storage data; it is designed for IaaS VMs, not PaaS storage services. Option C is wrong because it specifies Microsoft-managed keys, which do not satisfy the customer-managed key requirement; automatic key rotation with Microsoft-managed keys is handled by Azure, but the customer cannot control the key material or rotation schedule.

Full explanation →
285
MCQhard

A company runs an ASP.NET Core web app on Azure App Service. They need to implement health checks that monitor the app's dependencies, such as a database and an external API. The health endpoint should return a 200 status if all dependencies are healthy, a 503 if any dependency is unhealthy, and a 400 if the request is malformed. Which approach should you take?

A.Implement custom health checks using the ASP.NET Core Health Checks middleware.
B.Use the ASP.NET Core Diagnostics middleware to generate a health page.
C.Configure Application Insights availability tests.
D.Use the built-in health check endpoint in Azure App Service.
AnswerA

The ASP.NET Core Health Checks middleware provides a robust and extensible framework for monitoring the operational health of an application and its dependencies. Developers can register custom health checks for various components like databases, external APIs, or message queues, defining specific logic to determine their status. This middleware exposes an endpoint that returns detailed health reports, allowing for custom HTTP status codes (e.g., 200 for healthy, 503 for unhealthy, or even 400 for specific application-defined issues) based on the aggregated health of all registered checks, making it ideal for granular application-level monitoring.

Why this answer

The ASP.NET Core Health Checks middleware allows you to implement custom health checks that monitor specific dependencies like a database and an external API. You can configure the middleware to return a 200 OK status when all checks pass, a 503 Service Unavailable when any check fails, and a 400 Bad Request for malformed requests by using the appropriate response writer and status code mapping.

Exam trap

The trap here is that candidates often confuse the built-in Azure App Service health check endpoint (which only returns 200 OK for the app's root) with the customizable ASP.NET Core Health Checks middleware that supports dependency monitoring and custom status codes.

How to eliminate wrong answers

Option B is wrong because the ASP.NET Core Diagnostics middleware is designed for developer exception pages and status code pages, not for implementing dependency-specific health checks with custom status codes like 503 or 400. Option C is wrong because Application Insights availability tests are used for monitoring the availability of a web endpoint from external locations, not for implementing an internal health endpoint that checks application dependencies and returns specific HTTP status codes. Option D is wrong because the built-in health check endpoint in Azure App Service only provides a basic ping check (returning 200 OK) and does not support custom dependency monitoring or returning 503 or 400 status codes.

Full explanation →
286
MCQmedium

You are building an Azure Logic App that must call an external API secured with OAuth 2.0 Client Credentials flow. The external API is registered in a different Microsoft Entra ID tenant. You need to obtain an access token and add it to the request headers. Which action and authentication configuration should you use?

A.Use the HTTP action with Managed Identity authentication.
B.Use the HTTP + Swagger connector to import the API definition.
C.Use the HTTP action with Active Directory OAuth authentication, providing the tenant ID, client ID, and client secret.
D.Use the Azure Key Vault - Get secret action to retrieve a token.
AnswerC

This configuration correctly leverages the OAuth 2.0 Client Credentials flow, where the Logic App acts as a confidential client. By providing the external API's Microsoft Entra ID tenant ID, a registered application's client ID, and its corresponding client secret, the Logic App can directly request an access token from the external tenant's token endpoint. This token is then automatically attached to the HTTP request, authorizing access to the external API even across different tenants.

Why this answer

The HTTP action's Active Directory OAuth authentication type directly supports the OAuth 2.0 Client Credentials flow for cross-tenant scenarios. By providing the tenant ID, client ID, and client secret, the Logic App runtime can obtain an access token from the external tenant's token endpoint and automatically inject it into the Authorization header as a Bearer token. This is the only built-in authentication option in the HTTP action that handles the client credentials grant without custom code.

Exam trap

The trap here is that candidates often confuse Managed Identity with cross-tenant authentication, assuming it works across tenants, when in fact Managed Identity is strictly scoped to the resource's home tenant.

How to eliminate wrong answers

Option A is wrong because Managed Identity authentication only works within the same tenant as the Logic App; it cannot be used to obtain tokens from a different Microsoft Entra ID tenant. Option B is wrong because the HTTP + Swagger connector is used to import an API definition for design-time validation and does not provide any OAuth 2.0 Client Credentials token acquisition capability. Option D is wrong because the Azure Key Vault - Get secret action retrieves a stored secret (like a client secret) but does not perform the OAuth 2.0 token exchange; you would still need a separate action to call the token endpoint and construct the Bearer token.

Full explanation →
287
MCQeasy

You need to grant a user from another Microsoft Entra ID tenant access to a specific blob container in your Azure Storage account. The solution must use Azure RBAC and minimize administrative overhead. What should you do?

A.Generate a shared access signature (SAS) with read permissions for the container.
B.Invite the user as a guest in your Microsoft Entra ID tenant and assign the Storage Blob Data Reader role to the container.
C.Add the user as a Storage Blob Data Reader at the storage account level.
D.Share the storage account key with the user.
AnswerB

Inviting the user as a guest in your Microsoft Entra ID tenant establishes a B2B collaboration relationship, allowing their external identity to be recognized within your tenant. Once the user is a guest, you can then assign Azure RBAC roles, such as 'Storage Blob Data Reader', directly to the specific container. This approach provides secure, identity-based access with granular control and adheres to the principle of least privilege, as the user only gains the necessary permissions to the specified resource.

Why this answer

It uses Azure RBAC to grant cross-tenant access by inviting the user as a guest in your Microsoft Entra ID tenant, then assigning the Storage Blob Data Reader role at the container scope. This minimizes administrative overhead by leveraging existing role assignments without managing shared keys or SAS tokens, and it follows the principle of least privilege by scoping access to a specific container.

Exam trap

The trap here is that candidates often confuse RBAC with shared access signatures or account keys, assuming that any cross-tenant access requires a SAS token, when in fact Azure AD B2B collaboration with RBAC is the correct, low-overhead solution.

How to eliminate wrong answers

Option A is wrong because a shared access signature (SAS) does not use Azure RBAC; it uses a token-based delegation that requires manual token management and expiration, increasing administrative overhead. Option C is wrong because adding the user as a Storage Blob Data Reader at the storage account level grants access to all containers in the account, violating the requirement to scope access to a specific container. Option D is wrong because sharing the storage account key grants full administrative access to the entire storage account, bypassing RBAC entirely and creating a severe security risk.

Full explanation →
288
MCQhard

A storage account for thumbnail metadata must allow an application to read only blobs under one container for two hours. The application should not receive the account key. What should be issued? The design must avoid adding custom operational scripts.

A.A public access level on the container
B.A service SAS scoped to the container with read permission and expiry
C.A management group assignment
D.The storage account access key
AnswerB

A service SAS can grant limited, time-bound permissions without exposing account keys.

Why this answer

A service SAS (Shared Access Signature) scoped to a specific container with read permission and an expiry time of two hours meets the requirement: it grants time-limited read access to blobs under that container without exposing the account key. The SAS token is issued to the application, which can then use it to authenticate requests directly to Azure Blob Storage, avoiding the need for custom scripts.

Exam trap

The trap here is that candidates may confuse a service SAS with a public access level (Option A) because both allow read access, but they fail to recognize that public access is permanent and unrestricted, whereas a SAS provides time-limited, scoped access without exposing the account key.

How to eliminate wrong answers

Option A is wrong because setting a public access level on the container would allow anonymous read access indefinitely, not for a limited two-hour period, and it does not control which application can read—it's open to anyone. Option C is wrong because a management group assignment is an Azure RBAC construct for organizing subscriptions and managing governance at scale; it does not provide time-bound, scoped access to blob containers. Option D is wrong because providing the storage account access key grants full administrative access to the entire storage account (including all containers, write/delete operations) and cannot be scoped to a single container or limited to two hours; it also violates the requirement that the application should not receive the account key.

Full explanation →
289
MCQmedium

Your company has a set of REST APIs that are exposed through Azure API Management (APIM). One of the backend APIs is secured and requires an OAuth 2.0 access token from Microsoft Entra ID. The APIM instance has a system-assigned managed identity with permissions to request tokens for the backend API's scope. You need to configure APIM to automatically obtain a token and pass it to the backend API when requests come in. What should you do?

A.Add a set-backend-service policy with the authentication-managed-identity attribute
B.Configure the backend API's subscription key in policy
C.Use a validate-jwt policy to check incoming token
D.Create a named value with the token and reference it in policy
AnswerA

The `set-backend-service` policy with the `authentication-managed-identity` attribute is the correct approach for API Management to securely authenticate to an Azure AD-protected backend. This policy instructs APIM to use its assigned managed identity to automatically acquire an OAuth 2.0 access token from Azure Active Directory. The obtained token is then seamlessly added as a `Bearer` token in the `Authorization` header of the request forwarded to the backend API, eliminating the need for manual credential management.

Why this answer

The `set-backend-service` policy with the `authentication-managed-identity` attribute allows APIM to use its system-assigned managed identity to obtain an OAuth 2.0 access token from Microsoft Entra ID for the specified backend API scope. This token is automatically attached to the backend request as an Authorization header, enabling secure access without manual token management.

Exam trap

The trap here is that candidates confuse `validate-jwt` (which checks client tokens) with the need to obtain a new token for the backend, or they assume a static token stored in a named value is sufficient, ignoring the dynamic nature of OAuth 2.0 token expiry and managed identity capabilities.

How to eliminate wrong answers

Option B is wrong because subscription keys are used for APIM-level authentication and rate limiting, not for obtaining OAuth 2.0 tokens for backend APIs. Option C is wrong because `validate-jwt` only validates an incoming token from the client; it does not obtain or attach a token for the backend. Option D is wrong because named values store static secrets or configuration strings, not dynamically obtained tokens; manually storing a token would require frequent updates and defeats the purpose of managed identity.

Full explanation →
290
MCQhard

Your application uses Azure Key Vault to store cryptographic keys. You need to ensure that keys are automatically rotated every 90 days without any manual intervention. Which Key Vault feature should you configure?

A.Set a key rotation policy
B.Configure a Key Vault firewall
C.Enable soft-delete on the key vault
D.Use a managed HSM instead of a standard vault
AnswerA

Setting a key rotation policy in Azure Key Vault is the correct approach because it automates the generation of new cryptographic key versions based on a predefined schedule or an expiry notification. This feature ensures that keys are regularly updated without manual intervention, significantly enhancing security by limiting the lifespan of any single key. Automated rotation is a critical security best practice for managing the lifecycle of cryptographic assets and mitigating risks associated with long-lived keys.

Why this answer

Azure Key Vault supports key rotation policies that allow you to define automatic rotation intervals (e.g., every 90 days) for cryptographic keys. When a rotation policy is set, Key Vault automatically creates a new key version and optionally expires the old one, eliminating the need for manual intervention.

Exam trap

The trap here is that candidates may confuse soft-delete or Managed HSM with rotation capabilities, but neither feature automates key version creation; only a rotation policy does.

How to eliminate wrong answers

Option B is wrong because configuring a Key Vault firewall controls network access to the vault, not key lifecycle management or rotation. Option C is wrong because enabling soft-delete protects keys from accidental deletion by retaining them for a configurable retention period, but it does not automate key rotation. Option D is wrong because using a Managed HSM provides a higher security boundary with FIPS 140-2 Level 3 validation and dedicated hardware, but it does not inherently enable automatic key rotation; you still need to configure a rotation policy.

Full explanation →
291
MCQhard

A company has an Azure App Service web app that reads from Azure Blob Storage. The app uses a connection string stored in app settings. Recently, the storage account key was rotated, and the app started throwing authentication errors. What should the developer do to resolve this issue without redeploying the app?

A.Change the app to use managed identity
B.Rotate the storage account key again
C.Update the connection string in the app settings to use the new key
D.Restart the app service
AnswerC

Updating the app settings will automatically restart the app with the new connection string.

Why this answer

Updating the connection string in the App Service app settings (e.g., via Azure portal or Azure CLI) automatically restarts the app, applying the new key without requiring a redeployment. Option A (managed identity) would require code changes and is not necessary if connection strings are acceptable. Option B (rotating the key again) does not fix the mismatch if the app retains the old key.

Option D (restarting the app) alone does not update the stored connection string.

Full explanation →
292
MCQeasy

You are building an Azure Logic App that needs to call an external REST API. The API requires an API key to be passed in the 'X-API-Key' header. You have stored the API key as a secret in Azure Key Vault. The Logic App uses a managed identity that has read access to the Key Vault secret. You want to retrieve the API key securely at runtime and include it in the HTTP request. Which approach should you use?

A.Add a 'Get secret' action from Key Vault to retrieve the secret, then use the 'HTTP' action and set the 'X-API-Key' header to the secret value using a dynamic expression.
B.Configure the HTTP action to use managed identity authentication and set the 'Audience' to the Key Vault URL. This will automatically pass the API key as the Authorization header.
C.Store the API key in an Azure App Service application setting and reference it from the Logic App using the 'appsetting' function.
D.Use the 'Invoke an HTTP endpoint' action with Application Insights dependency tracking enabled. The API key is automatically logged by Application Insights.
AnswerA

This is the correct approach. The Logic App can use a managed identity to authenticate to Key Vault, retrieve the secret via the 'Get secret' action, and then use that value in the HTTP request header.

Why this answer

It uses the native 'Get secret' action from Azure Key Vault to securely retrieve the API key at runtime, leveraging the Logic App's managed identity for authentication. The secret value can then be dynamically injected into the 'X-API-Key' header of the subsequent HTTP action using an expression like `@{outputs('Get_secret')?['value']}`. This approach follows the principle of least privilege and avoids hardcoding secrets or exposing them in configuration.

Exam trap

The trap here is that candidates may confuse managed identity authentication on an HTTP action (which is for authenticating to the target API) with the mechanism to retrieve secrets from Key Vault, leading them to incorrectly select Option B.

How to eliminate wrong answers

Option B is wrong because managed identity authentication on an HTTP action is used to authenticate the Logic App to the target API (e.g., using OAuth 2.0), not to retrieve a secret from Key Vault; setting the 'Audience' to the Key Vault URL would attempt to authenticate to Key Vault, not pass the API key in the header. Option C is wrong because Azure App Service application settings are not accessible from a Logic App via the 'appsetting' function; that function is specific to Azure Functions and App Service code, not Logic App workflow expressions. Option D is wrong because the 'Invoke an HTTP endpoint' action with Application Insights dependency tracking does not automatically retrieve or inject API keys; it only enables telemetry logging of the HTTP call, and the API key would still need to be manually provided and could be exposed in logs.

Full explanation →
293
Multi-Selecthard

Which TWO are best practices for securing an Azure API Management instance?

Select 2 answers
A.Expose the management endpoint publicly for easy configuration
B.Require subscription keys for all APIs
C.Set rate limits to prevent brute force attacks
D.Use OAuth 2.0 with Azure AD to authenticate API consumers
E.Share API keys with partners via email
AnswersB, D

Subscription keys provide a basic level of access control.

Why this answer

Correct answers: B and D. Requiring subscription keys helps secure APIs by enforcing a per-call authentication mechanism. OAuth 2.0 with Azure AD provides robust, token‑based authentication for API consumers.

Option A (exposing the management endpoint) is insecure and should be restricted. Option C (rate limits) prevent resource exhaustion, not brute‑force attacks—that’s a different security control. Option E (sharing keys via email) is a security risk and not a best practice.

Full explanation →
294
MCQhard

A microservices application deployed on Azure Kubernetes Service (AKS) needs to securely store and retrieve configuration settings. The configuration should be updated without redeploying containers. Which Azure service should be used?

A.Azure App Configuration
B.Azure Cosmos DB
C.Azure Key Vault
D.Azure Blob Storage
AnswerA

Azure App Configuration is purpose-built for managing application settings and feature flags in modern distributed architectures like microservices on Azure Kubernetes Service. It centralizes configuration, allowing dynamic updates to be pushed to running services without requiring redeployments, which is crucial for agility. This service significantly simplifies feature management, A/B testing, and ensures configuration consistency across numerous service instances.

Why this answer

Azure App Configuration is purpose-built for managing configuration settings for microservices applications. It provides a centralized store for key-value pairs and feature flags, supports dynamic configuration updates without requiring container restarts or redeployments, and integrates natively with AKS via the App Configuration Kubernetes Provider or the Azure SDK. This enables live configuration changes that are automatically picked up by running containers.

Exam trap

The trap here is that candidates often confuse Azure Key Vault with a general configuration store, but Key Vault is strictly for secrets and does not support dynamic configuration reloading or feature flags, which are core requirements for the scenario described.

How to eliminate wrong answers

Option B (Azure Cosmos DB) is wrong because it is a NoSQL database designed for globally distributed, multi-model data storage, not for lightweight configuration management; using it for configuration would introduce unnecessary latency, cost, and complexity. Option C (Azure Key Vault) is wrong because it is a secrets management service for storing sensitive items like connection strings and certificates, not for general application configuration settings; while it can be used alongside App Configuration for secrets, it does not support dynamic configuration reloading without custom code. Option D (Azure Blob Storage) is wrong because it is an object storage service for unstructured data like files, images, and backups; it lacks built-in mechanisms for live configuration updates and would require custom polling or event-driven logic to detect changes.

Full explanation →
295
MCQeasy

You are developing an app that processes orders. When an order is placed, you need to send a confirmation email and update an inventory database. The email service may be slow but must not delay the order processing. Which approach should you use?

A.Scale out the email service to handle the load.
B.Send the email asynchronously via a queue (e.g., Azure Queue Storage).
C.Use Azure Event Grid to trigger the email.
D.Call the email service synchronously and wait for the response.
AnswerB

Sending the email asynchronously via a queue, such as Azure Queue Storage, effectively decouples the order processing from the potentially slow or unreliable email service. The order processing can quickly place a message onto the queue and complete, improving responsiveness and throughput for the core business logic. A separate worker process can then consume messages from the queue at its own pace, handling retries and ensuring eventual delivery without blocking the primary transaction.

Why this answer

Sending the email asynchronously via a queue (e.g., Azure Queue Storage) decouples the slow email service from the order processing workflow. This ensures the order processing completes immediately without waiting for the email to be sent, meeting the requirement that the email must not delay order processing.

Exam trap

The trap here is that candidates may confuse Azure Event Grid (which is for event-driven reactive architectures) with a queue-based decoupling pattern, not realizing that Event Grid does not provide the message buffering and independent processing that a queue offers for this specific requirement.

How to eliminate wrong answers

Option A is wrong because scaling out the email service addresses throughput but does not eliminate the synchronous wait time during order processing; the calling code would still block until the email is sent. Option C is wrong because Azure Event Grid is a publish-subscribe event routing service, not a queue; it delivers events to subscribers but does not provide a buffer or guaranteed asynchronous decoupling that prevents the order processing from waiting on the email delivery. Option D is wrong because calling the email service synchronously and waiting for the response directly contradicts the requirement that the email must not delay order processing.

Full explanation →
296
MCQmedium

A web app uses Azure Key Vault to store secrets. The app runs in a production environment and needs to authenticate to Key Vault without storing connection strings in configuration files. Which authentication method should be used?

A.Client secret stored in app settings
B.Managed identity
C.Storage account access keys
D.Certificate stored in Key Vault
AnswerB

Managed identity provides an automatically managed identity in Azure Active Directory (AAD) for Azure services, enabling them to authenticate to other AAD-protected services like Key Vault without requiring developers to manage any credentials. Azure automatically handles the creation, rotation, and secure provisioning of these identities, eliminating the need for secrets in application code or configuration. This approach significantly enhances security by removing the burden of credential management and reducing the attack surface.

Why this answer

Managed identity (Option B) is correct because it allows the web app to authenticate to Azure Key Vault without storing any credentials in code or configuration files. Azure automatically manages the identity for the app, and the app uses the Azure Identity SDK to obtain tokens via the Azure Instance Metadata Service (IMDS) endpoint, which eliminates the need for connection strings or secrets.

Exam trap

The trap here is that candidates may choose a certificate stored in Key Vault (Option D) thinking it is more secure, but they overlook that managed identity eliminates the need to manage any credential at all, which is the core requirement of the question.

How to eliminate wrong answers

Option A is wrong because storing a client secret in app settings violates the requirement of not storing connection strings in configuration files, and it introduces a security risk of secret leakage. Option C is wrong because storage account access keys are used for authenticating to Azure Storage, not for authenticating to Key Vault, and they would also need to be stored in configuration. Option D is wrong because while a certificate stored in Key Vault can be used for authentication, it still requires the app to have a mechanism to retrieve and use that certificate, which typically involves storing a client ID or other identifier in configuration, and it does not eliminate the need for credential management as effectively as managed identity.

Full explanation →
297
Multi-Selectmedium

Which THREE components are required to implement Azure AD B2C custom policies for sign-up and sign-in? (Choose three.)

Select 3 answers
A.A user journey definition
B.An Azure AD (Microsoft Entra ID) tenant for employee identities
C.An Azure subscription
D.A trust framework policy (XML)
E.A relying party application registration
AnswersA, D, E

A user journey definition is a core component within Azure AD B2C custom policies, specifically part of the Identity Experience Framework (IEF). It meticulously defines the sequence of orchestration steps a user must complete for a specific task, such as sign-up, sign-in, or profile editing. These journeys dictate the flow of claims and interactions with various technical profiles, making them indispensable for defining the user's authentication and authorization path.

Why this answer

A user journey definition is a core component of an Azure AD B2C custom policy. It orchestrates the sequence of technical profiles and orchestration steps that define the sign-up and sign-in experience, including self-asserted pages, multifactor authentication, and validation. Without a user journey, the policy cannot specify the flow of claims exchanges and user interactions.

Exam trap

The trap here is that candidates often confuse the Azure AD B2C tenant (which is required) with an Azure AD tenant for employee identities (Option B), or they mistakenly think an Azure subscription is a direct component of the policy implementation rather than a prerequisite for tenant creation.

Full explanation →
298
MCQeasy

Refer to the exhibit. You are analyzing the Azure Blob Storage service properties configured for a storage account. A web application hosted at https://www.contoso.com attempts to make a PUT request to a blob. The request fails with a CORS error. What is the most likely cause?

A.The request includes a header that is not in the allowed headers list.
B.The request's Origin header does not match the allowed origin.
C.The CORS rule does not include the DELETE method.
D.The exposedHeaders list does not include a required response header.
AnswerB

The CORS error occurs because the request's Origin header (https://www.contoso.com) does not match any allowed origin in the CORS rule. Azure Blob Storage enforces exact string matching for the Origin header against the allowed origins list; a mismatch causes the browser to block the PUT request.

Why this answer

The CORS error occurs because the request's Origin header (https://www.contoso.com) does not match any allowed origin in the CORS rule. Azure Blob Storage enforces exact string matching for the Origin header against the allowed origins list; a mismatch causes the browser to block the PUT request. Since the question states the request fails with a CORS error and the exhibit shows allowed origins that do not include https://www.contoso.com, this is the most likely cause.

Exam trap

The trap here is that candidates often assume CORS errors are always caused by missing methods or headers, but the most common cause is a mismatch between the request's Origin header and the allowed origins list, especially when the allowed origins are not configured to include the exact domain of the web application.

How to eliminate wrong answers

Option A is wrong because if a header not in the allowed headers list is included, the browser would send a preflight OPTIONS request and fail with a CORS error, but the question specifies a PUT request, which typically does not trigger a preflight unless custom headers are used; however, the exhibit shows allowed headers are set to '*', so header mismatch is unlikely. Option C is wrong because the CORS rule not including the DELETE method would only affect DELETE requests, not PUT requests; the error is for a PUT request, so method mismatch is irrelevant. Option D is wrong because exposedHeaders only controls which response headers the browser exposes to the client, not whether the request itself is allowed; missing exposed headers would not cause a CORS error on a PUT request.

Full explanation →
299
MCQeasy

You are developing a serverless application using Azure Functions. The function must process messages from an Azure Storage Queue and write results to Azure Cosmos DB. Which binding should you use for the output?

A.Azure Blob Storage output binding
B.Azure Cosmos DB input binding
C.Azure Storage Queue output binding
D.Azure Cosmos DB output binding
AnswerD

The Azure Cosmos DB output binding is the correct choice because it is specifically designed to write new documents or update existing ones within an Azure Cosmos DB collection directly from an Azure Function. This binding handles the underlying connection and data serialization, allowing the function to output a C# object, JavaScript object, or array of objects that are then automatically persisted as JSON documents into the specified Cosmos DB database and collection.

Why this answer

The Azure Cosmos DB output binding allows you to write the results of queue-triggered function execution directly to a Cosmos DB container. The function processes messages from an Azure Storage Queue (input binding) and uses the output binding to insert or upsert documents into Cosmos DB without writing any SDK code.

Exam trap

The trap here is that candidates may confuse input and output bindings, selecting the Cosmos DB input binding (Option B) because they see 'Cosmos DB' and forget the direction, or choose the Blob Storage binding (Option A) because they associate storage with output without reading the requirement for Cosmos DB.

How to eliminate wrong answers

Option A is wrong because the Azure Blob Storage output binding writes data to blobs, not to Cosmos DB, so it cannot satisfy the requirement to write results to Cosmos DB. Option B is wrong because the Azure Cosmos DB input binding is used to read data from Cosmos DB before function execution, not to write output results. Option C is wrong because the Azure Storage Queue output binding writes messages to a queue, which is unrelated to writing results to Cosmos DB.

Full explanation →
300
MCQmedium

Three analytics pipelines each need to read every event from the same Azure Event Hub: one pipeline archives events to cold storage, one computes real-time aggregations, and one feeds a machine learning model. How should the developer configure Event Hubs to allow all three to consume independently without interfering with each other?

A.Create a separate consumer group for each pipeline; each group tracks its own offset independently
B.Create three separate Event Hubs in the same namespace and replicate events between them with Event Hubs Capture
C.Use a single consumer group and route events to different pipelines by partition key prefix
D.Enable Event Hubs Capture for all three pipelines so they read from the captured Avro files in storage instead of the Event Hub directly
AnswerA

With three consumer groups, each pipeline reads the full stream from its own position. The archiving pipeline, aggregation pipeline, and ML pipeline each checkpoint independently. If one falls behind or restarts, it resumes from its own saved offset without disturbing the others.

Why this answer

A is correct because each consumer group in Event Hubs maintains its own independent offset and checkpoint, allowing multiple consumers to read the same event stream without interfering. By creating a separate consumer group for each pipeline (archival, real-time aggregation, ML), each pipeline can process events at its own pace and from its own position in the stream, ensuring no consumer's progress affects another.

Exam trap

The trap here is that candidates often confuse consumer groups with partitions, thinking that multiple consumers must use different partitions to avoid interference, but partitions are for scaling throughput, not for independent offset tracking—consumer groups are the correct abstraction for independent consumption.

How to eliminate wrong answers

Option B is wrong because creating three separate Event Hubs and replicating events between them is unnecessary overhead and does not solve the independent consumption requirement; each pipeline would still need its own consumer group within each hub, and replication introduces latency and complexity. Option C is wrong because using a single consumer group forces all pipelines to share the same offset, meaning one pipeline's consumption progress (e.g., fast real-time aggregation) would advance the offset, causing other pipelines (e.g., slower archival) to miss events. Option D is wrong because Event Hubs Capture writes events to Azure Blob Storage or Data Lake Store in Avro format, but it is a one-way archival feature, not a mechanism for multiple independent consumers; pipelines would still need to read from the Event Hub directly for real-time processing, and Capture does not provide independent offset tracking.

Full explanation →
Page 3

Page 4 of 12

Page 5

All pages

123456789101112

Practice AZ-204 by domain

Target a specific domain to shore up weak areas.

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