All practice questions

497 questions

Question 1Question

You are developing a document approval workflow using Azure Durable Functions in C# (.NET Isolated). The workflow must wait for an external approval event named `DocumentApproved` for up to 2424 hours. If the event is received within 2424 hours, the document is processed. If the 2424-hour limit is reached without receiving the event, the document must be marked as expired. You write the following orchestrator function code:

csharp
[Function("ApprovalOrchestrator")]
public static async Task Run(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
var approvalTask = context.WaitForExternalEvent<bool>("DocumentApproved");
var timeoutTask = Task.Delay(TimeSpan.FromHours(24));

var completedTask = await Task.WhenAny(approvalTask, timeoutTask);
if (completedTask == approvalTask)
{
bool isApproved = approvalTask.Result;
await context.CallActivityAsync("ProcessDocument", isApproved);
}
else
{
await context.CallActivityAsync("ExpireDocument", null);
}
}

Which of the following describes the defect in this orchestrator code?

Show answer & explanation

Answer: The use of `Task.Delay` violates the determinism constraint of orchestrator functions; you should use `context.CreateTimer` instead.

Answer

The use of Task.Delay violates the determinism constraint of orchestrator functions; you should use context.CreateTimer instead.
The correct answer is correct because orchestrator functions in Azure Durable Functions must be completely deterministic. Because they replay their execution state, developers must avoid non-deterministic APIs such as Task.Delay, Guid.NewGuid, or DateTime.UtcNow. Instead, durable orchestrator APIs like context.CreateTimer must be used to schedule timers, as this registers the timer event in the orchestration history and allows the orchestrator to safely suspend execution without blocking resources.

Step-by-Step Solution

1
Analyze the orchestrator code to identify non-deterministic or blocking APIs.
Identify the use of Task.Delay(TimeSpan.FromHours(24)) on the second line.
Orchestrator functions must be deterministic, and Task.Delay is non-deterministic because it does not register with the Durable Functions state store.
2
Determine the correct Durable Functions API to replace the non-deterministic call.
Identify context.CreateTimer as the appropriate API for scheduling delays in orchestrators.
context.CreateTimer creates a durable timer that persists its state and allows the orchestrator to sleep and replay correctly.
3
Evaluate the rest of the orchestration logic (Task.WhenAny, WaitForExternalEvent, and CallActivityAsync).
Confirm that task orchestration and external events are correctly structured using task combinators.
Task.WhenAny is the correct asynchronous, non-blocking method to wait for the first of multiple tasks to complete.

Key Concept

Durable Functions Orchestrator Determinism
Question 2Question

An organization deploys a background processing application to an Azure App Service Plan in the East US region. The application processes tasks from an Azure Service Bus queue named `task-queue` in the same region.

To handle spikes in workload, you configure an autoscale setting on the App Service Plan with the following scale-out rule:
- Metric source: Service Bus Queue (`task-queue`)
- Metric name: `ActiveMessages`
- Time Grain (Frequency): 11-minute
- Time Window: 1010-minutes
- Time Aggregation: `Total`
- Operator: `GreaterThan`
- Threshold: 500500
- Scale Action: Increase count by 22

During a period of stable, low traffic, the queue maintains a steady backlog of approximately 6060 active messages. However, you observe that the App Service Plan unexpectedly scales out to its maximum instance count.

Which of the following is the root cause of this unexpected scaling behavior?

Show answer & explanation

Answer: The `Total` time aggregation sums the samples over the 1010-minute window, resulting in an evaluated metric value of approximately 600600, which exceeds the threshold of 500500.

Answer

The scale-out rule triggers because the 'Total' time aggregation sums the samples of the queue size (approximately 6060 messages) over the 1010-minute window (1010 samples of 11 minute each), resulting in an evaluated value of approximately 600600, which exceeds the threshold of 500500.
The correct answer is correct because using the 'Total' time aggregation sums the point-in-time samples of the queue size (approximately 6060 messages) over the 1010-minute window (1010 samples of 11 minute each), resulting in an aggregated value of approximately 600600. Since this value exceeds the threshold of 500500, it triggers the scale-out action. To monitor queue lengths correctly, 'Average' or 'Maximum' aggregation must be used.

Step-by-Step Solution

