Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 361Question →

A developer is configuring a data retention policy for a Standard General Purpose v2 (GPv2) storage account. The goal is to automatically transition specific blobs to the Archive tier when they are no longer actively needed. The developer plans to identify target blobs using the index tag `ArchiveStatus = 'Pending'`. Which sequence of steps must the developer perform to configure, apply, and verify this lifecycle management policy?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure and verify the lifecycle management policy, you must first apply the case-sensitive blob index tag to the target blobs. Next, create a local JSON policy file defining a rule with a matching tag filter and a transition action. Then, run the CLI command to apply this policy. Allow up to 2424 hours for the platform's daily run to execute. Finally, query the properties of the blobs to confirm the access tier has transitioned to Archive.
The correct sequence begins with preparing the blobs by tagging them, as they must exist with index tags before evaluation. Then, the JSON policy document must be authored with a `blobIndexMatch` rule. The policy is applied to the Standard GPv2 storage account using `az storage account management-policy create`. Since execution occurs on a daily schedule, the developer must wait up to 2424 hours for the run to complete. Finally, the developer queries the blobs to verify the transition to the Archive tier.

Step-by-Step Solution

1
Tag the target blobs with the index tag `ArchiveStatus` set to `Pending`.
The blobs are indexed and searchable by the lifecycle management service.
The lifecycle service relies on these index tags to match the blob selection criteria during the policy run.
2
Create a JSON policy file defining the rules, filters, and actions.
A valid configuration document that includes the `blobIndexMatch` filter and the `tierToArchive` action.
The policy engine requires a JSON structure matching the Azure Storage lifecycle schema.
3
Apply the policy to the storage account using the Azure CLI command `az storage account management-policy create`.
The lifecycle policy is successfully bound to the Standard GPv2 storage account.
The configuration must be uploaded to the Azure Resource Manager to take effect.
4
Wait for the platform's scheduled execution run.
The platform processes the applied policy on all matching blobs in the storage account.
Lifecycle management policies are executed once every 2424 hours by the Azure platform.
5
Query the access tier of the blobs.
The metadata returns the access tier as Archive.
Confirming the metadata state change verifies that the policy was successfully executed.

Key Concept

Azure Blob Storage Lifecycle Management policy configuration, application, and scheduled execution cycles using index tag filters and Azure CLI.
Question 362Question →

Your development team is implementing a data migration service using the Azure.Storage.Blobs SDK (version 12.x) to migrate large media files from a source container in storage account 'mediaflowsource' to a destination container in storage account 'mediaflowdest' across different Azure regions. The destination blobs are locked with active leases to prevent accidental deletion during the process, and you must overwrite them with the new versions while preserving all user-defined metadata. The source blobs are private, and access must be granted using a Shared Access Signature (SAS) token.

Which of the following actions are required to complete this copy operation successfully? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Generate a Shared Access Signature (SAS) token for the source blob containing the Read permission, and append this token to the source URI passed to the copy operation.; Instantiate a BlobLeaseClient for the destination blob, and provide the active lease ID in the BlobCopyFromUriOptions.DestinationConditions.LeaseId property.

Answer

Generating a Shared Access Signature (SAS) token with Read permission and appending it to the source URI, along with providing the destination blob's active lease ID in the BlobCopyFromUriOptions.DestinationConditions.LeaseId property, are required to successfully complete the copy operation.
To copy a private source blob to a leased destination blob, the Azure Storage copy engine needs Read access to the source blob (provided via a SAS token with Read permission appended to the source URI), and the write request to the destination blob must include the active lease ID in the destination conditions (BlobCopyFromUriOptions.DestinationConditions.LeaseId) to authorize the overwrite.

Step-by-Step Solution

1
Generate a SAS token for the source blob with Read permissions and append it to the source blob's URI.
A secure source URI is created, enabling the Azure Storage service to access and copy the source blob.
Since the source blob is private and located in a different storage account, the Azure Storage copy engine requires read access to the source content.
2
Obtain the lease ID of the active lease on the destination blob using BlobLeaseClient.
The active lease ID is retrieved for authorization.
Modifying or overwriting a leased blob requires the lease ID to bypass the write lease protection.
3
Call StartCopyFromUriAsync on the destination BlobClient, passing the source URI and configuring the LeaseId in BlobCopyFromUriOptions.DestinationConditions.
The asynchronous copy operation is initiated successfully without throwing a 412 Precondition Failed error.
Providing the lease ID in the destination conditions permits the copy engine to overwrite the leased destination blob.

Key Concept

Asynchronous blob copying between storage accounts with source SAS authorization and destination lease handling using the .NET Azure.Storage.Blobs SDK.
Question 363Question →

You are designing a V4 Azure Function App that processes messages from an Azure Queue Storage queue. The Function App is hosted on a Consumption plan.

You have the following requirements:
1. Prevent a single Function App instance from processing more than 88 messages concurrently to avoid memory exhaustion.
2. Prevent the Function App from scaling out to more than 1010 instances to avoid overloading a downstream database.

