Microsoft Azure Developer Associate AZ-204 AZ-204 Questions 76–150 | Page 2/12

Multi-Selecthard

Which THREE Azure services or features can be used to implement retry logic for transient failures when calling an external API from a .NET Core application?

Select 3 answers

A.Azure SDK retry policies

B.Azure Logic Apps retry policy

C.Polly library

D.Azure Traffic Manager

E.Azure Front Door

AnswersA, B, C

Many Azure SDKs, such as those for Storage, Cosmos DB, and Service Bus, incorporate built-in retry policies to handle transient faults automatically. These policies typically employ strategies like exponential backoff with jitter, allowing client applications to gracefully recover from temporary network issues or service unavailability without custom code. Developers can often configure parameters like the maximum number of retries and the delay between attempts, ensuring robust communication with Azure services.

Why this answer

Azure SDK retry policies (A) are correct because the Azure SDK for .NET includes built-in retry policies (e.g., ExponentialRetry, FixedRetry) that automatically handle transient failures such as 408, 429, 500, 502, 503, and 504 responses when calling Azure services or external endpoints through the SDK pipeline. Azure Logic Apps retry policy (B) is correct because Logic Apps actions support configurable retry policies (default, exponential interval, fixed interval) with parameters like count, interval, and maximumInterval, which can wrap HTTP calls to external APIs and retry on transient errors. Polly library (C) is correct because Polly is a .NET resilience and transient-fault-handling library that provides policies such as Retry, WaitAndRetry, and WaitAndRetryAsync with exponential backoff and jitter, and it integrates directly into .NET Core applications via HttpClientFactory.

Azure Traffic Manager (D) is not correct because it is a DNS-based global traffic distribution service that routes users to endpoints; it does not implement application-level retry logic for outbound API calls. Azure Front Door (E) is not correct because it is a layer-7 global load balancer and CDN that can retry requests at the edge for inbound traffic, but it does not provide retry logic inside a .NET Core application calling an external API.

Exam trap

The trap here is that candidates may confuse network-level traffic management services (Traffic Manager, Front Door) with application-level retry mechanisms, assuming they handle transient failures automatically when they only provide routing and load balancing.

Full explanation →

MCQmedium

An application writes millions of small log entries (500 bytes each) daily. The logs are rarely read, and when read, they are accessed sequentially. You need to minimize storage costs and maximize write throughput. Which Azure Blob Storage type should you use?

A.Block Blob

B.Page Blob

C.Append Blob

D.Archive Blob

AnswerC

Append Blobs are purpose-built for scenarios requiring fast, sequential writes to the end of a blob, making them the optimal choice for logging, auditing, and IoT data streams. Each new block is added atomically to the end of the blob, ensuring data integrity and high throughput for millions of small log entries without modifying existing content. This design minimizes transaction costs and maximizes efficiency for append-only workloads, perfectly matching the requirement.

Why this answer

Append Blob is optimized for append operations, making it ideal for logging scenarios where new data is continuously added to the end of the blob. It provides high write throughput for small, sequential writes (like 500-byte log entries) and lower storage costs compared to Block Blob for this pattern, as it avoids the overhead of managing multiple blocks per append. Additionally, Append Blob supports sequential read access efficiently, matching the rare, sequential read requirement.

Exam trap

The trap here is that candidates confuse 'Append Blob' with 'Block Blob' because both support blocks, but they fail to recognize that Append Blob is specifically designed for append-only workloads, while Block Blob is not optimized for sequential writes and incurs higher overhead per operation.

How to eliminate wrong answers

Option A is wrong because Block Blob is designed for random read/write access and requires managing blocks for each write, which introduces overhead and reduces write throughput for millions of small appends; it is not optimized for sequential append-only workloads. Option B is wrong because Page Blob is optimized for random read/write operations on fixed-size 512-byte pages (e.g., for virtual machine disks) and incurs higher costs due to its support for frequent updates and snapshots, making it unsuitable for low-cost, append-only logging. Option D is wrong because Archive Blob is a tier for cold data with infrequent access and high retrieval latency (hours), not a blob type; it cannot be used for active writes and would block the required high write throughput.

Full explanation →

MCQmedium

You are developing a solution that needs to store and retrieve JSON documents with a flexible schema. The data is accessed via REST API and requires low-latency reads. Which Azure Storage service should you use?

A.Azure Blob Storage

B.Azure Cosmos DB

C.Azure Table Storage

D.Azure Files

AnswerB

Azure Cosmos DB is a globally distributed, multi-model database service that natively supports document data, including JSON, with a flexible schema. It automatically indexes all properties within documents, enabling powerful SQL-like query capabilities over JSON data with low-latency access. This makes it an excellent choice for solutions requiring dynamic data structures and efficient querying of document content.

Why this answer

Azure Cosmos DB is the correct choice because it natively supports storing and querying JSON documents with a flexible schema via its SQL API, and it guarantees single-digit millisecond read latencies at the 99th percentile, which meets the low-latency requirement. Unlike other Azure storage services, Cosmos DB is a fully managed NoSQL database designed for REST API access with automatic indexing of all JSON properties.

Exam trap

The trap here is that candidates often confuse Azure Blob Storage's ability to store JSON files (as blobs) with the ability to efficiently query and retrieve individual documents with low latency, overlooking the fact that Blob Storage lacks native indexing and querying capabilities for JSON content.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage stores unstructured binary data as blobs and does not provide native JSON document querying or indexing; it requires additional logic to parse and retrieve specific fields. Option C is wrong because Azure Table Storage is a key-value store that stores entities as rows with a fixed schema (partition key and row key), not flexible JSON documents, and it lacks native support for JSON querying or indexing. Option D is wrong because Azure Files provides SMB and NFS file shares for file-level access, not a REST API for JSON document storage and retrieval with low-latency reads.

Full explanation →

MCQhard

Application Insights ingestion cost is rising because a high-traffic app emits large telemetry volume. The team needs statistically useful telemetry while reducing ingestion. What should be configured?

A.Move the app to a larger App Service plan

B.Adaptive sampling

C.Disable all exception telemetry

D.Increase log verbosity to debug

AnswerB

Adaptive sampling dynamically adjusts the volume of telemetry items Application Insights retains, based on actual traffic rates, while preserving statistically representative samples and correlated request traces. This satisfies the constraint of reducing ingestion cost without losing statistically useful data, unlike fixed-rate sampling which can miss spikes.

Why this answer

Adaptive sampling is the correct solution because it automatically adjusts the volume of telemetry data sent to Application Insights, retaining only a representative subset that preserves statistical accuracy for analysis. This reduces ingestion costs while ensuring the sampled data remains statistically useful for detecting trends and anomalies in high-traffic applications.

Exam trap

The trap here is that candidates may think increasing resources (larger plan) or disabling entire telemetry categories (exceptions) is a valid cost-control measure, but the exam tests understanding that adaptive sampling is the designed Azure feature for reducing telemetry volume while preserving statistical significance.

How to eliminate wrong answers

Option A is wrong because moving the app to a larger App Service plan increases compute resources and cost, but does not reduce telemetry ingestion volume or address the root cause of rising Application Insights costs. Option C is wrong because disabling all exception telemetry would eliminate critical diagnostic data needed for monitoring application health, and it does not provide a balanced approach to reducing ingestion while maintaining statistical usefulness. Option D is wrong because increasing log verbosity to debug would generate even more telemetry data, exacerbating the ingestion cost problem rather than solving it.

Full explanation →

Multi-Selectmedium

Which TWO Azure services can be used to implement a pub/sub messaging pattern for decoupling microservices? (Choose two.)

Select 2 answers

A.Azure Storage Queue

B.Azure Service Bus Topics

C.Azure Event Hubs

D.Azure Event Grid

E.Azure Logic Apps

AnswersB, D

Azure Service Bus Topics are a robust enterprise messaging service explicitly designed to implement the publish/subscribe pattern. Publishers send messages to a topic, and multiple independent subscribers can register for specific subscriptions to that topic. Each subscription receives a copy of the message, allowing for decoupled communication and parallel processing by various consuming applications.

Why this answer

Azure Service Bus Topics (B) is correct because topics implement a true publish/subscribe model where each subscriber creates its own subscription and receives a copy of every published message, enabling one-to-many fan-out and decoupling of microservices. Azure Event Grid (D) is correct because it is a fully managed event routing service built on a pub/sub model, where publishers emit events to topics and multiple subscribers (webhooks, Functions, Service Bus queues, etc.) receive them via event subscriptions with filtering. Azure Storage Queue (A) is not correct because it is a simple point-to-point queue where each message is consumed by only one receiver, so it does not provide pub/sub fan-out.

Azure Event Hubs (C) is not correct because it is a high-throughput event streaming/ingestion platform based on partitions and consumer groups rather than a pub/sub topic-subscription messaging pattern. Azure Logic Apps (E) is not correct because it is a workflow orchestration/automation service that consumes messages but does not itself provide pub/sub messaging infrastructure.

Exam trap

The trap here is that candidates confuse Azure Event Hubs (which supports event streaming with consumer groups) with a true pub/sub messaging broker, but Event Hubs lacks per-subscriber independent queues and message-level features like sessions or duplicate detection that Service Bus Topics provide.

Full explanation →

MCQhard

You have an Azure API Management instance that exposes a REST API. You need to secure the API using OAuth 2.0 with Microsoft Entra ID. The API should accept tokens from multiple client applications. Which policy should you add to the inbound processing section?

A.<validate-jwt header-name="Authorization" failed-validation-httpcode="401" />

B.<xml-to-json>

C.<rate-limit>

D.<cache-lookup>

AnswerA

The <validate-jwt> policy is specifically designed to validate JSON Web Tokens (JWTs) presented in an HTTP header, typically the 'Authorization' header using the 'Bearer' scheme. It verifies the token's signature, expiration, audience, issuer, and other claims against configured validation parameters, ensuring the request originates from an authenticated and authorized source. If validation fails, it immediately terminates the request processing and returns the specified HTTP status code, such as 401 Unauthorized, preventing access to the backend API.

Why this answer

The <validate-jwt> policy is the correct choice because it validates the OAuth 2.0 token presented in the Authorization header, ensuring that only requests with valid tokens from Microsoft Entra ID are processed. This policy checks the token's signature, issuer, audience, and expiration, and returns a 401 status code if validation fails, which is essential for securing the API against unauthorized access from multiple client applications.

Exam trap

The trap here is that candidates often confuse authentication (validating who the user is) with authorization (what the user can do), and may incorrectly choose a policy like <rate-limit> or <cache-lookup> thinking they provide security, but only <validate-jwt> actually validates the OAuth 2.0 token's authenticity and integrity.

How to eliminate wrong answers

Option B is wrong because <xml-to-json> is a transformation policy that converts XML responses to JSON format, which has nothing to do with OAuth 2.0 token validation or API security. Option C is wrong because <rate-limit> is a throttling policy that limits the number of requests per time period, but it does not authenticate or authorize requests using OAuth 2.0 tokens. Option D is wrong because <cache-lookup> is a caching policy that retrieves responses from the cache to improve performance, and it does not perform any token validation or security checks.

Full explanation →

MCQhard

You are implementing a serverless function in Azure Functions that processes messages from an Azure Storage Queue. The function must ensure that each message is processed at least once and that processing failures are retried up to 5 times. After 5 failed attempts, the message should be moved to a poison queue. What should you configure?

A.Set the message time-to-live (TTL) to 5.

B.Implement a custom retry policy in the function code with a maximum of 5 retries.

C.Use the default queue poison message handling with 'maxDequeueCount' set to 5.

D.Set the visibility timeout to 5 minutes.

AnswerC

The 'maxDequeueCount' property, configurable for Azure Queue Storage bindings in Azure Functions, directly controls the maximum number of times a message can be dequeued and attempted for processing before it is automatically moved to a designated poison queue. Setting 'maxDequeueCount' to 5 ensures that if a function consistently fails to process a message, it will be retried up to four additional times (five total attempts) before being sent to the poison queue for manual inspection or dead-letter processing. This is the standard, built-in mechanism for handling message processing failures and retries.

Why this answer

Azure Functions' Storage Queue trigger automatically implements a poison queue mechanism. By setting the 'maxDequeueCount' property in the host.json file to 5, the runtime will dequeue a message up to 5 times; after the 5th failed attempt, the message is automatically moved to the associated poison queue (named {originalqueue}-poison). This ensures at-least-once processing and retry handling without custom code.

Exam trap

The trap here is that candidates often think they need to write custom retry logic (Option B) or adjust visibility timeout (Option D), when Azure Functions provides a declarative configuration-based poison queue solution that handles retries and dead-lettering automatically.

How to eliminate wrong answers

Option A is wrong because message time-to-live (TTL) controls the maximum time a message stays in the queue before being discarded, not the number of retry attempts. Option B is wrong because implementing a custom retry policy in function code is unnecessary and error-prone; the Azure Functions runtime already provides built-in poison queue handling via configuration, and custom retries could lead to duplicate processing or missed poison queue routing. Option D is wrong because setting the visibility timeout to 5 minutes only controls how long a message is hidden after a dequeue failure, not the number of retry attempts; it does not move messages to a poison queue after repeated failures.

Full explanation →

MCQmedium

You are deploying a containerized application to Azure Container Instances (ACI). The application requires a connection string to an Azure SQL Database. The connection string contains a password that is stored as a secret in Azure Key Vault. The container image expects to read the connection string from an environment variable named SQL_CONNECTION_STRING. You want to pass the secret securely without embedding it in the YAML deployment file and without modifying the container image. The ACI container group will use a system-assigned managed identity that has access to the Key Vault secret. Which approach should you use?

A.Mount a volume from Azure Files containing the connection string

