All practice questions

972 questions

Question 421Question

An organization is implementing a multi-tier solution where a mobile client calls a secure Web API. The Web API must call Microsoft Graph to access the user's files. The security policy dictates that the Web API must execute this request using the identity of the signed-in user, rather than using the API's own application identity. The Web API must authenticate to Microsoft Entra ID using a client certificate. You are writing the MSAL.NET code within the Web API to acquire the required token.

Which two code actions must you perform to implement this authentication flow? (Select two.)

Select all that apply

Show answer & explanation

Answer: Construct the application client using ConfidentialClientApplicationBuilder.Create(clientId).WithClientCertificate(certificate).Build(); Call the AcquireTokenOnBehalfOf(scopes, userAssertion) method on the application client, passing a UserAssertion object created from the incoming user token, and execute it.

Answer

Construct the application client using ConfidentialClientApplicationBuilder configured with the certificate, and then call AcquireTokenOnBehalfOf passing a UserAssertion object built from the incoming token.
The On-Behalf-Of (OBO) flow is designed for a Web API that needs to propagate the user's identity and permissions to a downstream API. To implement this using MSAL.NET, the Web API must act as a confidential client (configured via ConfidentialClientApplicationBuilder with its own certificate or secret) and request a token using AcquireTokenOnBehalfOf by supplying a UserAssertion derived from the incoming client JWT token.

Step-by-Step Solution

1
Determine the type of client application required.
The application must be configured as a confidential client since it runs on a secure Web API backend and must store a client certificate.
Web APIs are secure backends and must authenticate themselves to the Identity provider as confidential clients.
2
Initialize the confidential client application instance.
Use ConfidentialClientApplicationBuilder with the Client ID and the client certificate.
This establishes the client's identity for the subsequent token exchange process.
3
Extract the incoming JWT token from the client's request headers.
Construct a UserAssertion object using the raw JWT token.
The user assertion is needed to prove the identity of the signed-in user to Microsoft Entra ID.
4
Initiate the token acquisition flow for the downstream resource.
Call AcquireTokenOnBehalfOf(scopes, userAssertion) and execute the request.
This requests a new access token for the downstream API (Microsoft Graph) carrying the user's delegated permissions.

Key Concept

Microsoft Identity Platform On-Behalf-Of (OBO) authentication flow using MSAL.NET.
Estimated Time:3m 0s
Question 422Question

An organization registry application built in Microsoft Entra ID needs to support authentication for business users from external directories. The registration must allow log-in capabilities exclusively for corporate credentials across any Microsoft Entra ID tenant, preventing personal email accounts (such as Hotmail or Outlook.com) from authenticating. To implement this restriction, which setting should be selected for the application registration's sign-in audience in the manifest?

Show answer & explanation

Answer: AzureADMultipleOrgs

Answer

AzureADMultipleOrgs
The value AzureADMultipleOrgs is used in the Microsoft Entra ID application manifest to allow sign-ins from any organizational directory (work or school accounts) while preventing users with personal Microsoft accounts from signing in.

Step-by-Step Solution

1
Analyze the identity requirements for the registry application.
The application must support multi-tenant work/school accounts but exclude personal Microsoft accounts.
This determines the scope of the target identity providers.
2
Identify the corresponding Microsoft Entra ID application manifest property for audience configuration.
The target property is signInAudience.
This property controls which accounts are allowed to sign in to the application.
3
Select the correct value for the property.
AzureADMultipleOrgs is the value that enables multi-tenant work or school accounts while excluding personal accounts.
Choosing this specific value ensures compliance with the target security boundary.

Key Concept

Multi-tenant Applications Configuration
Question 423Question

You are developing a Python application that uses the `azure-storage-blob` (v12) SDK. The application must retrieve custom metadata from a blob named `financial_summary.xlsx` in a container named `archive`. The blob was previously uploaded with a custom metadata key-value pair of `Department: Finance`.

You write the following code:
python
from azure.storage.blob import BlobServiceClient

connection_string = "your_connection_string"
blob_service_client = BlobServiceClient.from_connection_string(connection_string)
blob_client = blob_service_client.get_blob_client(container="archive", blob="financial_summary.xlsx")

# Retrieve properties
properties = blob_client.get_blob_properties()

Which two of the following Python expressions will successfully retrieve the value of the department metadata ("Finance") from the `properties` object? (Choose two.)

Select all that apply

Show answer & explanation

Answer: `properties.metadata.get('department')`; `properties.metadata['department']`

Answer

The correct expressions are the ones accessing the metadata dictionary using lowercase keys without the 'x-ms-meta-' prefix, specifically by using the get method with 'department' or by indexing directly with 'department'.
When retrieving blob properties, the Azure Storage SDK parses the HTTP response headers. It removes the 'x-ms-meta-' prefix and converts the header names to lowercase before storing them in the metadata dictionary. Therefore, the metadata dictionary contains the key 'department' in lowercase, and can be successfully accessed using direct indexing or the get method with the lowercase key.