1
Analyze the sampling rate and the time window of the autoscale metric trigger.
The rule uses a Time Grain (frequency) of 11 minute and a Time Window of 1010 minutes, meaning 1010 metric samples are collected and evaluated during each autoscale check.
To understand how the metric value is calculated, we must determine the number of samples collected within the evaluation window.
2
Calculate the aggregated metric value based on the 'Total' Time Aggregation type and the steady backlog.
Under a stable workload of 6060 messages, each of the 1010 samples has a value of approximately 6060. Using 'Total' aggregation, the sum of these samples is calculated: 60×10=60060 \times 10 = 600.
The 'Total' aggregation sums all samples in the time window rather than taking the average, minimum, or maximum value.
3
Compare the aggregated metric value against the configured scale-out threshold.
The calculated value of 600600 is compared to the threshold of 500500. Since 600>500600 > 500, the operator GreaterThan is satisfied, and the scale-out action (Increase count by 22) is triggered.
This explains why the App Service Plan scales out to its maximum instance count even under low, stable traffic.

Key Concept

Azure Monitor Autoscale Cross-Resource Metrics and Time Aggregation Types
Question 3Question

You have an Azure subscription with a Standard General Purpose v2 (GPv2) storage account named `medicalrecordsstore`. The container named `patients` contains the following block blobs:

* `patients/recordA.json`: Modified 120120 days ago. Tag: `ArchiveStatus` = `Ready`. No active lease.
* `patients/recordB.json`: Modified 110110 days ago. Tag: `archivestatus` = `Ready`. No active lease.
* `patients/recordC.json`: Modified 105105 days ago. Tag: `ArchiveStatus` = `Ready`. Has an active lease.

You implement the following lifecycle management policy:

{
"rules": [
{
"enabled": true,
"name": "archiveRule",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 100
}
}
},
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["patients/"],
"blobIndexMatch": [
{
"name": "ArchiveStatus",
"op": "==",
"value": "Ready"
}
]
}
}
}
]
}

After the policy runs, which blobs will be successfully transitioned to the Archive tier?

Show answer & explanation

Answer: Only patients/recordA.json and patients/recordC.json

Answer

Only patients/recordA.json and patients/recordC.json will be transitioned to the Archive tier.
Only patients/recordA.json and patients/recordC.json are transitioned because they both exceed the 100100-day modification age limit and possess the exact case-sensitive tag key 'ArchiveStatus' with the value 'Ready'. The active lease on patients/recordC.json does not prevent the built-in lifecycle management service from modifying the blob tier.

Step-by-Step Solution

1
Evaluate the modification time constraint.
All three blobs (recordA.json modified 120120 days ago, recordB.json modified 110110 days ago, and recordC.json modified 105105 days ago) exceed the threshold of 100100 days since last modification.
The actions.baseBlob.tierToArchive.daysAfterModificationGreaterThan filter specifies a duration of 100100 days.
2
Apply the blob index tag filter rules.
Only recordA.json and recordC.json match the filter key 'ArchiveStatus' with value 'Ready'.
Blob index tag filters are case-sensitive. The blob recordB.json has the tag key 'archivestatus' in lowercase, which fails to match the rule's uppercase key 'ArchiveStatus'.
3
Evaluate lease status constraints on the matching blobs.
Both recordA.json and recordC.json are successfully transitioned.
Azure Blob Storage lifecycle management policy actions are execution-exempt from client-side blob leases. An active lease on recordC.json does not block the platform from performing the tier transition.

Key Concept

Azure Blob Storage lifecycle management policy execution constraints, index tag case-sensitivity, and lease interaction.
Estimated Time:1m 30s
Question 4Question

You are configuring an Azure Event Grid system topic to route system events to an Azure Function. To prevent event loss, you must configure dead-lettering to a secured Azure Storage account. The storage account has its firewall enabled, restricting access to virtual networks and trusted Microsoft services. Which configuration must you implement to authorize Event Grid to write the dead-letter events?

Show answer & explanation

Answer: Enable a system-assigned managed identity on the Event Grid topic, assign the identity the Storage Blob Data Contributor role on the storage account, and configure the event subscription to use this identity for dead-letter delivery.

Answer

Enable a system-assigned managed identity on the Event Grid topic, assign the identity the Storage Blob Data Contributor role on the storage account, and configure the event subscription to use this identity for dead-letter delivery.
To write dead-letter events to an Azure Storage account protected by a firewall, Event Grid must be recognized as a trusted Microsoft service. This requires enabling a system-assigned (or user-assigned) managed identity on the Event Grid topic, granting that identity the Storage Blob Data Contributor role on the destination storage account, and configuring the event subscription to use the managed identity when delivering dead-letter events.

Step-by-Step Solution