Which of the following configuration actions must you perform? (Select TWO)

Select all that apply

Show answer & explanation

Answer: In the host.json file, configure the batchSize property to 8 under the extensions/queues section.; Add an Application Setting named WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT and set its value to 10.

Answer

In the host.json file, configure the batchSize property to 8 under the extensions/queues section, and add an Application Setting named WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT and set its value to 10.
To limit the concurrent message processing on a per-instance basis, you must modify the global host configuration. In Azure Functions, the batchSize property within the extensions/queues block of the host.json file defines how many messages an instance can pull and process concurrently. To limit the overall scale-out of the Function App, you configure the WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT application setting, which tells the scale controller to cap instance allocation at the specified limit.

Step-by-Step Solution

1
Configure the per-instance concurrency limit.
Modify host.json to include "queues": { "batchSize": 8 } under the extensions section.
This limits the maximum number of queue messages that a single instance of the Functions runtime will retrieve and process concurrently.
2
Configure the scale-out limit for the Function App.
Add the WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT setting with a value of 10 in the Azure Function App application settings.
This restricts the scale controller from provisioning more than 10 instances under high load conditions.

Key Concept

Azure Functions Concurrency and Scale-out Configuration
Question 364Question →

You are troubleshooting a performance issue with a Kusto Query Language (KQL) query used to retrieve telemetry from Application Insights. The query currently looks like this:

kql
requests
| where success == false
| summarize count() by bin(timestamp, 1h)

The query is taking a long time to run and occasionally exceeds resource limits because it scans all historical data.

Which of the following changes should you make to the query to improve performance and prevent resource limit issues?

Show answer & explanation

Answer: Add a where clause filtering by a timestamp range (e.g., | where timestamp > ago(24h)) immediately after the requests table.

Answer

Add a where clause filtering by a timestamp range (e.g., | where timestamp > ago(24h)) immediately after the requests table.
Filtering by timestamp early in the query pipeline restricts the dataset size processed by subsequent operators. In this query, adding the time filter immediately after the requests table ensures the query engine only scans the last 24 hours of data, preventing slow execution times and resource limit exhaustion.

Step-by-Step Solution

1
Analyze the KQL query pipeline structure.
The query starts with the requests table, applies a success filter, and then summarizes the data.
Understanding the pipeline order is crucial because KQL executes operations sequentially.
2
Identify the performance bottleneck in the query.
The query lacks a time-range boundary, forcing Azure Monitor to scan the entire historical telemetry database.
Restricting the time range is the single most effective way to optimize telemetry queries.
3
Determine the optimal position for the time filter.
Placing '| where timestamp > ago(24h)' immediately after 'requests' ensures that only data from the last 24 hours is loaded into subsequent operators.
Filtering early reduces the volume of data processed by downstream operators like summarize.

Key Concept

KQL Query Optimization with Time-Range Filters
Estimated Time:1m 0s
Question 365Question →

You are developing a multi-tenant SaaS application that will be distributed to various corporate clients. The application requires access to the Microsoft Graph API.

You have the following requirements:
1. Users from any Microsoft Entra ID tenant must be able to sign in to the application.
2. Personal Microsoft accounts (such as Skype, Outlook.com, or Xbox Live) must be prevented from signing in.
3. A tenant administrator must be able to grant consent to the application's required permissions for all users in their tenant.

You need to configure the application registration and endpoints.

Which two actions should you perform? (Each correct answer presents part of the solution.)

Select all that apply

Show answer & explanation

Answer: In the application manifest, set the `signInAudience` property to `AzureADMultipleOrgs`.; Configure the application's user sign-in endpoint to target `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize`.

Answer

To configure the multi-tenant application to allow only organizational directories and block personal accounts, set the `signInAudience` property to `AzureADMultipleOrgs` in the application manifest and configure the user sign-in endpoint to target the `/organizations` authorize endpoint.
Configuring the application manifest with a `signInAudience` of `AzureADMultipleOrgs` specifies that the app supports accounts in any organizational directory. Pairing this with the `/organizations` authorize endpoint ensures that only work or school accounts are accepted during authentication, effectively blocking personal Microsoft accounts. Together, these steps satisfy the multi-tenant requirements while enforcing the exclusion of personal accounts.

Step-by-Step Solution

1
Select the correct `signInAudience` in the application manifest.
Setting `signInAudience` to `AzureADMultipleOrgs` enables multi-tenant support for organizational directories only.
This excludes personal Microsoft accounts at the application registration level.
2
Determine the appropriate sign-in endpoint for user authentication.
Using `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize` restricts incoming authentication requests to organizational tenants.
The `/common` endpoint would allow personal Microsoft accounts to authenticate, violating the requirement to exclude them.
3
Understand the requirements of the admin consent endpoint.
Constructing the admin consent URL requires a specific tenant ID or domain name instead of a generic placeholder like `/organizations`.
Microsoft Entra ID requires an explicit target directory to record the tenant-wide admin consent.