Step-by-Step Solution

1
Understand how the Azure Storage SDK handles HTTP headers for custom metadata.
Custom metadata is sent over HTTP with the 'x-ms-meta-' prefix (e.g., 'x-ms-meta-Department: Finance').
This is the protocol-level behavior of Azure Blob Storage.
2
Determine how the Python SDK parses and exposes these metadata headers.
The SDK strips the 'x-ms-meta-' prefix and normalizes all keys to lowercase, storing them in a standard Python dictionary under the 'metadata' property.
This simplifies key access for developers and abstracts HTTP header naming conventions.
3
Identify the correct way to query the dictionary in Python.
Access the key using the lowercase string 'department' either via dictionary indexing or the '.get()' method.
Case-sensitive lookups for the original casing or lookups including the prefix will not match the processed keys in the dictionary.

Key Concept

Azure Blob Storage SDK metadata casing normalization and prefix stripping
Estimated Time:1m 30s
Question 424Question

You are developing a web application that retrieves reports from Azure Blob Storage. You need to generate a Service Shared Access Signature (SAS) token to allow an external partner to download a specific report file. To meet security guidelines, you must restrict access to a specific client IP address and enforce the use of HTTPS. Which two configurations must you define in the SAS token to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: An IP address filter restricting access to the partner's public IP address; An HTTPS-only protocol restriction

Answer

The correct options are the IP address filter restricting access to the partner's public IP address, and the HTTPS-only protocol restriction.
The correct configurations are the IP address filter and the HTTPS-only protocol restriction. An IP address filter limits the client source IP, and the protocol parameter ensures secure transit over HTTPS.

Step-by-Step Solution

1
Analyze the security requirements specified in the scenario.
The requirements are: download a specific report file (Read access), restrict access to a specific client IP address, and enforce HTTPS.
This establishes the constraints needed to select the correct configurations.
2
Determine the SAS configurations that implement IP filtering and protocol enforcement.
Defining the allowed IP address or range limits source access, and setting the protocol parameter to HTTPS only secures transit.
These parameters directly correspond to standard Azure Storage SAS token properties.
3
Evaluate the incorrect options against security best practices.
Granting full container-level write/delete permissions violates least-privilege, and embedding root credentials compromises account security.
This rules out the distractors.

Key Concept

Configuring security constraints on Azure Storage Shared Access Signatures (SAS) to enforce least privilege, specific IP access, and secure protocols.
Question 425Question

You are developing a multi-tenant web application that must allow users from any Microsoft Entra ID tenant to sign in using their work or school accounts. Personal Microsoft accounts (such as outlook.com or xbox.com) must be prevented from signing in. Which two configurations must you implement to meet these requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set the signInAudience property in the application manifest to AzureADMultipleOrgs.; Configure the authority URI in the application code to use the organizations endpoint.

Answer

Set the signInAudience property in the application manifest to AzureADMultipleOrgs, and configure the authority URI in the application code to use the organizations endpoint.
To support multi-tenant login restricted to work or school accounts, the application's registration manifest must have the signInAudience set to AzureADMultipleOrgs. In the application code, the authentication flow must target the organizations endpoint, which ensures that personal accounts are blocked during the authentication process.

Step-by-Step Solution

1
Configure the application registration audience constraint in Entra ID.
Setting the signInAudience property to AzureADMultipleOrgs allows any organization tenant to sign in, but excludes personal accounts.
The AzureADMultipleOrgs setting is explicitly designed for multi-tenant applications that restrict access to work or school accounts.
2
Update the authentication authority endpoint in the application code.
Setting the endpoint path to organizations redirects authenticating users to the organization-specific login flow.
The organizations endpoint filters out personal accounts, whereas the common endpoint allows both organizational and personal accounts to sign in.

Key Concept

Multi-tenant Applications Configuration in Microsoft Entra ID
Estimated Time:1m 0s
Question 426Question

You are developing a C# (.NET Isolated process) Durable Function orchestrator named BillingReminderOrchestrator to implement a customer billing dunning process. If a credit card payment fails, the orchestrator must pause execution and wait exactly three days before invoking an activity function to retry the payment. Which code snippet should you use inside the orchestrator to implement this delay?

Show answer & explanation

Answer: await context.CreateTimer(context.CurrentUtcDateTime.AddDays(3), CancellationToken.None);

Answer

The correct snippet is the one that calls context.CreateTimer with context.CurrentUtcDateTime.AddDays(3).
The correct snippet uses context.CreateTimer alongside context.CurrentUtcDateTime. Durable orchestrators must be completely deterministic. Standard system-clock APIs like DateTime.UtcNow are non-deterministic during orchestration replays, so developers must use the context-provided CurrentUtcDateTime. Thread-blocking methods like Task.Delay and Thread.Sleep are also forbidden because they consume resources unnecessarily instead of scheduling a durable task in the execution history.

Step-by-Step Solution