1
Enable Managed Identity on the Event Grid Resource
A system-assigned managed identity is generated for the Event Grid system or custom topic.
This establishes an identity in Microsoft Entra ID that Event Grid can use to authenticate with other Azure resources.
2
Grant RBAC Permissions on the Destination Storage Account
The Storage Blob Data Contributor role is assigned to the Event Grid managed identity.
This role provides the necessary write permissions to deposit dead-letter blobs into the container.
3
Configure the Event Subscription to Use the Identity
The event subscription is updated to include a dead-letter destination and configured to use the system-assigned managed identity for delivery.
This instructs Event Grid to present its managed identity token when attempting to write dead-letter events to the secured storage account.

Key Concept

Configuring Event Grid dead-lettering with managed identities to write to secured storage accounts.
Question 5Question

You are developing a background daemon service named DataArchiver that runs on a schedule to back up documents from all user OneDrive libraries to an Azure Blob Storage container. The service must authenticate silently without any user interaction.

You register DataArchiver in Microsoft Entra ID. You need to configure the permissions for Microsoft Graph to allow the service to read the files.

Which configuration should you apply to the application registration to meet the requirements while adhering to the principle of least privilege?

Show answer & explanation

Answer: Configure Microsoft Graph Application permissions for Files.Read.All, and obtain tenant-wide admin consent.

Answer

Configure Microsoft Graph Application permissions for Files.Read.All, and obtain tenant-wide admin consent.
The correct configuration is to use Microsoft Graph Application permissions for Files.Read.All and obtain tenant-wide admin consent. Because the daemon runs as a background service without a signed-in user, it must authenticate as its own identity using Application permissions rather than Delegated permissions. Additionally, reading data across all users' OneDrive libraries is a high-privilege operation that requires tenant-wide admin consent.

Step-by-Step Solution

1
Determine the authentication context and identity flow.
Since the service runs silently on a schedule with no user interaction, it must use the client credentials flow with Application permissions instead of Delegated permissions.
Delegated permissions require an active user session, whereas Application permissions allow a daemon or service to run autonomously.
2
Identify the Microsoft Graph permission required to read all users' OneDrive files.
The minimum permission needed to read files across all user libraries is Files.Read.All.
Following the principle of least privilege, Files.Read.All provides read access to all files, which is sufficient for backup purposes without granting write or delete privileges.
3
Determine the consent requirement.
Obtain tenant-wide admin consent for the Files.Read.All Application permission.
Application permissions that access organization-wide data (like Files.Read.All) cannot be consented to by regular users and require an administrator to grant consent tenant-wide.

Key Concept

Configuring Application Permissions and Consent for Daemon Apps
Estimated Time:1m 30s
Question 6Question

A background data synchronization service runs on an Azure App Service plan (Standard S2 tier) that is currently scaled to 33 instances. You need to configure autoscale rules for the App Service plan based on the CPU percentage metric. You define the following rules:

* Scale-out rule: Increase the instance count by 33 when the average CPU percentage is greater than 75%75\% for 10 minutes.
* Scale-in rule: Decrease the instance count by 33 when the average CPU percentage is less than a target threshold for 10 minutes.

Under a constant workload, you must prevent the autoscale engine from flapping (repeatedly scaling out and scaling in).

Which of the following configurations should you implement?

Show answer & explanation

Answer: Set the scale-in threshold to 30%30\%.

Answer

Set the scale-in threshold to 30%30\%.
The correct option is to set the scale-in threshold to 30%30\%. To avoid flapping, the scale-in threshold must be strictly less than the average CPU load of the scaled-out instances under a constant workload. With 33 instances at a 75%75\% scale-out threshold, the total workload is 225%225\%. When the service scales out by 33 instances to a total of 66, the workload is distributed, resulting in an average CPU load of 37.5%37.5\%. Since 30%30\% is strictly less than 37.5%37.5\%, the scale-in rule will not immediately trigger, preventing flapping.

Step-by-Step Solution

1
Calculate the total CPU capacity load required to trigger the scale-out rule.
3×75%=225%3 \times 75\% = 225\% total CPU load
This represents the minimum combined CPU capacity utilized across all instances just as the scale-out threshold is crossed.
2
Determine the new instance count after the scale-out action occurs.
3 instances+3 instances=6 instances3 \text{ instances} + 3 \text{ instances} = 6 \text{ instances}
The scale-out rule increases the capacity by 33 instances from the current base of 33.
3
Calculate the new average CPU percentage across all instances under the same constant workload.
225%/6=37.5%225\% / 6 = 37.5\% average CPU
Dividing the total CPU load by the new instance count gives the expected average CPU usage per instance after scaling.
4
Select a scale-in threshold that is strictly lower than the post-scale-out average CPU percentage.
30%30\% is the only valid configuration that is strictly lower than 37.5%37.5\% while remaining on a supported App Service tier.
If the scale-in threshold is greater than or equal to 37.5%37.5\% (e.g., 40%40\%, 45%45\%), the autoscale engine will immediately scale back down to 33 instances, causing flapping.