Key Concept

Microsoft Entra ID multi-tenant application endpoint configuration and manifest properties
Question 366Question →

You are configuring a multi-tenant web application in Microsoft Entra ID. The application must allow users with work or school accounts from any organization's tenant to log in, but must exclude personal Microsoft accounts. Which two configurations are required 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 to use the /organizations endpoint

Answer

Set the signInAudience property in the application manifest to AzureADMultipleOrgs and configure the authority URI to use the /organizations endpoint.
To configure a multi-tenant application that supports work and school accounts from any organization but excludes personal accounts, you must set the signInAudience to AzureADMultipleOrgs and use the /organizations endpoint. The /organizations endpoint is specifically designed for work or school accounts from any Microsoft Entra ID tenant, whereas the /common endpoint would also include personal Microsoft accounts.

Step-by-Step Solution

1
Configure the application manifest to allow multi-tenant access.
The signInAudience property is set to AzureADMultipleOrgs.
This allows accounts in any organizational directory to sign in to the application.
2
Configure the authority endpoint URI in the application's authentication configuration.
The authority URI uses the /organizations endpoint.
This filters the sign-ins to only organizational accounts and excludes personal Microsoft accounts.

Key Concept

Configuring multi-tenant Microsoft Entra ID applications requires setting the appropriate signInAudience parameter in the application manifest and using the correct authority endpoint to filter user accounts.
Question 367Question →

You are developing a containerized background service that will be deployed to Azure Container Instances (ACI). The service must retrieve messages from an Azure Queue Storage queue, process the data, and write output files to an Azure Blob Storage container. You need to configure security and handle message payloads that may occasionally exceed 64 KB. Which configuration should you implement to meet these requirements securely while ensuring operational reliability?

Show answer & explanation

Answer: Enable a system-assigned managed identity on the ACI container group, assign it the Storage Queue Data Message Processor and Storage Blob Data Contributor roles, and store payloads larger than 64 KB in Blob Storage while sending only the URI reference in the queue message.

Answer

Enable a system-assigned managed identity on the ACI container group, assign it the Storage Queue Data Message Processor and Storage Blob Data Contributor roles, and store payloads larger than 64 KB in Blob Storage while sending only the URI reference in the queue message.
To securely connect the containerized service to Azure storage resources without managing credentials, a system-assigned managed identity should be enabled on the container group. The identity can then be granted the specific Azure RBAC roles required (Storage Queue Data Message Processor for queue operations and Storage Blob Data Contributor for blob operations). Furthermore, because Azure Queue Storage enforces a strict 64 KB size limit per message, payloads exceeding this threshold must be stored in Blob Storage, with only the reference URI placed in the queue.

Step-by-Step Solution

1
Configure authentication for the container group using a managed identity.
Enable a system-assigned managed identity on the Azure Container Instance (ACI) container group and assign it the necessary RBAC roles (Storage Queue Data Message Processor and Storage Blob Data Contributor) on the target storage resources.
This avoids hardcoding credentials or using long-lived SAS tokens, adhering to the principle of least privilege.
2
Implement message size handling in the application code.
Check if the message payload size exceeds 64 KB. If it does, upload the payload to Blob Storage first, and then write a queue message containing the URI reference to the blob.
Azure Queue Storage has a strict 64 KB message size limit, so larger payloads must be stored externally in Blob Storage.

Key Concept

Securing Azure Container Instances using managed identities and handling Queue Storage limits for large payloads.
Question 368Question →

A company is developing a C# daemon application that runs on an on-premises server. The application must connect to Microsoft Graph to read directory data without any user intervention.

Which two configuration steps must you perform to enable authentication for this daemon application? Select two.

Select all that apply

Show answer & explanation

Answer: Register the application as a confidential client in Microsoft Entra ID and configure a client secret or certificate.; Initialize the application using the ConfidentialClientApplicationBuilder class in the Microsoft Authentication Library (MSAL.NET).

Answer

To enable authentication for the daemon application, you must register the application as a confidential client in Microsoft Entra ID and configure a client secret or certificate, and initialize the application using the ConfidentialClientApplicationBuilder class in MSAL.NET.
The application runs unattended as a daemon service. In Microsoft Entra ID, this requires a confidential client registration with a client secret or certificate. In MSAL.NET, the developer must use the ConfidentialClientApplicationBuilder class to initialize the client and acquire tokens using the client credentials flow.

Step-by-Step Solution

1
Determine the application type based on user interaction requirements.
The application runs on a server without user intervention, meaning it must be treated as a daemon service (confidential client).
Daemon applications require application-level permissions and use confidential client flows because they can securely keep a client credential.
2
Configure the registration in Microsoft Entra ID.
Register the application and generate a client secret or upload a certificate under Certificates & secrets.
Confidential client flows require a secret or certificate credential to verify the application's identity.
3
Select the correct builder in MSAL.NET.
Use ConfidentialClientApplicationBuilder.Create(clientId) to build the client instance.
The ConfidentialClientApplicationBuilder class is specifically designed to support confidential client flows such as Client Credentials.