1
Analyze the orchestrator's requirements and constraints.
The orchestrator needs to wait three days. However, standard .NET sleep/delay APIs and clock APIs violate the determinism constraint of Durable Functions.
Durable Functions orchestrators run by executing code, recording checkpoints, and replaying history. Any non-deterministic value or thread-blocking operation causes runtime issues during replay.
2
Evaluate the date-time retrieval method.
Using DateTime.UtcNow is non-deterministic because it returns a different value on every execution, whereas context.CurrentUtcDateTime is deterministic because it retrieves a stable timestamp from the execution history.
Choosing the context-provided CurrentUtcDateTime ensures replay operations do not result in a different path or exception.
3
Select the correct asynchronous delay method.
Using context.CreateTimer schedules a durable timer task that yields execution back to the Azure Functions runtime rather than blocking the host worker thread.
This allows the function app to scale down to zero or handle other processes while waiting, and resumes the orchestrator once the timer fires.

Key Concept

Orchestrator determinism and durable timers
Estimated Time:1m 30s
Question 427Question

You are implementing a secure file-sharing module in a Python application using the `azure-storage-blob` (v12) SDK. A client application needs temporary, read-only access to a specific report blob named `q4_report.pdf` located in a container named `reports`. To adhere to the principle of least privilege, you must generate a Shared Access Signature (SAS) token that restricts access to only this single blob, allowing only read operations, and expiring in one hour. Which code segment should you use to generate the SAS token?

Show answer & explanation

Answer: from datetime import datetime, timedelta
from azure.storage.blob import generate_blob_sas, BlobSasPermissions

sas_token = generate_blob_sas(
account_name="mystorage",
container_name="reports",
blob_name="q4_report.pdf",
account_key="mykey",
permission=BlobSasPermissions(read=True),
expiry=datetime.utcnow() + timedelta(hours=1)
)

Answer

The correct code segment uses `generate_blob_sas` from the `azure.storage.blob` package, targeting the specific blob name 'q4_report.pdf' inside the container 'reports', and specifies `BlobSasPermissions(read=True)` to ensure read-only access, adhering to the principle of least privilege.
The correct segment calls `generate_blob_sas` specifying the single target blob `q4_report.pdf` within the container `reports` and configuring `BlobSasPermissions(read=True)`. This ensures that access is locked down specifically to the requested blob with read-only permissions for one hour.

Step-by-Step Solution

1
Determine the required resource scope of the SAS token.
Since only a single specific blob ('q4_report.pdf') should be accessed, we must generate a blob-level SAS token using `generate_blob_sas` rather than `generate_container_sas` or `generate_account_sas`.
Generating a container-level or account-level SAS token would violate the principle of least privilege by exposing other blobs or services in the storage account.
2
Define the minimum required permissions.
We must specify `BlobSasPermissions(read=True)`.
Adding write or delete permissions grants unnecessary access to the client, violating the least privilege requirement.
3
Configure the token's lifetime.
Set `expiry` to `datetime.utcnow() + timedelta(hours=1)`.
This guarantees that the token will automatically expire after one hour as requested.

Key Concept

Generating Shared Access Signatures (SAS) with least privilege scopes and permissions using the Azure Storage Blobs SDK.
Question 428Question

An organization has deployed a web API to Azure API Management (APIM). The API must be secured so that it only accepts requests from client applications that present a valid JSON Web Token (JWT) issued by Microsoft Entra ID. The token must contain an audience (aud) claim of api://backend-api and a scope (scp) claim of API.Read. Invalid requests must be rejected immediately with a 401 HTTP status code before reaching the backend service.

Which policy configuration should you apply?

Show answer & explanation

Answer: <inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
<openid-config url="https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration" />
<audiences>
<audience>api://backend-api</audience>
</audiences>
<required-claims>
<claim name="scp" match="any">
<value>API.Read</value>
</claim>
</required-claims>
</validate-jwt>
</inbound>

Answer

The configuration that places the validate-jwt policy inside the inbound section and validates the audience and the scp claim via the openid-config configuration.
The correct policy configuration uses the <validate-jwt> policy within the <inbound> block. This configuration retrieves Microsoft Entra ID metadata dynamically via the openid-config URL, ensures that the token audience is verified, and requires the scope (scp) claim to contain the correct value. Evaluating this inbound ensures unauthenticated requests are blocked before they reach the backend service.

Step-by-Step Solution

1
Identify where token validation must occur.
Inbound section.
To reject unauthorized requests before they reach the backend service.
2
Configure the openid-config endpoint for Microsoft Entra ID.
Dynamic signature validation.
To validate asymmetric signatures using rotated public keys.
3
Add audience and required claims checks.
Verified aud and scp claims.
To ensure the token is targeted for the correct API and contains the required scope.

Key Concept

Securing API Management endpoints by validating inbound JSON Web Tokens (JWT) using Microsoft Entra ID and policy claims.
Question 429Question