Key Concept

Avoiding Autoscale Flapping in Azure Monitor
Question 7Question

You are developing a Single Page Application (SPA) using React and MSAL.js to authenticate users and obtain tokens for a downstream Web API. During the application registration in Microsoft Entra ID, you configured the redirect URI as http://localhost:3000/callback. When testing the authentication flow, the user can successfully sign in and the application receives an authorization code. However, when MSAL.js attempts to exchange the authorization code for an access token by sending a POST request to the token endpoint, the browser blocks the request with a Cross-Origin Resource Sharing (CORS) error. Which of the following describes the cause of this issue and the correct action to resolve it?

Show answer & explanation

Answer: The redirect URI was registered under the Web platform in the App Registration. You must change the platform type of the redirect URI to Single-page application (SPA).

Answer

The redirect URI must be registered under the Single-page application (SPA) platform in the App Registration to enable CORS support on the token endpoint.
The platform type of the redirect URI dictates how the Microsoft Identity Platform handles token requests. For SPAs, registering the redirect URI under the 'Single-page application' platform enables Cross-Origin Resource Sharing (CORS) on the token endpoint. Without this, the token endpoint does not send the required CORS headers, leading to browser-side errors during the authorization code exchange.

Step-by-Step Solution

1
Analyze the CORS error generated when MSAL.js calls the token endpoint.
The token endpoint is blocking the request from the browser because it did not return the required Access-Control-Allow-Origin headers.
The browser blocks cross-origin requests unless the target resource explicitly allows the origin through CORS headers.
2
Inspect the application registration settings in Microsoft Entra ID.
Identify that the redirect URI is configured under the 'Web' platform type instead of the 'Single-page application' platform type.
The 'Web' platform type is designed for confidential clients (web servers) and does not support browser-based CORS operations at the token endpoint.
3
Change the platform type of the redirect URI in the App Registration.
Migrating the redirect URI to the 'Single-page application' platform enables CORS on the token endpoint for the registered origin and configures Authorization Code Flow with PKCE.
This updates the Entra ID security configuration to allow public browser clients to securely acquire tokens directly.

Key Concept

Entra ID App Registration Platform Types and CORS
Estimated Time:1m 30s
Question 8Question

A company implements an auditing application that processes financial messages. The application uses an Azure Cache for Redis instance to store temporary transaction states. It is critical that no cached transaction states are evicted under memory pressure, as this would cause auditing mismatches. Instead, if the cache memory limit is reached, the application must receive errors so it can temporarily throttle ingestion. Which eviction policy should you configure for the Azure Cache for Redis instance?

Show answer & explanation

Answer: noeviction

Answer

noeviction
The correct policy is noeviction because it is the only policy that does not automatically delete keys when the cache fills up. Instead, it returns an out-of-memory (OOM) error on write operations, which allows the application to detect the limit and throttle message ingestion.

Step-by-Step Solution

1
Determine the application's tolerance for data eviction.
The application requires that no cached transaction states be lost or evicted under memory pressure.
Evicting data would cause auditing mismatches and break core business logic.
2
Determine the expected application behavior when the cache limit is reached.
The application must receive errors so it can throttle ingestion.
Throttling requires a clear error signal from the database/cache layer when it cannot accept more writes.
3
Select the Redis maxmemory-policy that prevents eviction and returns out-of-memory errors.
The noeviction policy matches this behavior exactly.
Unlike other policies, noeviction returns an error on write commands rather than silently reclaiming space by deleting keys.

Key Concept

Azure Cache for Redis Eviction Policies
Question 9Question

You are developing a secure C# web application that runs on-premises. The application must sign in users and then call a downstream Web API on their behalf using the Microsoft Identity Platform.

The application is configured as a confidential client. You have already obtained the authorization code from the initial user login redirect.

You write the following code to initialize the application:

csharp
IConfidentialClientApplication app = ConfidentialClientApplicationBuilder.Create(clientId)
.WithClientSecret(clientSecret)
.WithRedirectUri(redirectUri)
.Build();

You need to complete the code to exchange the authorization code for an access token. Which code segment should you use?

Show answer & explanation

Answer: AuthenticationResult result = await app.AcquireTokenByAuthorizationCode(scopes, authorizationCode).ExecuteAsync();

Answer

AuthenticationResult result = await app.AcquireTokenByAuthorizationCode(scopes, authorizationCode).ExecuteAsync();
The application needs to exchange an authorization code for an access token to call a downstream API on behalf of a user. The app is a confidential client initialized as an IConfidentialClientApplication. The correct method to exchange the authorization code is AcquireTokenByAuthorizationCode, followed by ExecuteAsync to run the request.

Step-by-Step Solution

1
Identify the client type and the authentication flow needed.
The web application is a confidential client, and it must exchange an authorization code for a delegated user access token.
The scenario specifies a confidential client application that has already received an authorization code from a user login redirect.
2
Match the required flow to the correct MSAL.NET method.
Use the AcquireTokenByAuthorizationCode method of IConfidentialClientApplication.
This method is specifically designed to exchange the authorization code for access and refresh tokens.
3
Chain the MSAL builder execution method.
Append .ExecuteAsync() to the builder.
MSAL.NET uses a builder pattern, and .ExecuteAsync() must be called to send the asynchronous HTTP request to Microsoft Identity Platform.

Key Concept

Exchanging an authorization code for an access token using MSAL.NET ConfidentialClientApplication.
Question 10Question

An enterprise application uses Azure API Management (APIM) to route requests to a secure backend microservice. The backend microservice requires a specific API key passed via an HTTP header named X-Backend-Key. To secure the credential, the API key is stored as a secret in Azure Key Vault. You have already created an APIM named value named BackendApiKey that references this secret. APIM must retrieve the secret dynamically from the Key Vault using its system-assigned managed identity. Which configuration and policy placement will successfully inject the API key header into the request sent to the backend?

Show answer & explanation

Answer: Place a set-header policy in the inbound section of the policy definition using the {{BackendApiKey}} named value, and ensure the API Management system-assigned managed identity is granted the Key Vault Secrets User role in Azure Key Vault.

Answer

Place a set-header policy in the inbound section of the policy definition using the {{BackendApiKey}} named value, and ensure the API Management system-assigned managed identity is granted the Key Vault Secrets User role in Azure Key Vault.
Placing the set-header policy in the inbound section modifies the request headers before they are forwarded to the backend service. Referencing the named value via the double curly braces syntax retrieves the secret from Azure Key Vault, which succeeds because the system-assigned managed identity is assigned the Key Vault Secrets User role.

Step-by-Step Solution

1
Determine the correct policy section for modifying requests forwarded to the backend.
The inbound section must be used because it processes the request prior to calling the backend service.
Outbound and other sections run too late or are for different stages of the gateway pipeline.
2
Identify the correct referencing format for named values in API Management policies.
Use the curly brace notation format, which in this case is {{BackendApiKey}}.
This tells API Management to look up the named value and retrieve its mapped value, which points to the Key Vault secret.
3
Assign the necessary permissions for Key Vault retrieval via the system-assigned managed identity.
Grant the API Management system-assigned managed identity the Key Vault Secrets User role or Get secret permission in the target Key Vault.
Without explicit permissions, the Key Vault request will be denied, preventing the named value from resolving.

Key Concept

API Management policy configuration for inbound request header injection using Key Vault named values backed by system-assigned managed identities.
Question 11Question

A developer needs to push a locally built container image to an Azure Container Registry (ACR) named contosoacr. The developer has already logged into their Azure account on their workstation using the Azure CLI command az login. However, when they attempt to push the image, they receive an authentication error from the Docker daemon.

Which of the following Azure CLI commands should the developer run to authenticate the local Docker daemon to the registry?

Show answer & explanation

Answer: az acr login --name contosoacr

Answer

Run the command az acr login --name contosoacr to authenticate the local Docker daemon to the registry.
The command az acr login --name contosoacr uses the active Azure CLI session to fetch a token and configure the local Docker daemon. This allows the subsequent docker push command to authenticate successfully against the private container registry.

Step-by-Step Solution

1
Ensure the developer is signed in to Azure using the Azure CLI command az login.
The Azure CLI has an active authentication session on the workstation.
This provides the credentials necessary to access Azure resources, including the registry.
2
Run the command az acr login --name contosoacr.
The local Docker configuration is updated with credentials to access the registry.
This helper command bridges Azure CLI authentication with the Docker daemon configuration.
3
Execute the docker push command.
The container image is successfully pushed to the Azure Container Registry.
The Docker daemon is now authenticated and authorized to perform the push operation.

Key Concept

Authenticating a local developer workstation to Azure Container Registry using the Azure CLI.
Question 12Question

You are developing a serverless API using Azure Functions. The API must scale automatically to handle traffic spikes, but it requires that instances are pre-warmed to completely avoid cold-start latency. Which hosting plan should you select?

Show answer & explanation

Answer: Premium plan

Answer

Premium plan
The Premium plan is the correct choice because it offers the same dynamic scaling as the Consumption plan while ensuring that instances are kept pre-warmed to prevent cold starts.

Step-by-Step Solution

1
Identify the key requirements from the scenario.
The function app needs serverless automatic scaling and pre-warmed instances to eliminate cold start latency.
This determines which hosting plans meet both serverless scaling and zero cold start requirements.
2
Evaluate the capabilities of the Consumption plan.
The Consumption plan scales automatically but scales down to zero when idle, leading to cold starts on subsequent invocations.
This eliminates the Consumption plan as a valid option.
3
Evaluate the capabilities of the Premium plan.
The Premium plan scales automatically and maintains pre-warmed worker instances to avoid any cold start latency.
This confirms the Premium plan satisfies all criteria.

Key Concept

Azure Functions hosting plans capabilities and selection
Estimated Time:45s
Question 13Question

You are deploying an ASP.NET Core web application to an Azure App Service Web App named app-prod-01. The application requires a secret named DbConnectionString stored in an Azure Key Vault named kv-prod-01. The Web App has a system-assigned managed identity that is already configured with a GET access policy on the key vault. You must configure the application settings in the Web App to reference the Key Vault secret without modifying the code. Which configuration format must you use for the value of the DbConnectionString application setting?

Show answer & explanation

Answer: @Microsoft.KeyVault(VaultName=kv-prod-01;SecretName=DbConnectionString)

Answer

The correct format is to use the key-value pair syntax with the @Microsoft.KeyVault prefix, specifying the VaultName and SecretName parameters separated by a semicolon.
The configuration syntax stating '@Microsoft.KeyVault(VaultName=kv-prod-01;SecretName=DbConnectionString)' is correct. App Service successfully parses this format, identifies the Key Vault resource by name, and fetches the secret using the web app's managed identity.

Step-by-Step Solution

1
Identify the mandatory prefix for App Service Key Vault references.
The prefix must be @Microsoft.KeyVault.
Azure App Service parses application settings looking for this exact prefix to resolve secrets dynamically.
2
Select the correct parameters and delimiter for referencing the vault and secret name directly.
Use VaultName and SecretName parameters delimited by a semicolon.
The key-value pair syntax uses semicolons to separate parameters inside the parentheses.
3
Validate the final format structure.
The final structure is @Microsoft.KeyVault(VaultName=kv-prod-01;SecretName=DbConnectionString).
This matches the official syntax rules for referencing Key Vault secrets within App Service settings without relying on a full URI.

Key Concept

Azure App Service Key Vault references allow applications to securely access secrets from a key vault through environment variables without code modifications.
Estimated Time:1m 30s
Question 14Question

You are configuring an Azure Function App that runs on a Consumption hosting plan. You need to increase the execution timeout limit for all functions in the app to the maximum allowable duration under this hosting plan.

Which configuration should you apply to the host.json file?

Show answer & explanation

Answer: Set the "functionTimeout" property to "00:10:00" in the host.json file.

Answer

Set the "functionTimeout" property to "00:10:00" in the host.json file.
The configuration setting the property to 10 minutes ('00:10:00') is correct. Under the Consumption hosting plan, Azure Functions are limited to a maximum execution duration of 10 minutes, up from the default of 5 minutes.

Step-by-Step Solution

1
Identify the hosting plan constraints.
The function app runs on the Consumption plan, which has a default timeout of 5 minutes and a maximum hard limit of 10 minutes.
Knowing hosting plan limits is necessary to determine the maximum value that can be successfully configured.
2
Determine the host.json property used for configuring timeouts.
The correct property to configure function timeouts globally is "functionTimeout".
This property controls execution timeout behavior for all functions within the function app.
3
Format the timeout duration correctly.
The duration must be specified in a timespan format (HH:MM:SS), resulting in "00:10:00".
Azure Functions configuration parser requires timespan formatting for duration properties.

Key Concept

Azure Functions Consumption plan timeout configuration
Question 15Question

Your company deploys an Azure App Service web app named webapp-prod. The web app must retrieve a database connection string securely from an Azure Key Vault named kv-prod. You configure a user-assigned managed identity named id-webapp for webapp-prod and grant it the Key Vault Secrets User role on kv-prod. You need to configure the App Service application settings so that the web app can retrieve the latest version of the secret named DbConnectionString using the user-assigned identity. Which of the following configurations should you apply to the App Service application settings?

Show answer & explanation

Answer: Configure the DbConnectionString setting with the value @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString) and add an application setting named keyVaultReferenceIdentity set to the resource ID of the user-assigned managed identity.

Answer

Configure the DbConnectionString setting with the value @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString) and add an application setting named keyVaultReferenceIdentity set to the resource ID of the user-assigned managed identity.
The correct configuration uses the standard `@Microsoft.KeyVault(SecretUri=...)` syntax to point to the secret URI. Additionally, because the application uses a user-assigned managed identity, the `keyVaultReferenceIdentity` application setting must be added, with its value set to the resource ID of that user-assigned managed identity, to let App Service know which identity to use to authenticate to the Key Vault.

Step-by-Step Solution

1
Define the Key Vault reference in the application setting value.
The application setting is defined as @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString).
This uses the correct syntax and standard SecretUri parameter format to tell App Service where to retrieve the secret.
2
Configure App Service to use the user-assigned managed identity for resolution.
The keyVaultReferenceIdentity application setting is added with the user-assigned managed identity's resource ID as its value.
By default, App Service attempts to use the system-assigned identity. To use a user-assigned identity, you must set the keyVaultReferenceIdentity app setting to point to the resource ID of the user-assigned identity.

Key Concept

Key Vault references in Azure App Service allow applications to securely retrieve secrets without exposing them in configuration. When using user-assigned managed identities, you must configure the keyVaultReferenceIdentity setting alongside the reference.
Estimated Time:2m 0s
Question 16Question

You are configuring a continuous integration pipeline in GitHub Actions to build and push a container image to an Azure Container Registry (ACR) named contosoacr.azurecr.io. The runner does not have the Azure CLI installed, but has the Docker CLI installed. You have created an Azure Active Directory (Azure AD) service principal with the AcrPush role.

You need to authenticate the Docker CLI on the runner to contosoacr.azurecr.io using the service principal credentials.

Which command should you execute in the pipeline runner?

Show answer & explanation

Answer: echo <clientSecret> | docker login contosoacr.azurecr.io --username <clientId> --password-stdin

Answer

Run the command: echo <clientSecret> | docker login contosoacr.azurecr.io --username <clientId> --password-stdin
To authenticate the Docker CLI with an Azure Container Registry using a service principal when the Azure CLI is unavailable, you must use the standard docker login command. The username must be the service principal's Client ID, the password must be the Client Secret, and the target registry must be specified by its repository login server domain name.

Step-by-Step Solution

1
Identify the target registry URL and the authentication tools available.
The target registry is contosoacr.azurecr.io, and only the Docker CLI is available on the runner.
The runner does not have Azure CLI installed, meaning az acr commands cannot be executed.
2
Formulate the Docker login command using the service principal credentials.
Use the client ID as the username and the client secret as the password targeting contosoacr.azurecr.io.
The Docker CLI requires the full login server domain to route the authentication request to Azure Container Registry rather than Docker Hub.
3
Securely pass the client secret to the Docker login command.
Pipe the client secret into docker login using the --password-stdin flag.
Passing passwords directly via command line arguments is insecure and can expose credentials in build logs.

Key Concept

Authenticating to Azure Container Registry using Docker CLI and service principal credentials.
Question 17Question

You are a developer managing container images in Azure. You need to copy a container image named application:v1 from a development Azure Container Registry named devreg to a production Azure Container Registry named prodreg. Both registries are in the same Azure subscription. To save network bandwidth and time, you want to perform this copy directly from registry to registry, without downloading the image to your local workspace or requiring a local Docker installation. Which Azure CLI command should you run?

Show answer & explanation

Answer: az acr import --name prodreg --source devreg.azurecr.io/application:v1 --image application:v1

Answer

Run the command: az acr import --name prodreg --source devreg.azurecr.io/application:v1 --image application:v1
The correct command is the one starting with 'az acr import', as it enables registry-to-registry import directly in the cloud without downloading the image or requiring a local Docker installation.

Step-by-Step Solution

1
Identify the target registry name and the fully qualified source image path.
Target registry is 'prodreg', source image path is 'devreg.azurecr.io/application:v1'.
The import command requires the destination registry name and the source image identifier.
2
Select the correct Azure CLI command for registry-to-registry image copying.
The correct command is 'az acr import'.
This command performs a registry-to-registry import entirely in the cloud without downloading image layers locally.
3
Construct and execute the command specifying the target registry, source registry/image, and target image name/tag.
The final command is: az acr import --name prodreg --source devreg.azurecr.io/application:v1 --image application:v1
This provides all required parameters to copy the image directly on the Azure backend.

Key Concept

Direct registry-to-registry container image importing in Azure Container Registry
Question 18Question

Your company is deploying a web application to Azure App Service. The application requires a database connection string that is stored securely as a secret named 'db-conn' in an Azure Key Vault named 'kv-prod'. You need to configure the web app's application settings to reference this Key Vault secret using its name. Which value should you use for the application setting?

Show answer & explanation

Answer: @Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)

Answer

The correct reference format is '@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)' because it uses the correct prefix, encloses the parameters in parentheses, and separates the VaultName and SecretName parameters with a semicolon.
The correct option is the one specifying '@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)'. In Azure App Service, Key Vault references in application settings must start with the '@Microsoft.KeyVault' prefix, enclose the properties in parentheses, and use a semicolon as the delimiter between key-value pairs like VaultName and SecretName.

Step-by-Step Solution

1
Identify the required prefix for Key Vault references in Azure App Service application settings.
The prefix must be '@Microsoft.KeyVault'.
Azure App Service parses application setting values starting with '@Microsoft.KeyVault' to retrieve secrets at runtime.
2
Determine the parameter format when referencing a secret by the vault name and secret name.
The syntax requires 'VaultName=vault-name;SecretName=secret-name' inside the parentheses.
Parameters must be specified using key-value pairs separated by a semicolon.
3
Construct the final reference string with the given vault 'kv-prod' and secret 'db-conn'.
'@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)'
This matches the requirements of prefix, parameter names, semicolon separator, and parentheses wrapping.

Key Concept

Azure Key Vault references in Azure App Service Application Settings
Estimated Time:45s
Question 19Question

You are configuring a CI/CD pipeline script to push container images to an Azure Container Registry (ACR) named `myregistry`. The script runs in a lightweight container context where only the Docker CLI is available for the build and push steps. To authenticate, you have already retrieved a Microsoft Entra ID access token for the registry using the Azure CLI and stored it in a variable named `$TOKEN`.

You need to run the `docker login` command to authenticate the local Docker daemon to the registry using this token.

Which command should you run?

Show answer & explanation

Answer: docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password $TOKEN

Answer

docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password $TOKEN
The correct command uses the docker login utility to target the myregistry.azurecr.io login server. When authenticating with an access token (such as a Microsoft Entra ID token), the registry requires the username parameter to be the specific GUID 00000000-0000-0000-0000-000000000000, and the password parameter to contain the token value.

Step-by-Step Solution

1
Identify the registry's login server URL.
The login server URL for an ACR named myregistry is myregistry.azurecr.io.
The docker login command requires the full login server URL rather than just the registry name.
2
Determine the correct username for token-based authentication.
The designated username GUID is 00000000-0000-0000-0000-000000000000.
ACR requires the specific token GUID as the username when authenticating via an access token.
3
Formulate and run the docker login command.
docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password $TOKEN
This successfully logs the local Docker daemon into the target Azure Container Registry using the retrieved token.

Key Concept

Authenticating with Azure Container Registry using tokens
Question 20Question

An organization is designing a serverless background processing solution using Azure Functions V4 to process large batches of files uploaded to an Azure Blob Storage container. The solution must satisfy the following constraints:
- Individual file processing operations are CPU-intensive and can take up to 15 minutes to complete.
- The function app must connect securely to an Azure SQL Database that is restricted to a private virtual network.
- The system must dynamically scale out the number of instances to handle sudden, unpredictable spikes in upload volume, and scale back down when idle.
- Cold start latency must be minimized for initial requests after periods of inactivity.

Which hosting plan should the organization choose to deploy the Azure Function app?

Show answer & explanation

Answer: Premium plan

Answer

Premium plan
The Premium plan is the correct choice because it supports outbound virtual network integration, has a default execution timeout of 30 minutes (unbounded maximum), and provides event-based scaling via the Scale Controller to rapidly handle spikes while minimizing cold starts with pre-warmed instances.

Step-by-Step Solution

1
Evaluate the runtime execution limit requirement.
The Consumption plan has a strict 10-minute maximum execution limit, which rules it out since processing can take up to 15 minutes.
Azure Functions hosting plans have different default and maximum execution timeouts.
2
Evaluate the network connectivity requirement.
The basic Consumption plan does not support virtual network integration, further ruling it out.
Securing database access behind a private virtual network requires a plan that supports outbound VNet integration.
3
Compare scaling behaviors of the Premium and Dedicated plans.
The Dedicated plan scales based on standard autoscale rules (e.g., CPU/Memory metrics), whereas the Premium plan scales rapidly based on events (e.g., number of blobs/messages) via the Scale Controller and provides pre-warmed instances to prevent cold starts.
Unpredictable spikes require the event-driven Scale Controller to add instances dynamically and proactively.

Key Concept

Azure Functions hosting plan features and limits, focusing on execution timeouts, network integration, and scaling behaviors.
Page 1 / 25Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin