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.
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.
You are designing a solution that needs to react to changes in an Azure Cosmos DB container in real-time. Whenever a new document is inserted or updated, a downstream service must be triggered to process the change. You want to build a serverless solution that reliably captures each change exactly once. Which Azure Cosmos DB feature should you use?
A.Stored procedures
B.T-SQL queries
C.Change feed
D.Triggers
AnswerC
The Azure Cosmos DB change feed provides a persistent, ordered, and sequential log of all item modifications within a container, including inserts, updates, and deletes. It acts as a durable event source, allowing external consumers, such as Azure Functions, to reliably read and process these changes in near real-time without impacting database performance. This push-based mechanism is ideal for building event-driven architectures that react to data changes for scenarios like data synchronization, materialized views, or triggering downstream processes.
Why this answer
The Change feed in Azure Cosmos DB is designed to capture document-level changes (inserts and updates) in the order they occur and provides an event-driven, serverless mechanism to reliably process each change exactly once. It integrates natively with Azure Functions, enabling real-time reactions without polling or custom tracking.
Exam trap
The trap here is that candidates confuse Change feed with triggers, but triggers are synchronous and transactional, whereas Change feed provides an asynchronous, at-least-once (with idempotent handling) stream designed for event-driven architectures.
How to eliminate wrong answers
Option A is wrong because stored procedures are transactional scripts executed within the database engine, not designed for capturing or streaming changes to downstream services. Option B is wrong because T-SQL queries are used for ad-hoc data retrieval and do not provide a continuous, ordered stream of changes. Option D is wrong because triggers in Cosmos DB are pre- or post-operation hooks that run within the same transaction scope, not for decoupled, exactly-once event delivery to external services.
A company stores sensitive customer data in Azure Blob Storage. They require that all access to the storage account be logged and that any access from outside the corporate network be denied. They also need to allow read access from a specific Azure web app without exposing the storage account publicly. Which three actions should be taken? (Choose three.)
Select 3 answers
A.Enable Azure Defender for Storage
B.Enable diagnostic settings for the storage account and send logs to a Log Analytics workspace
C.Assign the 'Storage Blob Data Reader' role to the web app's managed identity
D.Configure the storage account firewall to allow access only from the virtual network/subnet of the web app
E.Generate a SAS token and store it in the web app's configuration
AnswersB, C, D
Enabling diagnostic settings for the storage account allows for comprehensive logging of all requests, including successful and failed operations, authentication types, and source IP addresses. By sending these logs to a Log Analytics workspace, the company gains a centralized, queryable repository for auditing all access attempts to the sensitive data. This fully satisfies the requirement to log all access, enabling detailed monitoring, security analysis, and compliance auditing.
Why this answer
Enabling diagnostic settings for the storage account and sending logs to a Log Analytics workspace captures all access logs (including read, write, and delete operations) as required by the scenario. This satisfies the logging requirement. Assigning the 'Storage Blob Data Reader' role to the web app's managed identity provides secure, credential-less read access for the web app to the storage account, aligning with the principle of least privilege and avoiding public exposure.
Configuring the storage account firewall to allow access only from the virtual network/subnet of the web app ensures that access from outside the corporate network is denied and that the storage account is not exposed publicly, as the web app would access it via a private link or service endpoint within the allowed VNet.
Exam trap
The trap here is that candidates often confuse Azure Defender for Storage (a security monitoring service) with diagnostic logging, or they incorrectly assume that a SAS token is the only way to grant access to a web app, overlooking managed identity and role-based access control (RBAC).
An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request?
Select 2 answers
A.Issuer and signature are valid for the trusted tenant
B.The user's display name is present
C.Token audience matches the API application ID URI or client ID
D.The token was sent in a query string
AnswersA, C
Validating the issuer (the 'iss' claim) confirms the token originated from the expected Microsoft Entra ID tenant, preventing tokens from unauthorized identity providers. Concurrently, verifying the token's cryptographic signature, using the issuer's public key, ensures its integrity and authenticity. This critical step guarantees the token has not been tampered with since it was issued and genuinely came from the claimed authority, establishing trust in the token's source.
Why this answer
The API must validate the token's issuer (iss) claim to ensure it matches the trusted Microsoft Entra ID tenant's issuer URL, confirming the token's origin. It must also verify the token's cryptographic signature to ensure it hasn't been tampered with. Additionally, the API must validate the token's audience (aud) claim, ensuring it matches the API's own Application ID URI or client ID, which confirms the token was intended for this specific API.
Exam trap
The trap here is that candidates confuse optional user claims (like display name) with mandatory security claims (iss, aud, signature), or think token transport method (query string vs. header) is a validation property rather than a security best practice.
You are developing a solution that processes orders from an e-commerce website. The order processing logic is CPU-intensive and can take up to 30 seconds per order. You need to ensure that the web front-end remains responsive and that orders are processed reliably. What should you use?
A.Use Azure WebJobs to process orders in the same App Service plan.
B.Add orders to Azure Queue Storage and process them using a background worker role.
C.Use Azure Service Bus Queues with sessions for order processing.
D.Use Azure Functions with Durable Functions to manage order processing state.
AnswerB
This approach leverages Azure Queue Storage as a robust, asynchronous message broker, effectively decoupling the order submission front-end from the actual processing logic. When an order is placed, the front-end quickly adds a message to the queue, ensuring immediate responsiveness to the user. A separate background worker role, which could be an Azure Function, a VM, or a containerized application, then independently retrieves and processes these messages at its own pace, providing fault tolerance and allowing for independent scaling of the processing component. This design enhances system reliability and user experience by preventing processing delays from affecting the interactive application.
Why this answer
Azure Queue Storage provides a reliable, asynchronous message-passing mechanism that decouples the CPU-intensive order processing from the web front-end. By adding orders to a queue and processing them with a background worker (e.g., a WebJob or Worker Role), the web front-end remains responsive, and the queue ensures at-least-once delivery and durability, even if the worker fails or restarts.
Exam trap
The trap here is that candidates often choose Azure Service Bus Queues (Option C) because they assume 'reliable' messaging requires a premium service, but Azure Queue Storage is fully reliable for this scenario and simpler/cheaper, while sessions are a red herring for unordered processing.
How to eliminate wrong answers
Option A is wrong because running CPU-intensive work in the same App Service plan (via WebJobs) can still compete for resources (CPU, memory) with the web front-end, potentially causing responsiveness issues; it does not truly decouple the workload. Option C is wrong because Azure Service Bus Queues with sessions are designed for ordered, grouped message processing (e.g., FIFO per session), but the scenario does not require session-based ordering or grouping—simple reliable queuing suffices, and Service Bus adds unnecessary complexity and cost. Option D is wrong because Durable Functions are optimized for orchestrating long-running, stateful workflows with checkpoints, not for simple CPU-intensive batch processing; they introduce overhead for state management and are not the simplest or most cost-effective solution for this use case.
You are building an API that needs to validate JWT tokens issued by Microsoft Entra ID. The API is registered as an application in Entra ID. Which endpoint should the API use to obtain the signing keys?
This endpoint, often referred to as the JSON Web Key Set (JWKS) endpoint, directly returns a set of public cryptographic keys in JSON Web Key (JWK) format. These public keys are precisely what an API needs to cryptographically verify the signature of a received JWT. By using these keys, the API can confirm that the token was issued by the trusted identity provider and has not been tampered with, ensuring its authenticity and integrity.
Why this answer
The endpoint `https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys` is the Microsoft Entra ID (formerly Azure AD) v2.0 JWKS (JSON Web Key Set) URI, which returns the public signing keys used to validate the signature of JWT tokens. The API must fetch these keys to verify the token's integrity and authenticity, as the keys are rotated periodically.
Exam trap
The trap here is that candidates often confuse the OpenID Connect metadata endpoint (Option C) with the actual key endpoint, not realizing that the metadata only provides a URL to the keys, and the exam expects you to know the specific `/discovery/v2.0/keys` endpoint for direct key retrieval.
How to eliminate wrong answers
Option A is wrong because the `/oauth2/v2.0/token` endpoint is used to obtain access tokens, not signing keys. Option B is wrong because the `/oauth2/v2.0/authorize` endpoint is used for user authorization and consent flows, not for key retrieval. Option C is wrong because the `/.well-known/openid-configuration` endpoint returns the OpenID Connect discovery metadata (including the `jwks_uri` field), but it does not directly return the signing keys; the actual keys must be fetched from the URI specified in that metadata (which is the `/discovery/v2.0/keys` endpoint).
You are developing a microservice that needs to publish events to multiple subscribers. Each subscriber should receive the event independently and at its own pace. The event must be retained for up to 7 days. Which Azure messaging service should you use?
A.Azure Service Bus queue
B.Azure Service Bus topic
C.Azure Event Grid
D.Azure Event Hubs
AnswerB
Azure Service Bus topic subscriptions provide each subscriber with an independent copy of the message, yet messages are removed from the subscription as soon as they are consumed. This means the event is not retained for the full seven-day window if all subscribers have processed it early. Event Hubs retains events in a partitioned log for the entire retention period regardless of consumption, supporting replay. Service Bus topics are tempting because they offer reliable pub/sub messaging and would be correct when you need transactional guarantees or message sessions, not long-term event storage.
Why this answer
Azure Service Bus Topic is the correct choice. It provides a publish-subscribe model where each subscriber receives events independently through its own durable subscription. Messages are retained within each subscription until they are processed or their time-to-live expires (up to 14 days by default), which perfectly meets the requirement for events to be retained for up to 7 days for subscribers to consume at their own pace.
Event Grid is designed for near real-time event delivery and does not offer durable message retention for subscribers over several days; its retry policy is limited to a maximum of 24 hours.
Exam trap
Candidates often confuse Event Grid's pub/sub capabilities with the durable messaging requirements of Service Bus Topics. While Event Grid supports multiple subscribers, it is optimized for near real-time event routing and does not provide durable message retention for subscribers to pick up events at their own pace over several days. Its retry mechanism is limited (max 24 hours), and dead-lettering is for failed deliveries, not for holding events for slow subscribers.
Service Bus Topics, conversely, offer durable subscriptions where messages are retained for each subscriber until processed, fulfilling the long-term retention requirement.
How to eliminate wrong answers
Option A is wrong because Azure Service Bus queues implement a point-to-point messaging pattern where each message is consumed by a single receiver, not multiple subscribers. Option B is wrong because Azure Service Bus topics do support multiple subscribers, but they are designed for message-oriented middleware with a maximum retention period of 14 days, not specifically optimized for event-driven architectures with independent subscriber pacing. Option D is wrong because Azure Event Hubs is a big data streaming platform optimized for high-throughput ingestion and replay, not for routing events to multiple subscribers with independent consumption and 7-day retention; it retains events for up to 7 days but focuses on event streaming rather than pub-sub event distribution.
You are a developer for a startup that is building a real-time chat application on Azure. The application uses Azure Web PubSub to broadcast messages to clients. The security team requires that only authenticated users can connect to the Web PubSub service. You plan to use Microsoft Entra ID for authentication. The application backend is an Azure Function that generates access tokens. What is the correct course of action to secure the Web PubSub service?
A.Configure the Web PubSub service to use a shared access key and distribute it to clients via the Function.
B.Enable managed identity for the Azure Function, assign it the 'Web PubSub Service Owner' role, and use the Web PubSub SDK to generate a client access token after authenticating the user.
C.Set the Web PubSub service's 'Anonymous mode' to 'Allow anonymous connections' and authenticate users at the application level.
D.Use the Web PubSub connection string (access key) in the Function to generate a client token, and store the connection string in Azure Key Vault.
AnswerB
This is the correct and most secure approach. Enabling a managed identity for the Azure Function allows it to authenticate with Azure Entra ID and subsequently with the Web PubSub service without storing any credentials. Assigning the 'Web PubSub Service Owner' role grants the Function the necessary permissions to generate secure, time-limited client access tokens for authenticated users, adhering to the principle of least privilege.
Why this answer
It uses managed identity to securely authenticate the Azure Function to the Web PubSub service without exposing any secrets. The Function then generates a client access token only after the user is authenticated via Microsoft Entra ID, ensuring that only authenticated users can connect to the Web PubSub service. This approach follows the principle of least privilege and avoids distributing shared access keys or connection strings to clients.
Exam trap
The trap here is that candidates often confuse generating a client access token from a connection string (Option D) with using managed identity (Option B), not realizing that the connection string is a static secret that does not enforce user-level authentication, whereas managed identity enables secure, identity-based token generation after user authentication.
How to eliminate wrong answers
Option A is wrong because distributing a shared access key to clients exposes the key, allowing anyone with the key to connect directly to the Web PubSub service without authentication. Option C is wrong because setting 'Anonymous mode' to 'Allow anonymous connections' bypasses authentication entirely, contradicting the requirement that only authenticated users can connect. Option D is wrong because using the connection string (access key) in the Function still requires storing a secret, and generating a client token from it does not enforce user authentication before token issuance; the token could be generated for any unauthenticated request.
You are developing a mobile app that uses Azure Cognitive Services to analyze images. The app must authenticate to the Computer Vision API using a key that is rotated monthly. What is the best practice for handling the key?
A.Store the key in Azure App Configuration with Key Vault references and retrieve it at runtime
B.Use a system-assigned managed identity and acquire a token for Cognitive Services
C.Prompt the user to enter the key on first launch
D.Store the key in the mobile app's local secure storage after initial retrieval
AnswerA
Storing the key in Azure App Configuration with Key Vault references and retrieving it at runtime provides a robust and secure solution. A backend service, not the mobile app directly, would fetch the secret from App Configuration, which in turn securely retrieves it from Key Vault. This architecture enables dynamic key rotation in Key Vault without requiring any redeployment of the backend service or updates to the mobile application, significantly enhancing security posture and operational agility by centralizing secret management.
Why this answer
Azure App Configuration with Key Vault references provides a secure, centralized way to store and rotate secrets like API keys without embedding them in code or requiring redeployment. A secure backend service (e.g., an Azure Function or App Service) that the mobile app interacts with would retrieve the key at runtime via a managed identity, ensuring the key is never stored locally on the mobile device and can be rotated monthly by updating Key Vault, with App Configuration automatically fetching the latest version. The mobile app would then call this backend service, which in turn authenticates to Cognitive Services.
Exam trap
The trap here is that candidates often assume managed identity works directly for client-side applications like mobile apps, or that Cognitive Services APIs can be directly authenticated with a managed identity without first acquiring a key or an Azure AD token. While a backend service can use a managed identity to acquire a token or retrieve a key, a mobile app itself does not use a system-assigned managed identity.
How to eliminate wrong answers
Option B is wrong because Azure Cognitive Services (including Computer Vision) do not support managed identity authentication for key-based access; they require either a key or a token from Azure AD, but the key rotation requirement here mandates a key, not a token. Option C is wrong because prompting the user to enter the key on first launch violates security best practices (exposes the key to the user) and is impractical for monthly rotation, as it would require user intervention every month. Option D is wrong because storing the key in the mobile app's local secure storage after initial retrieval still leaves the key vulnerable to extraction from the device and does not address the monthly rotation requirement—the app would need to re-fetch the new key each month, which is better handled via a centralized service like App Configuration.
You are developing a web app that uses Azure AD B2C for customer identity. The app must allow users to sign in with their social media accounts like Facebook and Google. Which Azure AD B2C policy type should you configure?
A.Profile editing policy
B.Sign-up and sign-in policy
C.Password reset policy
D.Conditional access policy
AnswerB
An Azure AD B2C sign-up and sign-in policy is the foundational user flow that orchestrates the entire user journey for both new user registration and existing user authentication. It is within this policy type that you configure and enable various identity providers, including social identity providers like Google or Facebook, allowing users to choose their preferred method for creating an account or signing into the application. This policy directly enables the required functionality for social sign-in.
Why this answer
The sign-up and sign-in policy (now called a user flow in the Azure portal) is the correct choice because it is the Azure AD B2C policy type specifically designed to handle both user registration and authentication in a single flow. This policy can be configured to include social identity providers like Facebook and Google, allowing users to sign in using those accounts. It orchestrates the OAuth 2.0 and OpenID Connect protocols to redirect users to the social provider's authorization endpoint and then process the returned tokens.
Exam trap
Candidates might mistakenly choose profile editing or password reset policies, which serve different purposes (post-authentication profile management and password recovery for local accounts, respectively) and are not designed for initial sign-up or sign-in with social identity providers. Conditional access policies are also not the correct mechanism for configuring identity providers in B2C. The key is to understand that the 'Sign-up and sign-in' user flow is specifically designed to integrate social identity providers for the primary authentication journey.
How to eliminate wrong answers
Option A is wrong because a profile editing policy is used only for allowing authenticated users to modify their account attributes (e.g., display name, city), not for initial sign-in or registration with social providers. Option C is wrong because a password reset policy is specifically for resetting a forgotten password via email verification or other methods; it does not handle social identity provider authentication. Option D is wrong because conditional access policy is a security feature that evaluates risk signals (e.g., location, device state) to grant or block access after authentication, not a policy type for configuring sign-in with social identity providers.
You are building a solution that processes events from multiple Azure Event Hubs. Events must be dispatched to different downstream services based on the event type. You need a serverless solution that can handle high throughput and uses managed identity to authenticate to Event Hubs. Which Azure service should you use?
A.Azure Functions (Event Hubs trigger) with managed identity
B.Azure Stream Analytics
C.Azure Logic Apps (Event Hubs connector)
D.Azure Data Factory
AnswerA
Azure Functions with an Event Hubs trigger is an excellent choice for processing events from multiple Event Hubs at scale. It automatically handles consumer group management and checkpointing, allowing for highly concurrent and reliable event processing. Utilizing a managed identity provides a secure, credential-free way for the Function App to authenticate with Event Hubs and other Azure services, adhering to the principle of least privilege and enhancing security posture.
Why this answer
Azure Functions with an Event Hubs trigger supports managed identity authentication, enabling secure, passwordless connections to Event Hubs. It is a serverless, event-driven compute service that can scale to handle high throughput by processing events in parallel across multiple partitions. This makes it the ideal choice for dispatching events to downstream services based on event type.
Exam trap
The trap here is that candidates often confuse Azure Stream Analytics as a general-purpose event dispatcher, but it is specifically a stream analytics engine, not a serverless event router; Azure Functions is the correct choice for event-driven dispatching with managed identity support.
How to eliminate wrong answers
Option B (Azure Stream Analytics) is wrong because it is designed for real-time analytics and complex stream processing (e.g., SQL-like queries over time windows), not for dispatching individual events to multiple downstream services based on event type. Option C (Azure Logic Apps) is wrong because while it can connect to Event Hubs, it is a low-throughput, workflow-orchestration service that does not natively support managed identity for Event Hubs authentication and is not optimized for high-throughput event processing. Option D (Azure Data Factory) is wrong because it is a data integration and ETL service for scheduled, batch-oriented data movement, not a real-time event processing or dispatching service.
Your company uses Microsoft Entra ID for identity management. You need to ensure that users accessing a line-of-business application from unmanaged devices must complete a multi-factor authentication (MFA) challenge. What should you configure?
A.Create a Conditional Access policy that requires MFA for users accessing the application, with a condition for 'Device state' set to 'Unmanaged'.
B.Configure a device compliance policy in Microsoft Intune.
C.Create a Conditional Access policy that requires MFA for all users.
D.Enable risk-based Conditional Access in Microsoft Entra ID Protection.
AnswerA
This is the correct approach because Microsoft Entra Conditional Access policies are specifically designed to enforce access controls based on various conditions, including the application being accessed and the state of the device. By configuring a policy to target the specific application and setting the 'Device state' condition to 'Unmanaged' (which typically means devices that are not Azure AD joined, Hybrid Azure AD joined, or Azure AD registered), you can precisely require multi-factor authentication (MFA) only when users attempt to access that application from a device not managed by the organization.
Why this answer
A Conditional Access policy in Microsoft Entra ID allows you to target specific applications and require MFA based on the device state condition. By setting the device state condition to 'Unmanaged', the policy applies only to devices that are not managed by your organization (e.g., not joined or compliant with Intune), ensuring that users on unmanaged devices must complete an MFA challenge before accessing the line-of-business application.
Exam trap
The trap here is that candidates often confuse device compliance policies (Intune) with Conditional Access policies, or they assume a blanket MFA policy for all users is sufficient, missing the specific device state condition that targets unmanaged devices.
How to eliminate wrong answers
Option B is wrong because a device compliance policy in Microsoft Intune defines the security requirements for managed devices (e.g., encryption, OS version) but does not enforce MFA based on device state; it is used for conditional access compliance checks, not for triggering MFA directly. Option C is wrong because creating a Conditional Access policy that requires MFA for all users would apply to every user regardless of device state, which does not meet the requirement to target only unmanaged devices. Option D is wrong because risk-based Conditional Access in Microsoft Entra ID Protection triggers MFA based on user or sign-in risk levels (e.g., leaked credentials, anonymous IP), not on the device state being unmanaged.
A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required?
A.Password hash synchronization
B.Delegated permissions only
C.Device code flow
D.Application permissions with client credentials flow
AnswerD
Application permissions, combined with the client credentials flow, are the correct approach for a background service (daemon application) that needs to call Microsoft Graph without a signed-in user. Application permissions are granted directly to the application's service principal, allowing it to act as itself and access data across all users or specific resources, independent of any user context. The client credentials flow is the OAuth 2.0 grant type where the application authenticates directly to Azure AD using its client ID and a client secret or certificate to obtain an access token.
Why this answer
When a background service or daemon calls Microsoft Graph without a signed-in user, it must authenticate as itself using application permissions (app roles) rather than delegated permissions. The client credentials flow (OAuth 2.0 grant type) allows the service to obtain an access token using its own credentials (client ID and client secret or certificate), without any user interaction. This flow is designed for server-to-server scenarios where the application acts on its own behalf.
Exam trap
The trap here is that candidates often confuse delegated permissions (which require a user) with application permissions (which do not), and mistakenly choose the device code flow thinking it works without a user, when in fact it still requires user authentication via a browser.
How to eliminate wrong answers
Option A is wrong because password hash synchronization is an Azure AD Connect feature for syncing user password hashes to Azure AD for hybrid identity, not a permission model for calling Microsoft Graph. Option B is wrong because delegated permissions require a signed-in user to delegate the application's permissions to act on the user's behalf, which contradicts the requirement of no signed-in user. Option C is wrong because the device code flow is an OAuth 2.0 flow designed for devices with limited input capabilities (e.g., IoT, CLI) that still requires a signed-in user to authenticate via a browser; it does not support unattended background service scenarios.
A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required? The team wants the control to be enforceable during normal operations.
A.Password hash synchronization
B.Delegated permissions only
C.Device code flow
D.Application permissions with client credentials flow
AnswerD
For a background service operating without a signed-in user, application permissions are essential as they allow the application itself to call Microsoft Graph. The client credentials flow is the appropriate OAuth 2.0 grant type for this scenario, enabling the application to authenticate using its own client ID and secret or certificate to acquire an access token. This token represents the application's identity, allowing it to perform actions based on the administrator-consented permissions, independent of any user context.
Why this answer
The scenario requires an unattended background service to call Microsoft Graph without a signed-in user. Application permissions, combined with the client credentials flow (OAuth 2.0 grant type), allow the service to authenticate as itself using a client ID and client secret or certificate, obtaining an access token with pre-authorized application-level permissions. This model enforces control during normal operations because the permissions are granted directly to the application and cannot be delegated by a user, ensuring consistent access regardless of user presence.
Exam trap
The trap here is that candidates often confuse delegated permissions (which require a user) with application permissions (which do not), and mistakenly choose the device code flow thinking it works without a user, when in fact it still requires interactive user authentication.
How to eliminate wrong answers
Option A is wrong because password hash synchronization is an Azure AD Connect feature for syncing user password hashes for hybrid identity, not a permission model for calling Microsoft Graph. Option B is wrong because delegated permissions require a signed-in user to delegate their privileges to the app; they cannot be used in a background service without a user context. Option C is wrong because the device code flow is designed for devices with limited input capabilities and still requires a signed-in user to authenticate interactively on another device, making it unsuitable for an unattended background service.
You are developing a serverless application using Azure Functions that processes orders. Each order must be validated by calling a third-party API. If the third-party API is unavailable, the function should retry with exponential backoff. How should you implement this?
A.Implement retry logic with exponential backoff and circuit breaker using Polly within the function
B.Enable automatic retries on the function's trigger binding
C.Configure the function to have a long timeout and hope the API responds
D.Use Azure Durable Functions to orchestrate the retry
AnswerA
Polly provides robust transient fault handling.
Why this answer
It uses the Polly library to implement retry logic with exponential backoff and circuit breaker, which is a lightweight and flexible approach. Option B is incorrect because the trigger binding's automatic retries are for infrastructure failures (e.g., message delivery), not for application-level errors like API unavailability. Option C is incorrect because a long timeout does not handle transient faults; it just waits.
Option D is incorrect because, while Azure Durable Functions does support retry via CallActivityWithRetryAsync, it introduces unnecessary complexity (orchestration overhead) for a simple HTTP call that can be handled directly with a library like Polly.
You are using Application Insights to monitor a web application. The business team wants to track how many users click a specific button on the page. You need to send custom telemetry data from the client-side JavaScript. Which Application Insights JavaScript SDK method should you call?
A.appInsights.trackTrace
B.appInsights.trackEvent
C.appInsights.trackPageView
D.appInsights.trackException
AnswerB
appInsights.trackEvent is the correct and most appropriate method for capturing custom user interactions and business events within an application, such as a button click, form submission, or item added to a cart. It allows developers to attach custom properties (e.g., button name, user ID, feature variant) and measurements (e.g., duration, value) to the event, enabling rich analytical queries, segmentation, and funnel analysis in Application Insights. This structured data is crucial for understanding user behavior and application engagement.
Why this answer
The correct method is `trackEvent` because it is specifically designed for capturing user interactions, such as button clicks, as custom events in Application Insights. Unlike other methods, `trackEvent` allows you to attach custom properties and measurements, making it ideal for business metrics like click tracking. This method sends the data as a custom event telemetry item, which can be analyzed in the Azure portal under 'Events'.
Exam trap
The trap here is that candidates often confuse `trackEvent` with `trackTrace` or `trackPageView`, thinking that any custom data can be sent via `trackTrace`, but `trackEvent` is the only method designed for user-defined business events like button clicks.
How to eliminate wrong answers
Option A is wrong because `trackTrace` is used for logging diagnostic trace messages, not for tracking user interactions or custom business events. Option C is wrong because `trackPageView` is designed to track page loads and views, not individual button clicks on a page. Option D is wrong because `trackException` is used to report exceptions and errors, not to track user actions or custom telemetry events.
Your company has several Azure subscriptions, and you need to create a custom role that allows security engineers to start and stop Azure virtual machines but not delete them or modify their network interfaces. The role must be scoped to a specific resource group. How should you define this custom role?
A.Assign the built-in Contributor role to the resource group.
B.Create a custom role with allowed actions for start and stop, and explicitly deny delete actions using NotActions.
C.Use Azure Policy to prevent deletion of VMs in that resource group.
D.Add the engineers to an Microsoft Entra ID administrative unit and assign permissions for VM operations.
AnswerB
Creating a custom Azure RBAC role allows for granular control over permissions, precisely aligning with the principle of least privilege. This role can be configured to include specific actions like 'Microsoft.Compute/virtualMachines/start/action' and 'Microsoft.Compute/virtualMachines/stop/action' within its 'Actions' property. Crucially, by adding 'Microsoft.Compute/virtualMachines/delete' to the 'NotActions' property, the role explicitly denies the ability to delete virtual machines, even if other broad permissions might implicitly grant it. This combination provides the exact required functionality while preventing unintended deletions.
Why this answer
Custom roles in Azure RBAC allow you to define granular permissions using Actions and NotActions. To allow start/stop but prevent delete, you can define a broad action like 'Microsoft.Compute/virtualMachines/*' (which includes start/stop and delete) and then use 'NotActions' to explicitly exclude 'Microsoft.Compute/virtualMachines/delete'. Since network interface modifications fall under the 'Microsoft.Network' resource provider, they are not included in 'Microsoft.Compute/virtualMachines/*' and thus are implicitly denied by this role definition.
Scoping the role to a specific resource group ensures the permissions apply only to that resource group, meeting the requirement.
Exam trap
The trap here is that candidates often confuse Azure Policy with RBAC, thinking Policy can control runtime actions like start/stop, when in fact Policy only governs resource configuration and compliance, not operational permissions.
How to eliminate wrong answers
Option A is wrong because the built-in Contributor role grants full management access, including the ability to delete VMs and modify network interfaces, which violates the requirement to prevent deletion and network interface changes. Option C is wrong because Azure Policy is used to enforce compliance rules (e.g., tagging, location restrictions) and cannot directly grant or deny RBAC permissions for specific actions like start/stop; it audits or prevents resource creation but does not control runtime operations. Option D is wrong because Microsoft Entra ID administrative units manage administrative scope for user and group management, not Azure resource permissions; RBAC roles are required for VM operations, and administrative units do not provide a mechanism to assign start/stop permissions.
You are deploying a Docker container to Azure Container Instances (ACI). The container must use GPU resources for machine learning inference. You need to select the appropriate option to provision GPU-enabled containers. What should you do?
A.Deploy the container to a container group with a GPU-enabled SKU (e.g., NV series).
B.Mount a GPU volume from the host.
C.Use Azure Batch with GPU-enabled pools.
D.Enable container GPU support in the Dockerfile.
AnswerA
To deploy a Docker container with GPU capabilities in Azure Container Instances, the correct approach is to provision a container group with a GPU-enabled SKU. This explicitly allocates a physical GPU from Azure's infrastructure, such as an NV-series VM, directly to your container instance. ACI then manages the necessary drivers and resources, making the GPU available to your containerized application for accelerated workloads like machine learning inference or training.
Why this answer
Azure Container Instances supports GPU resources only when you deploy a container group using a GPU-optimized SKU, such as the NV-series (e.g., Standard_NC6s_v3). These SKUs provide NVIDIA Tesla GPUs (e.g., K80, P100, V100) that are directly exposed to the container, enabling hardware-accelerated machine learning inference. You must specify the GPU SKU in the container group's resource requests during deployment, and the container image must include the appropriate NVIDIA CUDA drivers or runtime.
Exam trap
The trap here is that candidates confuse local Docker GPU configuration (e.g., `--gpus all` in Dockerfile or docker run) with ACI's infrastructure-level GPU provisioning, assuming that a Dockerfile directive alone will enable GPU access in ACI, when in fact the SKU selection is mandatory and overrides any local settings.
How to eliminate wrong answers
Option B is wrong because ACI does not support mounting a GPU volume from the host; GPU access is provided exclusively through the container group's SKU selection, not via volume mounts. Option C is wrong because Azure Batch with GPU-enabled pools is a separate service for batch processing, not a direct method to provision a single GPU container in ACI; the question specifically asks about ACI deployment. Option D is wrong because enabling GPU support in the Dockerfile (e.g., using `--gpus all` or NVIDIA runtime) is a local Docker configuration that does not affect ACI's provisioning; ACI ignores Dockerfile GPU directives and requires the SKU-based approach.
You need to restrict access to an Azure Storage blob container so that only users from your Microsoft Entra tenant can read blobs, and deny all other access including anonymous traffic. What should you configure?
A.Generate a shared access signature (SAS) for the container
B.Set public access level to private and assign RBAC roles to users
C.Configure a network firewall to allow only your tenant's IP range
D.Use storage account access keys and distribute them to users
AnswerB
This ensures only authenticated users from your tenant can access blobs.
Why this answer
Setting the public access level to private disables anonymous access, and assigning RBAC roles such as Storage Blob Data Reader to Entra ID users ensures only authenticated users from your tenant can read blobs. Option A is incorrect because a SAS token can be shared externally, allowing access to users outside your tenant. Option C is incorrect because a network firewall only restricts by IP address and does not authenticate users; anonymous traffic from allowed IPs would still be permitted.
Option D is incorrect because storage account access keys grant full administrative access to the account, not read-only access for specific users, and distributing keys is insecure.
You are designing a solution that uses Azure Event Grid to handle events from multiple Azure services. The events must be filtered and routed to different endpoints based on event type. Which component should you use to filter events before they are sent to subscribers?
A.Event grid domain
B.Event grid topic
C.Event subscription with filters
D.Event handler
AnswerC
An Event Grid event subscription is the precise mechanism for selecting and routing specific events to an event handler. Subscribers define criteria using basic filters (e.g., event type, subject begins/ends with) or advanced filters (e.g., properties within the event payload) directly within their subscription configuration. This ensures that only relevant events, matching the specified conditions, are delivered to the designated endpoint, optimizing processing and reducing unnecessary traffic.
Why this answer
C is correct because Event Subscriptions in Azure Event Grid allow you to define filters on event types, subject prefixes/suffixes, and advanced filtering (e.g., based on data fields) to control which events are delivered to each subscriber. This filtering happens before the events are sent to the endpoint, ensuring only matching events are routed.
Exam trap
The trap here is that candidates often confuse the role of a topic (which is just a channel for events) with the filtering capability that is actually implemented at the subscription level, leading them to incorrectly select Event Grid Topic.
How to eliminate wrong answers
Option A is wrong because an Event Grid domain is a management construct for grouping multiple topics and enabling topic-level authentication, not a component for filtering events before delivery. Option B is wrong because an Event Grid topic is an endpoint where publishers send events, but filtering is configured at the subscription level, not the topic itself. Option D is wrong because an Event Handler is the destination (e.g., Azure Function, Webhook) that receives events; it does not perform pre-delivery filtering.
Refer to the exhibit. You deploy this ARM template to a resource group. The template fails with a 'ResourceNotFound' error. What is the most likely cause?
A.The App Service plan 'myplan' does not exist in the resource group.
B.The 'apiVersion' is incorrect.
C.The template is missing the 'dependsOn' property.
D.The 'type' property is incorrect for a web app.
AnswerA
An Azure App Service Web App requires an existing App Service Plan to host it. If the ARM template attempts to deploy a web app and references an App Service Plan by name ('myplan') that is neither defined within the same template nor already present in the target resource group, the deployment will fail. The Azure Resource Manager (ARM) engine will return a `ResourceNotFound` error because it cannot locate the specified parent hosting plan for the web app.
Why this answer
The ARM template references an App Service plan named 'myplan' in the 'serverFarmId' property of the Microsoft.Web/sites resource. If 'myplan' does not exist in the same resource group, the deployment fails with a 'ResourceNotFound' error because Azure Resource Manager cannot resolve the dependency on a non-existent resource. The template does not include a definition for the App Service plan, so it must already exist in the resource group.
Exam trap
Microsoft often tests the distinction between a missing resource and a missing dependency; the trap here is that candidates assume a 'ResourceNotFound' error always means a missing 'dependsOn' property, when in fact it indicates the referenced resource does not exist at all.
How to eliminate wrong answers
Option B is wrong because an incorrect 'apiVersion' typically causes a 'NoRegisteredProviderFound' or 'InvalidApiVersion' error, not a 'ResourceNotFound' error. Option C is wrong because the 'dependsOn' property is not required when referencing an existing resource by name; it is only needed to enforce deployment order when both resources are defined in the same template. Option D is wrong because the 'type' property 'Microsoft.Web/sites' is correct for a web app; an incorrect type would result in a 'InvalidResourceType' or 'ResourceNotFound' error only if the resource provider does not recognize it.
A company has an Azure Kubernetes Service (AKS) cluster. They want to ensure that pods can securely access Azure SQL Database without using connection strings or secrets. The solution must use the principle of least privilege. What should they implement?
A.Use the Azure Key Vault Provider for Secrets Store CSI Driver to mount secrets into the pod.
B.Store the SQL connection string in a Kubernetes secret and mount it as a volume in the pod.
C.Enable Azure AD Workload Identity for AKS and assign a managed identity to the pod that has access to Azure SQL Database.
D.Configure Azure SQL Database firewall to allow the AKS cluster's IP addresses.
AnswerC
Pod-managed identity allows the pod to authenticate to Azure SQL without secrets, using a managed identity.
Why this answer
Azure AD Workload Identity allows you to assign a user-assigned managed identity to a pod in AKS. This identity can be granted specific permissions (e.g., db_datareader) on Azure SQL Database using Azure AD authentication, eliminating the need for connection strings or secrets. The pod authenticates directly via the managed identity token, adhering to the principle of least privilege by scoping access to only the required database roles.
Exam trap
The trap here is that candidates often confuse Azure AD Workload Identity with managed identity for AKS cluster itself (which is for cluster-level resources, not per-pod), or they assume that Key Vault integration (Option A) eliminates secrets entirely when it actually just moves them to a different store, still requiring secret material to be mounted.
How to eliminate wrong answers
Option A is wrong because the Azure Key Vault Provider for Secrets Store CSI Driver still requires storing a connection string or secret in Key Vault, which does not eliminate secrets entirely and introduces a dependency on a secret store, violating the 'without using connection strings or secrets' requirement. Option B is wrong because storing the SQL connection string in a Kubernetes secret and mounting it as a volume still exposes the secret in the cluster, violating the 'without using secrets' constraint and the principle of least privilege. Option D is wrong because configuring the Azure SQL Database firewall to allow the AKS cluster's IP addresses does not provide identity-based access control; it relies on network-level security, which is not least privilege (all pods share the same IP range) and does not eliminate connection strings or secrets.
Which TWO Azure Monitor features can help troubleshoot a web app that returns slow response times intermittently?
Select 2 answers
A.Sentinel incidents
B.Advisor recommendations
C.Live Metrics
D.Application Map
E.Policy compliance
AnswersC, D
Azure Monitor's Live Metrics Stream provides a near real-time, minute-by-minute view of a running web application's performance, including incoming requests, failures, dependency calls, and CPU utilization. This feature allows developers to observe the impact of deployments or diagnose issues immediately as they occur, offering a crucial, unfiltered stream of operational data directly from the application instance. It is invaluable for quickly identifying spikes in errors or latency during active troubleshooting sessions.
Why this answer
Live Metrics (C) is correct because it provides real-time, low-latency monitoring of a web app's performance, including CPU, memory, and request rates, allowing you to observe intermittent slow responses as they happen without sampling delays. Application Map (D) is correct because it visualizes the distributed components of your application and their dependencies, helping you identify which downstream service or component is causing latency spikes during intermittent slowdowns.
Exam trap
The trap here is that candidates often confuse Azure Monitor metrics (like Live Metrics) with log-based solutions (like Log Analytics queries) or governance tools (like Policy), failing to recognize that real-time streaming and dependency mapping are the only features that can capture and isolate intermittent performance issues without aggregation delays.
You deploy the above ARM template. Later, you update the web app's code by deploying a new ZIP package to Azure Blob Storage and updating the WEBSITE_RUN_FROM_PACKAGE setting with the new package URL. However, the web app continues to run the old code. What is the most likely cause?
A.The app setting name is misspelled. It should be 'WEBSITE_RUN_FROM_ZIP'.
B.The setting requires a value of '0' to enable external packages.
C.The ARM template uses an incorrect apiVersion.
D.The value '1' indicates the package is from local storage, not an external URL.
AnswerD
When 'WEBSITE_RUN_FROM_PACKAGE' is set to '1', it instructs the Azure App Service to run the application directly from a zip package that has already been deployed to the 'data/SitePackages' folder within the app's local file system. This value does not signify an external URL; rather, it points to a locally staged package. To run an application from an external URL, the value of 'WEBSITE_RUN_FROM_PACKAGE' must be the full HTTP or HTTPS URL of the zip package itself, allowing the App Service to download and mount it dynamically.
Why this answer
When the WEBSITE_RUN_FROM_PACKAGE app setting is set to '1', it tells Azure App Service to use a local package stored in the site's wwwroot folder. To use an external package from Azure Blob Storage, the setting must be set to the full URL of the blob (with a SAS token if private). Keeping the value as '1' means the service ignores the new blob URL and continues to run the old local package.
Exam trap
The trap here is that candidates assume setting the value to '1' is a generic 'enable' flag, not realizing it has a specific meaning (local package) and that external packages require the full URL as the setting value.
How to eliminate wrong answers
Option A is wrong because the correct app setting name is 'WEBSITE_RUN_FROM_PACKAGE', not 'WEBSITE_RUN_FROM_ZIP'; the latter is not a recognized setting. Option B is wrong because a value of '0' disables the run-from-package feature entirely, causing the app to run from the deployed files directly, not enabling external packages. Option C is wrong because the apiVersion in the ARM template only affects deployment of the template itself, not the runtime behavior of the web app after it's deployed; an incorrect apiVersion would cause a deployment failure, not silent use of old code.
You are deploying an Azure App Service that uses a Linux container to host a custom web application. You need to configure continuous deployment from a GitHub repository. Which TWO actions should you take?
Select 2 answers
A.Set up an FTP trigger to poll the GitHub repository for changes.
B.Use the App Service built-in CI/CD feature to connect to GitHub.
C.Configure the 'Deployment Center' in the App Service to use GitHub Actions.
D.Use the Kudu service to sync with GitHub.
E.Push the container image to Docker Hub and configure webhook.
AnswersB, C
Built-in CI/CD supports GitHub.
Why this answer
Azure App Service provides a built-in CI/CD feature that directly integrates with GitHub, enabling automatic deployment of code changes without additional configuration. Option C is also correct because the Deployment Center in App Service allows you to configure GitHub Actions as the CI/CD pipeline, which builds and deploys the container to the App Service on each push.
Exam trap
The trap here is that candidates may think Kudu is the only deployment engine for App Service, but for Linux containers, the built-in CI/CD and GitHub Actions are the supported methods, and Kudu is not used for GitHub sync in this scenario.
Your application writes temperature data to Azure Table Storage every second. You have noticed that queries for the latest readings are slower than expected. What is the most likely cause?
A.The storage account access tier is set to Cool.
B.The table name is too long.
C.The application is using an outdated version of the Azure Storage SDK.
D.The PartitionKey is not being used in the query filter.
AnswerD
In Azure Table Storage, the PartitionKey is a critical component of the primary clustered index, alongside the RowKey, determining how data is physically organized and accessed. When a query filter omits the PartitionKey, the system cannot efficiently locate the relevant data within a specific partition. Instead, it is forced to perform a full scan across all partitions in the table, leading to significantly slower query execution times, especially as the dataset grows large.
Why this answer
In Azure Table Storage, queries that do not include the PartitionKey in the filter result in a full table scan, which is significantly slower than a point query that uses both PartitionKey and RowKey. Since the application writes data every second, the latest readings likely have a timestamp-based RowKey, but without filtering by PartitionKey, the query must scan all partitions, causing poor performance.
Exam trap
The trap here is that candidates often focus on SDK versions or storage tiers, but the real performance killer in Table Storage is failing to include the PartitionKey in the query filter, which forces a full table scan.
How to eliminate wrong answers
Option A is wrong because the storage account access tier (Cool vs. Hot) affects blob storage pricing and performance, not Table Storage query speed. Option B is wrong because table names in Azure Table Storage can be up to 63 characters, and length does not impact query performance.
Option C is wrong because while an outdated SDK might lack optimizations, it would not cause a fundamental performance issue like missing PartitionKey filtering; the primary bottleneck is the query design, not the SDK version.
Which TWO actions should you take to secure an Azure Function app that is triggered by an HTTP request? (Choose two.)
Select 2 answers
A.Use function-level authorization keys (function or admin keys) for all HTTP triggers.
B.Enable App Service Authentication and configure Microsoft Entra ID as the identity provider.
C.Store connection strings and secrets in Azure Key Vault and reference them from the function app settings using Key Vault references.
D.Set the function app's public access to 'Off' and use virtual network integration.
E.Enable Cross-Origin Resource Sharing (CORS) with allowed origins set to '*'.
AnswersB, C
Enabling App Service Authentication, often called "Easy Auth," and configuring Microsoft Entra ID as the identity provider is a robust security measure. This offloads authentication to the platform, ensuring that only requests with valid Entra ID tokens are allowed to reach the function code. It provides strong identity-based authentication and authorization, integrating with corporate directories and conditional access policies to secure access.
Why this answer
Enabling App Service Authentication with Microsoft Entra ID (formerly Azure AD) provides a managed identity layer that validates JWT tokens from Microsoft Entra ID before the request reaches your function code. This ensures only authenticated users or applications can invoke the HTTP-triggered function, offloading token validation and session management from your code. Option C is correct because storing secrets in Azure Key Vault and referencing them via Key Vault references (syntax @Microsoft.KeyVault(SecretUri=...)) in the function app settings prevents hardcoding credentials in configuration files or source code, aligning with the principle of least privilege and secure secret management.
Exam trap
The trap here is that candidates often confuse network-level security (like virtual network integration) with application-level authentication, or they mistakenly believe that CORS or shared keys provide sufficient security for HTTP-triggered functions, when in fact Microsoft Entra ID authentication is the recommended approach for identity-based access control in Azure Functions.
A serverless app must react whenever audit documents are inserted or updated in Cosmos DB. Which trigger should the Azure Function use?
A.Queue trigger
B.Timer trigger
C.HTTP trigger
D.Cosmos DB trigger
AnswerD
The Azure Cosmos DB trigger for Azure Functions is specifically engineered to listen for changes in an Azure Cosmos DB container's change feed. It automatically processes new inserts and updates (and optionally deletes, depending on configuration) in near real-time, invoking the function for each change. This trigger efficiently leverages the change feed processor library to manage leases and distribute processing across multiple function instances, ensuring reliable and scalable event-driven reactions to data modifications without polling.
Why this answer
The Azure Cosmos DB trigger listens to the change feed of a Cosmos DB container, which captures inserts and updates to documents. This makes it the ideal choice for reacting to audit document changes in a serverless app, as it automatically invokes the function when new or modified documents appear in the feed.
Exam trap
The trap here is that candidates may confuse the Cosmos DB trigger with a generic database trigger, forgetting that it specifically relies on the change feed and not on direct database events like stored procedures or triggers in SQL Server.
How to eliminate wrong answers
Option A is wrong because a Queue trigger responds to messages in an Azure Storage Queue, not to document changes in Cosmos DB. Option B is wrong because a Timer trigger runs on a fixed schedule (e.g., every 5 minutes) and cannot react to real-time data changes. Option C is wrong because an HTTP trigger requires an explicit HTTP request to invoke the function, and it does not automatically fire when documents are inserted or updated in Cosmos DB.
Your company is building a microservices application on Azure Kubernetes Service (AKS). The application must securely access Azure Key Vault to retrieve secrets. Which identity type should you use for the pods?
A.Service principal with certificate stored in the pod
B.User-assigned managed identity on the node resource group
C.System-assigned managed identity on AKS cluster
D.Microsoft Entra Workload ID (formerly Azure AD Pod Identity)
AnswerD
Microsoft Entra Workload ID (formerly Azure AD Pod Identity) is the recommended and most secure approach for enabling applications running in AKS pods to authenticate to Azure services. It allows a Kubernetes service account to be federated with a managed identity in Microsoft Entra ID, enabling pods to securely obtain Azure AD tokens without managing any secrets. This provides fine-grained, pod-level identity for accessing Azure resources, adhering to the principle of least privilege.
Why this answer
Microsoft Entra Workload ID (formerly Azure AD Pod Identity) is the recommended identity type for pods in AKS because it directly maps an Azure managed identity to a pod, allowing the pod to authenticate to Azure Key Vault without storing any credentials. It integrates with the Kubernetes native service account token projection and uses federated identity credentials, eliminating the need for manual secret management or node-level configuration.
Exam trap
The trap here is that candidates often confuse the cluster-level managed identity (system-assigned or user-assigned) with pod-level identity, assuming that a managed identity on the AKS cluster or its nodes can be directly used by pods, when in fact Microsoft Entra Workload ID is the correct mechanism for pod-level identity.
How to eliminate wrong answers
Option A is wrong because storing a service principal certificate inside the pod violates the principle of secretless authentication and creates a security risk if the pod is compromised. Option B is wrong because a user-assigned managed identity on the node resource group applies to the underlying VM nodes, not to individual pods, and would require additional configuration to be used by pods. Option C is wrong because a system-assigned managed identity on the AKS cluster is assigned to the cluster's control plane, not to individual pods, and cannot be directly used by a pod to authenticate to Key Vault.
You are building a data pipeline that writes billions of small log records (each ~200 bytes) to Azure Blob Storage. The logs are always written in chronological order and are read sequentially in order. You must minimize storage cost and achieve maximum write throughput. Which blob type should you use?
A.Block blobs in the Cool tier
B.Append blobs in the Hot tier
C.Page blobs in the Premium tier
D.Block blobs in the Archive tier
AnswerB
Append blobs are purpose-built for scenarios requiring efficient append operations, such as logging or streaming data, where new data is continuously added to the end of a blob without modifying existing content. They allow for fast, sequential writes, ensuring high throughput crucial for ingesting billions of small log entries. The Hot tier provides the lowest access latency and transaction costs, making it the most suitable choice for frequently written and immediately accessed data, optimizing both performance and operational cost for active log ingestion.
Why this answer
Append blobs are optimized for append operations, making them ideal for writing billions of small log records in chronological order. They support high-throughput sequential writes without the overhead of managing block IDs, and the Hot tier provides low-latency access for immediate reading, minimizing storage cost while maximizing write throughput.
Exam trap
The trap here is that candidates often choose Block blobs (Option A) thinking they are the default for any data, but they overlook the append-specific optimization and the overhead of block management for billions of small writes.
How to eliminate wrong answers
Option A is wrong because Block blobs require managing block IDs and committing blocks, which adds overhead for billions of small writes and reduces throughput; the Cool tier also incurs early deletion penalties if logs are read soon after writing. Option C is wrong because Page blobs are designed for random read/write operations (e.g., VHDs) and use a fixed 512-byte page size, which is inefficient for small log records and incurs higher costs in the Premium tier. Option D is wrong because the Archive tier has high latency for read access (hours to rehydrate) and is not suitable for logs that need to be read sequentially in order; Block blobs also suffer from the same block management overhead as Option A.
You are developing an API using Azure API Management (APIM). The API is backed by an Azure Function that processes requests. You need to implement caching for responses that are expensive to compute. The cache should expire after 10 minutes. What should you configure in APIM?
A.Configure Azure Redis Cache as an external cache in APIM.
B.Add a cache-lookup and cache-store policy to the API operation.
C.Implement response caching in the Azure Function code.
D.Use Azure Front Door to cache responses.
AnswerB
Adding `cache-lookup` and `cache-store` policies directly to an API operation is the standard and most effective method for implementing response caching within Azure API Management. These policies leverage APIM's highly optimized, built-in cache, allowing the gateway to check for cached responses before forwarding requests and to store backend responses for subsequent requests, centralizing cache management at the API gateway level.
Why this answer
Azure API Management (APIM) provides built-in caching policies—`cache-lookup` and `cache-store`—that can be applied directly to an API operation. These policies cache the response from the backend (the Azure Function) and respect the `cache-control` header or a specified duration, such as 10 minutes, without requiring an external cache. This is the simplest and most direct way to implement response caching for expensive-to-compute operations within APIM.
Exam trap
The trap here is that candidates often assume an external cache like Redis is required for any caching in APIM, but the built-in cache-lookup and cache-store policies use APIM's internal cache by default, making external Redis optional and only needed for advanced scenarios like multi-region deployments or higher cache capacity.
How to eliminate wrong answers
Option A is wrong because configuring Azure Redis Cache as an external cache in APIM is an optional enhancement for scenarios requiring a distributed cache across multiple APIM instances, but it is not necessary for basic response caching; the built-in cache-lookup and cache-store policies work with APIM's internal cache by default. Option C is wrong because implementing response caching in the Azure Function code would cache responses at the function level, but the question specifically asks what to configure in APIM, and APIM caching policies provide centralized control, offload the backend, and can cache even non-cacheable responses from the function. Option D is wrong because Azure Front Door is a global load balancer and CDN that caches at the edge, not within APIM; it operates at a different layer and does not integrate with APIM's policy-based caching for API operations.
You need to process large volumes of streaming data from IoT devices in near real-time. The processed data must be stored in Azure Cosmos DB for further analysis. Which Azure service should you use for stream processing?
A.Azure Batch
B.Azure Databricks
C.Azure Data Lake Storage
D.Azure Stream Analytics
AnswerD
Azure Stream Analytics is a fully managed, real-time analytics service designed specifically for processing large volumes of streaming data with low latency. It enables users to perform complex event processing, aggregations, and transformations on data from sources like IoT Hub using a SQL-like query language. Its native integration with Azure IoT Hub for input and Azure Cosmos DB for output makes it the ideal, purpose-built solution for real-time IoT data pipelines.
Why this answer
Azure Stream Analytics is purpose-built for real-time stream processing, capable of ingesting large volumes of data from sources like Azure Event Hubs or IoT Hub, applying SQL-based queries, and outputting results directly to Azure Cosmos DB. This aligns perfectly with the requirement for near real-time processing and storage in Cosmos DB.
Exam trap
The trap here is that candidates may confuse Azure Databricks as the only option for streaming analytics due to its Spark Structured Streaming capability, overlooking that Azure Stream Analytics is the simpler, fully managed service specifically designed for near real-time processing without the need for cluster management.
How to eliminate wrong answers
Option A is wrong because Azure Batch is designed for batch processing of large-scale parallel compute jobs, not for continuous, low-latency stream processing. Option B is wrong because Azure Databricks is an Apache Spark-based analytics platform that can handle streaming via Structured Streaming, but it introduces additional complexity and overhead compared to a dedicated, fully managed stream processing service like Stream Analytics. Option C is wrong because Azure Data Lake Storage is a scalable data lake for storing raw and processed data, not a stream processing engine; it lacks the ability to perform real-time transformations or queries on streaming data.
Refer to the exhibit. You have an Azure Storage account with a blob container named container1. The container's public access level is set to Blob (anonymous read access for blobs only). You attempt to assign the custom role defined in the JSON using Azure PowerShell. The role assignment fails. What is the most likely reason?
A.The action 'Microsoft.Storage/storageAccounts/blobServices/containers/read' is not a valid action.
B.The principal ID is invalid.
C.The condition StringEquals expects publicAccess to be 'none', but the container has Blob (anonymous) access.
D.The resource scope is incorrectly formatted.
AnswerC
The condition explicitly requires the `publicAccess` property of the container to be set to 'None' for the permission to be granted. However, if the container is configured with 'Blob' or 'Container' anonymous access, this condition evaluates to false. Consequently, the access request is denied because the container's actual public access setting does not match the 'None' value mandated by the RBAC condition.
Why this answer
C is correct because the custom role includes a condition that uses the `StringEquals` operator to check that the `publicAccess` property of the container is set to `'none'`. Since `container1` has public access level set to `Blob (anonymous read access for blobs only)`, the condition evaluates to false, causing the role assignment to fail. Azure role assignments with conditions require all specified conditions to be met; otherwise, the assignment is rejected.
Exam trap
The trap here is that candidates often overlook the condition in the custom role definition and focus on the action or scope, assuming the failure is due to a syntax error or invalid principal, rather than recognizing that Azure RBAC conditions are evaluated at assignment time and can block the assignment if the resource's current state does not satisfy the condition.
How to eliminate wrong answers
Option A is wrong because `Microsoft.Storage/storageAccounts/blobServices/containers/read` is a valid Azure RBAC action that grants read access to blob containers. Option B is wrong because the principal ID is a standard GUID and there is no indication in the question that it is invalid; the failure is due to the condition, not the principal. Option D is wrong because the resource scope (e.g., `/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account}/blobServices/default/containers/container1`) is correctly formatted for a container-level role assignment.
You have an Azure Storage account that contains a blob container with thousands of small files. You need to generate a URL that allows users to download a single file for a limited time without changing the storage account's firewall rules or requiring authentication. Which approach should you use?
A.Create a Shared Access Signature (SAS) for the specific blob with a time limit
B.Provide the storage account key to the user so they can authenticate
C.Assign the user an RBAC role (e.g., Storage Blob Data Reader) and have them authenticate via Microsoft Entra ID
D.Set the blob container's public access level to Blob (anonymous read access for blobs)
AnswerA
Creating a Shared Access Signature (SAS) for the specific blob is the correct approach because it generates a URI that grants secure, time-limited, and granular access to that single resource. This cryptographically signed token allows the user to directly access the blob via the provided URL without needing to authenticate with their own credentials or be a registered Microsoft Entra ID user. The SAS can be configured with precise permissions (e.g., read-only) and an expiration time, ensuring access is temporary and restricted to only what is necessary.
Why this answer
A Shared Access Signature (SAS) for a specific blob provides delegated, time-limited access to that blob without requiring the storage account key or changing firewall rules. By generating a SAS token with a defined expiration time and attaching it to the blob URL, users can download the file directly via HTTPS while the storage account remains secured behind its firewall and authentication requirements.
Exam trap
The trap here is that candidates often confuse a container-level SAS or public access with a service-level SAS, or mistakenly think RBAC roles can provide anonymous access, when in fact only a blob-level SAS meets the exact constraints of time-limited, single-file, no-authentication access without altering firewall rules.
How to eliminate wrong answers
Option B is wrong because providing the storage account key grants full administrative access to the entire storage account, including all containers and blobs, which violates the principle of least privilege and is not a limited-time or single-file solution. Option C is wrong because assigning an RBAC role and requiring Microsoft Entra ID authentication would still require the user to authenticate, which contradicts the requirement of 'without requiring authentication.' Option D is wrong because setting the container's public access level to Blob makes all blobs in the container anonymously readable indefinitely, which does not provide time-limited access and bypasses the need for a SAS token.
A IoT command API runs in Azure App Service and must call a private API hosted inside a virtual network. Which feature allows outbound access from the app to the VNet?
A.Regional VNet integration
B.Azure CDN custom domain
C.Application Gateway path routing
D.Private Endpoint for the web app only
AnswerA
Regional VNet integration enables App Service outbound connectivity to resources in a virtual network.
Why this answer
Regional VNet integration enables an Azure App Service app to make outbound calls to resources in a virtual network (VNet) using the app's outbound IP addresses. It works by injecting the app's outbound traffic into the VNet via a delegated subnet, allowing the app to reach private APIs hosted inside the VNet without exposing them to the public internet.
Exam trap
The trap here is that candidates often confuse Private Endpoint (inbound) with VNet integration (outbound), mistakenly thinking a Private Endpoint on the app allows it to call VNet resources, when in fact it only allows VNet resources to call the app.
How to eliminate wrong answers
Option B is wrong because Azure CDN custom domain is a content delivery feature that caches and serves static content from edge locations; it does not provide outbound connectivity from an App Service to a VNet. Option C is wrong because Application Gateway path routing is an inbound traffic management feature that routes external HTTP/S requests to backend pools; it does not enable outbound access from the app to the VNet. Option D is wrong because Private Endpoint for the web app only secures inbound traffic to the app from the VNet; it does not allow the app to make outbound calls to resources inside the VNet.
You need to create a custom RBAC role that allows a security group to start and stop Azure virtual machines in a specific resource group, but not delete them or modify their network interfaces. Which set of actions should you include in the role definition?
A.Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/deallocate/action
B.Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/powerOff/action
C.Microsoft.Compute/virtualMachines/restart/action and Microsoft.Compute/virtualMachines/deallocate/action
D.Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/write
AnswerA
This combination correctly grants the precise permissions required to start and stop Azure Virtual Machines. The Microsoft.Compute/virtualMachines/start/action allows powering on a VM from a stopped or deallocated state. Conversely, Microsoft.Compute/virtualMachines/deallocate/action stops the VM and releases its associated compute resources, which is the standard and most cost-effective "stop" operation in Azure. These actions adhere to the principle of least privilege by not including permissions for deletion or configuration changes.
Why this answer
The custom RBAC role needs to allow starting and stopping (deallocating) VMs without permitting deletion or network interface modifications. The actions Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/deallocate/action precisely grant the ability to start a VM and deallocate it (which stops and releases resources), while excluding delete or write permissions on the VM or its network interfaces.
Exam trap
The trap here is that candidates confuse 'powerOff' (which stops the VM but keeps it allocated and billable) with 'deallocate' (which stops and releases resources), leading them to choose Option B instead of the correct deallocate action.
How to eliminate wrong answers
Option B is wrong because Microsoft.Compute/virtualMachines/powerOff/action only stops the VM but does not deallocate it, leaving the VM in a 'stopped' state that still incurs compute costs; the question requires the ability to stop (deallocate) the VM to release resources. Option C is wrong because Microsoft.Compute/virtualMachines/restart/action is not a stop operation—it restarts the VM, which does not fulfill the requirement to stop the VM. Option D is wrong because Microsoft.Compute/virtualMachines/write grants the ability to modify the VM resource, including deleting it or changing its configuration, which violates the requirement to prevent deletion or modification of network interfaces.
You deploy a web application to Azure App Service. You need to deploy a new version of the application without downtime and have the ability to test the new version before switching traffic. Which feature should you use?
A.Deployment slots
B.Auto-scaling
C.Backup
D.Custom domains
AnswerA
Azure App Service deployment slots provide a separate, live environment for your web application, distinct from the production slot. This enables you to deploy new application versions to a staging slot, test them thoroughly, and then perform a near-instantaneous swap with the production slot. This process ensures zero downtime for end-users during deployments and allows for easy rollback if issues are discovered post-swap, making it ideal for continuous delivery.
Why this answer
Deployment slots are live, independently running app versions in Azure App Service that allow you to deploy a new build to a staging slot, validate it with zero impact on production, and then swap it into production with instant traffic redirection. This swap operation is atomic and warm-up aware, ensuring no downtime during the transition.
Exam trap
The trap here is that candidates confuse auto-scaling with deployment strategies, thinking scaling out instances can serve new code without downtime, but auto-scaling only replicates the existing app version and does not provide a mechanism to test or switch traffic between builds.
How to eliminate wrong answers
Option B (Auto-scaling) is wrong because it adjusts the number of instances based on load metrics, not for staging or testing new code versions. Option C (Backup) is wrong because it creates point-in-time copies of app files and databases for disaster recovery, not for zero-downtime deployment or pre-production validation. Option D (Custom domains) is wrong because it maps a DNS name to the app's endpoint and has no role in deployment staging or traffic switching.
You are designing a solution that stores customer order data in Azure Table Storage. The data includes OrderID (string), CustomerID (string), OrderDate (datetime), and TotalAmount (decimal). You need to query orders for a specific customer within a date range efficiently. Which partition key and row key design should you use?
Setting CustomerID as the PartitionKey ensures that all orders belonging to a single customer are stored within the same logical partition. This design optimizes for customer-specific queries, allowing for highly efficient retrieval of all orders for a given customer. Furthermore, using OrderDate (with inverted ticks for descending order) as the RowKey enables fast range queries to fetch a customer's most recent orders or orders within a specific date range, leveraging the RowKey's sorted nature within the partition.
Why this answer
Azure Table Storage queries are most efficient when they use PartitionKey for exact matches and RowKey for range scans. By setting PartitionKey = CustomerID, all orders for a specific customer are stored in the same partition, allowing fast retrieval. Using RowKey = OrderDate (inverted ticks for descending order) enables efficient date-range filtering within that partition, as Azure Table Storage supports range queries on RowKey.
Exam trap
The trap here is that candidates often choose PartitionKey = OrderDate thinking it enables date-range queries, but they overlook that Azure Table Storage requires PartitionKey to be an exact match for efficient queries, and date-range filtering must be done on RowKey within a single partition.
How to eliminate wrong answers
Option A is wrong because PartitionKey = OrderDate scatters orders for the same customer across many partitions, requiring a full table scan to gather all orders for a customer. Option C is wrong because PartitionKey = OrderDate has the same scattering issue, and RowKey = CustomerID does not support efficient date-range filtering within a partition. Option D is wrong because PartitionKey = OrderID creates a unique partition per order, making it impossible to query all orders for a customer without scanning every partition.
You have multiple Azure virtual machines that need to access the same Azure Key Vault to retrieve certificates. You want to minimize administrative overhead while ensuring each VM can authenticate without managing credentials. Which identity type should you use?
A.System-assigned managed identity on each VM
B.User-assigned managed identity assigned to each VM
C.Service principal with client secret stored in each VM
D.Storage account key
AnswerB
A user-assigned managed identity is a standalone Azure resource that can be created once and then assigned to multiple Azure VMs. This approach centralizes identity management, as you only need to grant access permissions to the target resource, such as Azure Key Vault, to this single user-assigned identity. All assigned VMs can then leverage this identity, drastically reducing administrative overhead and simplifying permission management across your fleet of virtual machines.
Why this answer
A user-assigned managed identity can be created once and then assigned to multiple Azure VMs, allowing all of them to authenticate to the same Key Vault without storing any credentials. This minimizes administrative overhead compared to managing separate system-assigned identities or service principals, as the identity is independent of any single VM's lifecycle and can be reused across resources.
Exam trap
The trap here is that candidates often choose system-assigned managed identities (Option A) because they seem simpler per-VM, but they overlook the administrative overhead of managing separate access policies for each VM when multiple VMs require identical access to the same Key Vault.
How to eliminate wrong answers
Option A is wrong because system-assigned managed identities are tied to the lifecycle of each individual VM, meaning you would need to configure Key Vault access policies separately for each VM's identity, increasing administrative overhead when multiple VMs need identical access. Option C is wrong because storing a service principal's client secret on each VM reintroduces credential management overhead and security risks, contradicting the goal of minimizing administrative overhead and avoiding credential management. Option D is wrong because a storage account key is used for authenticating to Azure Storage, not Azure Key Vault, and it would require storing and rotating a shared secret across all VMs, which is insecure and high-overhead.
A company develops a web app that processes images uploaded by users. The app uses Azure Cognitive Services to analyze images for moderation. The solution must minimize latency when calling the Cognitive Services endpoint. Which service should the developer use to call the endpoint?
A.Azure Traffic Manager
B.Azure Front Door
C.Azure API Management
D.Azure Blob Storage with a public endpoint
AnswerB
Azure Front Door is a global, scalable entry-point that uses Microsoft's global edge network to provide fast, secure, and highly available web applications. It acts as a reverse proxy, leveraging Anycast IP and TCP split to terminate client connections at the closest edge location, then routing requests over Microsoft's optimized backbone network to the backend. This significantly reduces latency for users and accelerates calls to backend services like Azure Cognitive Services by optimizing the network path and providing caching capabilities, making it ideal for improving global application performance.
Why this answer
Azure Front Door is a global, scalable entry point that uses the Microsoft global edge network to route user traffic to the nearest regional Cognitive Services endpoint. It provides anycast-based acceleration and TLS termination at the edge, which minimizes latency by reducing the number of network hops and enabling connection reuse. This makes it the optimal choice for low-latency calls to Cognitive Services from a web app.
Exam trap
The trap here is that candidates confuse Azure Traffic Manager's DNS-level load balancing with Front Door's application-layer acceleration, assuming both provide similar latency benefits, but only Front Door offers anycast-based edge routing and TLS termination to minimize network hops.
How to eliminate wrong answers
Option A is wrong because Azure Traffic Manager operates at the DNS level and does not provide anycast routing or edge caching; it only distributes traffic based on DNS resolution, which adds DNS lookup latency and does not accelerate the actual HTTP request path. Option C is wrong because Azure API Management is a full API gateway focused on policy enforcement, rate limiting, and transformation, not on global low-latency acceleration; it introduces additional processing overhead and is not designed for edge-based latency minimization. Option D is wrong because Azure Blob Storage with a public endpoint is a storage service for binary data, not a routing or acceleration service; it cannot reduce latency for Cognitive Services API calls and would require the app to manage direct connectivity without any global optimization.
You design an application that writes millions of small sensor readings (each ~100 bytes) to Azure Blob Storage. The data is appended to files every minute and after 7 days it is archived for compliance. You need to minimize write costs and storage costs. Which blob type and tier strategy should you use?
A.Block blobs with Hot tier and a lifecycle rule to move to Cool after 7 days.
B.Append blobs with Hot tier and a lifecycle rule to move to Archive after 7 days.
C.Page blobs with Premium tier.
D.Append blobs with Cool tier and no lifecycle rule.
AnswerB
Append blobs are ideal for append-heavy workloads, Hot tier optimizes write performance, and Archive provides the lowest cost for compliance data not accessed frequently.
Why this answer
Append blobs are optimized for append operations, making them ideal for continuously adding small sensor readings without rewriting existing data, which minimizes write costs. Moving the blobs to the Archive tier after 7 days via a lifecycle rule reduces storage costs for compliance data, as Archive is the lowest-cost tier for infrequently accessed data.
Exam trap
The trap here is that candidates often choose block blobs (Option A) assuming they are the default for all data, overlooking the append blob's specific optimization for append operations and the cost benefits of Archive tier for compliance data.
How to eliminate wrong answers
Option A is wrong because block blobs require rewriting the entire block list for each append operation, leading to higher write costs and inefficiency for millions of small appends. Option C is wrong because page blobs are designed for random read/write access (e.g., VHDs) and use Premium tier, which is expensive and unsuitable for append-heavy sensor data. Option D is wrong because using Cool tier without a lifecycle rule keeps data in Cool tier indefinitely, missing the opportunity to further reduce storage costs by moving to Archive after 7 days.
You are optimizing an Azure API Management instance that handles 10,000 requests per second. You notice that caching is not effective. The cache hit ratio is below 10%. You need to increase the cache hit ratio. What should you do?
A.Use external Azure Cache for Redis
B.Configure cache key to include only relevant query parameters
C.Disable caching for low-traffic APIs
D.Increase the cache size to 5 GB
AnswerB
Optimizing the cache key to include only essential query parameters significantly improves the cache hit ratio by ensuring that logically identical requests map to the same cached response. By explicitly excluding irrelevant parameters (e.g., tracking IDs, timestamps, or optional filters that do not alter the core response content), multiple requests for the same resource will share a single cache entry. This consolidation ensures that the API Management instance can serve more requests directly from the cache, thereby reducing backend load, improving API response times, and maximizing caching efficiency.
Why this answer
The low cache hit ratio indicates that cache keys are too specific, causing each request to miss the cache. By configuring the cache key to include only relevant query parameters, you group similar requests under the same cache key, increasing the likelihood of cache hits. This directly addresses the root cause of poor cache utilization in Azure API Management.
Exam trap
The trap here is that candidates often assume a low cache hit ratio is due to insufficient cache size or backend performance, when the real issue is overly granular cache keys that prevent reuse.
How to eliminate wrong answers
Option A is wrong because switching to external Azure Cache for Redis does not solve the problem of ineffective cache keys; it only changes the cache backend, which may improve performance but not the hit ratio if keys remain overly specific. Option C is wrong because disabling caching for low-traffic APIs would reduce cache usage further, potentially worsening the overall hit ratio and not addressing the key design issue. Option D is wrong because increasing cache size to 5 GB does not fix the fundamental issue of cache key granularity; a larger cache may store more entries but still suffer from low hit rates if keys are too unique.
Refer to the exhibit. You run the above Azure CLI command to upload a blob to Azure Blob Storage. The command fails with the error 'This request is not authorized to perform this operation.' You have verified that the storage account name and container name are correct, and the file exists. What should you do to resolve the error?
A.Provide the storage account key using the --account-key parameter or set the AZURE_STORAGE_KEY environment variable.
B.Generate a shared access signature (SAS) and use it instead of key.
C.Change --auth-mode key to --auth-mode login.
D.Upgrade to the latest version of Azure CLI.
AnswerA
When `--auth-mode key` is specified, the Azure CLI command requires the storage account's access key to authenticate operations. The error indicates this essential credential is not being supplied. Providing the key directly via the `--account-key` parameter or by setting the `AZURE_STORAGE_KEY` environment variable allows the command to successfully authenticate and execute the intended operation using the chosen key-based method.
Why this answer
The error 'This request is not authorized to perform this operation' indicates that the Azure CLI command did not provide valid credentials for the storage account. By default, Azure CLI uses Azure AD authentication (--auth-mode login), but when the command is run without a logged-in user context or without proper RBAC roles, it fails. Providing the storage account key via --account-key or setting the AZURE_STORAGE_KEY environment variable supplies the shared key for HMAC-SHA256 authorization, which is a fallback authentication method that does not require Azure AD.
Exam trap
The trap here is that candidates assume the error is about network or permissions on the container, but the real issue is that the CLI command lacks any form of authentication credential (key or token), and they may incorrectly think changing to --auth-mode login will fix it without ensuring Azure AD authentication is properly set up.
How to eliminate wrong answers
Option B is wrong because generating a SAS token and using it instead of the key would still require proper authentication; the error is about missing credentials, not the type of credential, and SAS tokens are typically used for delegated access, not for fixing a missing-key issue. Option C is wrong because changing --auth-mode key to --auth-mode login would switch from shared key to Azure AD authentication, which would fail if the user is not logged in or lacks RBAC permissions (e.g., Storage Blob Data Contributor). Option D is wrong because upgrading Azure CLI does not resolve authentication failures; the error is a permissions/credentials issue, not a version incompatibility.
You are designing a serverless data processing pipeline. The pipeline receives JSON messages from an Azure Event Hubs instance. Each message must be enriched with data from a Cosmos DB database and then written to a Parquet file in Azure Data Lake Storage Gen2. The enrichment step involves a lookup that takes approximately 2 seconds per message. The pipeline must process up to 1000 messages per second. You need to choose the most cost-effective and scalable compute option. Consider the following options: A) Use a single Azure Function with Event Hubs trigger and output to Data Lake Storage. B) Use a Durable Functions orchestration with fan-out/fan-in pattern. C) Use Azure Stream Analytics with a reference data input from Cosmos DB and output to Data Lake Storage. D) Use an Azure Databricks notebook with structured streaming. Which option should you recommend?
A.Use a single Azure Function with Event Hubs trigger and output to Data Lake Storage. [wrong]
B.Use a Durable Functions orchestration with fan-out/fan-in pattern.
C.Use Azure Stream Analytics with a reference data input from Cosmos DB and output to Data Lake Storage.
D.Use an Azure Databricks notebook with structured streaming. [wrong]
AnswerC
Scalable, serverless, supports enrichment and Parquet output.
Why this answer
Azure Stream Analytics with a reference data input from Cosmos DB is the most cost-effective and scalable option because it can handle high-throughput streams (up to 1 GB/s) with sub-second latency, and it natively supports enriching incoming events with static or slowly-changing reference data (like Cosmos DB) without requiring custom code. The enrichment lookup is performed in-memory within the Stream Analytics job, avoiding per-message function invocation overhead and enabling linear scale-out across streaming units to meet 1000 messages/second with a 2-second lookup.
Exam trap
The trap here is that candidates often assume Azure Functions are the default serverless choice for all event processing, but they fail to recognize that per-message enrichment with a 2-second lookup creates a throughput bottleneck that only a streaming engine like Stream Analytics can handle cost-effectively at scale.
How to eliminate wrong answers
Option A is wrong because a single Azure Function with an Event Hubs trigger cannot scale to 1000 messages/second with a 2-second enrichment per message — the function would be severely throttled by its concurrency limits (default 200 max per plan) and the 2-second lookup would create a backlog, causing massive event processing delays and potential data loss. Option B is wrong because Durable Functions orchestration with fan-out/fan-in is designed for long-running workflows and stateful coordination, not for high-throughput stateless stream processing; the orchestration overhead and checkpointing would introduce latency and cost that far exceed the requirements. Option D is wrong because Azure Databricks with structured streaming, while scalable, is overkill and cost-inefficient for this simple enrichment and write pipeline — it requires a running cluster with VMs, incurs high per-hour costs, and introduces operational complexity (cluster management, autoscaling delays) that is unnecessary compared to a fully managed serverless service like Stream Analytics.
You manage an API in Azure API Management. You need to cache API responses such that different responses are returned based on the product subscription key used by the caller. Which set of policies should you implement?
A.Set a 'cache-lookup' policy in the inbound section and a 'cache-store' policy in the outbound section, using the subscription key as a cache vary-by parameter.
B.Set a 'cache-store' policy in the inbound section and a 'cache-lookup' policy in the outbound section.
C.Set both 'cache-lookup' and 'cache-store' policies in the inbound section.
D.Set only a 'cache-store' policy in the backend section.
AnswerA
This configuration correctly implements response caching in Azure API Management. The 'cache-lookup' policy in the inbound section efficiently checks for a cached response before forwarding the request to the backend, optimizing performance. If no cached entry is found, the request proceeds, and upon receiving a successful response from the backend, the 'cache-store' policy in the outbound section saves this response for future requests. Using the subscription key as a 'vary-by' parameter ensures that different API consumers receive their specific cached data, maintaining data isolation and correctness.
Why this answer
Caching API responses based on the subscription key ensures that each caller receives a cached response unique to their subscription. The 'cache-lookup' policy in the inbound section checks the cache before forwarding the request, and the 'cache-store' policy in the outbound section stores the response after it is generated. By specifying the subscription key as a vary-by parameter, the cache key includes the subscription key, so different keys produce different cached entries.
Exam trap
The trap here is that candidates often assume caching policies must both be in the inbound section, not realizing that 'cache-lookup' must run before the backend call and 'cache-store' must run after the response is generated, requiring them in inbound and outbound respectively.
How to eliminate wrong answers
Option B is wrong because it reverses the policy placement: 'cache-store' in the inbound section would attempt to store a response before it is generated, and 'cache-lookup' in the outbound section would check the cache after the response is already produced, defeating the purpose of caching. Option C is wrong because placing both policies in the inbound section would attempt to store a response before it is created, and the 'cache-lookup' would not have a response to cache from the outbound flow. Option D is wrong because a 'cache-store' policy alone in the backend section does not include a 'cache-lookup' to retrieve cached responses, and the backend section is not the correct location for response caching; caching policies must be paired in inbound/outbound sections.
You develop an Azure Durable Functions application that orchestrates a series of activities. The orchestrator function calls activity functions that perform long-running tasks. You need to ensure that the orchestrator function can handle transient errors and retry failed activity functions. Which feature should you use?
A.Polly library for retry logic
B.Built-in retry policies in Durable Functions
C.Application Insights alerts
D.Azure Storage queue message retries
AnswerB
Durable Functions provides robust built-in retry policies specifically designed for activity function calls, allowing orchestrators to gracefully handle transient failures. When calling an activity function, the orchestrator can specify `RetryOptions` that include parameters like `MaxNumberOfAttempts`, `FirstRetryInterval`, and `BackoffCoefficient`. This enables the Durable Functions runtime to automatically re-attempt failed activity executions after a specified delay, without requiring any custom retry logic within the activity function itself.
Why this answer
Durable Functions provides built-in retry policies that can be configured directly on activity function calls within orchestrator functions. This allows you to specify parameters such as max retry count, backoff interval, and retry timeout, enabling the orchestrator to automatically retry failed activities without custom code or external dependencies.
Exam trap
The trap here is that candidates may assume any retry mechanism (like Polly or queue retries) works equally well, but they fail to recognize that Durable Functions' built-in retry policies are the only option that integrates seamlessly with the orchestrator's deterministic replay and state management.
How to eliminate wrong answers
Option A is wrong because the Polly library is a general-purpose .NET resilience framework that would require manual integration and does not leverage Durable Functions' native replay and checkpointing mechanisms, leading to potential state inconsistencies. Option C is wrong because Application Insights alerts are used for monitoring and notification, not for implementing retry logic within the orchestrator's execution flow. Option D is wrong because Azure Storage queue message retries apply to queue-triggered functions, not to activity function calls orchestrated by Durable Functions; the orchestrator manages retries at the function invocation level, not via queue message dequeue counts.
A developer is building a microservices application on Azure Kubernetes Service (AKS). One service needs to consume messages from an Azure Service Bus queue. The solution must minimize cost and automatically scale based on the number of messages. Which approach should the developer choose?
A.Use KEDA to scale the pods based on the Service Bus queue length
B.Use Azure Event Grid to route messages to the microservice
C.Use Azure Functions with a Service Bus trigger on a dedicated App Service plan
D.Use the Azure Service Bus SDK in the pod code and manually scale pods
AnswerA
KEDA (Kubernetes Event-driven Autoscaling) is the optimal choice as it directly integrates with Azure Service Bus, enabling event-driven autoscaling for Kubernetes pods. It monitors the Service Bus queue length and automatically scales the number of microservice pods up or down based on the message backlog. This dynamic scaling ensures that compute resources are efficiently utilized, only consuming capacity when demand exists, which significantly optimizes operational costs and maintains application responsiveness.
Why this answer
KEDA (Kubernetes Event-Driven Autoscaling) is the correct choice because it natively integrates with Azure Service Bus to monitor queue length and automatically scale the number of pods in AKS based on that metric. This minimizes cost by scaling to zero when there are no messages and scaling up only as needed, without requiring manual intervention or additional infrastructure.
Exam trap
The trap here is that candidates might choose Azure Functions (Option C) because of its built-in Service Bus trigger, overlooking that the question explicitly requires the solution to run on AKS and minimize cost, whereas Functions on a dedicated plan incurs higher cost and is not part of the AKS microservices architecture.
How to eliminate wrong answers
Option B is wrong because Azure Event Grid is a publish-subscribe event routing service, not designed for consuming messages from a queue; it would require additional components to handle message processing and does not provide built-in autoscaling based on queue depth. Option C is wrong because Azure Functions with a Service Bus trigger on a dedicated App Service plan incurs higher costs compared to KEDA on AKS, and it moves the workload outside the microservices architecture on AKS, violating the requirement to minimize cost and stay within the AKS environment. Option D is wrong because manually scaling pods using the Azure Service Bus SDK in the pod code defeats the purpose of automatic scaling and increases operational overhead, making it inefficient and cost-ineffective.
Your company uses Azure App Service to host a web application. You need to allow only authenticated users from your Microsoft Entra ID tenant to access the app, without writing any authentication code. Which feature should you configure?
A.Azure App Service Authentication (EasyAuth) with Microsoft Entra ID as identity provider.
B.IP restrictions in the app’s web.config.
C.Client certificate authentication.
D.Shared access signatures (SAS) for the app URL.
AnswerA
Azure App Service Authentication, often referred to as EasyAuth, is the correct choice because it provides a built-in, no-code solution for integrating identity providers like Microsoft Entra ID directly into your web application. It automatically handles the entire authentication flow, including redirecting unauthenticated requests, token acquisition, validation, and session management. This offloads complex security concerns from the application code, allowing developers to secure their web applications with minimal effort and without modifying the application's codebase.
Why this answer
Azure App Service Authentication (EasyAuth) is the correct feature because it provides a built-in, code-free way to authenticate users by integrating with Microsoft Entra ID (formerly Azure AD). When configured, the App Service automatically validates tokens and redirects unauthenticated users to the identity provider, enforcing authentication at the platform level without requiring any changes to the application code.
Exam trap
The trap here is that candidates often confuse network-level access controls (like IP restrictions) with identity-based authentication, or mistakenly think SAS tokens can secure a web app URL, when in fact SAS are strictly for Azure Storage access and have no role in user authentication for App Service.
How to eliminate wrong answers
Option B is wrong because IP restrictions in web.config control network-level access based on source IP addresses, not user authentication; they cannot verify a user's identity or enforce Entra ID authentication. Option C is wrong because client certificate authentication requires the application to explicitly validate the certificate in code and does not integrate with Microsoft Entra ID for user authentication. Option D is wrong because Shared Access Signatures (SAS) are used to grant delegated access to Azure Storage resources (e.g., blobs, queues), not to authenticate users accessing a web application URL.
You are troubleshooting an Azure Function that intermittently throws exceptions. You have enabled Application Insights. You need to capture the exact line of code that caused the exception, even for exceptions that occur during high load. Which feature should you use?
A.Snapshot Debugger
B.Application Insights Profiler
C.Live Metrics Stream
D.SQL Insights
AnswerA
The Snapshot Debugger is specifically designed to diagnose intermittent issues in live Azure applications by automatically collecting debug snapshots when an exception occurs. It captures the full call stack and local variables at the exact moment of the exception, without impacting the running application's performance. This allows developers to inspect the state of the application at the point of failure, even for non-reproducible errors, making it ideal for troubleshooting intermittent exceptions in an Azure Function.
Why this answer
Snapshot Debugger is the correct choice because it captures a point-in-time snapshot of the call stack and local variables at the exact line where an exception occurs, even under high load. This allows you to see the precise line of code and state that caused the failure, which is essential for diagnosing intermittent exceptions. Application Insights integrates Snapshot Debugger to automatically collect these snapshots for thrown exceptions without requiring manual instrumentation.
Exam trap
The trap here is that candidates confuse Profiler (performance tracing) with Snapshot Debugger (exception debugging), assuming both capture code-level details, but only Snapshot Debugger provides the exact line of code and variable state at the moment of failure.
How to eliminate wrong answers
Option B is wrong because Application Insights Profiler traces performance bottlenecks by sampling CPU and request durations, not capturing exception call stacks or line-level details. Option C is wrong because Live Metrics Stream provides real-time monitoring of metrics like request rate and failure count, but it does not capture snapshots or line-of-code details for individual exceptions. Option D is wrong because SQL Insights focuses on diagnosing database query performance and deadlocks, not application-level exception line numbers.
A business process requires sending an approval email, waiting up to 48 hours for a manager's response, and then updating a SharePoint list based on the decision. The process owner has no programming experience and wants to build this without writing code. Which Azure service is the most appropriate?
A.Azure Logic Apps with the Office 365 Outlook approval action and the SharePoint connector
B.Azure Durable Functions with the Human Interaction pattern using a timer and event listener
C.Azure Data Factory with a Copy Activity pipeline triggered by an Azure Function
D.Azure Event Grid with a custom webhook handler that calls the SharePoint REST API
AnswerA
The Logic Apps approval action sends an email with Approve/Reject buttons and suspends the workflow run (using Azure's durable storage) until the response arrives or the timeout expires. The SharePoint connector's 'Update item' action then writes the outcome to the list. The entire workflow is configured without code using the Logic Apps Designer.
Why this answer
Azure Logic Apps is the correct choice because it provides a no-code/low-code designer that allows the process owner to visually build the approval workflow using the Office 365 Outlook 'Send approval email' action and the SharePoint connector to update the list. This fully meets the requirement of no programming experience while handling the 48-hour wait and conditional update.
Exam trap
The trap here is that candidates may over-engineer the solution by choosing Durable Functions (Option B) because they recognize the Human Interaction pattern, but they overlook the explicit 'no programming experience' constraint that makes Logic Apps the only viable choice.
How to eliminate wrong answers
Option B is wrong because Azure Durable Functions require writing code in C#, JavaScript, or Python to implement the Human Interaction pattern, which violates the 'no programming experience' requirement. Option C is wrong because Azure Data Factory is designed for data movement and transformation pipelines, not for human approval workflows or sending emails. Option D is wrong because Azure Event Grid is a pub/sub event routing service that requires a custom webhook handler (typically an Azure Function or web app) to process the approval logic and call the SharePoint REST API, which again requires coding.
You are designing a solution to store user-uploaded images. The images are accessed infrequently (a few times per month) and must be available for download within seconds when requested. You need to minimize storage costs while meeting the access requirements. Which Azure Blob Storage access tier should you choose for the container?
A.Hot tier
B.Cool tier
C.Cold tier
D.Archive tier
AnswerB
The Cool tier provides an optimal balance for data that is accessed infrequently, typically a few times per month, while still requiring sub-second latency for retrieval. It offers lower storage costs compared to the Hot tier, with slightly higher access costs. This tier is well-suited for user-uploaded images where immediate availability is expected upon request, but the overall access frequency is not high enough to justify the Hot tier's premium.
Why this answer
The Cool tier is optimal because the images are accessed infrequently (a few times per month) but require immediate download within seconds. Cool tier offers lower storage costs than Hot tier while maintaining low-latency access (milliseconds), meeting the access requirement without incurring the higher storage cost of Hot tier.
Exam trap
The trap here is that candidates often confuse 'infrequent access' with 'cold storage' and choose Cold or Archive tiers, failing to recognize that 'available within seconds' eliminates any tier requiring rehydration (Archive) or having a 90-day minimum duration (Cold).
How to eliminate wrong answers
Option A is wrong because the Hot tier is designed for frequent access (multiple times per day) and has higher storage costs, which would unnecessarily increase costs for infrequently accessed images. Option C is wrong because the Cold tier is intended for data accessed at most once per quarter (every 90 days) and has a higher minimum storage duration (90 days) and early deletion fee, making it cost-inefficient for monthly access patterns. Option D is wrong because the Archive tier has the lowest storage cost but requires rehydration (taking hours, not seconds) before data can be downloaded, violating the requirement that images be available within seconds.
Which TWO approaches can you use to call an external REST API from an Azure Function while ensuring the API key is not exposed in the function code?
Select 2 answers
A.Store the API key in GitHub repository secrets.
B.Hardcode the API key in the function code.
C.Store the API key as an environment variable in the function app settings.
D.Pass the API key in an HTTP header and include it in the source code.
E.Store the API key in Azure Key Vault and retrieve it using Managed Identity.
AnswersC, E
Storing the API key as an application setting within the Azure Function App configuration is a standard and secure practice for managing secrets. These settings are exposed to the function code as environment variables at runtime, keeping the sensitive key out of the source code. This approach allows for independent management, updates without code redeployment, and benefits from Azure's platform-level access controls.
Why this answer
Storing the API key in the function app settings (environment variables) keeps it out of the source code and allows the function to access it via the `Environment.GetEnvironmentVariable` method at runtime. Option E is correct because Azure Key Vault, combined with a Managed Identity, provides a secure, auditable, and rotation-friendly way to store secrets without embedding them in code or configuration files.
Exam trap
The trap here is that candidates often confuse storing secrets in environment variables (which is acceptable for app settings) with storing them in source code or CI/CD secrets, and they may overlook that Managed Identity with Key Vault is the recommended enterprise pattern for production-grade secret management.
You are a developer for a company that runs a critical e-commerce application on Azure. The application consists of an Azure App Service web app, an Azure SQL Database, and an Azure Cache for Redis. The web app experiences occasional performance degradation that you suspect is due to inefficient database queries caused by caching issues. You have enabled Application Insights on the web app. You need to identify the root cause of the performance issues and optimize the solution. The solution must minimize cost and administrative overhead. You have the following options:
Option A: Configure Azure SQL Database Intelligent Insights to automatically tune database queries.
Option B: Use Application Insights Profiler to capture and analyze database query performance.
Option C: Implement Redis cache-aside pattern and ensure that all database queries check the cache first.
Option D: Enable Azure SQL Database Query Performance Insight to identify the most costly queries and then implement caching.
Which option should you recommend?
A.Implement Redis cache-aside pattern and ensure that all database queries check the cache first.
C.Enable Azure SQL Database Query Performance Insight to identify the most costly queries and then implement caching.
D.Use Application Insights Profiler to capture and analyze database query performance.
AnswerC
Azure SQL Database Query Performance Insight is specifically designed to identify the top resource-consuming queries based on metrics like CPU, I/O, and duration. This tool allows developers to precisely pinpoint the exact queries causing performance bottlenecks. Once these 'most costly queries' are identified, implementing a targeted optimization, such as the Redis cache-aside pattern for those specific queries, becomes a highly effective and efficient strategy to reduce database load and improve overall application responsiveness.
Why this answer
The scenario requires identifying the root cause of performance degradation due to inefficient database queries caused by caching issues. Query Performance Insight in Azure SQL Database pinpoints the most resource-intensive and longest-running queries, allowing you to target exactly which queries need caching. After identifying these costly queries, implementing a Redis cache-aside pattern reduces redundant database hits, directly addressing the suspected caching issue while minimizing cost and administrative overhead.
Exam trap
The trap here is that candidates may confuse diagnostic tools (like Profiler or Intelligent Insights) with the specific query identification and caching optimization needed, overlooking that Query Performance Insight directly reveals which queries are most costly and thus candidates for caching.
How to eliminate wrong answers
Option A is wrong because Intelligent Insights provides automated tuning and proactive diagnostics for database performance, but it does not directly help identify which queries are causing the caching-related inefficiency; it focuses on index recommendations and query plan regressions, not on caching gaps. Option B is wrong because Application Insights Profiler captures and analyzes end-to-end request traces, including database calls, but it is a diagnostic tool for performance profiling, not a solution for optimizing caching; it adds overhead and cost without directly resolving the caching issue. Option D is wrong because while Application Insights Profiler can help diagnose performance, it does not provide the targeted query-level cost analysis needed to decide which queries to cache; it is better suited for general performance troubleshooting rather than identifying specific costly queries for caching optimization.
A company uses Azure API Management (APIM) to expose APIs to external partners. They need to enforce rate limiting per subscription key. Which APIM policy should be configured?
A.quota
B.rate-limit
C.ip-filter
D.throttling
AnswerB
The "rate-limit" policy in Azure API Management is specifically engineered to restrict the number of API calls a client can make within a precise, short time interval, such as per second or per minute. This policy can be effectively scoped to a `subscription-key`, ensuring that individual API consumers are prevented from making excessive requests and thereby protecting backend services from overload. It operates using a sliding or fixed window counter, rejecting requests that exceed the defined threshold until the window resets.
Why this answer
The rate-limit policy in Azure API Management is specifically designed to enforce rate limiting per subscription key, preventing individual API consumers from exceeding a defined number of calls within a specified time window (e.g., per second or per minute). This policy operates on a sliding window counter, ensuring fair usage across partners without affecting other subscribers. It is the correct choice because it directly targets subscription-based throttling at the API gateway level.
Exam trap
The trap here is that candidates confuse the 'quota' policy (which enforces total call volume over a long period) with 'rate-limit' (which enforces call frequency over a short window), or mistakenly think 'throttling' is a valid policy name when it is actually a deprecated term replaced by 'rate-limit' in Azure API Management.
How to eliminate wrong answers
Option A is wrong because the quota policy enforces a total number of calls over a longer period (e.g., per day, week, or month) and does not provide the per-time-window rate limiting required for subscription keys; it is used for volume-based caps, not rate limiting. Option C is wrong because the ip-filter policy restricts access based on client IP addresses, not subscription keys, and is used for security filtering rather than rate limiting. Option D is wrong because the throttling policy is a legacy name for rate limiting in older APIM documentation, but the correct current policy name is 'rate-limit'; 'throttling' is not a valid policy identifier in Azure API Management and would cause a configuration error.
You manage an API in Azure API Management. You need to enforce a rate limit of 200 requests per minute for each subscription key. Which policy should you include in the inbound policy section?
A.<rate-limit> policy
B.<quota> policy
C.<limit-concurrency> policy
D.<throttle> policy
AnswerA
The <rate-limit> policy is designed to restrict the number of API calls a client can make within a specified short time interval, such as per minute or per second. It operates using a sliding window mechanism, continuously evaluating the call count against the defined limit. This policy is crucial for preventing bursts of traffic, protecting backend services from overload, and ensuring fair usage across consumers by enforcing immediate call rate constraints.
Why this answer
The <rate-limit> policy in Azure API Management is specifically designed to enforce a per-subscription key rate limit, such as 200 requests per minute. It operates on a sliding window counter to smooth traffic and is applied in the inbound section to evaluate each request before it reaches the backend. This matches the requirement exactly.
Exam trap
The trap here is confusing <rate-limit> with <quota>, as both control request volume, but <quota> applies to total counts over days/months, not per-minute rate limiting.
How to eliminate wrong answers
Option B is wrong because the <quota> policy enforces a total number of requests over a longer period (e.g., 10,000 calls per month), not a per-minute rate limit. Option C is wrong because the <limit-concurrency> policy restricts the number of simultaneous connections, not the request rate over time. Option D is wrong because there is no <throttle> policy in Azure API Management; the correct term is <rate-limit> for per-key throttling.
You develop a C# application that stores sensitive documents in Azure Blob Storage. You need to generate a time-limited shared access signature (SAS) that allows a client to only read and list blobs in a specific container. The SAS must be valid for exactly 1 hour from the current time. Which code snippet correctly creates the SAS? (Assume BlobServiceClient and BlobContainerClient are properly initialized.)
This option correctly configures a container-level Shared Access Signature (SAS) by setting the 'Resource' type to "c", which targets the entire container. It precisely grants 'Read' and 'List' permissions, aligning with a common requirement to allow users to view container contents without modification. The 'StartsOn' and 'ExpiresOn' properties define a secure, short-lived access window starting immediately, ensuring the principle of least privilege and time-bound access for the generated URI.
Why this answer
It sets the `Resource` property to "c" for container-level SAS, uses `StartsOn` as the current UTC time, `ExpiresOn` exactly 1 hour later, and specifies only `Read` and `List` permissions via the `BlobContainerSasPermissions` enum. This combination generates a time-limited SAS URI that allows a client to read and list blobs within the specified container for exactly one hour.
Exam trap
The trap here is confusing the `Resource` property value "c" (container) with "b" (blob), leading candidates to pick Option B, and overlooking that `StartsOn` must be set to the current time (or omitted) to achieve exactly 1 hour validity, not a past time as in Option D.
How to eliminate wrong answers
Option B is wrong because it sets `Resource = "b"`, which is intended for blob-level SAS, not container-level SAS; this would generate a SAS that applies to a single blob rather than the entire container, failing the requirement to list blobs. Option C is wrong because it uses `Permissions = BlobContainerSasPermissions.All`, which grants full control (including delete, write, etc.) instead of restricting to only Read and List permissions, violating the principle of least privilege. Option D is wrong because it sets `StartsOn = DateTimeOffset.UtcNow.AddDays(-1)`, making the SAS valid from 24 hours in the past; this means the SAS is already active for a full day before the current time, not exactly 1 hour from now as required.
You are building a serverless application that needs to react to insertions and updates in an Azure Cosmos DB container. You want to process these changes using an Azure Function. Which trigger should you configure for the function?
A.Cosmos DB trigger
B.Blob trigger
C.Event Grid trigger
D.Service Bus trigger
AnswerA
The Azure Cosmos DB trigger is the native and most efficient mechanism for building serverless applications that react to changes in a Cosmos DB container. It directly leverages the built-in change feed functionality of Cosmos DB, which provides a persistent, ordered log of all document inserts, updates, and optionally deletes. This allows an Azure Function to process data modifications in near real-time without the need for inefficient polling, making it ideal for event-driven architectures.
Why this answer
A Cosmos DB trigger is the correct choice because it is specifically designed to react to changes in a Cosmos DB container by leveraging the change feed. The Azure Function runtime polls the change feed for inserts and updates, invoking the function with batches of documents as they occur. This provides a native, serverless integration without needing additional services.
Exam trap
The trap here is that candidates may confuse the Cosmos DB trigger with the Event Grid trigger, thinking Event Grid can directly subscribe to Cosmos DB changes, but Event Grid requires a custom event publisher or a separate Azure service like Azure Functions to bridge the change feed.
How to eliminate wrong answers
Option B is wrong because a Blob trigger reacts to changes in Azure Blob Storage (blob creation or updates), not to changes in a Cosmos DB container. Option C is wrong because an Event Grid trigger handles events from various Azure services (e.g., resource creation, blob events) but does not natively subscribe to the Cosmos DB change feed; it would require custom event publishing. Option D is wrong because a Service Bus trigger processes messages from a Service Bus queue or topic, which is a messaging system unrelated to Cosmos DB data changes.
A company stores secrets (e.g., connection strings) in Azure Key Vault and needs them automatically rotated every 90 days. Which solution should they implement?
A.Configure Key Vault access policies to enforce rotation
B.Enable Key Vault firewall to limit access
C.Use Event Grid to trigger an Azure Function or Automation runbook that rotates the secret
D.Enable soft-delete on the vault
AnswerC
This is the recommended and most robust pattern for automating secret rotation. Azure Key Vault integrates with Azure Event Grid, which can publish events such as 'SecretNearExpiry' when a secret is approaching its expiration date. Subscribing to these events allows an Azure Function or an Azure Automation runbook to be automatically triggered. This triggered logic can then programmatically generate a new secret, update it in the Key Vault, and subsequently update any applications or services that consume that secret, providing a fully automated and proactive rotation solution.
Why this answer
Azure Key Vault does not natively support automatic secret rotation; you must implement a custom solution using Event Grid to detect expiration events and trigger an Azure Function or Automation runbook that generates a new secret and updates the vault. This pattern leverages Key Vault's eventing capabilities to automate the rotation workflow without manual intervention.
Exam trap
The trap here is that candidates assume Key Vault has a built-in rotation feature, but Azure Key Vault only stores secrets and requires an external automation trigger (Event Grid + Azure Function) to implement rotation logic.
How to eliminate wrong answers
Option A is wrong because Key Vault access policies control permissions (who can read/write secrets), not rotation logic; they cannot enforce a schedule or automate secret renewal. Option B is wrong because enabling the Key Vault firewall restricts network access to the vault for security, but does not implement any rotation mechanism. Option D is wrong because soft-delete protects against accidental deletion by retaining deleted secrets for a configurable retention period, but it does not automate rotation or renewal of secrets.
You are designing a solution that runs background jobs to process images. The jobs can run up to 10 minutes each. You need to ensure the jobs are resilient to failures and can be retried automatically. Which Azure service should you use?
A.Azure Logic Apps with a recurrence trigger
B.Azure Queue Storage with an Azure Function trigger
C.Azure Service Bus with a WebJob
D.Azure Event Grid with a Logic App
AnswerB
Azure Queue Storage provides a highly reliable and scalable messaging solution, perfect for decoupling background job requests. When a message is added, an Azure Function is triggered, offering automatic scaling based on queue depth and cost-effective, consumption-based execution. This combination inherently supports automatic retries for transient failures and robust poison message handling, ensuring durable and resilient processing of potentially long-running background tasks without manual intervention.
Why this answer
Azure Queue Storage with an Azure Function trigger is the correct choice because it provides a reliable, message-based architecture for background job processing. Queue messages persist until processed, and the Azure Function trigger automatically retries on failure (up to 5 times by default, with configurable policies). This handles the 10-minute job duration via the queue's visibility timeout, which can be set to match the job's maximum runtime, ensuring messages are not prematurely reprocessed.
Exam trap
The trap here is that candidates often confuse Azure Queue Storage with Azure Service Bus, assuming Service Bus is always better for reliability, but Queue Storage is simpler, cheaper, and perfectly suited for long-running background jobs with automatic retry via Azure Functions.
How to eliminate wrong answers
Option A is wrong because Azure Logic Apps with a recurrence trigger is designed for scheduled, time-based workflows, not for resilient, failure-retry background job processing triggered by queue messages. Option C is wrong because Azure Service Bus with a WebJob is overly complex for this scenario; WebJobs are a legacy technology and Service Bus is better suited for enterprise messaging with advanced features like sessions and transactions, not simple image processing jobs. Option D is wrong because Azure Event Grid with a Logic App is an event-driven pattern for reacting to events (e.g., blob created), but it lacks built-in retry and queue-based persistence for long-running jobs; Event Grid has a 5-minute timeout and no native retry for failed processing.
You need to store large files that are written once and then frequently read for the first 30 days. After 30 days, the files are rarely accessed (once or twice per year) but must remain available for 5 years. You want to minimize storage costs. Which storage tier and lifecycle management rule should you apply?
A.Hot tier with a lifecycle rule to move to Cool after 30 days
B.Cool tier with a lifecycle rule to move to Archive after 30 days
C.Hot tier with a lifecycle rule to move to Archive after 30 days
D.Archive tier with a lifecycle rule to move to Cool after 30 days
AnswerA
Hot tier provides low latency for frequent reads. After 30 days, moving to Cool reduces cost while maintaining reasonable access for rare reads.
Why this answer
The Hot tier is optimized for frequent reads, and the lifecycle rule moves data to the Cool tier after 30 days when access drops, balancing performance and cost. After 30 days, the files are rarely accessed, so moving them to Cool (not Archive) keeps them available for occasional reads without the high retrieval costs and latency of Archive. This minimizes storage costs while meeting the 5-year retention requirement.
Exam trap
The trap here is that candidates assume Archive is always cheapest for long-term storage, ignoring the retrieval cost and latency for the rare but annual reads, and overlook the 30-day minimum billing period in Archive.
How to eliminate wrong answers
Option B is wrong because starting in the Cool tier incurs higher write costs and lower initial performance for the first 30 days of frequent reads, which is not cost-effective. Option C is wrong because moving directly to Archive after 30 days would impose a 30-day minimum billing period and high retrieval costs for the rare but annual reads, making it more expensive than Cool. Option D is wrong because starting in the Archive tier is designed for cold data with infrequent access, but the first 30 days have frequent reads, leading to unacceptable latency and high rehydration costs.
You are using Azure Logic Apps to integrate with a third-party CRM. The CRM API requires OAuth 2.0 authentication with a client secret. The secret must be stored securely and rotated automatically. What should you do?
A.Use a system-assigned managed identity without storing the secret
B.Store the secret in Azure Key Vault and use a managed identity to access it
C.Store the secret in the Logic App definition as a string parameter
D.Store the secret in Azure App Configuration with encryption
AnswerB
Correct. Store the client secret in Azure Key Vault, which provides secure storage and automatic rotation. Use a managed identity to allow the Logic App to retrieve the secret securely.
Why this answer
The CRM API requires OAuth 2.0 with a client secret, so the secret must be stored securely and support automatic rotation. Azure Key Vault is the appropriate service for storing secrets, and using a managed identity allows secure access without hardcoding credentials. Option A is incorrect because a managed identity alone does not store the secret; the secret must be kept in a vault.
Option C is wrong because storing secrets directly in a Logic App definition is insecure and does not support rotation. Option D is wrong because Azure App Configuration is designed for application settings, not secrets; it lacks automatic secret rotation capabilities.
You need to store millions of small JSON documents (each less than 1 KB) that are accessed by key. The data is read-heavy and requires low-latency access. Which Azure storage solution should you use?
A.Azure Files
B.Azure Table Storage
C.Azure Cosmos DB
D.Azure Blob Storage
AnswerC
Azure Cosmos DB is a globally distributed, multi-model database service designed for high-performance, low-latency applications at any scale. Its native support for the document model, where JSON documents are first-class citizens, makes it perfectly suited for storing millions of small JSON documents. It guarantees single-digit millisecond latency for reads and writes, offers automatic indexing, and provides flexible APIs, ensuring efficient and rapid access to the data.
Why this answer
Azure Cosmos DB is the correct choice because it provides single-digit millisecond latency for point reads by key, supports automatic indexing of JSON documents, and offers a globally distributed, multi-model database service. For millions of small JSON documents accessed by key in a read-heavy workload, Cosmos DB's throughput-provisioned model and consistency levels optimize for low-latency access at scale.
Exam trap
The trap here is that candidates confuse Azure Table Storage's key-value nature with JSON document support, but Table Storage stores entities as flat rows with limited property types and no native JSON indexing, whereas Cosmos DB is purpose-built for JSON documents with automatic indexing and guaranteed low latency.
How to eliminate wrong answers
Option A is wrong because Azure Files provides SMB/NFS file shares with higher latency and is designed for shared file access, not key-value lookups on millions of small JSON documents. Option B is wrong because Azure Table Storage is a NoSQL key-value store but lacks native JSON support, automatic indexing, and single-digit millisecond latency guarantees; it is optimized for structured tabular data, not JSON documents. Option D is wrong because Azure Blob Storage is optimized for large binary objects (blobs) and has higher latency for small objects due to per-blob metadata overhead and lack of native indexing by key; it is not designed for high-throughput point reads on millions of tiny JSON documents.
An application stores customer invoices in Azure Blob Storage. Deleted blobs must be recoverable for 14 days. What should be enabled?
A.Blob soft delete with a 14-day retention period
B.Archive access tier
C.Static website hosting
D.Immutable blob legal hold
AnswerA
Blob soft delete specifically addresses accidental deletion or overwrites by retaining deleted or overwritten blobs in a soft-deleted state for a user-defined period. Configuring a 14-day retention ensures that customer invoices, if accidentally deleted, can be restored to their previous state at any point within those two weeks. This feature provides a robust and straightforward recovery mechanism, making it the primary Azure Storage data protection feature for this scenario.
Why this answer
Blob soft delete protects against accidental deletion by retaining deleted blobs for a specified retention period. Enabling it with a 14-day retention period ensures that deleted invoices remain recoverable for exactly 14 days, meeting the requirement without additional cost or complexity.
Exam trap
The trap here is confusing soft delete (which recovers deleted blobs) with immutable storage (which prevents deletion or modification) or access tiers (which affect storage cost and retrieval speed, not recovery).
How to eliminate wrong answers
Option B is wrong because the Archive access tier is for cost-effective long-term storage with retrieval delays (hours), not for short-term recovery of deleted blobs. Option C is wrong because static website hosting serves web content from a container, not recover deleted blobs. Option D is wrong because an immutable blob legal hold prevents modification or deletion of blobs for legal purposes, but it does not provide a time-limited recovery window for already deleted blobs.
You are developing a web application that will be deployed to Azure App Service. You need to configure automatic scaling based on CPU usage. Which TWO settings should you configure?
Select 2 answers
A.Configure authentication for the scaling endpoint.
B.Set the minimum and maximum instance count.
C.Set the Always On setting to On.
D.Configure a scale in condition based on CPU percentage.
E.Configure a scale out condition based on CPU percentage.
AnswersD, E
Configuring a scale-in condition based on CPU percentage is a fundamental aspect of optimizing resource utilization for an Azure App Service. This rule specifies that when the average CPU utilization across all instances drops below a defined threshold (e.g., 20%) for a sustained period, the autoscaling engine should reduce the number of active instances. This action helps to minimize operational costs during periods of low demand by releasing unnecessary resources.
Why this answer
Configuring a scale-in condition based on CPU percentage allows the App Service plan to automatically reduce the number of instances when CPU usage drops below a defined threshold, which is essential for cost optimization. Option E is correct because configuring a scale-out condition based on CPU percentage enables the platform to automatically add instances when CPU usage exceeds a threshold, ensuring the application can handle increased load. Together, these two settings define the autoscale rules that react to CPU metrics, which is the core requirement for CPU-based automatic scaling.
Exam trap
The trap here is that candidates often confuse the prerequisite settings (like instance count limits) with the actual scaling condition rules, or they think that only one direction (scale-out or scale-in) is needed, but autoscale requires both to be fully defined for CPU-based scaling to work correctly.
You need to allow a client application to read a specific blob from Azure Blob Storage for one hour, without exposing your storage account key. Which approach should you use?
A.Provide the storage account access key to the client
B.Generate a shared access signature (SAS) URI with read permission and expiry of one hour
C.Use Azure RBAC to grant the client the Storage Blob Data Reader role for one hour
D.Make the blob publicly accessible for one hour using a stored access policy
AnswerB
Generating a Shared Access Signature (SAS) URI is the most appropriate and secure method for this scenario. A SAS token provides delegated access to specific Azure Storage resources, allowing precise control over permissions (e.g., read-only), the resource itself (a specific blob), and the duration of access (one hour). This ensures the client can only perform the required action for a limited time, adhering to the principle of least privilege and minimizing security risks by not exposing full account credentials.
Why this answer
A shared access signature (SAS) URI allows you to delegate limited access (read permission) to a specific blob for a defined time period (one hour) without exposing your storage account key. The SAS token is generated using the account key but does not reveal it, ensuring secure, time-bound access.
Exam trap
The trap here is that candidates may confuse RBAC with SAS, thinking RBAC can be used for temporary access, but RBAC does not support built-in expiry and requires manual revocation, whereas SAS provides precise time-bound delegation.
How to eliminate wrong answers
Option A is wrong because providing the storage account access key grants full administrative access to the entire storage account, not just a single blob, and violates the requirement to not expose the key. Option C is wrong because Azure RBAC role assignments (like Storage Blob Data Reader) are not designed for temporary, per-blob access with a one-hour expiry; they are persistent until changed and apply at the storage account, container, or blob level, but cannot be set to auto-expire after one hour without custom scripting. Option D is wrong because making the blob publicly accessible removes all access control, allowing anyone to read it indefinitely until manually changed, and does not provide a one-hour expiry mechanism.
You have an Azure Function app that uses .NET 8 isolated process. The function must connect to an Azure SQL database using a managed identity. The function app has a system-assigned managed identity enabled. Which code snippet correctly retrieves the access token?
A.new SqlConnection(connectionString) using Integrated Security=true;
B.var token = await new Azure.Identity.DefaultAzureCredential().GetTokenAsync("https://database.windows.net");
C.var credential = new DefaultAzureCredential(); var token = await credential.GetTokenAsync(new TokenRequestContext(new[] {"https://database.windows.net/.default"}));
D.var credential = new ManagedIdentityCredential(); var token = await credential.GetTokenAsync("https://database.windows.net");
AnswerC
This option is correct as it properly utilizes the `Azure.Identity` library to obtain an access token for a Managed Identity. `DefaultAzureCredential` intelligently determines the appropriate credential type in an Azure environment, and `GetTokenAsync` is correctly invoked with a `TokenRequestContext` specifying the `https://database.windows.net/.default` scope, which is the standard for Azure SQL Database.
Why this answer
It uses `DefaultAzureCredential` to obtain an access token for Azure SQL Database by specifying the resource URI `https://database.windows.net/.default` in a `TokenRequestContext`. In a .NET 8 isolated process function app with a system-assigned managed identity, `DefaultAzureCredential` automatically attempts managed identity authentication as one of its credential sources, making it the recommended approach. The `GetTokenAsync` method requires a `TokenRequestContext` object, not a plain string, to correctly request the token for the Azure SQL resource.
Exam trap
The trap here is that candidates often forget that `GetTokenAsync` requires a `TokenRequestContext` object with an array of scopes, not a plain string URL, and they may also omit the `/.default` suffix required for Azure SQL Database token requests.
How to eliminate wrong answers
Option A is wrong because `Integrated Security=true` is used for Windows authentication in on-premises environments, not for managed identity authentication to Azure SQL Database; it does not retrieve an access token. Option B is wrong because `GetTokenAsync` expects a `TokenRequestContext` object, not a plain string URL; passing `"https://database.windows.net"` without the `/.default` scope and without wrapping it in a `TokenRequestContext` will cause a compilation error. Option D is wrong because `ManagedIdentityCredential` is valid but the `GetTokenAsync` method still requires a `TokenRequestContext` object, not a plain string; additionally, using `DefaultAzureCredential` is preferred for flexibility in local development and production scenarios.
Your Azure Functions app uses Durable Functions to orchestrate a workflow. The orchestration sometimes fails with a 'FunctionRuntimeException' due to a timeout. You need to increase the maximum orchestration time. What should you modify?
A.Add an app setting 'AzureFunctionsJobHost__functionTimeout'
B.Change the Azure Storage account to a Premium account
C.Increase the 'functionTimeout' in host.json
D.Set 'maxOrchestrationTimeout' in the host.json file
AnswerD
Setting 'maxOrchestrationTimeout' in the host.json file is the correct approach because this specific configuration property, located within the 'durableTask' section, directly controls the maximum allowable wall-clock duration for a Durable Function orchestration instance. If an orchestration exceeds this configured timeout, the Durable Task Framework will automatically terminate it, preventing indefinitely running instances and ensuring proper resource management and application stability.
Why this answer
D is correct because in Durable Functions, the maximum orchestration time is controlled by the 'maxOrchestrationTimeout' setting in the host.json file. This setting specifies the maximum duration an orchestration instance can run before it times out, and increasing it directly addresses the 'FunctionRuntimeException' due to timeout. The default value is 7 days, but you can extend it as needed.
Exam trap
The trap here is that candidates often confuse 'functionTimeout' (for individual function execution) with 'maxOrchestrationTimeout' (for Durable Functions orchestration duration), leading them to incorrectly modify the wrong setting in host.json.
How to eliminate wrong answers
Option A is wrong because 'AzureFunctionsJobHost__functionTimeout' is not a valid app setting; the correct app setting for function timeout is 'AzureFunctionsJobHost:functionTimeout' or 'FUNCTIONS_EXTENSIONVERSION' related settings, but this does not apply to Durable Functions orchestration timeout. Option B is wrong because changing the Azure Storage account to a Premium account improves performance and throughput but does not affect the maximum orchestration timeout; it addresses storage latency, not timeout duration. Option C is wrong because 'functionTimeout' in host.json controls the timeout for individual function executions (e.g., HTTP triggers), not the orchestration timeout in Durable Functions; orchestration timeout is managed separately via 'maxOrchestrationTimeout'.
Your application writes millions of small log entries per hour to an Azure Storage account. You notice throttling errors (HTTP 503) during peak traffic. You need to minimize throttling without changing the application code. What should you do?
A.Request a storage account limit increase from Azure Support
B.Use a separate storage account for log data
C.Change the replication type to geo-redundant storage (GRS)
D.Enable soft delete on the blob container
AnswerB
Using a separate storage account for log data is the correct approach because each Azure Storage account has its own independent set of scalability targets, including maximum request rates and ingress/egress bandwidth. By distributing high-volume workloads, such as millions of small log entries, across multiple storage accounts, the application effectively increases its aggregate throughput capacity. This strategy prevents a single account from hitting its throttling limits, ensuring consistent performance and availability for all data operations.
Why this answer
Using a separate storage account for log data isolates the high-volume write traffic from other workloads, distributing the request load across different storage account endpoints. Azure Storage accounts have scalability targets (e.g., up to 20,000 requests per second per account for blob storage), and splitting logs into a dedicated account prevents hitting those limits, reducing HTTP 503 throttling errors without requiring code changes.
Exam trap
The trap here is that candidates may think throttling can be resolved by increasing limits or changing replication settings, but Azure's scalability targets are fixed per account, and the only way to increase throughput without code changes is to distribute the load across multiple storage accounts.
How to eliminate wrong answers
Option A is wrong because requesting a storage account limit increase from Azure Support does not change the per-account scalability targets (e.g., ingress/egress limits, request rate limits) which are fixed by Azure's architecture; support can only increase quotas for specific resources like capacity, not throughput or request rates. Option C is wrong because changing replication type to geo-redundant storage (GRS) does not affect throttling; GRS provides durability and disaster recovery by replicating data to a secondary region, but it does not increase the request rate or throughput limits of the storage account. Option D is wrong because enabling soft delete on the blob container protects against accidental deletion by retaining deleted blobs for a retention period, but it has no impact on request throttling or storage account scalability limits.
You are designing a cost-effective solution to store log files that are accessed infrequently after 30 days. The logs must be retained for 7 years for compliance. Data must be available within 1 hour of a request. Which Azure Blob Storage access tier and lifecycle management rule should you use?
A.Use Hot tier initially, then move to Archive after 30 days, and delete after 7 years.
B.Use Archive tier immediately and set a lifecycle rule to delete after 7 years.
C.Use Cool tier initially, then move to Archive after 30 days, and delete after 7 years.
D.Use Hot tier for 30 days, then Cool tier until 90 days, then Archive tier until deletion after 7 years.
AnswerD
This strategy provides an optimal balance between cost-effectiveness and data accessibility requirements for log files. The Hot tier ensures immediate, low-cost access for frequently used recent logs (e.g., first 30 days). Transitioning to the Cool tier for the next period (e.g., 30-90 days) reduces storage costs for data that is less frequently accessed but still potentially needed. Finally, moving to the Archive tier for long-term retention (up to 7 years) minimizes costs for rarely accessed historical data, aligning perfectly with typical log data lifecycle patterns.
Why this answer
It balances cost and compliance: the Hot tier handles initial frequent writes, Cool tier reduces cost for infrequent access after 30 days, and Archive tier provides the lowest-cost storage for long-term retention while still allowing rehydration within 1 hour (via High Priority rehydration). The lifecycle rule deletes the blobs after 7 years to meet compliance requirements.
Exam trap
The trap here is that candidates often overlook the 1-hour availability requirement and choose Archive tier immediately (Option B) or skip the Cool tier (Option A), not realizing that Archive rehydration can take up to 15 hours unless High Priority is explicitly used, and that Hot tier is more cost-effective for the initial high-write period.
How to eliminate wrong answers
Option A is wrong because moving directly from Hot to Archive after 30 days skips the Cool tier, which would incur higher costs for the infrequent access period (30–90 days) compared to using Cool tier. Option B is wrong because storing logs immediately in Archive tier prevents timely access (rehydration can take up to 15 hours, exceeding the 1-hour requirement) and does not address the initial 30-day period where logs are accessed frequently. Option C is wrong because it uses Cool tier initially, but the logs are accessed frequently in the first 30 days, making Hot tier more cost-effective for writes; Cool tier has higher write costs and lower availability for frequent access.
You find the above ARM template snippet in a deployment. What is the effect of this configuration on the App Service?
A.Allows cross-origin requests from app.contoso.com and portal.contoso.com without credentials.
B.Configures the App Service to require authentication for cross-origin requests.
C.Enables CORS for all origins by setting allowedOrigins to a wildcard.
D.Blocks all cross-origin requests because supportCredentials is false.
AnswerA
The `allowedOrigins` property explicitly lists `https://app.contoso.com` and `https://portal.contoso.com`, granting these specific domains permission to make cross-origin requests to the App Service. Concurrently, `supportCredentials: false` dictates that the browser should not include credentials, such as cookies, HTTP authentication headers, or client-side SSL certificates, with these permitted cross-origin requests. This configuration enables secure communication from the specified front-end applications to the App Service API without relying on credential-based authentication at the CORS level.
Why this answer
The ARM template snippet sets `allowedOrigins` to specific domains (`app.contoso.com` and `portal.contoso.com`) and `supportCredentials` to `false`. This configuration allows cross-origin requests from those two origins but does not include credentials (cookies, HTTP authentication, or client-side certificates) in the requests, as per the CORS specification.
Exam trap
The trap here is that candidates often confuse `supportCredentials: false` with blocking all cross-origin requests, when in fact it only disallows credentials while still allowing non-credentialed requests from the specified origins.
How to eliminate wrong answers
Option B is wrong because CORS does not require authentication; it controls which origins can make cross-origin requests, and `supportCredentials` being `false` means credentials are not sent, not that authentication is required. Option C is wrong because `allowedOrigins` is set to specific domains, not a wildcard (`*`), so it does not enable CORS for all origins. Option D is wrong because `supportCredentials: false` does not block all cross-origin requests; it only prevents credentials from being included in the requests, while the allowed origins can still make non-credentialed requests.
A developer is implementing Key Vault certificate retrieval. The application runs on Azure App Service and must avoid stored credentials. Which design should be used?
A.Use a shared administrator account
B.Store a client secret in source control
C.Enable managed identity and grant least-privilege access to the target resource
D.Disable authentication for the target resource
AnswerC
Enabling managed identity for an Azure-hosted application provides a highly secure and recommended method for authenticating to Azure resources like Key Vault. This approach eliminates the need for developers to manage, store, or rotate any credentials or client secrets within their code or configuration. By assigning the managed identity specific, least-privilege access roles to the target Key Vault, the application can securely retrieve certificates while adhering to robust security principles, significantly reducing the attack surface.
Why this answer
Azure App Service supports Managed Identity, which allows the application to authenticate to Key Vault without storing any credentials in code or configuration. By enabling a system-assigned or user-assigned managed identity and granting it least-privilege access (e.g., via an access policy with `Get` permission for secrets), the app can securely retrieve certificates using the Azure Identity SDK's `DefaultAzureCredential` class, which automatically obtains an access token from Azure AD.
Exam trap
The trap here is that candidates might think storing a client secret in source control is acceptable if the repo is private, but Azure explicitly forbids this in security best practices, and the question requires 'avoid stored credentials' entirely.
How to eliminate wrong answers
Option A is wrong because using a shared administrator account violates the principle of least privilege and introduces a security risk; credentials would need to be stored or hardcoded, defeating the goal of avoiding stored credentials. Option B is wrong because storing a client secret in source control exposes it to unauthorized access, breaches security best practices, and contradicts the requirement to avoid stored credentials. Option D is wrong because disabling authentication for the target resource (Key Vault) would allow anonymous access, which is a severe security vulnerability and not a valid design for production workloads.
Your Azure Function app uses an Event Hub trigger. Under high load, some events are processed multiple times. You need to ensure exactly-once processing without losing events. What should you implement?
A.Make the function idempotent
B.Use Azure Queue Storage instead
C.Enable checkpointing
D.Increase the batch size
AnswerA
When an Azure Function processes Event Hub messages, especially under high load or transient errors, messages can be delivered multiple times due to the at-least-once delivery guarantee. Implementing idempotency means designing the function's logic so that processing the same event multiple times produces the same result as processing it once, without adverse side effects. This typically involves using a unique identifier from the event to check if the operation has already been completed before performing it again, often by storing processing status in a durable store like Azure Cosmos DB or Table Storage.
Why this answer
Making the function idempotent ensures that even if the Event Hub trigger delivers the same event multiple times (which can happen under high load due to at-least-once delivery semantics), the function's side effects are safe to repeat. Idempotency is the only reliable way to achieve exactly-once processing in a distributed system where the trigger itself does not guarantee deduplication.
Exam trap
The trap here is that candidates confuse checkpointing with deduplication, assuming it guarantees exactly-once processing, when in reality checkpointing only tracks read progress and does not prevent duplicate event delivery within the same batch or across restarts.
How to eliminate wrong answers
Option B is wrong because switching to Azure Queue Storage does not inherently solve duplicate processing; queues also use at-least-once delivery and require idempotent consumers. Option C is wrong because checkpointing tracks progress in the Event Hub partition but does not prevent duplicate deliveries; it only helps resume from the last checkpoint after a restart, not deduplicate within a batch. Option D is wrong because increasing the batch size increases throughput but amplifies the risk of duplicates and does not address the root cause of duplicate event processing.