You are deploying a Java-based web application to Azure App Service. The application is integrated with Application Insights for monitoring. During testing, you want to use Application Insights Profiler to identify code-level bottlenecks and analyze performance hot paths. The application is currently running on an App Service plan configured with the Free (F1) pricing tier, and it retrieves its telemetry settings from Azure Key Vault using a managed identity. Which of the following actions must you take to enable the Application Insights Profiler?

Show answer & explanation

Answer: Scale the App Service plan to the Basic tier or higher, as the Free tier does not support the Application Insights Profiler.

Answer

Scale the App Service plan to the Basic tier or higher, as the Free tier does not support the Application Insights Profiler.
The correct answer is to scale the App Service plan to the Basic tier or higher. Application Insights Profiler requires dedicated capabilities that are only available starting from the Basic tier of Azure App Service. Free and Shared tiers do not support Profiler operations.

Step-by-Step Solution

1
Identify the hosting requirements for Application Insights Profiler on Azure App Service.
Profiler requires the App Service plan to be at least on the Basic, Standard, Premium, or Isolated tier.
Free and Shared pricing tiers lack the system resources and capabilities required to run the Profiler background process.
2
Determine the current pricing tier and scale-up path.
The current plan is Free (F1). It must be scaled up to at least Basic (B1) or higher.
Scaling up ensures the application resides on a supported tier where the Profiler service can be enabled and successfully execute.

Key Concept

Pricing tier requirements for Application Insights Profiler
Question 430Question

You are developing a batch telemetry processing service in C# that consumes messages from an Azure Queue Storage queue named telemetry-ingest. The service must retrieve up to 32 messages at a time and prevent other instances from processing these messages for 5 minutes while they are being processed. Once a message is successfully processed, it must be permanently removed from the queue. Complete the C# code snippet by filling in the blanks with the correct Azure Storage Queues SDK for .NET method names.

Fill in the blanks below

using System;
using System.Threading.Tasks;
using Azure.Storage.Queues;
using Azure.Storage.Queues.Models;

public async Task ProcessTelemetryBatchAsync(QueueClient queueClient)
{
var response = await queueClient.
(
maxMessages: 32,
visibilityTimeout: TimeSpan.FromMinutes(5)
);

foreach (var message in response.Value)
{
try
{
ProcessTelemetry(message.Body.ToString());

await queueClient.
(message.MessageId, message.PopReceipt);
}
catch (Exception ex)
{
// Log error
}
}
}
Show answer & explanation

Answer

The first blank must be filled with ReceiveMessagesAsync to retrieve multiple messages with a visibility timeout, and the second blank must be filled with DeleteMessageAsync to delete the processed message from the queue using its ID and pop receipt.
ReceiveMessagesAsync is the correct method in the Azure.Storage.Queues SDK to retrieve one or more messages and hide them from other consumers by setting a visibility timeout. DeleteMessageAsync is the correct method to remove a message from the queue after processing, requiring both the message ID and the pop receipt.

Step-by-Step Solution

1
Identify the method required to retrieve multiple messages asynchronously with custom parameters in Azure.Storage.Queues.
ReceiveMessagesAsync is identified as the method that accepts maxMessages and visibilityTimeout parameters and returns a Response containing an array of messages.
The scenario requires retrieving up to 32 messages at once and locking them (hiding them) for 5 minutes, which is done using ReceiveMessagesAsync.
2
Identify the method required to remove a message from the queue after processing is complete.
DeleteMessageAsync is identified as the method that takes a MessageId and PopReceipt to permanently delete the message.
Messages in Azure Storage Queues must be explicitly deleted after processing to prevent them from becoming visible again after the visibility timeout expires.

Key Concept

Retrieving and deleting queue messages using the Azure.Storage.Queues SDK for .NET
Estimated Time:2m 0s
Question 431Question

You manage a web application named LogiRoute that runs on a Standard (S2) App Service plan. The plan currently has 2 instances. You configure an autoscale scale-out rule to increase the instance count by 1 when the average CPU percentage exceeds 80%80\%. During a peak period, the average CPU utilization across the 2 instances reaches 84%84\%, triggering a scale-out event. You need to configure a scale-in rule to decrease the instance count by 1 when the load decreases, ensuring that the scale-in action does not immediately trigger another scale-out (preventing autoscale flapping). Assuming the total workload remains constant immediately after scaling, what is the maximum CPU percentage threshold you should set for the scale-in rule?

Show answer & explanation

Answer: A CPU percentage threshold of 50%50\% on the Standard (S2) App Service plan

Answer

A CPU percentage threshold of 50%50\% on the Standard (S2) App Service plan
The correct option is correct because the total workload of 168%168\% is divided across 3 instances after scaling out, resulting in 56%56\% CPU load per instance. To prevent immediate scale-in (flapping), the scale-in threshold must be set below 56%56\%. A threshold of 50%50\% on a Standard (S2) plan is valid and prevents flapping.

Step-by-Step Solution

1
Calculate the total CPU workload before scaling.
Total CPU workload is 2 instances×84%=168%2 \text{ instances} \times 84\% = 168\%.
Determining the total aggregate CPU utilization helps predict the load per instance when distributed across more instances.
2
Calculate the expected CPU utilization per instance after scaling out to 3 instances.
Expected CPU utilization per instance is 168%/3=56%168\% / 3 = 56\%.
This shows the immediate CPU level that the autoscale engine will evaluate after the scale-out event completes.
3
Determine the maximum scale-in threshold to prevent flapping.
The scale-in threshold must be strictly less than 56%56\%. Therefore, 50%50\% is the correct and safe threshold.
If the scale-in threshold is set to a value higher than 56%56\% (such as 60%60\% or 70%70\%), the autoscale engine will detect that the CPU (56%56\%) is below the threshold and immediately scale in, causing a continuous loop of scaling out and in (flapping).

Key Concept

Autoscale flapping prevention and pricing tier constraints
Question 432Question

A multi-tenant SaaS application stores tenant-specific documents in a single Azure Cosmos DB container using the .NET SDK v3. The container is configured with a partition key path of `/TenantId`, and the database account uses the default Session consistency level. Separate instances of the client application run on different virtual machines, each initializing its own `CosmosClient` instance.

You need to ensure that reads and writes performed by separate client instances achieve read-your-writes consistency while maintaining optimal write/read partition distribution and meeting SDK design standards.

Which of the following actions should you perform to implement this correctly? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Retrieve the session token from the write response headers on one client instance and pass it in the request options of subsequent read requests on other client instances.; Explicitly pass the `TenantId` value as a `PartitionKey` parameter in the SDK item operation methods such as `CreateItemAsync` or `ReadItemAsync`.

Answer

To configure the Cosmos DB SDK operations correctly, you must pass the session token between separate client instances to maintain session consistency, and you must explicitly pass the partition key in all item operation calls.
To maintain read-your-writes consistency across separate CosmosClient instances, you must manually pass the session token from the write response to the subsequent read requests. Additionally, when using the .NET SDK v3, performing item operations requires explicitly passing the PartitionKey parameter to target the correct logical partition and avoid exceptions.

Step-by-Step Solution

1
Analyze consistency scope across multiple client instances.
Determine that Session consistency is scoped to the client instance, meaning different instances require explicit token sharing.
Ensures read-your-writes guarantees are met globally across instances.
2
Analyze SDK requirement for item operations.
Identify that the Cosmos DB .NET SDK v3 requires passing the partition key value as a parameter in item-level methods.
Ensures operations target the correct logical partition and prevents SDK runtime validation errors.

Key Concept

Managing session consistency tokens across multiple client instances and passing partition keys in SDK operations.
Estimated Time:1m 30s
Question 433Question

You are developing an Azure-hosted application that processes large batch PDF generation requests. Each request contains user preferences and a raw list of data records to include. The size of the request payload ranges from 10 KB to 500 KB. You plan to use Azure Queue Storage to process these requests asynchronously using a background worker. You need to design the solution to handle the request payloads while minimizing costs and ensuring reliability. Which approach should you implement to handle the request payloads?

Show answer & explanation

Answer: Upload the request payload to an Azure Blob Storage container, write the URI of the blob as the message content to the Azure Queue Storage queue, and have the worker retrieve the payload from Blob Storage and delete the blob after processing.

Answer

Upload the request payload to an Azure Blob Storage container, write the URI of the blob as the message content to the Azure Queue Storage queue, and have the worker retrieve the payload from Blob Storage and delete the blob after processing.
The correct option is the one that uploads the payload to Azure Blob Storage and writes the blob's URI to the queue. Azure Queue Storage has a hard message size limit of 64 KB. For payloads exceeding this limit (such as requests ranging from 10 KB to 500 KB), the industry-standard pattern is to store the actual data in Blob Storage and pass a reference (such as the blob URI) in the queue message. The processing worker can then read the reference, retrieve the blob content, process it, and delete the blob.

Step-by-Step Solution

1
Analyze the message payload size requirements.
The payload size ranges from 10 KB to 500 KB, which can exceed the maximum message size limit of Azure Queue Storage.
Azure Queue Storage has a hard message size limit of 64 KB per message.
2
Determine the appropriate Azure service for storing payloads larger than 64 KB.
Azure Blob Storage is selected to store the large request payloads.
Blob Storage is designed to store unstructured data of virtually any size cost-effectively.
3
Design the queue message format to reference the stored payload.
Store the payload in a blob container, retrieve the blob's URI, and write the URI as the text payload of the queue message.
This allows the queue message size to remain extremely small (under 1 KB) while referencing the full payload.
4
Design the worker processing and cleanup workflow.
The worker reads the queue message, retrieves the payload from Blob Storage using the URI, processes the request, and deletes both the queue message and the blob.
Deleting the blob prevents orphaned storage files and manages storage costs.

Key Concept