B.Use a secure environment variable with a Key Vault reference syntax (e.g., secret://myvault/secretname)

C.Use the managed identity inside the container to call the Key Vault SDK and retrieve the secret

D.Store the connection string as an environment variable in ACI configuration but mark it as secure

AnswerB

Using a secure environment variable with a Key Vault reference syntax (e.g., secret://myvault/secretname) is the recommended and most secure approach for ACI. Azure Container Instances natively supports resolving these references at runtime. When an ACI container group is configured with a managed identity and appropriate access policies to Azure Key Vault, the ACI platform intercepts this special syntax, uses its managed identity to fetch the secret from Key Vault, and then injects the actual secret value as an environment variable into the container *before* the application starts. This ensures the secret never appears in the deployment definition or container image, adhering to security best practices and requiring no application code changes.

Why this answer

Azure Container Instances supports Key Vault references in environment variables using the `secret://` syntax, which allows you to securely inject secrets into containers at runtime without exposing them in the deployment YAML. The system-assigned managed identity is automatically used by the ACI infrastructure to authenticate to Key Vault and retrieve the secret, so no code changes to the container image are required.

Exam trap

The trap here is that candidates often assume they must write code inside the container to use the managed identity with the Key Vault SDK, but ACI provides a built-in mechanism to inject secrets as environment variables without any code changes.

How to eliminate wrong answers

Option A is wrong because mounting a volume from Azure Files would require the connection string to be stored in a file, which still exposes the secret in the storage account and does not leverage Key Vault for secret management. Option C is wrong because using the managed identity inside the container to call the Key Vault SDK would require modifying the container image to include code for secret retrieval, which violates the requirement of not modifying the image. Option D is wrong because marking an environment variable as 'secure' in ACI only hides its value in the Azure portal and logs, but the secret is still embedded in the deployment configuration and can be retrieved by anyone with access to the resource definition.

Full explanation →

MCQeasy

You deploy a containerized application to Azure Container Instances (ACI). The application needs to store configuration settings that might change at runtime. You need to update the configuration without redeploying the container. What should you do?

A.Use environment variables in the container group

B.Mount an Azure Files share and update the configuration file

C.Use Application Settings in the container

D.Modify the container image to include new configuration

AnswerB

While Azure Container Instances supports mounting Azure Files shares as volumes, simply updating a configuration file on the mounted share does not automatically trigger a configuration refresh within the running container. The application inside the container would need to implement specific logic to continuously monitor the file for changes or be restarted to re-read the updated configuration. This method introduces additional complexity and does not provide a truly dynamic, out-of-the-box configuration update mechanism for ACI.

Why this answer

To update configuration settings at runtime without redeploying the container in Azure Container Instances (ACI), you should mount an Azure Files share. The application can read its configuration from a file stored on this share. When configuration changes are needed, you can update the file directly on the Azure Files share.

The container itself does not need to be redeployed or restarted, provided the application is designed to periodically re-read the configuration file or react to file changes. This approach allows for dynamic configuration updates independent of the container lifecycle.

Exam trap

The trap here is that candidates confuse Azure Container Instances with Azure App Service, mistakenly selecting 'Application Settings' (Option C) which is an App Service feature, not available in ACI.

How to eliminate wrong answers

Option B is wrong because mounting an Azure Files share and updating a configuration file requires the application to watch for file changes and reload configuration, which adds complexity and is not a built-in ACI feature for runtime updates without redeployment. Option C is wrong because 'Application Settings' is an Azure App Service concept, not applicable to Azure Container Instances; ACI does not have an Application Settings blade. Option D is wrong because modifying the container image to include new configuration requires rebuilding, pushing to a registry, and redeploying the container group, which contradicts the requirement to avoid redeployment.

Full explanation →

MCQhard

Your company uses Microsoft Sentinel for security information and event management (SIEM). You need to detect and automatically respond to a potential credential theft attack where an anomalous number of failed logins are followed by a successful login from a different geographic location. Which Microsoft Sentinel feature should you use?

A.Microsoft Sentinel Data Connectors

B.An analytics rule with an automated response

C.Microsoft Defender for Identity

D.Microsoft Sentinel playbooks

AnswerB

An analytics rule in Microsoft Sentinel is designed to detect specific threat patterns or anomalies within the ingested data using Kusto Query Language (KQL). When an analytics rule's query condition is met, it can automatically generate an incident, signaling a potential security threat. Crucially, these rules can be configured to trigger an automated response directly, such as running a playbook to disable a user account or isolate a compromised host, thereby combining detection with immediate mitigation. This integrated approach directly addresses both the identification and remediation aspects of threat management.

Why this answer

An analytics rule in Microsoft Sentinel can be configured to detect patterns like anomalous failed logins followed by a successful login from a different geography. The rule can then trigger an automated response, such as running a playbook or creating an incident, to remediate the threat in near real-time. This combines detection and automated action within a single rule, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates often confuse 'playbooks' (the automation component) with the complete detection-and-response feature, forgetting that an analytics rule is required to trigger the playbook and that the rule itself can include an automated response directly.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel Data Connectors are used to ingest log data from various sources (e.g., Azure AD, firewalls) but do not perform detection or automated response. Option C is wrong because Microsoft Defender for Identity is a separate security product focused on on-premises Active Directory identity threats, not a native Sentinel feature for creating custom detection rules with automated responses. Option D is wrong because Microsoft Sentinel playbooks are automated workflows (based on Azure Logic Apps) that can be triggered by analytics rules, but they are not the detection mechanism themselves; the question asks for the feature that both detects and automatically responds, which is the analytics rule with an automated response.

Full explanation →

Multi-Selectmedium

Which TWO options are valid ways to authenticate an Azure Functions app to Azure Storage when using a managed identity? (Choose two.)

Select 2 answers

A.Enable system-assigned managed identity on the function app and grant it the 'Storage Blob Data Contributor' role

B.Generate a shared access signature (SAS) token and include it in the connection string

C.Use the storage account access key in the connection string

D.Create a user-assigned managed identity, assign it to the function app, and grant it the 'Storage Queue Data Contributor' role

E.Use the default AzureWebJobsStorage connection string from the function app settings

AnswersA, D

Enabling a system-assigned managed identity on an Azure Function App provisions an identity directly tied to the function's lifecycle. This identity, authenticated by Azure Active Directory, can then be granted specific Azure RBAC roles, such as 'Storage Blob Data Contributor,' allowing the function to securely access Azure Storage blobs without managing any credentials in code or configuration. This method adheres to the principle of least privilege and eliminates the security risks associated with shared secrets.

Why this answer

Options A and D are correct because both describe using a managed identity (system-assigned in A, user-assigned in D) to authenticate the function app to Azure Storage, which is the intended passwordless approach. In A, enabling a system-assigned managed identity on the function app and granting it the 'Storage Blob Data Contributor' role gives the identity the necessary RBAC permissions to access blob data. In D, creating a user-assigned managed identity, assigning it to the function app, and granting it the 'Storage Queue Data Contributor' role similarly provides the required RBAC permissions for queue data access.

Options B and C are not valid managed-identity authentication methods because SAS tokens and storage account access keys are shared secrets, not identity-based credentials. Option E is also incorrect because the default AzureWebJobsStorage connection string typically relies on an account key or other connection-string credentials, not a managed identity.

Exam trap

The trap here is that candidates may confuse 'managed identity' with any non-key-based method (like SAS tokens) or assume the default AzureWebJobsStorage connection string automatically uses managed identity, when in fact it defaults to a key-based connection unless explicitly configured for identity-based authentication.

Full explanation →

MCQmedium

You are developing a serverless function app that processes credit card payments. The function app must securely store the payment gateway API key. Which Azure service should you use to store the key?

A.Store the key in an Azure Storage queue and read it at runtime.

B.Store the key in Azure Key Vault and retrieve it using a managed identity.

C.Store the key in Azure Cosmos DB with client-side encryption.

D.Store the key in the function app's application settings.

AnswerB

Azure Key Vault is purpose-built for securely storing and managing cryptographic keys, secrets, and certificates, offering strong encryption at rest, access policies, and comprehensive auditing. Utilizing a managed identity for the function app allows it to authenticate to Azure AD and then to Key Vault without any hardcoded credentials in the application code or configuration. This establishes a secure, credential-less connection, adhering to the principle of least privilege and simplifying secret rotation.

Why this answer

Azure Key Vault is the designated service for securely storing and managing secrets, keys, and certificates. By using a managed identity, the function app can authenticate to Key Vault without embedding any credentials in code or configuration, ensuring the API key is never exposed in plaintext.

Exam trap

The trap here is that candidates often choose application settings (Option D) because they are convenient and commonly used for non-sensitive configuration, but they fail to recognize that secrets like API keys require the dedicated security and access control provided by Key Vault.

How to eliminate wrong answers

Option A is wrong because an Azure Storage queue is a messaging service, not a secure secret store; storing an API key there would expose it in transit and at rest without native access control or auditing. Option C is wrong because Azure Cosmos DB is a NoSQL database, and while client-side encryption can protect data, it still requires managing encryption keys and does not provide the centralized secret lifecycle management, rotation, and access policies that Key Vault offers. Option D is wrong because function app application settings are stored in plaintext in the Azure portal and can be read by anyone with contributor-level access; they lack the fine-grained access control, audit logging, and automatic rotation capabilities of Key Vault.

Full explanation →

MCQhard

A single-page app signs in users with Microsoft Entra ID and calls a protected API. The app cannot safely keep a client secret. Which OAuth flow should be used?

A.Implicit flow

B.Client credentials flow

C.Resource owner password credentials flow

D.Authorization code flow with PKCE

AnswerD

Authorization code flow with PKCE uses a dynamically generated code verifier and challenge, so the public single-page app proves possession without storing a client secret. This satisfies the constraint that the app cannot safely keep a client secret while calling a protected API.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth flow for single-page apps that cannot securely store a client secret. PKCE ensures that even if the authorization code is intercepted, it cannot be exchanged for tokens without the original code verifier, mitigating the risk of code injection attacks. This flow aligns with Microsoft's best practices for native and browser-based applications using Microsoft Entra ID.

Exam trap

The trap here is that candidates often confuse the implicit flow (which was historically used for SPAs) as still valid, but Microsoft and OAuth standards now mandate the authorization code flow with PKCE for all public clients, including single-page apps.

How to eliminate wrong answers

Option A is wrong because the implicit flow is deprecated by the OAuth 2.0 Security Best Current Practice (BCP) and Microsoft Entra ID due to security risks like access token leakage in the browser history and lack of PKCE support. Option B is wrong because the client credentials flow is designed for server-to-server (daemon) applications without a user context, not for single-page apps that need to sign in users and call APIs on their behalf. Option C is wrong because the resource owner password credentials flow requires the app to handle user credentials directly, which is insecure for browser-based apps and violates the principle of not exposing passwords to the client.

Full explanation →

MCQhard

A background data pipeline runs on a schedule and must read user profile data from Microsoft Graph. No user is present during execution. The service authenticates to Microsoft Entra ID and calls the Graph API. Which permission type and OAuth 2.0 flow are correct for this scenario?

A.Application permissions with the client credentials flow, authenticating with the app's client ID and secret (or certificate)

B.Delegated permissions with the authorization code flow, initiating a browser redirect to collect user consent

C.Delegated permissions with the device code flow, prompting a user to authenticate on a separate device

D.Application permissions with the on-behalf-of flow, passing the calling user's token to the Graph API

AnswerA

Application permissions are granted by an admin via the app registration manifest. The client credentials flow does not require user interaction — the service presents its own credentials to the token endpoint and receives a token scoped to the application. This is the standard pattern for background services, daemons, and scheduled jobs that call Microsoft Graph.

Why this answer

This scenario requires a background service to access Microsoft Graph without any user interaction. Application permissions are designed for such non-interactive, service-to-service calls, and the client credentials OAuth 2.0 flow (defined in RFC 6749 section 4.4) allows the app to authenticate using its own identity (client ID and secret or certificate) to obtain an access token. Delegated permissions would be incorrect because they require a signed-in user context, which is absent here.

Exam trap

The trap here is that candidates often confuse application permissions with delegated permissions, mistakenly thinking a user context is always required for Graph API calls, but the client credentials flow is the correct choice for any background service that operates without a signed-in user.

How to eliminate wrong answers

Option B is wrong because delegated permissions require a signed-in user and the authorization code flow involves a browser redirect for user consent, which cannot occur in an unattended background pipeline. Option C is wrong because the device code flow is designed for devices with limited input capabilities and still requires a user to authenticate interactively on a separate device, not suitable for a fully automated service. Option D is wrong because the on-behalf-of flow (OAuth 2.0 On-Behalf-Of) is used to pass a user's delegated token to a downstream API, requiring an initial user token, which does not exist in this no-user scenario.

Full explanation →

MCQmedium

A Cosmos DB container for session records receives hot-partition throttling because the partition key has only five possible values. What should the developer change?

A.Increase the default TTL

B.Enable analytical store only

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

D.Use a stored procedure for every write

AnswerC

A partition key with only five values concentrates writes, causing hot-partition throttling. Selecting a higher-cardinality key with even request distribution spreads load across logical partitions, satisfying Cosmos DB's requirement that the partition key evenly distribute both storage and throughput.

Why this answer

A partition key with only five values leads to hot partitions, where one or a few partitions handle the majority of requests, causing throttling. By choosing a partition key with higher cardinality (many distinct values) and even request distribution, the load is spread evenly across physical partitions, eliminating hot spots and throttling.

Exam trap

The trap here is that candidates often confuse throttling with performance tuning (TTL) or data storage (analytical store), rather than recognizing that the root cause is an insufficiently granular partition key leading to uneven request distribution.

How to eliminate wrong answers

Option A is wrong because increasing the default TTL (Time to Live) only affects how long data lives in the container; it does not change the partition key design or distribute request load, so it cannot resolve hot-partition throttling. Option B is wrong because enabling analytical store only creates a separate columnar store for analytical queries; it does not alter the transactional partition key or distribute write/read requests, so throttling persists. Option D is wrong because using a stored procedure for every write does not change the underlying partition key distribution; stored procedures execute within a single logical partition and cannot spread load across partitions, so hot partitions remain throttled.

Full explanation →

Multi-Selecthard

Which THREE considerations are important when designing a solution using Azure Functions with a Consumption plan for a latency-sensitive application?

Select 3 answers

A.Cold start latency may impact initial requests.

B.Function execution timeout is limited to 10 minutes.

C.Scaling may not be instantaneous, causing latency spikes.

D.Always-on feature must be enabled to avoid cold starts.

E.Pre-warmed instances can be configured to reduce latency.

AnswersA, B, C

In the Azure Functions Consumption plan, instances are dynamically allocated and deallocated based on demand. When a function has been idle for a period, its underlying host instance may be shut down. The "cold start" refers to the latency incurred when the first request arrives, requiring the Azure platform to spin up a new instance, load the function code, and initialize the runtime environment, which can significantly delay the initial response.

Why this answer

Option A is correct because on the Consumption plan, function apps scale to zero when idle, so the first request after an idle period triggers a cold start that adds latency to that initial invocation. Option B is correct because the Consumption plan enforces a maximum function execution timeout of 10 minutes (default 5 minutes), which constrains long-running latency-sensitive workloads. Option C is correct because Consumption-plan scaling is event-driven and not instantaneous, so bursts of traffic can cause temporary latency spikes while new instances are provisioned.

Option D is incorrect because Always On is a feature of App Service plans (and Premium/ Dedicated), not the Consumption plan, and cannot be enabled there. Option E is incorrect because pre-warmed instances are a Premium plan capability, not available on the Consumption plan.

Exam trap

The trap here is that candidates often confuse the features of the Consumption plan with those of the Premium plan, mistakenly thinking Always-on or pre-warmed instances are available in the Consumption plan, when they are exclusive to higher-tier plans.

Full explanation →

Multi-Selectmedium

Which TWO actions should you take to optimize costs for an Azure SQL Database that is underutilized? (Choose two.)

Select 2 answers

A.Enable geo-replication

B.Increase the DTU or vCore limit

C.Purchase reserved capacity

D.Enable read scale-out

E.Scale down to a lower service tier

AnswersC, E

Purchasing reserved capacity for Azure SQL Database allows organizations to commit to a specific amount of database compute usage for a one-year or three-year term. By making this upfront commitment, Azure provides substantial discounts, often ranging from 30% to 70% compared to standard pay-as-you-go rates. This strategy is particularly effective for predictable, long-running workloads, significantly reducing the total cost of ownership over the reservation period and directly optimizing expenditures.

Why this answer

Option C (Purchase reserved capacity) is correct because committing to a 1- or 3-year reservation for Azure SQL Database provides a significant discount (up to ~33% for 1-year and ~55% for 3-year) compared to pay-as-you-go pricing, directly reducing cost for a database that will continue running. Option E (Scale down to a lower service tier) is correct because an underutilized database is provisioned with more DTUs/vCores than it needs, so moving to a lower service tier or compute size reduces the hourly provisioned cost while still meeting actual workload demand. Option A (Enable geo-replication) is incorrect because it adds a secondary readable database and increases cost rather than optimizing it.

Option B (Increase the DTU or vCore limit) is incorrect because it raises provisioned resources and cost, the opposite of optimization for an underutilized database. Option D (Enable read scale-out) is incorrect because, while it can offload read workloads, it does not reduce the cost of an underutilized database and may require a higher service tier.

Exam trap

The trap here is that candidates often confuse cost optimization with performance improvement, selecting options like enabling geo-replication or read scale-out, which are high-availability and scalability features that increase costs, not reduce them.

Full explanation →

MCQeasy

You are developing an application that stores user-uploaded profile pictures in Azure Blob Storage. Users frequently access these pictures for the first 7 days after upload, then rarely. To minimize costs, you need to automatically delete pictures that are older than 30 days. Which Azure Storage feature should you use to achieve this?

A.Lifecycle management policy

B.Blob snapshots

C.Change feed

D.Soft delete

AnswerA

Azure Blob Storage lifecycle management policies enable defining rules to automatically transition blobs between access tiers or delete them after a specified period. These policies are configured at the storage account level, allowing users to set conditions based on blob age, last modified time, or creation time. For instance, a rule can be established to automatically delete profile pictures (blobs) that are older than 30 days, directly fulfilling the requirement for automated data retention and cleanup. This optimizes storage costs and ensures compliance with data retention policies.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automatically tier or expire blobs based on age. By defining a rule that deletes blobs after 30 days from creation, you can remove old profile pictures without manual intervention, directly minimizing storage costs.

Exam trap

The trap here is that candidates may confuse soft delete (which retains deleted blobs) with automatic deletion, or think change feed or snapshots can trigger deletions, when only lifecycle management provides scheduled, rule-based expiration.

How to eliminate wrong answers

Option B (Blob snapshots) is wrong because snapshots are point-in-time read-only copies of a blob, used for versioning or backup, not for automatic deletion based on age. Option C (Change feed) is wrong because it provides transaction logs of blob changes for event processing or replication, not a mechanism to delete blobs automatically. Option D (Soft delete) is wrong because it protects blobs from accidental deletion by retaining them for a specified period, but it does not automatically delete blobs based on age; it requires an explicit delete operation to trigger.

Full explanation →

MCQmedium

Refer to the exhibit. You executed the Azure CLI command to create a storage account. Later, you attempt to connect from an application that uses TLS 1.1. The connection fails. What is the most likely reason?

A.The storage account uses Standard_GRS replication which is not accessible from all clients

B.The storage account is in a different location than the client

C.The storage account kind is StorageV2 which does not support blobs

D.The minimum TLS version is set to 1.2, blocking TLS 1.1

AnswerD

The Azure CLI command `az storage account update --minimum-tls-version TLS1_2` explicitly configures the storage account to reject any incoming connections that attempt to negotiate a TLS protocol version older than 1.2. If a client application or operating system is configured to use TLS 1.0 or TLS 1.1, the connection will fail during the initial TLS handshake phase, resulting in a connectivity error. This setting directly enforces a higher security standard, blocking older, less secure TLS versions.

Why this answer

The Azure CLI command used to create the storage account did not specify a minimum TLS version, so the default value of 1.2 applies. When the application attempts to connect using TLS 1.1, Azure Storage rejects the connection because the service enforces TLS 1.2 or higher. This is a security default in Azure Storage accounts created after a certain date, and it can be overridden by setting the `--min-tls-version` parameter to 1.0 during creation or by updating the account's properties.

Exam trap

The trap here is that candidates may overlook the default minimum TLS version setting in Azure Storage and assume that TLS 1.1 is always supported, or they may incorrectly attribute the failure to replication type, location, or storage account kind.

How to eliminate wrong answers

Option A is wrong because Standard_GRS replication provides geo-redundant storage and does not impose any TLS version restrictions; all replication types support the same TLS protocols. Option B is wrong because the location of the storage account relative to the client does not affect TLS version negotiation; TLS is a transport-layer protocol independent of geographic location. Option C is wrong because StorageV2 (general purpose v2) fully supports blobs, including block blobs, append blobs, and page blobs; the 'kind' parameter does not disable blob functionality.

Full explanation →

MCQmedium

You are developing a .NET Core application that stores session state data. The data is infrequently updated but must be read quickly for every user request. You need a serverless, globally distributed storage solution with low latency reads. Which Azure storage solution should you use?

A.Azure Table Storage

B.Azure Cosmos DB with SQL API

C.Azure Redis Cache

D.Azure Blob Storage

AnswerB

Azure Cosmos DB with the SQL API is an ideal choice for session state due to its guaranteed single-digit millisecond latency for both reads and writes, backed by comprehensive SLAs. It offers native global distribution with multi-region write capabilities, ensuring high availability and low latency for users worldwide without complex configuration. Furthermore, its serverless capacity model allows for automatic and cost-effective scaling based on demand, perfectly suiting dynamic session data requirements.

Why this answer

Azure Cosmos DB with SQL API is the correct choice because it provides a globally distributed, serverless database service with single-digit millisecond read latency at any scale, making it ideal for infrequently updated session state that must be read quickly for every user request. Its multi-region replication ensures low-latency reads from any location, and the SQL API offers a familiar query interface for .NET Core applications.

Exam trap

The trap here is that candidates often choose Azure Redis Cache because of its reputation for low-latency caching, but they overlook the 'serverless' and 'globally distributed' requirements, which Redis Cache does not natively satisfy without manual configuration and provisioning, whereas Cosmos DB offers these features out of the box.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a NoSQL key-value store that does not offer global distribution or guaranteed low-latency reads; it is regionally scoped and lacks the throughput and latency guarantees required for fast session reads. Option C is wrong because Azure Redis Cache is an in-memory data store that provides low-latency reads, but it is not serverless (requires provisioning and managing cache tiers) and is not inherently globally distributed; it would require additional configuration like geo-replication, and it is optimized for frequently updated data, not infrequently updated session state. Option D is wrong because Azure Blob Storage is designed for unstructured object storage with higher latency for individual reads, and it does not support the low-latency, high-frequency read patterns needed for session state per user request.

Full explanation →

MCQmedium

You are building an Azure Logic App that processes orders. When an order is placed, the Logic App must send a message to an Azure Service Bus queue. The queue is secured using managed identity. Which connector action should you use?

A.HTTP action with SAS token

B.Service Bus connector with managed identity authentication

C.Azure Functions connector

D.Event Grid connector

AnswerB

This is the optimal and recommended approach. The Azure Service Bus connector natively supports managed identity authentication, allowing the Logic App to securely authenticate with Azure Service Bus using an identity managed by Azure Active Directory. This eliminates the need to store or manage connection strings, SAS tokens, or other credentials within the Logic App, significantly enhancing security and simplifying credential rotation and lifecycle management through Azure RBAC.

Why this answer

The Service Bus connector with managed identity authentication is correct because it allows the Logic App to authenticate to the Azure Service Bus queue using an Azure AD managed identity, eliminating the need for secrets or SAS tokens. This is the recommended approach for securing Service Bus resources when using Azure services, as it leverages Azure RBAC for fine-grained access control and aligns with the principle of least privilege.

Exam trap

The trap here is that candidates may confuse the HTTP action with SAS token as a valid way to use managed identity, but managed identity requires Azure AD authentication, not SAS, and the Service Bus connector explicitly supports this authentication type.

How to eliminate wrong answers

Option A is wrong because the HTTP action with SAS token requires you to generate and manage a Shared Access Signature token, which introduces secret management overhead and does not use managed identity; it is less secure and not the intended method for managed identity scenarios. Option C is wrong because the Azure Functions connector is used to trigger or invoke Azure Functions, not to directly send messages to a Service Bus queue; it would add unnecessary complexity and latency. Option D is wrong because the Event Grid connector is designed for publishing and subscribing to events via Azure Event Grid, not for sending messages to a Service Bus queue; it does not support Service Bus queue operations directly.

Full explanation →

MCQmedium

You find the above ARM template for an App Service. What is a security concern with this configuration?

A.The connection string is stored in the source code.

B.The password is passed as a parameter and may be exposed in deployment logs.

C.The connection string type should be 'Custom' instead of 'SQLAzure'.

D.The connection string is not encrypted at rest.

AnswerB

This statement is correct because while ARM templates support `securestring` parameters to prevent values from being displayed in the Azure portal after deployment, the actual parameter value can still be captured and exposed in deployment logs during the execution phase. This risk is particularly relevant in CI/CD pipelines or if the parameter is used in a way that triggers logging of its content. For true secret management, integrating with Azure Key Vault is the recommended secure approach.

Why this answer

When a password is passed as an ARM template parameter, its value can be captured in deployment logs (e.g., Azure Activity Logs or PowerShell verbose output) if the parameter is not marked as 'secureString'. This exposes sensitive credentials to anyone with log access, violating security best practices. In contrast, using a secureString parameter encrypts the value and masks it in logs.

Exam trap

The trap here is that candidates focus on the connection string being in the template (Option A) or its type (Option C), but the real security issue is the plaintext parameter exposure in deployment logs, which is a common oversight in ARM template security.

How to eliminate wrong answers

Option A is wrong because the connection string is not stored in source code; it is defined in the ARM template and deployed as a resource property, which is a standard practice. Option C is wrong because 'SQLAzure' is a valid connection string type for Azure SQL Database, and changing it to 'Custom' would not address security concerns. Option D is wrong because connection strings in App Service are encrypted at rest by default using Azure platform-managed keys; the concern is about exposure during deployment, not at rest.

Full explanation →

MCQhard

You are designing a solution that uses Azure Container Instances (ACI) to run a batch job that processes images. The job is triggered by a message in Azure Queue Storage. Each image takes about 5 minutes to process. You need to ensure that the container runs only when there are messages in the queue and scales automatically. What should you use?

A.Use Azure Logic Apps with a Container Instances connector.

B.Use Azure Functions with a custom container and queue trigger.

C.Use Azure Batch to process the images in a pool of VMs.

D.Deploy the image processing job as a pod in Azure Kubernetes Service.

AnswerA

Azure Logic Apps provide a robust, serverless workflow engine perfectly suited for event-driven scenarios, such as processing messages from a queue. Its native Azure Container Instances (ACI) connector enables the dynamic creation and execution of a new container instance for each incoming queue message. This design ensures true 'from zero' scaling, where compute resources are provisioned only when needed and deallocated immediately after the containerized task completes, optimizing cost and operational overhead for sporadic batch jobs.

Why this answer

Azure Logic Apps provides a serverless workflow that can be triggered by a queue message (via the Azure Queue Storage connector) and then use the Container Instances connector to start a container group. This ensures the container runs only when messages are present and scales automatically by creating a new container instance per message, matching the requirement for event-driven, on-demand execution without idle costs.

Exam trap

The trap here is that candidates often assume Azure Functions is the only serverless option for queue-triggered workloads, overlooking that Logic Apps can directly orchestrate ACI creation without writing custom code, which is simpler and more aligned with the requirement to 'run the container only when there are messages'.

How to eliminate wrong answers

Option B is wrong because Azure Functions with a custom container and queue trigger runs the function code inside the container, but it does not directly orchestrate the creation of a separate ACI container for each batch job; the function would need to manage ACI lifecycle manually, adding complexity and not leveraging ACI's native scaling. Option C is wrong because Azure Batch is designed for large-scale parallel batch processing with a pool of VMs, which is overkill for a simple queue-triggered job and introduces unnecessary overhead for managing a VM pool. Option D is wrong because Azure Kubernetes Service (AKS) is a full orchestration platform for containerized applications, requiring cluster management and scaling configuration, which is excessive for a single batch job that should run only on demand; it does not natively integrate with Azure Queue Storage triggers without additional components like KEDA.

Full explanation →

MCQhard

You are a developer for a large e-commerce company. The company has a global customer base and runs a critical web application on Azure App Service (Premium v3 plan) deployed in multiple regions. The application uses Azure Cosmos DB (multi-region writes enabled) for product catalog and session state. Recently, the operations team reported that during peak shopping hours (e.g., Black Friday), the application becomes slow and some users experience timeouts. You have implemented Application Insights to collect telemetry. After analyzing the data, you find that the Cosmos DB write operations are experiencing high latency (average 200ms) and occasional throttling (429 errors). The read latency is acceptable. The App Service instances are scaled out to 20 instances during peak, and CPU usage is around 70%. You need to optimize the solution to reduce write latency and eliminate throttling without over-provisioning resources. The solution must be cost-effective and require minimal code changes. What should you do?

A.Scale up the App Service plan to a higher tier to increase CPU capacity

B.Implement Azure Cache for Redis to cache Cosmos DB read and write operations

C.Increase the provisioned RU/s manually before peak hours and decrease after

D.Enable autoscale on the Cosmos DB container with a maximum throughput limit

AnswerD

Enabling autoscale on the Cosmos DB container is the most effective solution for dynamically managing throughput and preventing throttling errors. Autoscale automatically adjusts the provisioned Request Units per second (RU/s) based on the actual usage patterns of the workload, scaling up during peak demand and scaling down during lulls. Setting a maximum throughput limit ensures cost control by preventing the throughput from exceeding a predefined ceiling, while still allowing the system to adapt to varying loads and maintain application responsiveness without manual intervention.

Why this answer

Enabling autoscale on the Cosmos DB container allows the throughput to automatically scale up to the maximum limit during peak traffic, eliminating throttling (429 errors) and reducing write latency without manual intervention. This approach is cost-effective as it scales down during low traffic, and requires minimal code changes since it's a configuration change at the Cosmos DB level.

Exam trap

The trap here is that candidates may confuse scaling the App Service (Option A) with scaling the database, or assume caching (Option B) can solve write latency, but writes must be persisted to Cosmos DB and caching does not help with throttling.

How to eliminate wrong answers

Option A is wrong because scaling up the App Service plan increases CPU capacity, but the issue is with Cosmos DB write latency and throttling, not App Service CPU (which is at 70%). Option B is wrong because Azure Cache for Redis can cache read operations to reduce read latency, but it cannot cache write operations (writes must go to Cosmos DB for durability), so it does not address write throttling or latency. Option C is wrong because manually increasing RU/s before peak hours and decreasing after is not cost-effective (you pay for provisioned RU/s even if unused) and requires operational overhead, whereas autoscale dynamically adjusts throughput based on demand.

Full explanation →

100

MCQhard

You need to emit a custom metric in Application Insights that tracks the number of page views per browser. You expect high volume (millions of events per day). Which API should you use to ensure efficient pre-aggregation and avoid performance issues?

A.TrackEvent

B.TrackMetric

C.GetMetric

D.TrackDependency

AnswerC

GetMetric (specifically, GetMetric().TrackValue()) is the recommended approach for high-volume custom metrics that require multiple dimensions. It provides an in-memory metric object that intelligently aggregates data points client-side over a configurable interval (typically 1 minute) before sending a single, summarized data point to Application Insights. This client-side pre-aggregation significantly reduces telemetry volume, optimizes ingestion costs, and supports rich dimensional analysis without incurring high overhead.

Why this answer

C is correct because the GetMetric API (previously known as Pre-Aggregated Metric API) is designed for high-volume telemetry scenarios. It pre-aggregates metrics on the client side before sending them to Application Insights, significantly reducing network traffic and storage costs while avoiding performance bottlenecks from millions of individual events.

Exam trap

The trap here is that candidates often confuse TrackEvent (for custom events) with metric tracking, or assume TrackMetric is the correct choice because of its name, not realizing it is deprecated and lacks client-side pre-aggregation.

How to eliminate wrong answers

Option A is wrong because TrackEvent sends each event individually, which would generate millions of separate telemetry records, causing excessive network overhead and ingestion costs. Option B is wrong because TrackMetric is deprecated and also sends individual metric values without client-side aggregation, leading to similar performance issues. Option D is wrong because TrackDependency is used to track external dependency calls (e.g., HTTP, SQL), not custom metrics like page views per browser.

Full explanation →

101

MCQeasy

You are deploying a containerized application using Azure Kubernetes Service (AKS). You need to ensure that sensitive configuration data, such as API keys, is not stored in container images. Which Kubernetes resource should you use?

A.Deployment

B.ConfigMap

C.PersistentVolume

D.Secret

AnswerD

A Kubernetes Secret object is specifically engineered to store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys, within the cluster. Secrets provide a more secure mechanism for injecting this data into pods compared to plain text in ConfigMaps or direct pod definitions. They can be mounted as data volumes or exposed as environment variables, with Kubernetes handling base64 encoding and offering integration with external secret management systems for enhanced security.

Why this answer

Kubernetes Secrets are specifically designed to store sensitive data like API keys, connection strings, and passwords. They are stored in etcd as base64-encoded values (and can be encrypted at rest) and are injected into pods as environment variables or mounted as volumes, ensuring the sensitive data never resides in the container image.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both are interchangeable for configuration, but ConfigMaps store data in plain text and are not secure for sensitive information, while Secrets provide base64 encoding and optional encryption for sensitive data.

How to eliminate wrong answers

Option A is wrong because a Deployment manages replica sets and pod lifecycle, but it does not provide any mechanism for storing or injecting sensitive configuration data. Option B is wrong because ConfigMaps store non-sensitive configuration data in plain text (base64-encoded but not encrypted by default) and are not intended for secrets; using a ConfigMap for API keys would expose them in plain text. Option C is wrong because a PersistentVolume provides storage for stateful workloads (e.g., databases) but is not designed for injecting sensitive configuration into pods; it would require manual management of secret files and does not integrate with Kubernetes RBAC or encryption for secrets.

Full explanation →

102

Multi-Selecthard

Which TWO actions should you take to securely store and access secrets for a legacy application that cannot be modified? The application runs on an Azure Virtual Machine and needs to read a database connection string. The solution must use Azure Key Vault and adhere to the principle of least privilege.

Select 2 answers

A.Create a new VM and install the Key Vault extension during provisioning.

B.Configure the application to read the connection string from a local file that is updated by the Key Vault extension.

C.Assign a managed identity to the legacy application.

D.Use a user-assigned managed identity and assign it to the VM.

E.Enable the Azure Key Vault VM extension for the virtual machine.

AnswersB, E

Configuring the legacy application to read connection strings from a local file is the crucial step for enabling it to consume secrets securely. The Azure Key Vault VM extension facilitates this by periodically fetching secrets from Key Vault and writing them to a designated file path on the VM's local file system. This method allows the application, which lacks native Key Vault integration capabilities, to access sensitive data without code changes or embedding credentials.

Why this answer

The legacy application cannot be modified, so it cannot directly call the Key Vault REST API or SDK. The Azure Key Vault VM extension (also known as the Key Vault Sync extension) runs as a daemon on the VM, retrieves secrets from Key Vault using a managed identity, and writes them to a local file. The application reads the connection string from that local file, achieving secure secret access without code changes.

Exam trap

The trap here is that candidates often think a managed identity alone allows an unmodified application to access Key Vault, but in reality, the application must either use the Azure SDK or rely on the Key Vault extension to write secrets to a local file, since the legacy code cannot be changed to call the Key Vault REST API.

Full explanation →

103

MCQmedium

You have an Azure Function app that processes orders. The function uses a queue trigger from Azure Storage. Recent load tests show that the function is not scaling out fast enough under high load. What should you do to improve scaling?

A.In the function code, increase the number of retries on failure

B.In host.json, increase the batchSize and increase the newBatchThreshold

C.In host.json, increase the batchSize and decrease the newBatchThreshold

D.Switch from Consumption plan to Premium plan

AnswerD

Switching to an Azure Functions Premium plan provides significantly more predictable scaling and eliminates cold starts by maintaining pre-warmed instances. Unlike the Consumption plan, which dynamically provisions resources on demand, the Premium plan offers dedicated, always-ready instances that can scale out much faster and more consistently, ensuring lower latency and higher throughput for order processing during peak loads. This dedicated resource model is crucial for performance-critical applications requiring rapid responsiveness.

Why this answer

Switching to the Premium plan provides faster scale-out capabilities, including pre-warmed instances and more scalable infrastructure, which helps the function scale out more quickly under high load compared to the Consumption plan.

Exam trap

The trap is that candidates may think increasing batch sizes improves throughput, but for faster scaling, smaller batches trigger more frequent fetch operations, which the scale controller uses to decide to add instances. The key is to balance efficiency with scale-out speed.

How to eliminate wrong answers

Option A is wrong because increasing the number of retries on failure does not affect scaling speed; it only affects fault tolerance for individual message processing failures. Option C is wrong because decreasing newBatchThreshold would cause the runtime to wait longer before fetching a new batch, which would actually slow down scaling and worsen the problem. Option D is wrong because switching to Premium plan provides more predictable scaling and VNET integration but does not inherently improve scaling speed; the bottleneck here is the queue trigger configuration, not the hosting plan.

Full explanation →

104

Multi-Selecteasy

You are monitoring an Azure App Service web app that is experiencing intermittent high CPU usage. You need to configure alerts and troubleshoot the issue. Which TWO actions should you take? (Choose two.)

Select 2 answers

A.Create a metric alert rule that triggers when average CPU exceeds 90% over 5 minutes.

B.Scale up the App Service plan to a higher tier to ensure sufficient resources.

C.Create a Log Analytics workspace and configure diagnostic settings to send platform logs.

D.Enable Application Insights and configure autoscale based on custom metrics.

E.Create an autoscale rule for the App Service plan to scale out when CPU > 80%.

AnswersA, C

An alert rule primarily provides notification when a specific metric threshold, such as average CPU exceeding 90%, is breached. While crucial for operational awareness and indicating a potential problem, it does not automatically remediate the high CPU usage or provide the detailed diagnostic data necessary for root cause analysis. This action only informs about the issue, rather than proactively resolving it or enabling deep troubleshooting.

Why this answer

Option A is correct because a metric alert on the CPU Percentage metric with an average aggregation over a 5-minute window and a 90% threshold is the standard way to detect sustained high CPU on an App Service plan and get notified when the condition is met. Option C is correct because sending platform logs and metrics to a Log Analytics workspace via diagnostic settings enables querying historical resource and platform data (e.g., using KQL) to troubleshoot the intermittent CPU spikes and correlate them with events. Option B is not appropriate because scaling up changes the pricing tier and resources but does not by itself alert or diagnose the intermittent issue.

Option D is incorrect because Application Insights primarily provides application-level telemetry and autoscale cannot be driven by Application Insights custom metrics for App Service plans in the way described. Option E is incorrect because autoscale rules react to load by adding instances but do not satisfy the requirement to configure alerts and troubleshoot the root cause.

Exam trap

The trap here is that candidates confuse alerting (Option A) with troubleshooting, or they assume scaling (Option B) is a valid troubleshooting action rather than a mitigation, while Option D mixes a diagnostic tool (Application Insights) with an autoscale action that does not directly help identify the cause.

Full explanation →

105

MCQeasy

You are deploying a containerized application to Azure Container Instances. The application requires a custom domain name and SSL/TLS certificate. What should you do?

A.Place an Azure Application Gateway in front of the container group.

B.Configure the container to listen on port 443 and map a custom domain.

C.Upload the certificate to the container and configure the web server.

D.Use a private endpoint with a custom domain.

AnswerA

Azure Application Gateway serves as a Layer 7 load balancer and web application firewall, perfectly suited for exposing containerized applications like those in Azure Container Instances (ACI). It provides robust SSL/TLS termination at the edge, offloading this compute-intensive task from the backend containers. Furthermore, Application Gateway enables custom domain mapping and advanced routing rules, allowing traffic to be directed to specific container instances based on URL paths or hostnames, ensuring secure and flexible access to the application.

Why this answer

Azure Container Instances (ACI) does not natively support custom domain names or SSL/TLS termination. By placing an Azure Application Gateway in front of the container group, you can offload SSL/TLS termination at the gateway layer, map a custom domain via the gateway's frontend IP, and route traffic to the container group's private IP. This is the recommended pattern for adding HTTPS and custom domains to ACI workloads.

Exam trap

The trap here is that candidates assume Azure Container Instances supports custom domains and SSL/TLS natively, similar to Azure App Service, but ACI lacks these features, requiring an external load balancer or gateway like Application Gateway.

How to eliminate wrong answers

Option B is wrong because simply configuring the container to listen on port 443 and mapping a custom domain does not provide SSL/TLS termination; ACI does not support binding a custom domain or certificate directly to the container group's public IP. Option C is wrong because uploading a certificate to the container and configuring the web server would require managing the certificate lifecycle inside the container, but ACI still cannot expose a custom domain name on its public endpoint; the container's FQDN is auto-generated and cannot be changed. Option D is wrong because a private endpoint with a custom domain only enables private connectivity within a virtual network; it does not expose the container group to the internet with a custom domain and SSL/TLS certificate.

Full explanation →

106

MCQeasy

A Windows desktop application uses standard .NET file system calls such as File.ReadAllText and Directory.GetFiles. The team wants to move the file storage to Azure. The application code must not be rewritten. Which Azure storage service supports this requirement?

A.Azure Files with an SMB share mounted as a drive letter on the Windows machine

B.Azure Blob Storage with the Azure Storage SDK replacing all file system calls

C.Azure Queue Storage for staging files between producer and consumer processes

D.Azure Table Storage with the file content stored as base64-encoded entity properties

AnswerA

SMB shares exposed by Azure Files are indistinguishable from local or network drives at the OS level. The .NET file system APIs translate directly to SMB operations on the share, requiring zero code changes in the application.

Why this answer

Azure Files with an SMB share mounted as a drive letter on the Windows machine allows the existing .NET application to use standard file system calls like File.ReadAllText and Directory.GetFiles without any code changes. This is because the mounted SMB share presents itself as a local drive, and the .NET runtime interacts with it through the standard Windows file system API, which internally uses the SMB protocol (CIFS) to communicate with Azure Files. No SDK or API rewrite is required.

Exam trap

The trap here is that candidates may assume Azure Blob Storage is the only file storage option and overlook Azure Files, which is specifically designed for lift-and-shift scenarios requiring SMB-based file sharing without code changes.

How to eliminate wrong answers

Option B is wrong because Azure Blob Storage with the Azure Storage SDK would require rewriting all file system calls to use the SDK's methods (e.g., BlobClient.DownloadAsync), which violates the requirement that the application code must not be rewritten. Option C is wrong because Azure Queue Storage is a messaging service for asynchronous communication between processes, not a file storage service, and cannot be used with standard file system calls. Option D is wrong because Azure Table Storage is a NoSQL key-value store with a 64 KB entity size limit, making it impractical for storing file content as base64-encoded properties, and it does not support standard file system APIs.

Full explanation →

107

MCQmedium

Refer to the exhibit. You are reviewing an Azure Policy definition. When applied to a subscription, what is the effect of this policy?

A.Audit resources in locations other than eastus or westus

B.Append a tag to resources in eastus or westus

C.Deny deployment of resources in eastus or westus

D.Deny deployment of resources in locations other than eastus or westus

AnswerD

This option is correct because it accurately describes both the effect and the condition of the Azure Policy. The 'deny' effect prevents the creation or update of resources that violate the policy rules. When combined with a condition that specifies 'location notIn ['eastus', 'westus']', the policy will block any attempt to deploy resources into any Azure region other than East US or West US, ensuring strict regional compliance.

Why this answer

The policy definition uses the 'deny' effect with a condition that evaluates to true when the resource location is not equal to 'eastus' or 'westus'. This means any deployment attempt to a region outside these two will be blocked. The 'deny' effect prevents the resource creation entirely, rather than just auditing or modifying it.

Exam trap

The trap here is that candidates misread the condition logic—the 'notEquals' combined with 'or' for allowed regions means the deny triggers for any location that is not in the allowed list, not for the allowed locations themselves.

How to eliminate wrong answers

Option A is wrong because the policy uses the 'deny' effect, not 'audit', so it blocks deployment rather than merely logging non-compliance. Option B is wrong because the policy does not use the 'append' effect or any tag-related operation; it denies deployment based on location. Option C is wrong because the condition denies resources in locations other than eastus or westus, not resources in eastus or westus themselves.

Full explanation →

108

MCQmedium

You are designing a solution where an Azure Logic App needs to send emails via Microsoft Graph. The Logic App should authenticate without user interaction. What authentication method should you use?

A.Use a user-assigned managed identity and grant it the Mail.Send application permission

B.Use OAuth 2.0 authorization code grant with a user account

C.Use a service principal and store its client secret in the Logic App configuration

D.Use basic authentication with an email account password

AnswerA

User-assigned managed identities provide an Azure AD identity for Azure resources, eliminating the need for developers to manage credentials. By granting the Mail.Send application permission to this managed identity, the Logic App can securely authenticate with Microsoft Graph and send emails programmatically without any user interaction or storing secrets. This approach adheres to the principle of least privilege and enhances security by leveraging Azure AD for authentication and authorization.

Why this answer

A user-assigned managed identity provides a secure, passwordless authentication method for Azure resources. By granting it the Mail.Send application permission (not delegated), the Logic App can authenticate to Microsoft Graph without any user interaction, as managed identities are automatically managed by Azure and do not require credential rotation or storage.

Exam trap

The trap here is that candidates often confuse delegated permissions (which require a signed-in user) with application permissions (which allow daemon/service scenarios), and mistakenly choose OAuth authorization code grant or service principal with secret, not realizing managed identities are the recommended zero-secret approach for Azure resources.

How to eliminate wrong answers

Option B is wrong because the OAuth 2.0 authorization code grant requires an interactive user login to obtain a code and token, which violates the 'without user interaction' requirement. Option C is wrong because storing a client secret in the Logic App configuration introduces a security risk (secret exposure) and requires manual secret rotation, whereas managed identities eliminate the need for secrets entirely. Option D is wrong because basic authentication with a password is deprecated by Microsoft for Graph API and does not support application-level permissions; it also requires user interaction and is insecure.

Full explanation →

109

MCQeasy

You are deploying a multi-tier application: a frontend web app (Azure App Service) that calls a backend API (another Azure App Service). Both apps use Microsoft Entra ID for authentication. The frontend needs to authenticate to the backend on behalf of the signed-in user. You need to configure the OAuth 2.0 flow correctly. You have already registered both applications in Microsoft Entra ID. Which configuration should you apply?

A.In the frontend app registration, grant API permissions for the backend using the 'Delegated permissions' type. In the backend app registration, expose an API scope. The frontend uses the on-behalf-of flow (OBO) to exchange the user's token for a token to call the backend.

B.In the frontend app registration, enable the implicit grant flow for access tokens. The frontend gets a token for the backend directly from the authorization endpoint.

C.In the frontend app registration, set the redirect URI to the backend URL. The frontend uses the authorization code flow to get a token for the backend directly.

D.In the frontend app registration, grant API permissions for the backend using the 'Application permissions' type. In the backend app registration, expose an API scope. The frontend uses the client credentials flow to get a token for the backend.

AnswerA

This option correctly describes the standard and secure pattern for a multi-tier application using Azure AD. The frontend application, acting on behalf of the signed-in user, requests a token for the backend API using the On-Behalf-Of (OBO) flow. This flow exchanges the user's token, obtained by the frontend, for a new token specifically scoped for the backend API, preserving the user's identity throughout the call chain. Delegated permissions in the frontend's app registration allow it to request access to the backend API on behalf of the user, while the backend exposes API scopes to define what access is available.

Why this answer

The frontend needs to act on behalf of the signed-in user, which requires delegated permissions. The backend must expose an API scope so the frontend can request it. The OAuth 2.0 On-Behalf-Of (OBO) flow is designed for this scenario: the frontend receives a token for itself, then exchanges it via the OBO flow for a token scoped to the backend API, preserving the user's identity and consent.

Exam trap

The trap here is confusing delegated permissions (user context) with application permissions (app-only context), leading candidates to incorrectly choose the client credentials flow (Option D) or the implicit flow (Option B) when the OBO flow is required for multi-tier user delegation.

How to eliminate wrong answers

Option B is wrong because the implicit grant flow is deprecated and insecure; it exposes access tokens in the URL fragment and does not support the OBO flow needed to propagate the user context to the backend. Option C is wrong because setting the redirect URI to the backend URL would cause the authorization code to be sent to the backend, not the frontend, breaking the authentication flow; the frontend must receive the code itself. Option D is wrong because 'Application permissions' are used for client credentials flow (daemon/service scenarios) without a user context; this would make the frontend act as itself, not on behalf of the signed-in user, violating the requirement.

Full explanation →

110

Multi-Selecteasy

You are creating an Azure Functions app that uses a Blob Storage trigger to process new files. The function must process files only when they are completely written (i.e., no ongoing writes). You need to avoid processing partially written files. Which TWO configurations should you consider?

Select 2 answers

A.Increase the 'BatchSize' to reduce the frequency of trigger evaluations.

B.Check the blob's 'LastModified' timestamp in the function code to verify no recent changes.

C.Use a timer-triggered function that lists blobs and processes those with a stable size.

D.Use the 'BlobTrigger' with the 'LeaseBlob' property set to 'True'.

E.Set the 'ScanBlob' property to 'True' in the trigger binding.

AnswersB, C

Comparing the blob's LastModified timestamp lets the function detect whether writing has recently occurred, satisfying the requirement to avoid processing partially written files. If the timestamp is too recent, the function defers processing until the blob has settled, preventing reads of incomplete uploads.

Why this answer

Option B is correct because inspecting the blob's LastModified timestamp (and comparing it against the current time or a prior poll) lets the function confirm the blob has not been modified recently, which is a standard way to detect that writing has finished before processing. Option C is correct because a timer-triggered function that lists blobs and only processes those whose size has remained stable across polls avoids the race condition inherent in BlobTrigger, which can fire while a blob is still being written. Options A, D, and E are not valid: BatchSize applies to batching/parallelism of trigger invocations and does not guarantee a blob is fully written; there is no LeaseBlob property on the BlobTrigger binding; and ScanBlob is not a real BlobTrigger binding property.

Exam trap

Candidates often assume that the Blob trigger has built-in properties like 'LeaseBlob' or 'ScanBlob' to handle partial writes, but these are not valid. Instead, the proper patterns are to check the blob's timestamp or use a separate timer-triggered function to poll for stability.

Full explanation →

111

MCQhard

You are developing an ASP.NET Core web API that uses Microsoft Entra ID for authentication via Microsoft.Identity.Web. The application needs to authorize actions based on custom roles such as "Editor" and "Reviewer". These roles are not defined in Microsoft Entra ID app roles or directory roles; instead, they are stored in an application database and can be assigned dynamically by administrators. You need to implement authorization with minimal impact on performance and without modifying the application's authentication flow. Which approach should you use?

A.Add custom claims to the token via Microsoft Entra ID custom claims policies

B.Implement a custom authorization filter that reads the user's roles from the database on each request and caches them

C.Use Microsoft Entra ID app roles and assign them to users or groups

D.Use a custom middleware to modify the User principal after authentication, adding role claims from the database

AnswerD

A custom middleware positioned after authentication middleware but before authorization middleware is ideal for this scenario. It can access the authenticated `ClaimsPrincipal`, query the application database for dynamic roles (with caching for performance), and then add these roles as `ClaimTypes.Role` claims to the principal. This ensures the `ClaimsPrincipal` is fully enriched with application-specific roles early in the request pipeline, making them consistently available for all subsequent authorization checks, including `[Authorize]` attributes and policy-based authorization, without modifying the core authentication process.

Why this answer

It allows you to add role claims from the application database to the User principal after authentication via custom middleware, without altering the authentication flow. This approach leverages the existing Microsoft.Identity.Web authentication pipeline and caches the role claims in the principal, minimizing performance impact by avoiding repeated database lookups on every request.

Exam trap

The trap here is that candidates often confuse custom middleware with authorization filters, assuming both run at the same point in the pipeline, but middleware modifies the principal before authorization runs, while filters run after authentication and can cause redundant database calls if not designed carefully.

How to eliminate wrong answers

Option A is wrong because custom claims policies in Microsoft Entra ID are used to add claims to tokens issued by Entra ID, but they cannot dynamically read roles from an external database; they are static and defined at the tenant level, not suitable for application-specific dynamic roles. Option B is wrong because implementing a custom authorization filter that reads roles from the database on each request would cause a database call for every authorization check, significantly impacting performance even with caching, as the filter runs after authentication and does not modify the principal for downstream use. Option C is wrong because Microsoft Entra ID app roles are static and must be defined in the app manifest and assigned to users or groups in the portal, which does not support dynamically assigning roles from an application database without administrative intervention.

Full explanation →

112

MCQeasy

You are developing a solution that uploads large files to Azure Blob Storage. Users report that uploads fail after 4 minutes. You need to ensure uploads can complete successfully. What should you do?

A.Enable soft delete and versioning on the blob container.

B.Use premium block blob storage accounts.

C.Increase the client-side timeout value in the upload request.

D.Increase the storage account scale limit.

AnswerC

When uploading large files, especially using block blobs, the client-side library often breaks the file into smaller blocks, each with its own timeout. The default per-block timeout, typically around 4 minutes, can be insufficient for very large blocks or slow network conditions, leading to premature termination of the upload. Explicitly increasing this client-side timeout value in the upload request allows more time for each block or the entire file to transfer successfully, directly addressing and resolving upload timeout errors for large files.

Why this answer

The default client-side timeout for Azure Blob Storage uploads is 4 minutes. When uploading large files, the operation may exceed this timeout, causing the upload to fail. Increasing the client-side timeout value in the upload request extends the allowed duration, ensuring the upload completes successfully.

Exam trap

The trap here is that candidates may confuse client-side timeout with server-side timeout or storage account limits, leading them to choose options like increasing scale limits or using premium storage, which do not address the root cause of the upload failure.

How to eliminate wrong answers

Option A is wrong because enabling soft delete and versioning protects against accidental deletion or overwrites, but does not affect upload timeout limits. Option B is wrong because premium block blob storage accounts offer consistent low-latency and high transaction rates, but they do not change the default client-side timeout for upload operations. Option D is wrong because increasing the storage account scale limit raises throughput or capacity caps, but does not extend the client-side timeout for individual upload requests.

Full explanation →

113

MCQmedium

You are designing a backup solution for a virtual machine. Monthly backups are large VHD files (up to 1 TB) that must be retained for 7 years. After creation, backups are accessed only rarely (once or twice per year). You need to minimize storage cost. Which storage tier should you use for the VHD files?

A.Hot tier

B.Cool tier

C.Archive tier

D.Premium tier

AnswerC

The Archive tier is the most cost-effective option for storing data that is rarely accessed and can tolerate retrieval times of several hours, with a minimum retention period of 180 days. It offers the lowest storage costs per GB, making it ideal for long-term backups, historical data, or compliance archives where immediate access is not critical. For monthly virtual machine backups, which are typically stored for extended periods and retrieved only in disaster recovery scenarios, the Archive tier provides the optimal balance of cost savings and acceptable recovery time.

Why this answer

The Archive tier is the correct choice because it offers the lowest storage cost for data that is rarely accessed (once or twice per year) and has a long retention period (7 years). Azure Archive storage is optimized for data that can tolerate a retrieval latency of several hours, which is acceptable given the infrequent access pattern of these monthly backup VHD files.

Exam trap

The trap here is that candidates often choose Cool tier because they see 'backup' and think 'infrequent' but fail to recognize that 'rarely accessed' (once or twice per year) and 'long retention' (7 years) specifically point to Archive tier as the most cost-effective option, not Cool.

How to eliminate wrong answers

Option A is wrong because the Hot tier is designed for frequently accessed data and incurs higher storage costs, making it unsuitable for backups accessed only once or twice per year. Option B is wrong because the Cool tier, while cheaper than Hot, still has higher storage costs than Archive and is intended for data accessed every 30 days or more, not for annual access patterns. Option D is wrong because the Premium tier is for low-latency, high-performance workloads (e.g., I/O-intensive VMs) and has the highest cost, which is wasteful for rarely accessed backup files.

Full explanation →

114

MCQhard

You have an Azure Logic App that processes orders. Occasionally, the Logic App fails due to a transient error from a downstream API. You want to automatically retry the failed action after 10 seconds, up to 3 times, with exponential backoff. Which configuration should you set on the action?

A.Set retry policy to default with interval of 10 seconds and count of 3

B.Set retry policy to fixed interval with 10-second delay and 3 retries

C.Set retry policy to none and implement custom retry logic

D.Set retry policy to custom with exponential interval and 3 retries

AnswerA

The default retry policy in Azure Logic Apps automatically implements an exponential backoff strategy, which is ideal for transient errors as it progressively increases the delay between retries. When configured with an interval of 10 seconds and a count of 3, the initial delay will be 10 seconds, and subsequent retries will have longer delays, preventing immediate re-bombardment of a potentially overloaded service. This approach significantly improves the chances of success by allowing the target system time to recover.

Why this answer

The default retry policy in Azure Logic Apps uses exponential backoff, which automatically increases the delay between retries. Setting the interval to 10 seconds and count to 3 configures the initial delay and maximum retry attempts, while the exponential backoff behavior is inherent to the default policy. This matches the requirement to retry after 10 seconds initially, up to 3 times, with exponential backoff.

Exam trap

The trap here is that candidates often assume 'default' means no configuration is needed, but the default policy actually uses exponential backoff and requires explicit interval and count settings to control the retry behavior.

How to eliminate wrong answers

Option B is wrong because a fixed interval retry policy uses a constant delay between retries (e.g., exactly 10 seconds each time), not exponential backoff, which violates the requirement for exponential backoff. Option C is wrong because setting the retry policy to 'none' disables automatic retries entirely, requiring custom logic that would be unnecessary and more complex when the built-in default policy already supports exponential backoff. Option D is wrong because there is no 'custom' retry policy type in Azure Logic Apps; the available types are 'default', 'fixed interval', and 'none', and the default policy already provides exponential backoff without needing a custom configuration.

Full explanation →

115

MCQhard

A company has an Azure Service Bus namespace with a topic that receives high-throughput messages. They need to ensure that if a subscriber fails, messages are not lost and can be replayed. The subscriber is a client application that uses the PeekLock receive mode. What should they configure?

A.Enable auto-forwarding on the subscription.

B.Set a SQL filter on the subscription.

C.Disable dead-lettering on the subscription.

D.Enable dead-lettering on the subscription.

AnswerD

Enabling dead-lettering on a subscription automatically moves messages that cannot be delivered or processed successfully into a special sub-queue called the Dead-Letter Queue (DLQ). Messages are typically dead-lettered if they exceed the MaxDeliveryCount, expire, or if there are issues with subscription filters. This provides a crucial fault-tolerance mechanism, allowing operators to inspect failed messages, diagnose the root cause of processing errors, and potentially re-submit them for processing after corrective action, preventing data loss and enabling message recovery.

Why this answer

Dead-lettering on a subscription allows messages that cannot be processed by a subscriber to be moved to a dead-letter queue (DLQ) instead of being lost. When a subscriber using PeekLock mode fails to process a message (e.g., exceeds MaxDeliveryCount or the lock expires), the message is automatically transferred to the DLQ. This ensures messages are preserved and can be replayed later by reprocessing the DLQ, meeting the requirement for no message loss and replay capability.

Exam trap

The trap here is that candidates may think disabling dead-lettering prevents message loss (by keeping messages in the subscription), but in reality, without dead-lettering, messages that cannot be delivered are simply discarded after exceeding the maximum delivery count, leading to permanent loss.

How to eliminate wrong answers

Option A is wrong because auto-forwarding automatically moves messages from one subscription to another queue or topic, which does not preserve failed messages for replay; it simply redirects them, potentially losing the original failure context. Option B is wrong because a SQL filter is used to select which messages are delivered to a subscription based on message properties, not to handle message failures or replay. Option C is wrong because disabling dead-lettering would cause messages that exceed the maximum delivery count or expire to be silently discarded, violating the requirement to not lose messages.

Full explanation →

116

MCQmedium

You are building an IoT solution that generates millions of small log entries (each less than 1 KB) per day. The logs are rarely read, and when they are read, they are always accessed in chronological order. You need to minimize storage costs and maximize write throughput. Which Azure Blob Storage type should you use?

A.Append Blob

B.Block Blob

C.Page Blob

D.Archive Blob

AnswerA

Append Blobs are specifically optimized for append operations, making them ideal for logging scenarios like IoT telemetry where new data is continuously added to the end of a file. They are designed for high-throughput sequential writes and efficient sequential reads, ensuring cost-effectiveness and performance for millions of small log entries without needing to modify existing data blocks.

Why this answer

Append Blob is optimized for append operations, making it ideal for scenarios like logging where data is continuously added and rarely modified. It supports high-throughput writes because each append operation is atomic and does not require reading or updating existing blocks, which minimizes overhead. Since the logs are accessed in chronological order, Append Blob's sequential block structure allows efficient streaming reads without random access overhead.

Exam trap

The trap here is that candidates often choose Block Blob because it is the most common blob type for general-purpose storage, but they overlook that Append Blob is specifically designed for append-heavy workloads like logging, where write throughput and cost efficiency for small sequential writes are critical.

How to eliminate wrong answers

Option B (Block Blob) is wrong because while it supports high throughput for large objects, it requires managing block IDs and committing blocks, which adds complexity and overhead for millions of small appends; it is not optimized for frequent append-only writes. Option C (Page Blob) is wrong because it is designed for random read/write operations on fixed-size pages (512 bytes), typically used for virtual machine disks, and its write throughput is lower for small sequential appends due to page alignment requirements. Option D (Archive Blob) is wrong because it is a tier for cold data with high latency and no real-time write throughput optimization; it is meant for long-term storage after data is already written, not for active ingestion.

Full explanation →

117

MCQhard

You are a developer at a financial services company. You need to design a solution for processing real-time stock trade data. The system receives thousands of trades per second from an on-premises system. Each trade must be validated, enriched with reference data, and then stored in a data lake for analytics. You have the following requirements: - The processing must be serverless and scale automatically with high throughput. - The enrichment step requires calling an external REST API that can handle up to 100 requests per second. If the API is overwhelmed, trades must be retried with exponential backoff. - The solution must minimize cost and operational overhead. - Trades must be processed in order per stock symbol. You provision an Azure Event Hubs namespace with a single event hub. Trades are sent to the event hub with the stock symbol as the partition key. You configure an Azure Functions app with an Event Hubs trigger to process events. The function validates, enriches by calling the external API, and writes the enriched trade to Azure Data Lake Storage. During testing, you notice that some trades are processed out of order for the same stock symbol when the external API throttles requests. What should you do to ensure ordering per stock symbol?

A.Use Durable Functions to orchestrate the processing and enforce ordering.

B.Increase the 'maxEventBatchSize' setting to 100 in the host.json file to improve throughput.

C.Set the 'maxEventBatchSize' to 1 in the host.json file to process one event at a time per instance.

D.Use a different partition key such as a unique trade ID to distribute load evenly.

AnswerC

Setting 'maxEventBatchSize' to 1 in the host.json file ensures that the Azure Function's Event Hubs trigger processes only one event at a time from each partition it consumes. This configuration is critical for maintaining strict sequential processing order within an Event Hubs partition. By forcing single-event processing, the function guarantees that event N is fully processed before event N+1 from the same partition is even delivered, thereby preserving the required transactional integrity.

Why this answer

Setting 'maxEventBatchSize' to 1 ensures that each function instance processes only one event at a time. When the external API throttles and triggers retries with exponential backoff, processing of subsequent events for the same partition (stock symbol) is blocked until the current event completes. This preserves the per-partition ordering guarantee that Event Hubs provides, as events within a partition are processed sequentially by a single consumer.

Exam trap

The trap here is that candidates often assume increasing batch size improves throughput without realizing that it can break ordering when retries are involved, or they mistakenly think Durable Functions are needed for any ordering requirement.

How to eliminate wrong answers

Option A is wrong because Durable Functions add unnecessary complexity and cost for this scenario; they are designed for long-running workflows and state management, not for preserving per-partition ordering in a high-throughput event stream. Option B is wrong because increasing 'maxEventBatchSize' to 100 would allow multiple events to be processed concurrently within a single function invocation, which can break ordering when retries occur due to throttling. Option D is wrong because using a unique trade ID as the partition key would distribute trades for the same stock symbol across multiple partitions, eliminating the ordering guarantee that Event Hubs provides per partition.

Full explanation →

118

MCQhard

Refer to the exhibit. You are deploying an API in Azure API Management using an ARM template. The API is configured to use OAuth 2.0 authentication. The deployment fails with a validation error. What is the most likely cause?

A.The serviceUrl is not a valid URL.

B.The dependsOn array uses resourceId incorrectly.

C.The protocols array does not include http.

D.The authorization server 'auth-server-1' is not defined in the template.

AnswerD

OAuth 2.0 in API Management requires an `authorizationServer` resource declared in the ARM template, referenced by the API's `authenticationSettings.oAuth2.authorizationServerId`. If `auth-server-1` is absent, template validation fails because the API references a non-existent resource, satisfying the stem's validation-error constraint.

Why this answer

When an API in Azure API Management is configured to use OAuth 2.0 authentication, the ARM template must include a corresponding authorization server resource (type 'Microsoft.ApiManagement/service/authorizationServers') that defines the OAuth 2.0 provider. The API's authenticationSettings reference this authorization server by name, and if that server is not defined in the template, the deployment fails with a validation error indicating a missing dependency or undefined resource.

Exam trap

A common pitfall is assuming that OAuth 2.0 configuration for an API in Azure API Management can be defined entirely within the API resource itself in an ARM template. In reality, a separate authorization server resource (type 'Microsoft.ApiManagement/service/authorizationServers') must be deployed and referenced by the API's authenticationSettings. If that resource is missing or not properly referenced, the deployment fails with a validation error.

How to eliminate wrong answers

Option A is wrong because the serviceUrl is validated for format but does not cause a validation error related to OAuth 2.0 authentication; an invalid URL would produce a different error (e.g., 'Invalid service URL'). Option B is wrong because the dependsOn array using resourceId incorrectly would cause a deployment ordering issue or a 'ResourceNotFound' error, not a validation error specifically about OAuth 2.0 configuration. Option C is wrong because the protocols array does not need to include http; Azure API Management supports https by default, and omitting http is not a validation error—it is a common security best practice.

Full explanation →

119

Matchingmedium

Match each Azure messaging pattern to its description.

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

Concepts

Matches

Point-to-point messaging for decoupling components

Pub/sub messaging with multiple subscribers

Big data streaming ingestion service

Push notification service for mobile apps

Why these pairings

Azure messaging patterns include Queue Storage for simple queuing, Service Bus Topics for pub-sub with filters, Event Grid for event routing, and Event Hubs for streaming. Common confusions involve attributing advanced features like dead-lettering to Queue Storage or mixing IoT scenarios with Service Bus Topics.

Full explanation →

120

Multi-Selecthard

A company stores customer images in Azure Blob Storage. They need to reduce costs by automatically moving blobs that have not been accessed for 30 days to Cool tier, and after 90 days to Archive tier. They also need to delete blobs after one year. Which two Azure features should they implement? (Choose two.)

Select 2 answers

A.Azure Blob Storage lifecycle management policy

B.Azure Blob Storage object replication

C.Azure Blob Storage soft delete

D.Azure Blob Storage immutability policy

E.Azure Blob Storage versioning with a retention policy

AnswersA, E

A lifecycle management policy offers a robust, automated solution for optimizing storage costs by defining rules to transition blobs between access tiers (Hot, Cool, Archive) or delete them based on age or last modification time. This policy directly automates the movement of less frequently accessed data to more cost-effective tiers or its permanent removal, significantly reducing storage expenses without requiring application changes or manual oversight.

Why this answer

Azure Blob Storage lifecycle management policy allows you to define rules to automatically transition blobs to Cool and Archive tiers based on last access time and delete them after one year. Additionally, versioning with a retention policy automatically removes old blob versions after a specified period, preventing unnecessary storage costs from accumulating. Together, these features optimize storage costs by managing both current blobs and their versions.

Exam trap

Candidates often think only lifecycle management is required, but versioning with a retention policy is also needed to handle blob versions that can accumulate and increase costs. Additionally, some may confuse access tier configuration (which is automatically available) as a separate feature, but it is not an option here.

Full explanation →

121

MCQeasy

You need to ensure that data stored in Azure Blob Storage is encrypted at rest using a customer-managed key stored in Azure Key Vault. Which feature should you configure?

A.Azure Storage encryption with customer-managed keys in Azure Key Vault

B.Azure Disk Encryption (ADE) for the storage account

C.Azure Information Protection (AIP) for the blob container

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

AnswerA

Azure Storage encryption with customer-managed keys (CMK) in Azure Key Vault provides robust encryption at rest for blob data, allowing organizations to maintain full control over their encryption keys. By integrating with Azure Key Vault, customers can manage the lifecycle of their keys, including rotation and revocation, ensuring compliance with stringent regulatory requirements. This approach enhances the security posture by separating key management from data storage, giving customers exclusive access to the encryption keys.

Why this answer

Azure Storage encryption with customer-managed keys in Azure Key Vault allows you to use your own encryption keys to protect data at rest in Blob Storage. This feature leverages Azure Storage Service Encryption (SSE) but wraps the data encryption key with a customer-managed key stored in Azure Key Vault, providing full control over key rotation and access policies.

Exam trap

The trap here is that candidates confuse Azure Disk Encryption (ADE) with storage account encryption, or assume that default Microsoft-managed keys satisfy the requirement for customer-managed keys, when in fact you must explicitly configure customer-managed keys in Azure Key Vault.

How to eliminate wrong answers

Option B is wrong because Azure Disk Encryption (ADE) encrypts OS and data disks of virtual machines using BitLocker or DM-Crypt, not the data stored in Azure Blob Storage. Option C is wrong because Azure Information Protection (AIP) classifies and protects documents and emails with labels and rights management, not encryption at rest for blob containers. Option D is wrong because Azure Storage Service Encryption (SSE) with Microsoft-managed keys encrypts data at rest by default, but it does not allow you to use your own customer-managed keys from Azure Key Vault.

Full explanation →

122

MCQhard

You are developing an ASP.NET Core web API that is protected by Microsoft Entra ID. The API must validate incoming access tokens, and you need to ensure that tokens issued for a different API cannot be used. The API is registered in Microsoft Entra ID with an Application ID URI of api://contoso-inventory. Which validation should you implement in the token validation parameters?

A.Validate the audience claim against the Application ID URI api://contoso-inventory and validate the issuer against the tenant's token issuer.

B.Validate only the signature and expiration of the token, and trust any token signed by Microsoft Entra ID.

C.Validate the issuer against the common endpoint that accepts any tenant, and skip audience validation.

D.Validate the audience against the client application's client ID instead of the API's Application ID URI.

AnswerA

Validating the audience against the API's Application ID URI ensures the token was issued for this API and not another. Validating the issuer confirms the token came from the expected Microsoft Entra ID tenant. Together these checks prevent token reuse across APIs and reject tokens from other tenants, which is the correct validation for this scenario.

Why this answer

A protected API must validate both the audience and the issuer. The audience must match the API's Application ID URI so tokens issued for other APIs are rejected, and the issuer must match the tenant so tokens from other tenants are rejected. Signature and expiration checks alone are not sufficient.

Exam trap

The trap here is validating only signature and expiration, which accepts any token from the tenant even if it was issued for a completely different API.

Full explanation →

123

MCQeasy

You are building an Azure Logic App that must call a third-party REST API. The API requires an API key passed as a query parameter. You need to store the API key securely and automatically add it to each request. Which approach should you use?

A.Hardcode the API key in the Logic App definition.

B.Use Azure Key Vault and the Key Vault connector to retrieve the secret dynamically.

C.Store the API key in an Azure Storage Table and reference it from the Logic App.

D.Use an environment variable in the Logic App.

AnswerB

Azure Key Vault is the industry-standard solution for securely storing and managing cryptographic keys, secrets, and certificates. By using the Key Vault connector in a Logic App, the API key is retrieved dynamically at runtime, typically leveraging a Managed Identity assigned to the Logic App for authentication to Key Vault. This approach ensures the secret is never exposed in the Logic App's definition, source control, or logs, facilitating secure rotation and auditing while adhering to robust security and compliance standards.

Why this answer

Azure Key Vault provides a secure, centralized service for storing secrets like API keys, and the Key Vault connector in Logic Apps allows you to dynamically retrieve the secret at runtime without exposing it in the workflow definition. This approach ensures the API key is never hardcoded or stored in plaintext, meeting security best practices for accessing third-party APIs.

Exam trap

The trap here is that candidates may think storing the key in an Azure Storage Table or using environment variables is sufficient, but Azure Key Vault is the only option that provides secure, auditable, and managed secret storage with built-in integration for Logic Apps.

How to eliminate wrong answers

Option A is wrong because hardcoding the API key in the Logic App definition exposes the secret in plaintext within the workflow JSON, making it visible to anyone with access to the definition and violating security best practices. Option C is wrong because storing the API key in an Azure Storage Table does not provide encryption at rest by default (unless client-side encryption is implemented), and the key would be stored as plaintext in a table, which is not a secure secret management solution. Option D is wrong because Logic Apps do not support environment variables; this concept is not applicable to Azure Logic Apps, and even if it were, environment variables are not a secure way to store secrets as they can be exposed in logs or configuration files.

Full explanation →

124

MCQmedium

You are a developer at a global e-commerce company. The company uses Azure Blob Storage to store product images and customer uploads. The application is deployed in the East US region. You need to design a solution that meets the following requirements: - Customers upload images (up to 10 MB) that must be immediately accessible worldwide after upload. - You must minimize egress costs for data transfer from Azure to customers. - The solution must be resilient to regional outages. - You must not use any custom caching logic. Which approach should you implement?

A.Use read-access geo-redundant storage (RA-GRS) and direct customers to the secondary endpoint for reads.

B.Use Premium Block Blob storage in multiple regions and use Traffic Manager for routing.

C.Use Azure CDN from Microsoft with the storage account as origin, and enable geo-replication on the storage account.

D.Use Azure Front Door with caching enabled, and point it to a single Blob Storage account in East US.

AnswerD

Azure Front Door is a global, scalable entry-point that leverages Microsoft's global edge network to deliver web applications and content. With caching enabled, it serves content from edge locations closest to users, significantly reducing latency and egress costs from the origin Blob Storage account. Front Door also inherently provides advanced routing capabilities, including automatic failover to a secondary origin if configured, and Web Application Firewall (WAF) features, making it ideal for global e-commerce scenarios requiring high performance and availability.

Why this answer

Azure Front Door with caching enabled provides global HTTP caching at Microsoft edge nodes, which minimizes egress costs by serving cached content from the edge closest to the user. It also offers built-in regional failover for resilience, and requires no custom caching logic. This meets all requirements: immediate global accessibility, minimized egress costs, regional outage resilience, and no custom caching.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing geo-replication or multiple storage accounts, when a single storage account with a global caching layer like Azure Front Door is simpler, cheaper, and meets all requirements without custom logic.

How to eliminate wrong answers

Option A is wrong because RA-GRS secondary endpoint is read-only and not designed for low-latency global access; it also does not cache content, so egress costs are incurred for every read from the secondary region. Option B is wrong because Premium Block Blob storage in multiple regions with Traffic Manager does not provide caching, leading to higher egress costs and requiring custom logic for replication and failover. Option C is wrong because Azure CDN with geo-replicated storage adds unnecessary complexity and cost; geo-replication is not needed when CDN caching is used, and the CDN itself provides global distribution and resilience.

Full explanation →

125

Multi-Selecthard

Which THREE considerations are important when designing a solution using Azure API Management (APIM) to secure backend APIs?

Select 3 answers

A.Implement rate limiting to prevent abuse

B.Store backend database credentials in APIM policies

C.Use OAuth2 authentication with Azure AD

D.Use JWT validation policies to verify tokens

E.Disable TLS to improve performance

AnswersA, C, D

Implementing rate limiting in API Management (APIM) is crucial for protecting backend services from denial-of-service attacks, excessive consumption, and unintentional abuse. By configuring policies that restrict the number of API calls a client can make within a specified time frame, such as per minute or per hour, it ensures fair usage and maintains the stability and availability of the underlying resources. This prevents a single client from monopolizing resources and impacting other legitimate users.

Why this answer

Option A is correct because implementing rate limiting (via the rate-limit or rate-limit-by-key policy) in APIM protects backend APIs from abuse, throttling excessive requests and mitigating denial-of-service or brute-force scenarios. Option C is correct because using OAuth2 authentication with Azure AD (Microsoft Entra ID) lets APIM validate caller identity through token issuance and scopes, ensuring only authorized clients can reach the backend. Option D is correct because JWT validation policies (validate-jwt) verify token signatures, issuers, audiences, and claims at the gateway, enforcing authentication and authorization before requests reach the backend.

Option B is wrong because storing backend database credentials in APIM policies exposes secrets in policy definitions; credentials should be kept in Azure Key Vault and referenced via named values. Option E is wrong because disabling TLS removes transport encryption, exposing API traffic to interception and violating security best practices.

Exam trap

The trap here is that candidates might think storing credentials in APIM policies is acceptable for simplicity, but Azure explicitly warns against this, and the exam expects knowledge of secure secret management via Key Vault integration.

Full explanation →

126

MCQhard

Refer to the exhibit. You run the Azure CLI command to retrieve a secret from Azure Key Vault. The output shows the secret metadata but not the secret value. The command returns without error. What is the most likely cause?

A.The secret has expired.

B.The user does not have the Key Vault Secrets Officer role.

C.The secret is in a soft-deleted state.

D.The command output only shows metadata by default; you must specify --query "value" to retrieve the secret value.

AnswerD

Azure CLI commands for Key Vault secrets are inherently security-conscious, and by default, "az keyvault secret show" only displays the secret's metadata, such as its ID, attributes, and tags, but intentionally omits the sensitive "value" field. This design choice prevents accidental exposure of secret content in terminal outputs or logs. To explicitly retrieve the actual secret value, users must leverage the "--query \"value\"" parameter, which uses JMESPath to filter the JSON response and extract only the desired sensitive data.

Why this answer

The Azure CLI `az keyvault secret show` command returns the secret metadata (including attributes like id, enabled, created, updated) by default, but does not include the secret value unless you explicitly request it using the `--query "value"` parameter. Since the command completed without error and only metadata was shown, the most likely cause is that the output was not filtered to retrieve the secret value.

Exam trap

The trap here is that candidates assume the command output includes the secret value by default, but Azure CLI intentionally omits it for security, requiring an explicit `--query "value"` to retrieve the actual secret.

How to eliminate wrong answers

Option A is wrong because an expired secret would still return its value if queried; the command would show an error or the secret would be disabled, not silently omit the value. Option B is wrong because the Key Vault Secrets Officer role is required to manage secrets (set, delete, etc.), but reading a secret value requires the Key Vault Secrets User role; a permissions issue would result in a 403 Forbidden error, not a successful command with metadata only. Option C is wrong because a soft-deleted secret would not be returned by the standard `show` command; you would need to use `az keyvault secret show --id <id> --include-soft-deleted` to see it, and the command would not succeed without that flag.

Full explanation →

127

MCQmedium

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

A.Azure Blob Storage lifecycle policy

B.Azure Storage Queue

C.Azure Cache for Redis list only

D.Azure Service Bus topic

AnswerD

Azure Service Bus topics are purpose-built for enterprise-grade publish-subscribe messaging scenarios, enabling a publisher to send messages to a topic that can then be delivered to multiple independent and competing subscriptions. Each subscription acts as a virtual queue, receiving its own copy of the messages published to the topic, and can be configured with filtering rules to selectively receive events. This architecture perfectly supports the requirement for multiple independent applications to consume order events without affecting each other.

Why this answer

Azure Service Bus topics support a publish/subscribe pattern where multiple independent subscribers can each receive a copy of the same message. This decouples the publisher from subscribers, allowing new subscribers to be added later without modifying the publisher. The topic's subscription mechanism ensures each subscriber processes the event independently.

Exam trap

The trap here is that candidates often confuse Azure Storage Queue (point-to-point) with Service Bus topics (pub/sub), mistakenly thinking a queue can serve multiple independent subscribers when it actually requires a single consumer or competing consumers pattern.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage lifecycle policies automate tiering or deletion of blobs based on age, not message delivery to multiple subscribers. Option B is wrong because Azure Storage Queue provides a point-to-point messaging model where a single consumer processes each message, not a broadcast to multiple independent subscribers. Option C is wrong because Azure Cache for Redis list only supports a simple list data structure for point-to-point message queuing (e.g., via LPUSH/BRPOP), lacking the publish/subscribe semantics needed for multiple independent subscribers.

Full explanation →

128

MCQmedium

You are developing a web application that uses Azure Files shares for storing user documents. Users complain that they sometimes see stale file listings. The application uses the SMB protocol. What should you do to ensure the file listing is always current?

A.Set the SMB_DIRECTORY_CACHE_MAX_AGE registry key to 0 on clients.

B.Enable soft delete for the file share.

C.Switch to using REST API for file listings.

D.Disable CDN caching for the storage account.

AnswerA

SMB clients, by default, cache directory listings to improve performance and reduce network traffic. This caching can lead to stale views of the file share if changes are made by other clients or processes. Setting the SMB_DIRECTORY_CACHE_MAX_AGE registry key to 0 on the client machines effectively disables this directory caching. This forces the client to re-query the Azure File Share for the latest directory contents every time, ensuring immediate visibility of new or modified files and folders.

Why this answer

The SMB protocol caches directory listings on the client side to improve performance. By setting the SMB_DIRECTORY_CACHE_MAX_AGE registry key to 0, you disable this caching, forcing the client to always fetch the latest directory listing from the Azure file share. This ensures that users see current file listings instead of stale cached data.

Exam trap

The trap here is that candidates often confuse client-side caching with server-side features like soft delete or CDN, or assume that switching to a different API (REST) will bypass the caching issue, when in fact the root cause is the SMB protocol's built-in directory cache on the client.

How to eliminate wrong answers

Option B is wrong because soft delete is a data protection feature that recovers accidentally deleted files; it does not affect client-side caching of directory listings. Option C is wrong because switching to the REST API for file listings does not change the client-side SMB caching behavior—the issue is caused by the SMB protocol's directory cache, not the API used. Option D is wrong because CDN caching is for static content delivery and is not involved in SMB-based file share listings; disabling it would not resolve client-side SMB caching.

Full explanation →

129

MCQeasy

You are using Azure Blob Storage to store large media files. Clients upload files directly to the storage account using SAS tokens. You need to ensure that the SAS token expires 1 hour after creation. Which parameter should you set when generating the SAS token?

A.SignedProtocol (spr)

B.IP range (sip)

C.SignedExpiry (se)

D.SignedStart (st)

AnswerC

The SignedExpiry (se) parameter is the fundamental and correct mechanism for defining the lifespan of an Azure Storage Shared Access Signature (SAS) token. It specifies the exact Coordinated Universal Time (UTC) date and time at which the SAS token will cease to be valid. Once this time is reached, any subsequent attempts to use the token for accessing storage resources will be met with an authorization failure, thereby enforcing time-limited access and adhering to security best practices.

Why this answer

The SignedExpiry (se) parameter explicitly defines the expiration time of a SAS token. When generating a SAS token for Azure Blob Storage, setting 'se' to a UTC time 1 hour from creation ensures the token is valid only for that duration, meeting the requirement that clients can upload files directly using the SAS token for exactly 1 hour.

Exam trap

The trap here is that candidates confuse SignedStart (st) with SignedExpiry (se), mistakenly thinking setting a start time alone controls the token's lifetime, when in fact without an expiry, the token remains valid indefinitely.

How to eliminate wrong answers

Option A is wrong because SignedProtocol (spr) restricts the protocol (HTTPS or HTTP) used for requests, not the token's validity period. Option B is wrong because IP range (sip) limits the source IP addresses that can use the SAS token, not its expiration. Option D is wrong because SignedStart (st) defines when the SAS token becomes valid, not when it expires; setting only 'st' without 'se' would make the token valid indefinitely from that start time.

Full explanation →

130

MCQmedium

You have an Azure Function app that uses an Event Hubs trigger. The function processes events in batches. You notice that some events are being processed more than once. Which setting should you adjust to minimize duplicate processing?

A.Increase the maxRetries per event

B.Enable checkpointing in the function code

C.Increase the event batch size

D.Decrease the prefetch count

AnswerB

Enabling checkpointing in the function code is crucial for ensuring "at-least-once" processing and preventing duplicate event reprocessing. Checkpointing involves recording the offset of the last successfully processed event for each partition in a durable store, typically Azure Storage. When a function instance restarts, scales out, or a new instance takes over a partition, it retrieves the last checkpointed offset and begins processing events from that point, effectively preventing the re-delivery of already processed events. This mechanism is fundamental for managing distributed Event Hubs consumers.

Why this answer

Checkpointing in Azure Event Hubs stores the offset of the last successfully processed event in a durable store (e.g., Azure Blob Storage). When the function restarts or scales, it resumes from that checkpoint, preventing reprocessing of already-handled events. Without checkpointing, the default behavior may start from the earliest offset or use the `latest` position, leading to duplicate processing.

Exam trap

The trap here is that candidates often confuse retry policies or batch sizes with the checkpointing mechanism, not realizing that duplicate processing in Event Hubs is typically caused by missing or infrequent checkpointing, not by event handling failures.

How to eliminate wrong answers

Option A is wrong because increasing `maxRetries` per event only controls how many times a failed event is retried, not the root cause of duplicate processing from checkpointing gaps. Option C is wrong because increasing the event batch size processes more events per invocation but does not affect whether events are reprocessed after a restart or scaling event. Option D is wrong because decreasing the prefetch count reduces the number of events buffered locally, which can reduce the chance of duplicates from a crash during processing, but it does not address the fundamental need for checkpointing to persist progress across function restarts.

Full explanation →

131

MCQeasy

Your application stores user profile images in Azure Blob Storage. You need to serve these images to users with low latency from a domain name that you own. What should you use?

A.Enable static website hosting and configure a custom domain directly on the storage account.

B.Create an Azure CDN endpoint with a custom domain and point it to the blob container.

C.Configure a custom domain in Azure DNS and point it to the storage account endpoint.

D.Use Azure Front Door with a custom domain.

AnswerB

Azure CDN is specifically engineered to cache static content, such as user profile images, at strategically located Points of Presence (PoPs) across the globe. When a user requests an image, it is served from the closest available edge location, dramatically reducing network latency and improving load times for global users. Furthermore, a custom domain can be seamlessly integrated with the CDN endpoint, ensuring a consistent and branded user experience.

Why this answer

Azure CDN is the best choice for serving static images from Blob Storage with low latency using a custom domain. While Azure Front Door can also serve content with low latency, it is primarily a global load balancer and application acceleration service, and for simple image serving from blob storage, CDN is more cost-effective and directly designed for caching static content. Option A (static website hosting) does not provide edge caching for low latency.

Option C (Azure DNS) only resolves the domain; it doesn't provide caching.

Exam trap

The trap here is that candidates often confuse Azure CDN with Azure Front Door or static website hosting, assuming any custom domain on a storage account automatically provides low latency, but only CDN adds the necessary edge caching layer for static blob content.

How to eliminate wrong answers

Option A is wrong because enabling static website hosting on a storage account serves static content (e.g., HTML, JS) but does not inherently provide low-latency edge caching; it only allows a custom domain for the static website endpoint, not for blob containers. Option C is wrong because pointing a custom domain in Azure DNS directly to the storage account endpoint (e.g., via a CNAME record) bypasses any caching layer, resulting in higher latency for users far from the storage account's primary region. Option D is wrong because Azure Front Door is a global load balancer and application delivery service optimized for HTTP(S) traffic with advanced routing and WAF, which is overkill for simple static image serving and incurs higher cost and complexity compared to CDN.

Full explanation →

132

Multi-Selecteasy

Which TWO Azure services can be used to implement a publish-subscribe messaging pattern?

Select 2 answers

A.Azure Queue Storage

B.Azure Event Grid

C.Azure Notification Hubs

D.Azure Service Bus Topics

E.Azure Event Hubs

AnswersB, D

Azure Event Grid implements publish-subscribe through event topics and subscriptions, pushing events to subscribers via webhooks or handlers. It satisfies the stem's requirement by decoupling publishers from consumers, using a push delivery model with filtering, unlike pull-based queues. This makes it a valid choice for the pub-sub pattern.

Why this answer

Azure Event Grid (B) is correct because it is a fully managed event-routing service built on a publish-subscribe model, where publishers emit events to topics and subscribers receive them via event subscriptions with filters and push delivery. Azure Service Bus Topics (D) is correct because a topic implements the pub/sub pattern: senders publish messages to the topic and multiple subscriptions (each with its own filters and rules) receive independent copies, unlike a Service Bus Queue which is point-to-point. Azure Queue Storage (A) is not correct because it provides simple point-to-point queue messaging where each message is consumed by a single receiver, not broadcast to multiple subscribers.

Azure Notification Hubs (C) is not correct because it is a push-notification broadcast/engagement service for mobile devices (targeting tags, platforms), not a general pub/sub messaging broker. Azure Event Hubs (E) is not correct because it is a high-throughput event-streaming ingestion service based on partitions and consumer groups, where consumers pull from the stream rather than receiving independent subscription copies as in pub/sub.

Exam trap

The trap here is confusing Azure Event Hubs (a telemetry ingestion service) with a publish-subscribe broker, since both support multiple consumers, but Event Hubs uses consumer groups for partitioned stream processing, not topic subscriptions with independent message copies.

Full explanation →

133

Multi-Selecteasy

Which TWO Azure services can be used to trigger an Azure Function in response to a new blob being added to an Azure Storage account? (Choose two.)

Select 2 answers

A.HTTP trigger

B.Queue trigger

C.Timer trigger

D.Azure Blob Storage trigger

E.Azure Event Grid subscription

AnswersD, E

The Azure Blob Storage trigger is a native binding in Azure Functions that automatically executes a function whenever a new or updated blob is detected in a specified container within an Azure Storage account. This built-in integration directly monitors the storage account for changes, providing a straightforward and efficient way to process blob events without requiring intermediary services. The function receives the blob content or metadata as input, enabling immediate processing upon creation or modification.

Why this answer

The Azure Blob Storage trigger is specifically designed to execute a function whenever a new or updated blob is detected in a storage container. It uses a polling mechanism to monitor the container and invokes the function with the blob's content and metadata as input. Option E is correct because an Azure Event Grid subscription can be configured to listen for the 'Microsoft.Storage.BlobCreated' event and route it to an Azure Function as an event-driven trigger, providing near-real-time, push-based notification without polling.

Exam trap

The trap here is that candidates often confuse the Blob Storage trigger (which directly monitors blob containers) with Event Grid subscriptions (which require explicit configuration), or mistakenly think an HTTP trigger can be used by having a client poll for new blobs, but the question specifically asks for services that trigger the function in response to a new blob being added.

Full explanation →

134

Multi-Selecthard

You are deploying a containerized application to Azure App Service. The application requires a custom startup command and must pull the image from a private Azure Container Registry. You need to ensure the deployment succeeds and the container starts correctly. (Choose two.)

Select 2 answers

A.Configure the WEBSITES_PORT application setting to the port that the container listens on.

B.Set the DOCKER_CUSTOM_IMAGE_NAME application setting to the full image name and tag.

C.Set the startup command in the App Service configuration to override the container's default entrypoint.

D.Set the DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME, and DOCKER_REGISTRY_SERVER_PASSWORD application settings with the ACR credentials.

E.Enable the 'Always On' setting to keep the container running continuously.

AnswersC, D

App Service allows you to specify a custom startup command that overrides the container's default entrypoint. This is configured in the App Service's configuration settings, often via the Azure portal or CLI. It ensures the container starts with the required command, which is necessary when the default entrypoint does not match the application's needs. This directly addresses the custom startup command requirement.

Why this answer

To deploy a container from a private Azure Container Registry, you must supply registry credentials via the DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME, and DOCKER_REGISTRY_SERVER_PASSWORD application settings. To use a custom startup command, you must set the startup command in the App Service configuration. Together, these two actions ensure the image can be pulled and the container starts with the required command.

Exam trap

The trap here is focusing on port or image name settings while overlooking that private registry access requires explicit credentials and that a custom startup command must be configured separately.

Full explanation →

135

Multi-Selectmedium

Which FOUR features are supported by Azure Container Apps? (Select four.)

Select 4 answers

A.Virtual network (VNet) injection.

B.Mounting Azure NetApp Files volumes.

C.Event-driven scaling using KEDA.

D.Blue-green deployment with revisions.

E.Integration with Dapr (Distributed Application Runtime).

AnswersA, C, D, E

Azure Container Apps environments are deployed into a managed virtual network by default, or can be deployed into an existing VNet using custom VNet integration. However, "VNet injection" as a direct, granular control over individual container app network interfaces within a pre-existing VNet is not the operational model. Instead, the entire Container Apps environment is integrated into a subnet, providing network isolation and connectivity to other VNet resources, but not direct injection at the app level.

Why this answer

Option A is correct because Azure Container Apps supports VNet injection, allowing the environment to be deployed into a delegated subnet so apps can privately reach resources such as Azure SQL or Storage via private endpoints. Option C is correct because Azure Container Apps natively integrates KEDA scalers, enabling event-driven scaling based on sources like Service Bus queues, Event Hubs, or HTTP traffic. Option D is correct because Container Apps uses immutable revisions, which support blue-green (and canary) deployment patterns by splitting traffic between revisions and shifting weight after validation.

Option E is correct because Container Apps has built-in Dapr integration, exposing sidecars for service invocation, pub/sub, state management, and bindings without extra infrastructure. Option B is not supported: Azure Container Apps does not natively mount Azure NetApp Files volumes; persistent storage is provided via Azure Files mounts or ephemeral storage, while Azure NetApp Files is used with services like Azure Kubernetes Service or Azure VMware Solution.

Exam trap

The trap here is that candidates might confuse specific advanced networking features of AKS with Container Apps. While Container Apps abstracts much of the underlying Kubernetes complexity, it *does* support VNet integration for deploying the environment into an existing VNet. Azure NetApp Files, however, is not directly supported for volume mounting in Container Apps.

Full explanation →

136

MCQhard

Refer to the exhibit. You run the Azure CLI command to list blobs in a container that are larger than 1 MB. The command returns no results even though you know there are blobs larger than 1 MB. What is the most likely cause?

A.The JMESPath query uses backticks incorrectly

B.The storage account has hierarchical namespace enabled (Azure Data Lake Storage Gen2)

C.The --container-name parameter is case-sensitive

D.The --account-name parameter is incorrect

AnswerB

When a storage account has hierarchical namespace enabled, effectively becoming Azure Data Lake Storage Gen2, the JSON output schema for `az storage blob list` changes significantly. Unlike standard Blob Storage, the `properties` object, or specifically `properties.creationTime`, may not exist or be structured differently within the returned JSON for each item. Consequently, the JMESPath query `properties.creationTime` will fail to find a match in the altered schema, resulting in an empty list even if blobs are present.

Why this answer

The Azure CLI command uses the `az storage blob list` command with a JMESPath query to filter blobs larger than 1 MB. However, when a storage account has hierarchical namespace enabled (Azure Data Lake Storage Gen2), the blob listing API returns directory entries and file entries in a flat list, but the `az storage blob list` command does not support the hierarchical namespace by default. The command may return no results because the underlying REST API (Blob Service REST API) does not properly enumerate blobs in a Data Lake Storage Gen2 account without using the `--use-hierarchical-namespace` flag or the `az storage fs file list` command instead.

This is a known limitation where the standard blob list operation fails to list files in a hierarchical namespace-enabled account.

Exam trap

Microsoft often tests the distinction between Azure Blob Storage and Azure Data Lake Storage Gen2, specifically that the `az storage blob list` command does not work as expected in hierarchical namespace accounts, leading candidates to overlook the storage account type as the root cause.

How to eliminate wrong answers

Option A is wrong because backticks in JMESPath queries are used correctly in the command to denote a comparison value; the issue is not with backtick syntax but with the storage account type. Option C is wrong because the `--container-name` parameter in Azure CLI is not case-sensitive; container names are lowercase by convention but the CLI handles them case-insensitively. Option D is wrong because if the `--account-name` parameter were incorrect, the command would fail with an authentication or resource-not-found error, not return an empty result set.

Full explanation →

137

MCQmedium

Your web app running on Azure App Service requires access to a storage account using managed identity. You enable the system-assigned managed identity on the App Service and assign the 'Storage Blob Data Contributor' role at the storage account scope. However, the app receives 403 errors when trying to read blobs. What is the most likely cause?

A.The managed identity token is being requested with the wrong audience. You need to specify 'https://storage.azure.com' as the resource.

B.Managed identity is not supported for Azure App Service; use a connection string instead.

C.The role assignment has not propagated yet; wait 30 minutes.

D.The storage account has a firewall rule that blocks the App Service outbound IPs.

AnswerA

When an Azure App Service uses a managed identity to access another Azure service, it requests an OAuth 2.0 access token from Azure Active Directory. Each Azure service exposes a specific 'resource' URI, which acts as the audience for the token. For Azure Storage, this required audience is 'https://storage.azure.com', not the default 'https://management.azure.com' used for Azure Resource Manager operations. Requesting a token with the incorrect audience will result in an authorization failure, typically a 403 Forbidden error, because the target service will reject the token as not being issued for its intended use.

Why this answer

When using managed identity with Azure Storage, the access token must be requested with the correct audience (resource). For Azure Blob Storage, the audience must be 'https://storage.azure.com'. If the app requests the token with a different audience (e.g., the default Azure Resource Manager endpoint 'https://management.azure.com'), the token will be rejected by the storage service, resulting in a 403 error despite the role assignment being in place.

Exam trap

The trap here is that candidates assume the role assignment alone is sufficient, overlooking that the token's audience must match the target service (storage vs. management), which is a subtle but critical detail in managed identity authentication flows.

How to eliminate wrong answers

Option B is wrong because managed identity is fully supported for Azure App Service; it is a recommended best practice over connection strings for security. Option C is wrong because role assignments for managed identities typically propagate within a few minutes, not 30 minutes; waiting 30 minutes is unnecessary and not the cause of the 403 error. Option D is wrong because firewall rules blocking outbound IPs would cause a network-level failure (e.g., timeout or connection refused), not a 403 authorization error; a 403 indicates the request reached the storage account but was denied due to invalid credentials or permissions.

Full explanation →

138

MCQmedium

You are deploying a sensitive configuration to Azure Container Instances. The configuration must be encrypted at rest and not visible in the container logs. What should you use?

A.Environment variables in the container group

B.Azure Key Vault with managed identity and secret volumes

C.Azure Files volume mounted into the container

D.ConfigMap in a Kubernetes cluster

AnswerB

Azure Key Vault provides a secure, centralized store for secrets, encrypting them at rest and in transit. A managed identity grants the Azure Container Instance (ACI) secure, authenticated access to Key Vault without needing hardcoded credentials. By mounting secrets as volumes, they are injected directly into the container's filesystem, making them accessible to the application while avoiding exposure in environment variables or logs, thus enhancing security posture.

Why this answer

Azure Key Vault with managed identity and secret volumes is the correct choice because it allows you to mount secrets as files into the container without exposing them in environment variables or logs. The secrets are encrypted at rest in Key Vault and are only accessible via a managed identity assigned to the container group, ensuring the configuration remains secure and invisible in container logs.

Exam trap

The trap here is that candidates often choose environment variables (Option A) because they are easy to implement, but they overlook the requirement that the configuration must not be visible in container logs, which environment variables inherently violate.

How to eliminate wrong answers

Option A is wrong because environment variables in the container group are visible in the container logs and can be exposed through the Azure portal or CLI, failing the requirement to not be visible in logs. Option C is wrong because Azure Files volumes are not encrypted at rest by default (unless using Azure Storage Service Encryption, but the configuration data would still be visible in the container's file system and potentially in logs if accessed). Option D is wrong because ConfigMap is a Kubernetes concept and does not apply to Azure Container Instances, which is a serverless container service without Kubernetes orchestration.

Full explanation →

139

Multi-Selectmedium

You need to design a solution to securely store and access secrets (e.g., API keys, connection strings) for a set of Azure Functions. The solution must minimize administrative overhead and avoid storing secrets in code or configuration files. Which THREE should you include? (Choose three.)

Select 3 answers

A.Store secrets in Azure Key Vault

B.Store secrets in application settings as plain text

C.Use Azure App Configuration for feature flags

D.Assign a managed identity to each function app

E.Enable Key Vault soft-delete and purge protection

AnswersA, D, E

Azure Key Vault is the industry-standard, highly secure solution for centrally storing and managing cryptographic keys, certificates, and sensitive application secrets like API keys and database connection strings. It provides robust protection through FIPS 140-2 Level 2 validated Hardware Security Modules (HSMs) for cryptographic operations, ensuring secrets are encrypted at rest and in transit. Access to these secrets is meticulously controlled via Azure Role-Based Access Control (RBAC) or Key Vault access policies, enabling fine-grained permissions and comprehensive auditing.

Why this answer

Azure Key Vault is the correct service for securely storing secrets like API keys and connection strings because it provides centralized, hardware-backed secret management with access policies and auditing. By referencing Key Vault secrets from Azure Functions via a managed identity, you avoid storing secrets in code or configuration files, which aligns with the requirement to minimize administrative overhead and eliminate plaintext secrets. Enabling Key Vault soft-delete and purge protection is a critical security best practice to prevent accidental or malicious permanent deletion of secrets, ensuring data resilience and compliance, which is essential for a robust 'secure solution'.

Exam trap

The trap here is that candidates often confuse Azure App Configuration with a secret store, but App Configuration is for feature flags and non-sensitive configuration, while Key Vault is the dedicated service for secrets, and managed identities are required to access it securely without storing credentials.

Full explanation →

140

MCQeasy

Your company stores sensitive financial documents in Azure Blob Storage. You need to ensure that only authorized users can access the blobs, and you must avoid exposing storage account keys. You want to generate time-limited URLs that grant access to specific blobs. What should you use?

A.Shared Access Signatures (SAS)

B.Storage account access keys

C.Azure role-based access control (RBAC)

D.Managed identities for Azure resources

AnswerA

A SAS is a signed token appended to a blob URL, granting scoped, time-limited permissions without revealing the account key. Delegating access this way satisfies the constraint that only authorised users reach specific blobs while storage account keys stay unexposed.

Why this answer

Shared Access Signatures (SAS) are the correct choice because they allow you to delegate access to specific blobs with granular permissions (read, write, delete) and enforce a time-limited validity period, all without exposing the storage account keys. This directly meets the requirement of generating time-limited URLs for authorized access while keeping the account keys secure.

Exam trap

Azure exam often tests the misconception that RBAC or managed identities can generate time-limited URLs, but they cannot—only SAS tokens provide the ability to create scoped, time-bound URLs without exposing account keys.

How to eliminate wrong answers

Option B is wrong because storage account access keys provide full administrative access to the entire storage account, cannot be scoped to specific blobs, and cannot be time-limited, which violates the requirement to avoid exposing keys and to grant granular, temporary access. Option C is wrong because Azure RBAC controls access at the management plane or data plane via Azure AD identities, but it does not generate time-limited URLs; it requires the caller to authenticate with Azure AD, which is not suitable for distributing short-lived, anonymous URLs to specific blobs. Option D is wrong because managed identities provide an Azure AD identity for Azure resources to authenticate to storage, but they do not generate time-limited URLs; they are used for server-to-server authentication without credential management, not for issuing time-bound access tokens to external users.

Full explanation →

141

MCQmedium

You deploy the ARM template shown in the exhibit. After deployment, you need to change the replication to geo-redundant storage (GRS) with read access (RA-GRS). What should you do?

A.Redeploy the same template; Standard_GRS already provides geo-redundancy.

B.Set the 'supportsHttpsTrafficOnly' property to false.

C.Change the 'accessTier' to 'Cool'.

D.Update the 'sku.name' to 'Standard_RAGRS' and redeploy.

AnswerD

To enable read access to a secondary region for geo-redundant storage, the storage account SKU must be specifically configured for this capability. 'Standard_RAGRS' (Read-Access Geo-Redundant Storage) is the precise SKU designed to provide this functionality. It replicates data to a secondary region and exposes an additional, separate endpoint, allowing applications to read data directly from the secondary location even when the primary region is fully operational, which is essential for high availability and disaster recovery architectures.

Why this answer

The ARM template initially deploys a storage account with 'Standard_GRS' (geo-redundant storage), but to enable read access to the secondary region (RA-GRS), you must change the SKU name to 'Standard_RAGRS'. Redeploying the template with this updated property updates the replication setting to RA-GRS, which provides both geo-redundancy and read access to the secondary endpoint.

Exam trap

The trap here is that candidates confuse 'Standard_GRS' (which already provides geo-redundancy) with 'Standard_RAGRS', not realizing that read access to the secondary region requires an explicit SKU change, not just a property toggle.

How to eliminate wrong answers

Option A is wrong because 'Standard_GRS' provides geo-redundancy but does not allow read access to the secondary region; you need 'Standard_RAGRS' for read access. Option B is wrong because the 'supportsHttpsTrafficOnly' property controls whether HTTPS is required for storage account access, not replication type. Option C is wrong because changing the 'accessTier' to 'Cool' affects blob storage pricing and performance, not the replication strategy.

Full explanation →

142

MCQmedium

Your company develops a microservices application deployed to Azure Kubernetes Service (AKS). You need to enable secure communication between services using managed identities. Which Azure service should you use to manage the identities and access control for the pods?

A.Azure Service Bus

B.Microsoft Entra Workload ID

C.Azure Key Vault

D.Azure Policy

AnswerB

Microsoft Entra Workload ID for Kubernetes enables Kubernetes pods to authenticate to Azure resources using a Microsoft Entra ID application and service principal, without needing to manage secrets. It leverages Kubernetes service accounts and federated identity credentials to allow pods to obtain tokens directly from Microsoft Entra ID. This facilitates secure, fine-grained access control for microservices within an AKS cluster, eliminating the need for manual secret rotation and enhancing the security posture.

Why this answer

Microsoft Entra Workload ID (formerly Azure AD Workload Identity) is the correct choice because it integrates with Kubernetes to automatically project an Azure AD-managed identity into each pod. This allows pods to authenticate to Azure resources (e.g., Key Vault, Storage) without managing secrets, using federated identity credentials that map a Kubernetes service account to an Azure AD application or user-assigned managed identity.

Exam trap

The trap here is that candidates often confuse Azure Key Vault (a secret store) with identity management, but Key Vault cannot authenticate pods—it requires an identity service like Workload ID to grant access to its secrets.

How to eliminate wrong answers

Option A is wrong because Azure Service Bus is a message broker for decoupling applications, not an identity or access control service for pods. Option C is wrong because Azure Key Vault stores secrets, keys, and certificates but does not manage identities or provide pod-level authentication; it relies on an identity service like Workload ID to grant access. Option D is wrong because Azure Policy enforces compliance rules on Azure resources (e.g., requiring TLS) but cannot assign or manage managed identities for AKS pods.

Full explanation →

143

MCQeasy

Your web app needs to authenticate users with Microsoft Entra ID (formerly Azure AD). Which OAuth 2.0 flow should you use for a single-page application (SPA) that uses MSAL.js?

A.Client credentials flow

B.Authorization code flow with PKCE

C.Implicit flow

D.Resource owner password credentials flow

AnswerB

The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended and most secure method for authenticating users in public clients like single-page applications (SPAs) and mobile apps. This flow prevents code interception attacks by requiring the client to generate a secret `code_verifier` and a `code_challenge` that are exchanged during the authorization and token request steps, respectively. This ensures that only the legitimate client that initiated the authorization request can successfully exchange the authorization code for access and refresh tokens, providing robust security without exposing client secrets.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth 2.0 flow for single-page applications (SPAs) using MSAL.js because it provides a secure way to obtain tokens without exposing the client secret. PKCE ensures that even if the authorization code is intercepted, it cannot be exchanged for tokens without the original code verifier, mitigating authorization code injection attacks. Microsoft deprecated the implicit flow for SPAs in favor of this flow due to its enhanced security.

Exam trap

The trap here is that candidates often confuse the deprecated implicit flow (Option C) as the correct answer for SPAs, but Microsoft now mandates the authorization code flow with PKCE for all new SPA applications using MSAL.js.

How to eliminate wrong answers

Option A is wrong because the client credentials flow is designed for server-to-server (daemon) applications that need to authenticate without a user context, not for SPAs that require user authentication. Option C is wrong because the implicit flow was the original OAuth 2.0 flow for SPAs but is now deprecated by Microsoft due to security vulnerabilities, such as access token leakage in the browser history and lack of PKCE support. Option D is wrong because the resource owner password credentials flow requires the user to provide their username and password directly to the application, which is highly insecure and violates the principles of delegated authentication; it is only recommended for legacy or highly trusted scenarios.

Full explanation →

144

MCQmedium

An app must store relational state and perform transactions across multiple tables with T-SQL support. Which Azure data service should the developer choose?

A.Azure Queue Storage

B.Azure SQL Database

C.Azure Cache for Redis

D.Azure Blob Storage

AnswerB

Azure SQL Database is a fully managed relational database service that natively supports structured data with defined schemas, T-SQL querying, and robust ACID (Atomicity, Consistency, Isolation, Durability) transactions. It is specifically engineered to maintain data integrity and consistency across complex operations, making it the ideal choice for applications requiring relational state and transactional guarantees.

Why this answer

Azure SQL Database is a fully managed relational database service that supports T-SQL and ACID transactions across multiple tables, making it the correct choice for storing relational state and performing transactional operations. It provides built-in high availability, automatic backups, and elastic scaling, which are essential for enterprise applications requiring consistent, multi-table transactions.

Exam trap

The trap here is that candidates often confuse Azure SQL Database with Azure Storage services (Blob, Queue, Cache) because all fall under the 'Azure storage' domain, but only Azure SQL Database provides relational, T-SQL-based transactional capabilities.

How to eliminate wrong answers

Option A is wrong because Azure Queue Storage is a message queuing service for asynchronous communication, not a relational database; it does not support T-SQL or multi-table transactions. Option C is wrong because Azure Cache for Redis is an in-memory data store used for caching and session state, lacking relational capabilities, T-SQL support, and transactional integrity across tables. Option D is wrong because Azure Blob Storage is an object storage service for unstructured data (blobs), not a relational database; it cannot execute T-SQL queries or enforce ACID transactions across tables.

Full explanation →

145

MCQmedium

Your company uses Azure App Service to host a web application that requires periodic database maintenance. The maintenance tasks are time-consuming and must run outside of peak hours. You need to schedule these tasks to run automatically at 2:00 AM every Sunday. The tasks should be implemented as an Azure Function that runs in the same App Service plan to reduce costs. What should you do?

A.Deploy the maintenance code as an Azure Function in the Consumption plan and configure a timer trigger.

B.Create a separate Azure Function App in the same App Service plan and configure a timer trigger.

C.Add a WebJob to the App Service that uses a scheduled trigger to run the maintenance code.

D.Use Azure Logic Apps with a recurrence trigger to call the web application's maintenance endpoint.

AnswerB

Creating a separate Azure Function App, even within the same App Service plan, introduces an additional logical application resource. While sharing the App Service plan reduces infrastructure costs, this approach creates a distinct management and deployment unit for the function. The scenario requires implementing *an* Azure Function to run alongside an existing web application, implying integration or a single function within the existing application's context. This option is tempting because Azure Function Apps are the standard hosting unit for functions, and they can indeed share an App Service plan, making it the correct choice when a new, dedicated logical application for functions is desired.

Why this answer

Creating a separate Azure Function App and hosting it on the *same existing dedicated App Service Plan* (e.g., Basic, Standard, Premium) allows the Azure Function to run using the existing compute resources. This directly meets the requirement to run in the 'same App Service plan to reduce costs' by leveraging existing infrastructure. A timer trigger is the appropriate mechanism to schedule the function to run automatically at 2:00 AM every Sunday. This option also fulfills the requirement that the tasks 'should be implemented as an Azure Function'.

Option A is incorrect because deploying to a Consumption plan would create a *separate* Function App resource with a serverless billing model, which does not align with the 'in the same App Service plan' requirement for cost reduction in the context of an existing dedicated App Service plan.

Option C is incorrect because, while WebJobs are suitable for background tasks and can share an App Service plan, they are not Azure Functions. The STEM explicitly requires the tasks to be implemented as an Azure Function.

Option D is incorrect because Azure Logic Apps are a separate service, incurring separate costs, and do not fulfill the requirement to implement the task 'as an Azure Function' and run it 'in the same App Service plan' for cost reduction.

Exam trap

Candidates might overlook the specific requirement to implement the task 'as an Azure Function' and instead choose a WebJob, which is a different technology for background tasks. Another trap is confusing the cost implications of deploying an Azure Function to a Consumption plan (which is a separate serverless billing model) versus deploying it to an existing dedicated App Service Plan (which shares resources and costs with other apps on that plan).

How to eliminate wrong answers

Option A is wrong because deploying the Azure Function in the Consumption plan would incur separate costs and does not run in the same App Service plan, violating the cost-reduction requirement. Option B is wrong because creating a separate Azure Function App in the same App Service plan still requires a separate Function App resource, which adds management overhead and does not leverage the existing App Service's built-in WebJob feature for cost efficiency. Option D is wrong because Azure Logic Apps is a separate service with its own pricing model, and using it to call a maintenance endpoint would introduce additional costs and complexity, not reducing costs as required.

Full explanation →

146

MCQeasy

You are developing an application that needs to store and retrieve large binary objects (up to 5 TB) in Azure Blob Storage. The application requires the ability to access data from any URL via HTTP/HTTPS. Which Blob Storage access tier should you use?

A.Hot

B.Archive

C.Cool

D.Premium

AnswerA

The Hot storage tier is specifically designed for frequently accessed data that requires instant retrieval capabilities via HTTP/HTTPS. It offers the lowest access costs and highest availability among the standard tiers, making it ideal for active datasets and applications where immediate data access is critical for user experience or operational efficiency. While its storage cost per GB is higher than Cool or Archive, its low transaction costs make it the most cost-effective choice for high-access patterns.

Why this answer

The Hot access tier is optimized for frequent read and write access to data, supports objects up to 5 TB, and allows access via HTTP/HTTPS from any URL. It is the only tier that combines low-latency access, high throughput, and public internet accessibility without requiring rehydration or special permissions, making it suitable for general-purpose blob storage scenarios.

Exam trap

The trap here is that candidates may confuse the Archive tier's low storage cost with suitability for large objects, forgetting that Archive requires manual rehydration (which can take hours) before data can be accessed via HTTP/HTTPS, making it incompatible with the requirement for immediate URL-based access.

How to eliminate wrong answers

Option B (Archive) is wrong because it is designed for long-term cold storage with retrieval times of up to 15 hours, and data must be rehydrated to a Hot or Cool tier before it can be accessed via HTTP/HTTPS, making it unsuitable for immediate URL-based access. Option C (Cool) is wrong because while it supports HTTP/HTTPS access, it is optimized for infrequently accessed data with higher access costs and lower availability guarantees compared to Hot, and it does not meet the requirement for frequent or large-scale binary object access. Option D (Premium) is wrong because it is a block blob storage tier optimized for low-latency and high transaction rates using SSD-backed hardware, but it is not designed for general-purpose large binary objects up to 5 TB and incurs significantly higher costs without providing any benefit for standard HTTP/HTTPS access patterns.

Full explanation →

147

MCQhard

Your Azure Function app needs to call a third-party REST API that requires OAuth 2.0 client credentials flow. The API expects a JWT token signed with a client certificate. You want to store the certificate securely and rotate it automatically. Which Azure service and feature should you use?

A.Store the certificate in Azure Cosmos DB as a document, and retrieve it using the Cosmos DB SDK.

B.Store the certificate in Azure Key Vault with automatic rotation enabled, and use Managed Identity to access it from the Function app.

C.Store the certificate in Azure App Service as a TLS/SSL binding, and use the WEBSITE_LOAD_CERTIFICATES app setting.

D.Store the certificate in Azure Storage as a blob, and reference it from the Function app using a SAS token.

AnswerB

Azure Key Vault is specifically designed as a secure, centralized store for cryptographic keys, secrets, and certificates, offering robust access control, versioning, and auditing. Enabling automatic rotation within Key Vault ensures certificates are refreshed before expiration, minimizing operational overhead and security risks associated with manual management. Using Managed Identity allows the Azure Function App to authenticate directly with Key Vault without needing to manage any connection strings or secrets, adhering to the principle of least privilege and significantly enhancing overall security. This combination represents the recommended best practice for secure certificate handling and access in Azure.

Why this answer

Azure Key Vault provides secure storage for client certificates with built-in automatic rotation capabilities, and using Managed Identity allows the Azure Function app to authenticate to Key Vault without storing any secrets in code or configuration. This combination satisfies the OAuth 2.0 client credentials flow requirement by enabling the Function app to retrieve the certificate dynamically and sign the JWT token.

Exam trap

The trap here is that candidates often confuse inbound TLS/SSL certificate binding (Option C) with outbound client certificate usage, mistakenly thinking the WEBSITE_LOAD_CERTIFICATES setting provides programmatic access to certificates for signing outbound requests.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB is a NoSQL database designed for transactional and analytical workloads, not for secure secret storage; it lacks automatic rotation and access control features like Managed Identity integration. Option C is wrong because Azure App Service TLS/SSL bindings are intended for securing inbound HTTPS traffic to the app, not for storing client certificates used to authenticate outbound calls to third-party APIs; the WEBSITE_LOAD_CERTIFICATES setting loads certificates for inbound TLS termination, not for programmatic signing. Option D is wrong because Azure Storage blobs do not support automatic certificate rotation and using a SAS token to access the blob introduces a long-lived secret that must be managed separately, defeating the purpose of secure, automated rotation.

Full explanation →

148

MCQmedium

You are developing a serverless API using Azure Functions. The API should only be accessible from a specific virtual network. You need to configure network security. What should you do?

A.Place the Functions in Azure API Management and configure IP restrictions.

B.Configure IP address restrictions on the Function App to allow only the VNet's public IP range.

C.Deploy the Function App in a Premium plan and configure VNet integration, then use a Network Security Group to restrict traffic.

D.Configure a private endpoint for the Function App and disable public access.

AnswerD

Configuring a private endpoint for the Function App primarily provides secure *inbound* access to the Function App from within a Virtual Network (VNet), making the service appear as if it's part of the VNet and disabling public access. However, a private endpoint does not inherently enable the Function App to establish *outbound* connections to other resources located *within* that VNet. VNet integration is the specific feature designed for a Function App to access resources inside a VNet.

Why this answer

To ensure the Azure Function API is *only* accessible from a specific virtual network, the most secure and direct approach is to configure a private endpoint for the Function App within that VNet. A private endpoint assigns a private IP address from your VNet to the Function App, making it accessible privately within the VNet. Crucially, you must then disable public access to the Function App.

This combination ensures that all traffic must flow through the private endpoint from within the VNet, thereby meeting the requirement for network-level isolation and restricting access exclusively to the specified VNet. Option C's explanation is misleading as VNet integration primarily enables outbound connectivity, and an NSG on the VNet-integrated subnet does not directly block public internet access to the Function App's public endpoint.

Exam trap

The trap here is that candidates might consider VNet integration (which primarily enables outbound connectivity from the Function App to the VNet) or IP restrictions on the public endpoint. However, for truly restricting inbound access *only* from a VNet and disabling public internet access, a Private Endpoint is the most robust and secure solution.

How to eliminate wrong answers

Option A is wrong because placing Functions in Azure API Management and configuring IP restrictions does not restrict access to the underlying Function App itself; API Management acts as a gateway, but the Function App's public endpoint remains accessible unless additional restrictions are applied, and IP restrictions in API Management only control access to the API Management instance, not the VNet. Option B is wrong because configuring IP address restrictions on the Function App to allow only the VNet's public IP range is ineffective; VNet traffic uses private IP addresses (RFC 1918), not public IPs, and the Function App's public endpoint would still be reachable from the internet if the VNet's public IP range is allowed, which does not enforce VNet-only access. Option D is wrong because configuring a private endpoint for the Function App and disabling public access would restrict access to the private endpoint, but private endpoints require a Premium or Dedicated plan and are designed for inbound traffic from a VNet; however, the question asks for access from a specific VNet, and while private endpoints can achieve this, the correct combination for outbound VNet integration and inbound NSG control is described in option C, and private endpoints alone do not provide the same level of outbound traffic control as VNet integration with NSGs.

Full explanation →

149

Multi-Selecthard

A production API needs proactive alerting for high telemetry cost. Which two elements are required for a useful Azure Monitor alert?

Select 2 answers

A.A signal or metric/log query that detects the condition

B.A public IP address on the app

C.A manually exported CSV report

D.An action group for notification or automation

AnswersA, D

To proactively alert on high telemetry, an Azure Monitor alert rule requires a specific signal, which can be a platform metric (e.g., CPU utilization, request count) or a custom log query (e.g., Kusto Query Language for Application Insights logs). This signal serves as the condition that the alert rule continuously evaluates against a defined threshold, triggering an alert when the telemetry exceeds the specified limit.

Why this answer

An Azure Monitor alert requires a signal—either a metric (e.g., number of API calls, or a custom metric for telemetry cost) or a log query (e.g., Application Insights traces analyzed for cost patterns)—that defines the condition to detect high telemetry cost. Without this signal, the alert has no data source to evaluate against a threshold or pattern, making proactive detection impossible. Additionally, a useful alert requires an action group to define what happens when the alert condition is met, such as sending notifications (email, SMS) or triggering automated actions (webhooks, runbooks).

Without an action group, the alert would trigger but provide no practical benefit.

Exam trap

The trap here is that candidates often confuse the components needed for an alert (signal and action group) with unrelated infrastructure details like IP addresses or manual exports, leading them to select options that are not part of the alert definition.

Full explanation →

150

MCQeasy

You have an Azure Storage account that hosts blobs for a public website. You need to grant a partner application read-only access to a specific container for 24 hours without using a storage account key. What should you create?

A.A shared access signature (SAS) URI with read permission and expiry set to 24 hours

B.An access policy for the container with read permission

C.A storage account key

D.A managed identity for the partner application

AnswerA

A Shared Access Signature (SAS) URI provides delegated access to Azure Storage resources with granular control over permissions and a defined validity period. By generating a SAS with read-only permission and a 24-hour expiry, the partner receives a time-limited URI that grants access only for the specified duration, minimizing security risks associated with long-term credentials and avoiding exposure of the sensitive storage account key. This approach perfectly aligns with the requirement for temporary, scoped external access.

Why this answer

A shared access signature (SAS) URI with read permission and a 24-hour expiry provides time-limited, delegated access to a specific container without exposing the storage account key. This meets the requirement for read-only access for exactly 24 hours, as the SAS token can be scoped to a single container and its permissions set to read.

Exam trap

The trap here is that candidates often confuse a stored access policy (Option B) with a SAS, not realizing that a policy alone does not grant access—it only defines constraints that a SAS must reference, and without a SAS token, no access is provided.

How to eliminate wrong answers

Option B is wrong because an access policy (stored access policy) alone does not grant access; it must be combined with a SAS to enforce permissions and expiry, and it cannot be used directly to grant time-limited access without a SAS token. Option C is wrong because using a storage account key would grant full administrative access to the entire storage account, not read-only access to a specific container, and violates the requirement to avoid using a storage account key. Option D is wrong because a managed identity is used for Azure resources to authenticate to Azure services without credentials, but it cannot be assigned to an external partner application and does not provide a time-limited, scoped access token for a specific container.

Full explanation →

Microsoft Azure Developer Associate AZ-204 (AZ-204) — Questions 76–150