Key Concept

Daemon applications run without user interaction and must be configured as confidential clients using MSAL.NET ConfidentialClientApplicationBuilder and registered in Microsoft Entra ID with appropriate credentials (client secrets or certificates).
Question 369Question →

You host a file compression utility named ZipArchiver on an Azure App Service Web App. The web app currently runs on a Basic (B2) App Service plan. During daytime operations, CPU utilization frequently spikes to 85%, causing request queues to build up. You need to configure the Web App to automatically scale out when CPU utilization exceeds 80% for more than 10 minutes, and scale in when CPU utilization drops below 40%.

What should you do first?

Show answer & explanation

Answer: Scale up the App Service plan to the Standard (S1) tier.

Answer

Scale up the App Service plan to the Standard (S1) tier.
Scaling up the App Service plan to the Standard (S1) tier is the correct first step because the Basic tier does not support metric-based autoscale settings. Standard and higher tiers are required to configure automatic scale-out and scale-in actions based on CPU utilization.

Step-by-Step Solution

1
Analyze the scaling requirement and the current pricing tier.
The requirement demands automatic scale-out and scale-in rules based on CPU utilization metrics, but the current plan is Basic (B2).
Different Azure App Service tiers support different scaling features; Basic only supports manual scale.
2
Evaluate the scaling capabilities of the Basic tier.
The Basic tier does not support metric-based autoscale rules.
To use autoscale rules, the App Service plan must support this capability.
3
Identify the minimum App Service tier that supports autoscale rules.
The Standard (S1) tier is the lowest tier that supports metric-based autoscale rules.
Upgrading the plan to the Standard tier is a necessary first step to allow configuring CPU-based autoscale rules.

Key Concept

Azure App Service scaling tiers and autoscale capabilities
Estimated Time:1m 30s
Question 370Question →

You are developing an ASP.NET Core web application that will be hosted on an Azure App Service. The application must securely read blobs from an Azure Storage container. You decide to use a user-assigned managed identity to handle authentication.

Which sequence of steps should you perform to provision, configure, and utilize the user-assigned managed identity to access the storage container?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first create the user-assigned managed identity, then associate it with the Azure App Service instance, then assign the Storage Blob Data Reader RBAC role to the identity at the storage container scope, and finally instantiate the DefaultAzureCredential class in the application code by passing the Client ID of the identity to the constructor options.
The correct sequence begins with provisioning the user-assigned managed identity. Once created, the identity is linked to the App Service hosting environment. Next, the identity is granted the Storage Blob Data Reader role to authorize access. Finally, the application code initiates authentication using DefaultAzureCredential configured with the identity's Client ID.

Step-by-Step Solution

1
Create the user-assigned managed identity resource.
A standalone user-assigned managed identity resource is created with its own Client ID and Principal ID.
The identity must exist in Microsoft Entra ID before it can be associated with hosts or granted access permissions.
2
Associate the user-assigned managed identity with the App Service.
The identity is linked to the App Service host instance, permitting it to request tokens for this identity.
The hosting platform must be aware of the identity to expose its credentials through the local metadata endpoint.
3
Create an RBAC role assignment for the identity on the Storage account.
The identity is granted the Storage Blob Data Reader role at the container or storage account scope.
The identity needs explicit authorization to perform data plane operations on the Azure Storage resource.
4
Configure the application code to use the identity client ID.
The application code uses DefaultAzureCredential with the specific Client ID to request a token and read blobs.
Without the client ID, DefaultAzureCredential will default to a system-assigned managed identity and fail since only a user-assigned identity is associated.

Key Concept

Provisioning and configuring a user-assigned managed identity for Azure App Service authorization
Question 371Question →

You are developing a secure Web API named InventoryAPI and registering it in Microsoft Entra ID. You need to expose two distinct permission sets for client applications that will consume this API:

1. A permission set for automated backend daemon services that run without user interaction.
2. A permission set for user-facing client applications where permissions are delegated on behalf of the signed-in user.

You need to configure the application registration manifest for InventoryAPI to support these requirements.

Which configuration should you implement in the manifest?

Show answer & explanation

Answer: Define app roles in the appRoles array with allowedMemberTypes set to ["Application"] for the daemon services, and define delegated scopes in the oauth2PermissionScopes array for the user-interactive applications.

Answer

Define app roles in the appRoles array with allowedMemberTypes set to ["Application"] for the daemon services, and define delegated scopes in the oauth2PermissionScopes array for the user-interactive applications.
The correct option correctly states that application permissions (which daemon applications require because they authenticate as their own identity) must be defined as app roles within the appRoles array with the allowedMemberTypes property containing "Application". Meanwhile, delegated permissions (which user-facing client applications require to act on behalf of a signed-in user) must be defined as scopes within the oauth2PermissionScopes array.

Step-by-Step Solution

1
Analyze client type requirements for the API.
Backend daemon applications require Application permissions (as they run without a signed-in user). User-facing applications require Delegated permissions (scopes) since they act on behalf of a signed-in user.
This establishes the appropriate Entra ID authorization model needed for each consumer type.
2
Map the permission types to their respective Microsoft Entra ID manifest elements.
Application permissions are represented by appRoles where allowedMemberTypes includes "Application". Delegated permissions are represented by OAuth 2.0 permission scopes defined in the oauth2PermissionScopes array.
This determines the syntax and structure needed in the InventoryAPI registration manifest.
3
Validate the valid values for manifest properties.
allowedMemberTypes only accepts "User", "Application", or both. oauth2PermissionScopes defines scopes for delegated user access.
This ensures the manifest configuration is syntactically valid and aligns with Microsoft Entra ID schema constraints.

Key Concept

Exposing delegated permissions (scopes) vs application permissions (app roles) in a Microsoft Entra ID App Registration manifest
Question 372Question →

You are developing a C# .NET 8 application hosted on an Azure App Service. The application must access both an Azure Key Vault and an Azure SQL Database.

You have the following security and lifecycle requirements:
- The credentials used to access the Key Vault must be unique to the App Service instance and must be automatically deleted if the App Service is deleted.
- The credentials used to access the SQL Database must be shared with another App Service instance in a different region and must persist even if the primary App Service is deleted.

To meet these requirements, you enable a system-assigned managed identity on the App Service and grant it access to the Key Vault. You also create a user-assigned managed identity, assign it to the App Service, and grant it access to the SQL Database.

In your application code, you instantiate the clients using the parameterless DefaultAzureCredential constructor from the Azure.Identity library. During testing, the application successfully retrieves secrets from the Key Vault, but attempts to connect to the SQL Database fail with an access denied error.

Which modification must you make to resolve the SQL Database connection failure?

Show answer & explanation

Answer: Instantiate the credential for the SQL Database client by passing a DefaultAzureCredentialOptions object with its ManagedIdentityClientId property set to the client ID of the user-assigned managed identity.

Answer

Instantiate the credential for the SQL Database client by passing a DefaultAzureCredentialOptions object with its ManagedIdentityClientId property set to the client ID of the user-assigned managed identity.
When both system-assigned and user-assigned managed identities are enabled on a resource, DefaultAzureCredential defaults to using the system-assigned identity. To use the user-assigned identity for the SQL Database connection, you must explicitly specify its client ID using the ManagedIdentityClientId property of DefaultAzureCredentialOptions.

Step-by-Step Solution

1
Identify the default behavior of DefaultAzureCredential when both identity types are enabled.
DefaultAzureCredential defaults to using the system-assigned managed identity.
Azure token endpoints resolve requests without a client ID to the system-assigned managed identity by default.
2
Analyze why Key Vault succeeds and SQL Database fails.
Key Vault client succeeds because it uses the default system-assigned identity which has access, while SQL Database fails because the system-assigned identity does not have SQL access.
Only the user-assigned managed identity has been granted permissions to the SQL Database.
3
Configure the credential for the user-assigned managed identity.
Provide the user-assigned managed identity client ID in the DefaultAzureCredentialOptions.
Specifying the ManagedIdentityClientId overrides the default behavior and forces the credential to authenticate using the user-assigned managed identity.

Key Concept

Configuring DefaultAzureCredential when using both system-assigned and user-assigned managed identities on a single Azure resource.
Question 373Question →

You are developing a C# console application that processes IoT telemetry using the Azure Cosmos DB .NET SDK v3.

The application must connect to a database named `TelemetryDb` and a container named `DeviceData`. The container's partition key path is set to `/deviceId`.

You need to write code to retrieve a single telemetry reading document with an ID of `device-reading-101` and a partition key value of `device-id-55`.

Arrange the following steps in the correct order to configure the SDK, execute the point read operation, and retrieve the deserialized telemetry data.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To retrieve the telemetry data, you must first initialize a CosmosClient. Then, call GetDatabase to get a Database reference, and call GetContainer on that database to get a Container reference. Execute the point read by calling ReadItemAsync on the container with the item ID and the PartitionKey. Finally, retrieve the deserialized object by accessing the Resource property of the response.
The correct order follows the logical hierarchy of the Azure Cosmos DB SDK v3: first, a CosmosClient is initialized to manage connections; then, a Database reference is retrieved; next, a Container reference is obtained; after that, ReadItemAsync is called on the container using the document's ID and its partition key; finally, the Resource property of the response is accessed to get the deserialized entity.

Step-by-Step Solution

1
Initialize CosmosClient
A thread-safe, singleton client instance connected to Azure Cosmos DB
The CosmosClient acts as the entry point to the Azure Cosmos DB service and maintains connection pools.
2
Obtain Database reference
A Database object representing TelemetryDb
You must navigate the hierarchy from client to database before referencing a container.
3
Obtain Container reference
A Container object representing DeviceData
Item operations are executed against a specific Container object, which is a child of the database.
4
Call ReadItemAsync
An ItemResponse containing the status and payload of the read
The point read must be executed by passing both the item ID and the partition key value as a PartitionKey object.
5
Access Resource property
The deserialized DeviceReading object
The ItemResponse contains metadata and headers; the actual document payload is accessed via the Resource property.

Key Concept

Point read operations using the Azure Cosmos DB .NET SDK v3 hierarchy
Estimated Time:2m 0s
Question 374Question →

A developer is configuring security for an Azure App Service instance. They need to understand how managed identities behave when the App Service is deleted or updated. Which of the following statements correctly describe the characteristics of a system-assigned managed identity? (Select TWO).

Select all that apply

Show answer & explanation

Answer: The identity is tied directly to the lifecycle of the Azure App Service instance.; The identity is automatically deleted when the associated Azure App Service instance is deleted.

Answer

The correct statements are that the system-assigned managed identity is tied directly to the lifecycle of the Azure App Service instance, and it is automatically deleted when the associated App Service instance is deleted.
A system-assigned managed identity is created directly on an Azure resource instance (such as an App Service). As a result, its lifecycle is directly tied to that resource: it is automatically deleted when the resource is deleted, and it cannot be shared with or assigned to any other resources.

Step-by-Step Solution

1
Analyze the lifecycle characteristics of system-assigned managed identities.
System-assigned managed identities are enabled directly on a resource, and their identity in Microsoft Entra ID is tied directly to that resource.
This establishes that the identity's existence depends entirely on the resource's existence.
2
Determine the behavior of the identity when the hosting resource is deleted.
Deleting the Azure App Service instance automatically triggers the cleanup and deletion of the associated system-assigned identity in Microsoft Entra ID.
This ensures that no orphaned identities remain when resources are decommissioned.
3
Contrast with user-assigned managed identities to eliminate incorrect options.
User-assigned managed identities are created as independent Azure resources and can be shared across multiple Azure resources, whereas system-assigned identities are exclusive and have a dependent lifecycle.
This distinguishes system-assigned identities from user-assigned identities.

Key Concept

Managed Identity Lifecycle and Resource Binding
Question 375Question →

You are configuring a custom Webhook endpoint to receive events from Azure Event Grid. During the creation of the event subscription, Azure Event Grid sends a subscription validation request to your endpoint. To successfully complete the validation handshake under the default Event Grid event schema, which property from the event payload data object must your endpoint return in the validation response body?

Show answer & explanation

Answer: validationCode

Answer

validationCode
The correct answer is validationCode. When Event Grid sends a subscription validation event to a Webhook endpoint using the default Event Grid schema, it includes a validationCode inside the data object of the payload. The endpoint must echo this validationCode back in the response body to successfully complete the validation handshake.

Step-by-Step Solution

1
Identify the mechanism Azure Event Grid uses to verify ownership of a Webhook endpoint during subscription.
Azure Event Grid sends a subscription validation event containing a unique validation code in the data payload.
This prevents abuse by ensuring the endpoint is configured to receive Event Grid events.
2
Determine the correct property name to be returned in the validation response.
The property is named validationCode.
The validation handshake protocol requires the client to echo the validationCode back to Azure Event Grid.

Key Concept

Azure Event Grid Webhook endpoint validation handshake
Question 376Question →

An organization deploys an Azure Content Delivery Network (CDN) endpoint to deliver static images for a web application. The application frequently appends version query strings to image URLs (e.g., `image.png?v=1.1` and `image.png?v=1.2`) to force updates. However, the CDN currently serves stale images by returning the cached version of `image.png` for all versioned requests.

Which query string caching setting should you configure on the Azure CDN endpoint to ensure that each unique version query string is cached and served as a separate asset?

Show answer & explanation

Answer: Cache every unique URL

Answer

Configure the Azure CDN endpoint query string caching behavior to 'Cache every unique URL'.
The correct setting is to cache every unique URL. This ensures that when a client requests an asset with a specific query string (such as `image.png?v=1.1`), the Azure CDN treats it as a unique asset and caches it separately from `image.png?v=1.2` or the base `image.png` URL.

Step-by-Step Solution

1
Analyze the business requirement and current problematic behavior.
The application requires query-string versioned URLs (e.g., `?v=1.1`) to be treated as distinct assets, but the CDN currently returns the same cached version of the base file.
This indicates that the CDN is ignoring query parameters during caching lookup.
2
Evaluate Azure CDN query string caching options.
Azure CDN offers three behaviors: 'Ignore query strings' (default, ignores parameters), 'Bypass caching' (does not cache any parameterized requests), and 'Cache every unique URL' (caches each unique URL as a separate asset).
We need to identify the setting that permits caching of individual versioned requests.
3
Select the correct caching setting.
Choosing 'Cache every unique URL' matches the requirement because each query string is treated as a unique identifier for caching.
This enables versioned assets to be cached and served directly from CDN edge servers without returning stale content or overloading the origin.

Key Concept

Azure CDN query string caching behavior determines how requests with query parameters are cached at edge nodes.
Estimated Time:45s
Question 377Question →

A development team is troubleshooting intermittent database connectivity errors in an Azure Web App. You need to write a Kusto Query Language (KQL) query in Application Insights to correlate failed dependency calls with exceptions. The query must return the target of the failed dependency, the associated exception details, and the operation ID. To prevent query timeouts on high-volume production logs, the query must be optimized to scan the minimum amount of data possible within the last 24 hours.

Which KQL query should you use?

Show answer & explanation

Answer: dependencies
| where timestamp > ago(24h) and success == false
| join kind=inner (
exceptions
| where timestamp > ago(24h)
) on operation_Id
| project timestamp, operation_Id, target, outerMessage

Answer

The query that filters both the dependencies and exceptions tables by the 24-hour time range before joining them on the operation ID.
The correct query applies the 24-hour time filter to both the dependencies table and the exceptions subquery. In Kusto, telemetry tables are partitioned by timestamp. Applying the time filter to both datasets before performing the join ensures that partition pruning is applied on both tables, drastically reducing the data scanned during the join and preventing query timeouts.

Step-by-Step Solution

1
Apply a time-range filter to the left table (dependencies) to limit the scan size prior to joining.
The left side of the join is restricted to failed dependencies from the last 24 hours.
Kusto partitions telemetry data by time, and filtering early enables partition pruning.
2
Define an inner join subquery on the right table (exceptions) and apply the same time-range filter inside it.
The right side of the join is restricted to exceptions from the last 24 hours.
Without a filter in the subquery, Kusto would scan the entire historical log of exceptions.
3
Correlate records between the two filtered datasets using the common operation ID key.
Only matching dependencies and exceptions within the 24-hour window are joined.
This minimizes memory usage and CPU time during the join operation.
4
Use the project operator to select only the required fields.
The output contains the timestamp, operation ID, target, and exception message.
Projecting only necessary columns reduces data serialization and transfer size.

Key Concept

Partition pruning and early time-range filtering in KQL joins
Question 378Question →

You are configuring caching rules for an Azure CDN Standard from Microsoft endpoint. The origin server hosts a web application with the following requirements:

* JSON configuration files located in the `/config/` directory must be cached on the CDN for exactly 2 hours, regardless of any `Cache-Control` headers returned by the origin server.
* Media files located in the `/media/` directory must honor the `Cache-Control` header set by the origin server. If the origin server does not return a `Cache-Control` header, the CDN must cache these files for 5 days.
* For all requests to the endpoint, any query string parameters must be ignored by the CDN, and the same cached asset must be served to all users.

Which configuration should you apply to the CDN endpoint?

Show answer & explanation

Answer: Query string caching behavior: Ignore query strings; Custom caching rule for /config/*: Caching behavior set to Override with a duration of 2 hours; Custom caching rule for /media/*: Caching behavior set to Set if missing with a duration of 5 days

Answer

The configuration that sets Query string caching behavior to 'Ignore query strings', the custom caching rule for `/config/*` to 'Override' with a 2-hour duration, and the custom caching rule for `/media/*` to 'Set if missing' with a 5-day duration.
The correct configuration requires setting the global query string caching behavior to 'Ignore query strings' to ensure that query parameters are not used to generate separate cache entries. For the configuration files under `/config/*`, setting the custom caching behavior to 'Override' ignores the origin's Cache-Control header and applies the 2-hour duration. For media files under `/media/*`, setting the custom caching behavior to 'Set if missing' honors the origin's Cache-Control header if it exists and uses the 5-day duration only when the header is missing.

Step-by-Step Solution

1
Select the correct Query String caching behavior.
Query string caching behavior: Ignore query strings
The requirement states that query string parameters must be ignored by the CDN so that the same cached asset is served regardless of the query parameters.
2
Configure the custom caching rule for configuration files under `/config/`.
Caching behavior: Override; Duration: 2 hours
To cache files for exactly 2 hours regardless of the origin server's Cache-Control headers, the 'Override' behavior must be used to ignore the origin's caching instructions.
3
Configure the custom caching rule for media files under `/media/`.
Caching behavior: Set if missing; Duration: 5 days
To honor the origin server's Cache-Control headers when present and only apply the 5-day duration when the headers are absent, the 'Set if missing' behavior must be used.

Key Concept

Azure CDN Caching Rules and Query String Caching Behavior
Estimated Time:2m 0s
Question 379Question →

An Azure App Service web application experiences performance degradation due to slow external HTTP dependency calls. You need to write a Kusto Query Language (KQL) query in Application Insights to identify the top three external dependencies that failed in the last 24 hours, sorted by their average duration, along with the total count of failures for each dependency. The query must be optimized for performance and scan the minimum amount of data.

Which KQL query should you use?

Show answer & explanation

Answer: dependencies
| where timestamp > ago(24h) and success == false
| summarize AvgDuration = avg(duration), FailureCount = count() by name
| top 3 by AvgDuration desc

Answer

The correct query filters the dependencies table by timestamp and success status first, then summarizes the average duration and count of failures by name, and finally selects the top 3 by average duration descending.
The query filtering by timestamp and success at the very beginning of the pipeline is correct because it limits the scope of the telemetry records before aggregation, optimizing query performance. It utilizes the dependencies table to analyze outgoing calls and aggregates by name using avg(duration) and count() to calculate average duration and total failures respectively.

Step-by-Step Solution

1
Identify the appropriate Application Insights table for external calls.
The dependencies table is selected.
The requests table only tracks incoming HTTP requests, whereas external calls are logged in the dependencies table.
2
Apply a time-range filter as early as possible in the KQL query.
The clause 'where timestamp > ago(24h)' is placed immediately after the table name.
Filtering early minimizes the volume of scanned telemetry data, improving query performance and preventing scan limits from being reached.
3
Filter for failed dependencies and aggregate the results.
The query filters for 'success == false' and uses 'summarize AvgDuration = avg(duration), FailureCount = count() by name' followed by 'top 3 by AvgDuration desc'.
This properly calculates the average duration and total failure count per dependency name, and retrieves the top three slow failed dependencies.

Key Concept

Querying and optimizing Application Insights telemetry using KQL by applying early time filters
Question 380Question →

An organization is implementing a cloud-based event-driven architecture using Azure Event Grid. You are tasked with creating an event subscription for a custom Event Grid topic that forwards events to an external, third-party REST API via a Webhook.

The architecture has the following constraints and requirements:
1. Endpoint Validation: The third-party API processes incoming requests asynchronously. Upon receiving a request, it immediately returns an HTTP status code of 202 Accepted and does not support returning a JSON response body synchronously.
2. Dead-Lettering: Any events that fail to deliver must be stored in a secure Azure Blob Storage container named 'deadletters'. You must avoid storing any static credentials or SAS tokens in the subscription configuration.

Which of the following configuration strategies should you implement to satisfy these requirements?

Show answer & explanation

Answer: Capture the SubscriptionValidationEvent sent to the webhook, extract the validationUrl, send an HTTP GET request to that URL within 10 minutes, and configure dead-lettering by enabling a system-assigned managed identity on the custom topic and granting it the Storage Blob Data Contributor role on the storage account.

Answer

To satisfy the requirements, perform manual validation by capturing the SubscriptionValidationEvent, extracting the validationUrl, and sending an HTTP GET request to that URL within 10 minutes. For dead-lettering, enable a system-assigned managed identity on the Event Grid custom topic and grant it the Storage Blob Data Contributor role on the destination storage account.
The correct strategy implements manual (asynchronous) validation by parsing the SubscriptionValidationEvent sent to the webhook, extracting the validationUrl, and sending an HTTP GET request to it within 10 minutes. For credential-free dead-lettering, a system-assigned managed identity is enabled on the custom topic, and it is assigned the Storage Blob Data Contributor role on the destination storage account to grant Event Grid the necessary write permissions.

Step-by-Step Solution

1
Determine the endpoint validation type based on the response behavior.
Since the webhook endpoint returns HTTP 202 Accepted synchronously and does not return the validationCode in the body, synchronous validation is impossible. An asynchronous (manual) validation handshake must be used.
Event Grid synchronous validation fails if the endpoint does not return a JSON payload containing the validationResponse synchronously within the body of a successful HTTP response.
2
Complete the manual validation handshake.
Retrieve the validationUrl from the Microsoft.EventGrid.SubscriptionValidationEvent payload received by the webhook, and perform an HTTP GET request to that URL.
Performing an HTTP GET request to the validationUrl validates the endpoint ownership and activates the event subscription. The URL is valid for 10 minutes.
3
Identify the credential-free authentication mechanism for dead-lettering.
Select managed identities as the authentication mechanism for accessing the Azure Blob Storage account.
Managed identities allow Azure resources to authenticate securely without storing credentials in the code or deployment configurations.
4
Configure the managed identity and assign appropriate roles.
Enable a system-assigned managed identity on the Event Grid custom topic. Assign the 'Storage Blob Data Contributor' role to the topic's managed identity on the target storage account.
The Event Grid topic requires write permissions (Storage Blob Data Contributor) to upload and write dead-lettered events to the storage container. Reader permissions or configuring the identity on the storage account itself will fail.

Key Concept

Azure Event Grid manual webhook validation and secure dead-lettering configuration using managed identities
PreviousPage 19 / 49Next