Handling messages that exceed the 64 KB Azure Queue Storage size limit.
Question 434Question

You are developing an Azure App Service web app that needs to retrieve a database connection string stored as a secret in Azure Key Vault. You want to authenticate the web app using a system-assigned managed identity.

Which two actions should you perform to configure the required access? (Select two.)

Select all that apply

Show answer & explanation

Answer: Enable a system-assigned managed identity on the App Service web app.; Create an access policy in Azure Key Vault that grants the Get permission for secrets to the web app's managed identity.

Answer

Enable a system-assigned managed identity on the App Service web app, and create an access policy in Azure Key Vault that grants the Get permission for secrets to the web app's managed identity.
To retrieve a secret using a system-assigned managed identity, you must first enable the identity on the App Service web app to register it with Microsoft Entra ID. Then, you must configure authorization on the Azure Key Vault (such as an access policy) to grant the web app's identity the Get permission for secrets.

Step-by-Step Solution

1
Enable the identity on the web app.
The web app gets registered in Microsoft Entra ID with a system-assigned managed identity.
This establishes a security principal for the web app without needing credentials.
2
Configure Azure Key Vault access.
An access policy or Azure RBAC role assignment is created on the Key Vault.
This authorizes the web app's managed identity to perform the Get operation on secrets.

Key Concept

Configuring secure access to Key Vault secrets using managed identities
Question 435Question

You are developing a multi-tenant web application named App1 that will be registered in Microsoft Entra ID under Tenant A. Users from other Microsoft Entra ID tenants, such as Tenant B, must be able to sign in to App1 and grant the application permissions to read their profile data.

You need to understand how the identity objects are represented in the directory structure when a user from Tenant B consents to App1.

Which of the following describes the resource creation behavior in Tenant B?

Show answer & explanation

Answer: A service principal is created in Tenant B that references the application object in Tenant A.

Answer

A service principal is created in Tenant B that references the application object in Tenant A.
The correct answer is correct because in Microsoft Entra ID, the application registration generates a global application object in the home tenant. When the application is made multi-tenant and consented to by a user in another tenant, a local service principal (enterprise application) is created in that target tenant to represent the application and hold its local permissions.

Step-by-Step Solution

1
Understand the difference between application objects and service principals in Microsoft Entra ID.
The application object is the global definition of the application, while the service principal is the local instance or representation of that application within a specific tenant.
This conceptual distinction is fundamental to understanding how multi-tenant applications operate and are authorized across tenant boundaries.
2
Analyze the lifecycle of a multi-tenant application consent flow.
When a user in Tenant B consents to the application registered in Tenant A, Microsoft Entra ID creates a service principal in Tenant B pointing back to the application object in Tenant A.
This establishes the security principal in Tenant B to which permissions and roles can be assigned locally.

Key Concept

The relationship between application objects (global definition) and service principals (local instance) in multi-tenant environments.
Question 436Question

An engineer is designing a background daemon service that synchronizes directory metadata across several external corporate Microsoft Entra ID tenants using the Microsoft Graph API. The service must operate with application-only permissions (`User.Read.All`), prevent consumer accounts (such as Outlook.com) from registering, and allow external tenant administrators to grant consent and run the sync process without user interaction.

Which configuration combination must be used to meet these requirements?

Show answer & explanation

Answer: Manifest signInAudience: AzureADMultipleOrgs; Admin consent endpoint: https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent; Token acquisition endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token

Answer

The configuration using 'AzureADMultipleOrgs' for signInAudience, combined with the tenant-specific endpoints for admin consent (https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent) and token acquisition (https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token).
Configuring the application with 'AzureADMultipleOrgs' ensures that only work or school accounts from Microsoft Entra ID can access the application, satisfying the requirement to prevent personal Microsoft accounts. For daemon applications that run in the background using application-only permissions (such as the client credentials flow), token acquisition requires a tenant-specific endpoint (containing the client's tenant ID or verified domain) because the identity provider cannot resolve the tenant context without an active user session. Similarly, administrative consent must be granted within a specific tenant context, requiring a tenant-specific admin consent endpoint.

Step-by-Step Solution

1
Determine the required client directory audience.
The application must support multi-tenant organizations but exclude personal Microsoft accounts, pointing to the 'AzureADMultipleOrgs' audience configuration.
The 'AzureADMultipleOrgs' signInAudience targets corporate directories while preventing consumer Microsoft accounts from authenticating.
2
Identify the endpoint required for tenant-wide administrative consent.
The consent URL must be directed to a tenant-specific endpoint: https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent.
Administrative consent for application permissions requires a specific target tenant ID or domain context to apply the permissions to that directory.
3
Select the appropriate token endpoint for the background synchronization service.
The background service must request tokens using the client credentials grant flow directed to the tenant-specific endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token.
The client credentials flow is a non-interactive flow that lacks a user context, meaning the generic /common or /organizations endpoints cannot resolve the target directory and will fail.

Key Concept

Multi-tenant daemon application configuration and endpoint routing in Microsoft Entra ID.
Question 437Question

You are developing a secure Web App named InventoryManager that runs on Azure App Service. The application must perform two main tasks:
1. Allow signed-in users to view their own profile details and manage their calendar events in Microsoft 365.
2. Run a scheduled background job every night to retrieve a list of all office groups in the tenant to update local access lists. This background job runs without a signed-in user.

You need to configure the app registration in Microsoft Entra ID.

Which of the following configurations must you apply to meet these requirements while adhering to the principle of least privilege? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure the Microsoft Graph delegated permissions User.Read and Calendars.ReadWrite, and allow signed-in users to consent to these permissions.; Configure the Microsoft Graph application permission Group.Read.All, and have a tenant administrator grant tenant-wide consent.

Answer

Configure the Microsoft Graph delegated permissions User.Read and Calendars.ReadWrite for user-interactive operations, and configure the application permission Group.Read.All with tenant-wide administrator consent for the background daemon job.
For the user-centric features, the application runs on behalf of the signed-in user. This necessitates delegated permissions (User.Read and Calendars.ReadWrite) which are eligible for user consent. In contrast, the nightly background task operates independently of any user context, which requires a daemon flow (client credentials flow) and application-level permissions. Specifically, Group.Read.All is the correct application permission to read tenant groups, and because it is an application-level permission, it requires tenant-wide administrator consent.

Step-by-Step Solution

1
Analyze the client contexts for the two tasks.
Task 1 involves a signed-in user (delegated context), whereas Task 2 is a background daemon running without a user (application context).
This determines whether delegated or application permissions are required for each task.
2
Select the appropriate permissions under the principle of least privilege.
For the user context, delegated permissions User.Read and Calendates.ReadWrite are needed. For the background context, application permission Group.Read.All is needed.
Least privilege mandates using specific, narrow scopes rather than broad directory-wide administrative scopes like Directory.Read.All.
3
Determine the consent requirements for the selected permissions.
Delegated permissions can be consented to by individual users. Application permissions always require administrator consent.
Application permissions bypass user consent checks and expose tenant-wide data, requiring a tenant administrator to explicitly authorize them.
4
Determine the token request structure for the daemon service.
The client credentials flow must request the scope ending in /.default.
Unlike delegated flows that can request specific scopes dynamically, daemon flows require static permission registration and the use of the default scope suffix.

Key Concept

Differentiating delegated permissions and user consent from application permissions and admin consent in Microsoft Entra ID app registrations.
Question 438Question

You are developing a telemetry processing workflow using Azure Durable Functions in Node.js. The orchestrator function must process incoming data, wait for 5 minutes, and then run an aggregation activity. You write the following orchestrator function code:

javascript
const df = require("durable-functions");

module.exports = df.orchestrator(function* (context) {
const input = context.df.getInput();

// Generate a unique identifier for the execution run
const runId = context.df.newGuid();

// Get the current date and time
const timestamp = new Date();

// Perform processing by calling an activity function
const processedData = yield context.df.callActivity("ProcessSensorData", input);

// Delay execution for 5 minutes
yield context.df.createTimer(new Date(Date.now() + 5 * 60 * 1000));

// Run the aggregation activity
yield context.df.callActivity("AggregateSensorData", { runId, timestamp, processedData });
});

During testing, you notice that the orchestrator behaves non-deterministically. Which two changes should you make to ensure the orchestrator complies with Durable Functions determinism constraints? Select two.

Select all that apply

Show answer & explanation

Answer: Replace the instantiation of the local system date new Date() with context.df.currentUtcDateTime to capture the timestamp.; Calculate the timer deadline using context.df.currentUtcDateTime instead of Date.now().

Answer

Replace the instantiation of the local system date new Date() with context.df.currentUtcDateTime to capture the timestamp, and calculate the timer deadline using context.df.currentUtcDateTime instead of Date.now().
To ensure the orchestrator function is deterministic, all date and time operations must use the API provided by the Durable Functions context (context.df.currentUtcDateTime). The native JavaScript new Date() and Date.now() are non-deterministic because they return different values on each execution replay, causing the execution history to mismatch. Replacing them with the context's currentUtcDateTime property ensures consistent values across replays. The context.df.newGuid() is already the correct deterministic API for generating unique identifiers, and activity calls are required for I/O operations.

Step-by-Step Solution

1
Analyze the orchestrator code for sources of non-determinism.
Identify that new Date() and Date.now() are used to fetch the current timestamp and to compute the timer's expiration time.
Orchestrator functions replay multiple times to rebuild their execution state, and native system date/time calls will return different values on each replay.
2
Replace the non-deterministic date/time retrievals with deterministic alternatives.
Replace new Date() and Date.now() with context.df.currentUtcDateTime.
The Durable Functions framework provides context.df.currentUtcDateTime to ensure that time values are recorded in the execution history and replayed consistently.
3
Verify that remaining APIs are compliant with Durable Functions constraints.
Keep context.df.newGuid() for UUID generation and use activity calls for operations rather than direct HTTP clients.
context.df.newGuid() is safe for orchestrators, and network or direct database operations must go through activity functions to maintain determinism.

Key Concept

Orchestrator code determinism constraints in Azure Durable Functions
Question 439Question

An application named PromoCampaignPortal is currently hosted on a Basic (B1B1) App Service plan. During marketing campaigns, the application experiences significant memory spikes. You want to implement autoscaling to automatically handle this demand, while ensuring that the scaling behavior remains stable and does not cause rapid, repeated scaling actions (flapping).

Which two of the following actions must you perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Scale up the App Service plan to the Standard (S1S1) pricing tier.; Configure a scale-out rule to add an instance when memory usage exceeds 80%80\% and a scale-in rule to remove an instance when memory usage falls below 40%40\%.

Answer

To configure autoscaling for the application, you must scale up the App Service plan to the Standard (S1S1) pricing tier, as the Basic (B1B1) tier does not support autoscale. In addition, you must set a scale-out rule to add an instance when memory usage exceeds 80%80\% and a scale-in rule to remove an instance when memory usage falls below 40%40\% to maintain a safe margin and prevent autoscale flapping.
To enable rules-based autoscaling, the App Service plan must be scaled up to at least the Standard (S1S1) pricing tier, as the Basic (B1B1) tier only supports manual scaling. In addition, when configuring scale-out and scale-in rules, there must be a sufficient margin between the thresholds to prevent flapping. Setting the scale-out rule to trigger when memory exceeds 80%80\% and the scale-in rule to trigger when memory drops below 40%40\% ensures that the reduction in average memory usage per instance after scaling out does not immediately trigger a scale-in action.

Step-by-Step Solution

1
Evaluate the current App Service pricing tier for autoscale compatibility.
Identify that the Basic (B1B1) plan only supports manual scale-out (up to 33 instances) and does not support autoscale rules.
To use autoscale rules, the App Service plan must first be scaled up to at least the Standard (S1S1) tier.
2
Scale up the App Service plan.
The App Service plan is updated to the Standard (S1S1) pricing tier, enabling autoscale capabilities.
Enables the Azure Monitor autoscale engine to manage the instance count dynamically.
3
Determine the appropriate autoscale metric thresholds to avoid flapping.
Establish a scale-out threshold at 80%80\% memory usage and a scale-in threshold at 40%40\% memory usage.
A sufficient gap between the scale-out and scale-in thresholds prevents the system from immediately scaling back in once the load is distributed to the new instance, thereby preventing flapping.

Key Concept

Autoscaling configuration requirements and flapping prevention in Azure App Service
Question 440Question

You are developing a workflow to process monthly customer billing reports using Azure Durable Functions in a C# (.NET Isolated process) environment. You need to write an HTTP-triggered function that starts a new instance of the orchestrator function named BillingReportOrchestrator and returns a standard HTTP 202 response containing the status check URI. Which code segment should you use?

Show answer & explanation

Answer: [Function("StartBillingReport")]
public static async Task<HttpResponseData> Run(
[HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequestData req,
[DurableClient] DurableTaskClient client)
{
string instanceId = await client.ScheduleNewOrchestratorInstanceAsync("BillingReportOrchestrator");
return client.CreateCheckStatusResponse(req, instanceId);
}

Answer

The correct code segment binds to a DurableTaskClient instance using the [DurableClient] attribute, schedules the execution using client.ScheduleNewOrchestratorInstanceAsync, and yields the status endpoints with client.CreateCheckStatusResponse using HttpResponseData.
In C# .NET Isolated process functions, the modern Durable Functions extension shifts to using DurableTaskClient to manage orchestrations. To schedule a workflow, the ScheduleNewOrchestratorInstanceAsync method is called. The HTTP payload handles input/output using HttpRequestData and HttpResponseData, and status URL payloads are generated via CreateCheckStatusResponse.

Step-by-Step Solution

1
Determine the execution process model context.
The requirements specify the C# (.NET Isolated process) model.
This helps filter out types that only exist in the In-Process model.
2
Identify the correct bindings and classes for the client in the .NET Isolated model.
The [DurableClient] attribute binds to the DurableTaskClient class, whereas HttpRequestData and HttpResponseData represent the HTTP context.
The In-Process SDK class IDurableOrchestrationClient and standard HttpRequestMessage/HttpResponseMessage are not natively supported in the .NET Isolated model's durable extension.
3
Identify the method signature to trigger the orchestrator.
The method to invoke is client.ScheduleNewOrchestratorInstanceAsync("BillingReportOrchestrator").
The older StartNewAsync method belongs to the legacy in-process library and is absent from the newer DurableTaskClient interface.

Key Concept

Azure Durable Functions .NET Isolated Worker Client Bindings
Estimated Time:1m 30s
PreviousPage 22 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin