Tüm alıştırma soruları

972 soru

Soru 241Soru

You are defining an Azure Container App named `order-processor` within an Azure Resource Manager Bicep template. The container app has the following deployment requirements:
1. It must pull its container image from a private Azure Container Registry named `myregistry.azurecr.io` using a user-assigned managed identity. The identity's resource ID is `/subscriptions/.../resourceGroups/.../providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity`.
2. It must accept public HTTPS traffic from the internet on port 8080 using the HTTP/2 transport protocol.
3. It must scale between 2 and 10 replicas based on average CPU usage.

Which of the following configuration blocks must be defined inside the `properties.configuration` section of the Bicep template to satisfy the registry credentials and ingress requirements? (Select TWO)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: registries: [
{
server: 'myregistry.azurecr.io'
identity: '/subscriptions/.../resourceGroups/.../providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity'
}
]; ingress: {
external: true
targetPort: 8080
transport: 'http2'
}

Cevap

The correct configurations are the registries block referencing the user-assigned identity resource ID, and the ingress block configuring external access, targetPort of 8080, and http2 transport.
The registries configuration correctly maps the private ACR server to the resource ID of the user-assigned managed identity, allowing secure image pulling. The ingress configuration correctly exposes the container app externally on port 8080 using the required http2 transport.

Adım Adım Çözüm

1
Analyze the registry authentication requirements to determine the correct Bicep syntax for pulling images with a user-assigned managed identity.
The configuration must include a registries array under properties.configuration. The target registry server must be defined, and the identity field must be set to the user-assigned identity's resource ID rather than 'system'.
Azure Container Apps requires explicit registry credentials setup under the configuration block to pull from private registries like ACR, pointing to the specific managed identity resource ID.
2
Analyze the ingress requirements to determine the correct Bicep property names for public traffic, target port, and transport protocol.
The configuration must define an ingress block under properties.configuration with 'external' set to true, 'targetPort' set to 8080, and 'transport' set to 'http2'.
Bicep properties for ingress configuration in Azure Container Apps are strictly named: 'external' (not public), 'targetPort' (not port), and 'transport' (not protocol).

Anahtar Kavram

Configuring ingress and private registry authentication via Bicep for Azure Container Apps.
Soru 242Soru

You are designing an Azure Blob Storage lifecycle management policy for a Standard General Purpose v2 (GPv2) storage account. The policy must automatically transition block blobs to the Cool tier if they have not been modified for 30 days. Additionally, the policy must only apply to blobs that have been tagged with a Blob Index tag where the key is `ArchiveStatus` and the value is `Ready`.

Which of the following JSON policy definitions should you use?

Cevabı ve açıklamayı göster

Cevap: {
"rules": [
{
"enabled": true,
"name": "move-to-cool",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [ "blockBlob" ],
"blobIndexMatch": [
{
"name": "ArchiveStatus",
"op": "==",
"value": "Ready"
}
]
}
}
}
]
}

Cevap

The correct JSON policy definition uses lowercase keys for the 'blobIndexMatch' array ('name', 'op', 'value') and defines the tiering transition using 'daysAfterModificationGreaterThan' inside the 'baseBlob' actions of a Standard GPv2 storage account lifecycle policy.
The correct JSON policy matches the required schema syntax for Standard GPv2 storage accounts. It correctly specifies the transition action using 'daysAfterModificationGreaterThan' and formats the filter using 'blobIndexMatch' with lowercase property keys ('name', 'op', 'value').

Adım Adım Çözüm

1
Analyze the action requirements.
Transition block blobs to Cool tier after 30 days of no modifications.
This corresponds to 'actions' -> 'baseBlob' -> 'tierToCool' -> 'daysAfterModificationGreaterThan': 30.
2
Analyze the filter requirements.
Only match block blobs tagged with ArchiveStatus = Ready using Blob Index tags.
This corresponds to 'filters' -> 'blobTypes': ['blockBlob'] and 'blobIndexMatch': [{'name': 'ArchiveStatus', 'op': '==', 'value': 'Ready'}].
3
Verify schema casing and extra parameters.
Keys within the 'blobIndexMatch' filter must be lowercase ('name', 'op', 'value'). No administrative parameters like 'leaseAction' or 'sasTokenScope' are supported in the lifecycle schema.
Ensures the policy passes ARM template and storage API schema validation.

Anahtar Kavram

Azure Blob Storage lifecycle management schema validation rules, specifically focusing on the case sensitivity of Blob Index tag filter keys ('name', 'op', 'value') and the exclusion of lease/security token attributes.
Tahmini Süre:1m 30s
Soru 243Soru

You manage a web application named ShipRoute that is currently hosted on a Basic (B1B1) App Service plan. During seasonal promotions, the application experiences high CPU utilization. You must configure autoscale rules to automatically increase the instance count by 11 when the average CPU Percentage is greater than 75%75\% for 1010 minutes. You also need to scale in the application by decreasing the instance count by 11 when CPU utilization drops, while ensuring that the scale-in action does not immediately trigger flapping when the instance count scales out from 11 to 22.

What configuration should you apply?

Cevabı ve açıklamayı göster

Cevap: Scale up the App Service plan to the Standard (S1S1) tier, and configure a scale-in rule with a CPU Percentage threshold of less than 35%35\%.

Cevap

Scale up the App Service plan to the Standard (S1S1) tier, and configure a scale-in rule with a CPU Percentage threshold of less than 35%35\%.
Upgrading the App Service plan to the Standard (S1S1) tier is required because the Basic (B1B1) tier does not support custom autoscale rules. To prevent flapping when the instance count increases from 11 to 22 at a scale-out threshold of 75%75\% CPU, the scale-in CPU threshold must be set below the resulting average CPU load of 37.5%37.5\% (calculated as 75%/275\% / 2). Setting the scale-in rule to trigger when the CPU Percentage is less than 35%35\% ensures the rule is not immediately triggered after a scale-out event.

Adım Adım Çözüm

1
Determine the minimum App Service plan tier required for autoscale rules.
Standard (S1S1) tier or higher.
The Basic (B1B1) tier only supports manual scaling up to 33 instances, whereas the Standard (S1S1) tier is the entry level for metric-based and schedule-based autoscale.
2
Calculate the average CPU Percentage per instance immediately after scaling out from 11 to 22 instances.
Approximately 37.5%37.5\%.
The scale-out rule triggers when the CPU exceeds 75%75\% on the single instance. Assuming the total load remains constant at 75%75\% during the transition, distributing this load across 22 instances yields an average of 75%/2=37.5%75\% / 2 = 37.5\% CPU per instance.
3
Set the scale-in threshold to a value that prevents immediate scale-in.
A threshold of less than 35%35\% CPU Percentage.
To prevent immediate scale-in (flapping), the scale-in threshold must be lower than the post-scale-out average CPU of 37.5%37.5\%. A threshold of 35%35\% prevents the scale-in rule from triggering at 37.5%37.5\%, whereas a threshold of 50%50\% would trigger it immediately.

Anahtar Kavram

Azure App Service Autoscale Tiers and Flapping Prevention
Soru 244Soru

You are developing a .NET application that stores user session data in an Azure Cosmos DB container. The container's partition key path is set to `/userId`. You need to perform point operations using the Azure Cosmos DB .NET SDK v3 to read and update a user's session data. To ensure session-level consistency across multiple independent clients, you must pass the session token obtained from the writer client to the reader client. Assuming `container` is a valid `Container` instance, `sessionData` is a populated `SessionData` object, and `writerSessionToken` is the session token from the writing client, which two of the following C# statements should you use to perform these operations? (Select two.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: ItemResponse<SessionData> response = await container.ReadItemAsync<SessionData>("session-101", new PartitionKey("user-202"), new ItemRequestOptions { SessionToken = writerSessionToken });; ItemResponse<SessionData> response = await container.UpsertItemAsync<SessionData>(sessionData, new PartitionKey("user-202"));

Cevap

The correct statements are the point read operation that specifies the item ID, the matching user ID partition key, and the shared session token, and the upsert operation that updates the session data using the matching user ID partition key.
The correct answers are the statements that use the correct SDK methods with the appropriate partition key. The point read statement must use the item ID, the correct partition key based on the /userId path (in this case, the user ID 'user-202'), and pass the session token from the writing client via the ItemRequestOptions to guarantee session consistency. The upsert statement must save the session data object using the correct user ID partition key.

Adım Adım Çözüm

1
Identify the required parameters for Azure Cosmos DB .NET SDK v3 point operations.
Point operations like ReadItemAsync and UpsertItemAsync require the item identifier and the PartitionKey parameter to match the container's partition key path (/userId).
To perform efficient item operations, the SDK must route the request to the correct physical partition using the logical partition key.
2
Apply the session token to achieve read-your-writes consistency across separate clients.
The writer client's session token must be passed to the reader client via ItemRequestOptions.SessionToken.
Setting the consistency level to Session without sharing the token is insufficient for multi-client scenarios.

Anahtar Kavram

Performing point operations with proper partition key routing and session consistency in Cosmos DB SDK v3.
Soru 245Soru

An application needs to assign custom metadata to an Azure Blob Storage container. You write C# code using the Azure.Storage.Blobs SDK (v12) to define the metadata. You want to store a custom key named Environment with the value Production.

Which of the following code snippets correctly defines the metadata dictionary?

Cevabı ve açıklamayı göster

Cevap: var metadata = new Dictionary<string, string>
{
{ "Environment", "Production" }
};

Cevap

The correct option is the dictionary that defines 'Environment' as the key directly, without any prefixes, like: new Dictionary<string, string> { { "Environment", "Production" } }.
When using the Azure.Storage.Blobs SDK (v12) in C#, metadata is defined as a standard Dictionary<string, string>. The SDK automatically handles prepending the 'x-ms-meta-' prefix to each key when making the REST API call to Azure Storage. Therefore, you only need to specify the custom key name, such as 'Environment', directly in the dictionary.

Adım Adım Çözüm

1
Identify the target metadata key and value.
The target key is 'Environment' and the value is 'Production'.
This matches the requirements of the custom metadata to be stored.
2
Determine if any prefixes are required when using the C# Azure.Storage.Blobs SDK (v12).
No prefix (such as 'x-ms-meta-') should be prepended manually to the dictionary key.
The SDK automatically adds the 'x-ms-meta-' prefix to the dictionary keys before transmitting the HTTP request headers.
3
Construct the Dictionary<string, string> with the clean key and value.
The dictionary should have the key 'Environment' and value 'Production'.
This matches the correct dictionary definition for setting metadata in the Azure SDK.

Anahtar Kavram

Azure Storage Blob Metadata SDK Configuration
Tahmini Süre:45s
Soru 246Soru

You are developing a document migration solution using Azure Durable Functions. The workflow uses a Fan-out/Fan-in pattern to process documents concurrently. One of the activity functions performs optical character recognition (OCR) on large PDF files; this task is CPU-intensive and can take up to 20 minutes to complete. The function app must also access files stored in an Azure Storage account that is secured behind a private endpoint inside an Azure Virtual Network.

You need to choose the most cost-effective hosting plan and configuration that meets these requirements.

Which hosting plan and configuration should you select?

Cevabı ve açıklamayı göster

Cevap: The Azure Functions Premium plan, because it supports virtual network integration to access the private endpoint and allows for unbounded function execution timeouts.

Cevap

The Azure Functions Premium plan, because it supports virtual network integration to access the private endpoint and allows for unbounded function execution timeouts.
The Azure Functions Premium plan is the correct choice because it supports outbound virtual network integration, enabling access to resources behind private endpoints, and allows for unbounded execution times (guaranteed up to 60 minutes and configuration-unbounded), which is necessary for the 20-minute OCR activity function.

Adım Adım Çözüm

1
Analyze the network integration requirements.
Outbound virtual network integration is required because the Azure Storage account is secured behind a private endpoint.
This rules out the Consumption plan and lower-tier App Service plans (Free/Shared), as they do not support outbound virtual network integration.
2
Analyze the execution timeout constraints.
The optical character recognition (OCR) task runs up to 20 minutes.
This exceeds the maximum 10-minute execution limit of the Consumption plan. The hosting plan must support extended or unbounded execution durations, which the Premium and Dedicated plans do.
3
Evaluate the placement of the long-running task within the Durable Functions execution model.
The long-running OCR task must be executed as an activity function, not directly in the orchestrator.
Orchestrator functions must remain deterministic and must not perform I/O-bound or CPU-intensive work. Placing the OCR processing logic directly inside the orchestrator would block the orchestrator thread and cause execution failures.

Anahtar Kavram

Selecting hosting plans based on execution limits and network requirements, while maintaining orchestrator determinism.
Soru 247Soru

You are developing a web API using Azure Functions. The API contains two HTTP-triggered functions: a function named GetProducts that retrieves public product catalog data, and a function named UpdateInventory that performs administrative inventory modifications. You must deploy these functions to a single Azure Function App. The security requirements are as follows: clients must be able to call GetProducts without providing any credentials or API keys; clients calling UpdateInventory must provide an API key, but you must minimize permissions and avoid using the master host key. Which configuration should you apply to the HTTP triggers to meet these requirements?

Cevabı ve açıklamayı göster

Cevap: Set the authorization level of GetProducts to Anonymous, and set the authorization level of UpdateInventory to Function.

Cevap

Configure the HTTP trigger authorization level for the GetProducts function to Anonymous and the UpdateInventory function to Function.
The correct configuration sets the authorization level of the public function to Anonymous (allowing access without any key validation) and sets the administrative function to Function (requiring a function-specific API key, which restricts access and avoids exposing the broader master host key).

Adım Adım Çözüm

1
Analyze the access requirement for the public product catalog retrieve endpoint.
The GetProducts function must allow public clients to access it without API keys or credentials.
This points to the Anonymous authorization level, which bypasses key validation.
2
Analyze the access requirement for the administrative inventory modification endpoint.
The UpdateInventory function must be secured using a key, but must avoid using the master host key.
The Function authorization level utilizes function-specific keys. The Admin authorization level requires the master host key, which has root-level access and should be avoided here.
3
Combine the configurations into a single deployment profile.
Select the option that configures GetProducts as Anonymous and UpdateInventory as Function.
This is the only configuration that simultaneously allows public access to GetProducts and secured, restricted key-based access to UpdateInventory.

Anahtar Kavram

HTTP Trigger Authorization Levels in Azure Functions
Tahmini Süre:1m 30s
Soru 248Soru

You are planning to deploy a containerized application to Azure Container Instances (ACI). The container requires access to a persistent volume hosted on an Azure File Share. You decide to use the Azure CLI to provision the resources and deploy the container. Which sequence of steps should you perform to create the storage resources and deploy the container with the mounted volume?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

To deploy a container to Azure Container Instances with a mounted Azure File Share, you must first create the storage account, retrieve its access keys, create the file share within the storage account using those keys, and finally deploy the container group using the `az container create` command with the appropriate volume mount parameters.
The correct sequence starts with provisioning the physical storage account. Next, the access keys must be retrieved because they are required to authorize the creation of the file share and the subsequent mount operation. Once the keys are available, the file share is created. Finally, the container group is created using the container deployment command, which references the storage account, key, and share to mount the volume to the container.

Adım Adım Çözüm

1
Create the storage account
A storage account is provisioned in Azure.
You need a storage account to host the Azure File Share.
2
Retrieve the storage account keys
The primary and secondary storage access keys are obtained.
The access keys are required to authenticate the creation of the file share and to allow ACI to mount the volume.
3
Create the Azure File Share
An SMB file share is created within the storage account.
ACI mounts an existing file share, so the share must exist prior to container deployment.
4
Deploy the container with the mounted volume
The ACI container group is created and the file share is mounted to the specified path.
The container group needs to reference the storage account credentials and share name at creation time to mount it.

Anahtar Kavram

Mounting an Azure File Share as a persistent volume in Azure Container Instances
Soru 249Soru

A sports platform manages live match telemetry. Each match has a unique matchId. The platform stores match events (such as goals, penalties, and player substitutions) as separate documents in an Azure Cosmos DB for NoSQL container.

The application must meet the following requirements:
- Guarantee ACID compliance when executing updates on multiple event documents belonging to the same match using transactional batches.
- Avoid hot partitions during peak hours when many live matches are played simultaneously.
- Maintain high write throughput to handle real-time event ingestion.

Which property should you configure as the partition key for the container?

Cevabı ve açıklamayı göster

Cevap: matchId

Cevap

matchId
Configuring matchId as the partition key meets all requirements. Because Azure Cosmos DB transactional batches are scoped to a single logical partition, using matchId ensures that all events for a given match reside in the same logical partition, allowing transaction execution. Furthermore, because there are many concurrent matches, matchId provides high cardinality, which distributes write throughput (RUs) and storage requirements evenly across physical partitions, avoiding the hot partition problem.

Adım Adım Çözüm

1
Analyze the transactional requirement.
In Azure Cosmos DB, transactional batches are scoped to a single logical partition. Therefore, all items participating in the transaction must share the same partition key value.
This guarantees ACID compliance across the targeted documents.
2
Analyze the scale and cardinality requirements.
A high-cardinality key like matchId or eventId is needed to distribute writes evenly. However, eventId cannot support multi-document transactions for a single match.
Choosing a key with too low cardinality (like sportType or tournamentId) leads to hot partitions and limits scalability.
3
Select the key that satisfies both constraints.
matchId is the correct partition key.
It groups all events of a match into the same logical partition for transactions while providing sufficient cardinality across many concurrent matches to avoid hot partitions.

Anahtar Kavram

Azure Cosmos DB logical partitions serve as the boundary for both scalability (distribution) and transactions (ACID transactional batches).
Soru 250Soru

You need to use the Azure CLI to create a new application registration in Microsoft Entra ID, instantiate its service principal, and grant the service principal Contributor access to a resource group.

Which sequence of commands should you perform? To answer, move all the actions from the list of actions to the answer area and arrange them in the correct order.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence of actions is: First, run `az login` to authenticate. Second, run `az ad app create` to register the application. Third, run `az ad sp create` to create a service principal for the registered application. Fourth, run `az role assignment create` to assign the Contributor role to the service principal.
The correct sequence begins with authenticating via `az login`. Next, the application registration must be created using `az ad app create` to obtain the Application ID. Then, a service principal must be instantiated in the tenant via `az ad sp create` using that Application ID. Finally, role-based access control (RBAC) is configured by running `az role assignment create` to grant the service principal the Contributor role.

Adım Adım Çözüm

1
Run `az login` to authenticate the session.
The CLI session is authenticated with Azure.
Authentication is a prerequisite for executing any commands that interact with Azure resources or Microsoft Entra ID.
2
Run `az ad app create` to register the application.
The application object is created in Microsoft Entra ID, generating an Application (client) ID.
An application object must exist in the directory before a service principal can be created for it.
3
Run `az ad sp create` to create the service principal.
A service principal object is created in the tenant, linked to the application registration.
The service principal acts as the security identity (credential holder) that can be assigned roles in Azure.
4
Run `az role assignment create` to grant access.
The service principal is assigned the Contributor role on the resource group.
Azure RBAC roles can only be assigned to existing security principals, such as the newly created service principal.

Anahtar Kavram

An Application Registration creates the global definition of the application, while a Service Principal is the local representation (security principal) in a specific tenant that receives role assignments and permissions.
Tahmini Süre:1m 0s
Soru 251Soru

You are developing a solution that processes updates from an Azure Cosmos DB container using the .NET SDK v3 Change Feed Processor. The solution uses a monitored container and a lease container.

What is the primary purpose of the lease container?

Cevabı ve açıklamayı göster

Cevap: To store the state of the change feed processor and coordinate the distribution of work across multiple compute instances.

Cevap

To store the state of the change feed processor and coordinate the distribution of work across multiple compute instances.
The lease container is a required helper container used by the Cosmos DB Change Feed Processor. It stores state information such as partition ownership leases and checkpoints (last processed offsets), which allows multiple instances of the processor to coordinate work and balance the processing load dynamically.

Adım Adım Çözüm

1
Identify the primary architectural components of the Cosmos DB Change Feed Processor pattern.
The architecture contains a monitored container (source), a lease container (state store), a compute host, and a delegate.
Establishing the basic roles of each component helps isolate the purpose of the lease container.
2
Determine how the change feed processor tracks progress and distributes the workload dynamically.
The processor uses lease documents to keep track of checkpoints (offsets) for each partition and to negotiate partition ownership among multiple instances.
This shows that the lease container is dedicated to state-tracking and scaling coordination rather than caching or locking.
3
Select the option that matches this coordination and state storage functionality.
The correct option is the one stating that it stores the processor state and coordinates work distribution across instances.
This aligns directly with Microsoft's documentation and SDK v3 design guidelines.

Anahtar Kavram

Purpose of the lease container in Azure Cosmos DB Change Feed Processor
Soru 252Soru

You are deploying a new Azure Container App named `shipment-processor` to an Azure Container Apps environment. The container image is stored in a private Azure Container Registry (ACR) named `contosoregistry.azurecr.io`.

Security policies prohibit enabling the admin user on the ACR. You must configure the Container App to pull the image from the ACR using a managed identity with the least privilege.

You want to perform this deployment in a single CLI command execution without using temporary public images or bootstrap steps.

Which of the following approaches should you use to achieve this goal?

Cevabı ve açıklamayı göster

Cevap: Create a user-assigned managed identity, assign the AcrPull role to the identity on the ACR scope, and run the `az containerapp create` command with the `--user-assigned` and `--registry-identity` parameters configured to use this identity.

Cevap

Create a user-assigned managed identity, assign the AcrPull role to the identity on the ACR scope, and run the `az containerapp create` command with the `--user-assigned` and `--registry-identity` parameters configured to use this identity.
The correct approach uses a user-assigned managed identity because it can be pre-created and granted the AcrPull role on the Azure Container Registry prior to deploying the Container App. During the initial creation of the Container App, Azure needs to pull the container image from the private ACR. Since the user-assigned identity already has the required permissions, the deployment succeeds in a single step.

Adım Adım Çözüm

1
Create a user-assigned managed identity in Azure.
A user-assigned managed identity resource is created and receives a principal ID.
We need an identity that exists independently of the Container App lifecycle so it can be authorized before the Container App is deployed.
2
Assign the AcrPull role to the user-assigned identity on the Azure Container Registry.
The identity is authorized to pull images from the registry.
This provides the identity with the least-privilege permission required to access the registry data plane.
3
Execute the `az containerapp create` command with the `--user-assigned` and `--registry-identity` parameters referencing the identity.
The Container App is successfully deployed using the identity to authenticate to the ACR during the initial pull.
This allows the deployment command to succeed in a single execution since the identity already has the necessary read rights on the ACR.

Anahtar Kavram

Azure Container Apps deployment with private registry authentication using a user-assigned managed identity.
Tahmini Süre:2m 0s
Soru 253Soru

A logistics company is building a real-time shipment tracking application. You are developing a REST API hosted in Azure App Service that will subscribe to transit update events from an Azure Event Grid custom topic. The REST API must receive events via a Webhook endpoint and securely authorize Event Grid to write dead-letter events to a private Azure Storage account.

Which two of the following configuration tasks or code implementations must you perform to establish the connection and handle validation?

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Implement code in the Webhook endpoint to respond to HTTP POST requests containing a validationCode by returning that code in a JSON object with the key validationResponse.; Enable a system-assigned managed identity for the Event Grid subscription or topic and assign it the Storage Blob Data Contributor role on the dead-letter storage account.

Cevap

To establish the connection and handle validation, you must implement code in the Webhook endpoint to respond to HTTP POST requests containing a validationCode by returning that code in a JSON object with the key validationResponse, and enable a system-assigned managed identity for the Event Grid subscription or topic and assign it the Storage Blob Data Contributor role on the dead-letter storage account.
For automatic endpoint validation, Event Grid sends an HTTP POST request to the Webhook endpoint with a validationCode in the body. The Webhook endpoint must respond with the validationCode in a JSON structure under the validationResponse key. For dead-lettering, Event Grid writes the failed delivery events as blobs to a storage account. The subscription or topic requires a managed identity that has the Storage Blob Data Contributor role assigned on that storage account.

Adım Adım Çözüm

1
Handle Webhook handshake validation by implementing code to listen for HTTP POST requests containing a SubscriptionValidationEvent.
The endpoint successfully responds with a JSON object containing the validationResponse field set to the validationCode.
Event Grid performs an automatic handshake validation when the Webhook subscription is created.
2
Create a managed identity for the Event Grid subscription or custom topic.
Event Grid now has an identity that Microsoft Entra ID can authenticate.
A managed identity is needed to authorize Event Grid to write to resources secured by Microsoft Entra ID.
3
Grant the managed identity the Storage Blob Data Contributor role on the dead-letter destination Storage Account.
Event Grid has permission to write events to the storage account's blob container when delivery fails.
Event Grid dead-lettering requires blob write access (Storage Blob Data Contributor) to store undelivered events.

Anahtar Kavram

Azure Event Grid Webhook validation and dead-lettering authorization using managed identities.
Soru 254Soru

An organization hosts a processing-heavy application named FlightDataAnalyzer on an Azure App Service Web App. The application currently runs on a Standard (S2) App Service plan. During daily data aggregation runs at 04:00 UTC, the application experiences a rapid spike in memory usage, causing performance degradation. You want to implement an autoscale setting with a scale-out rule that increases the instance count by 1 when the Memory Percentage exceeds 80%80\%. To minimize costs, you must also define a scale-in rule that decreases the instance count by 1 when load drops, while ensuring the system does not experience flapping when scaling between 1 and 2 instances. Which two configurations should you apply to meet these requirements? (Select TWO.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Configure a scale-out rule based on the Memory Percentage metric with a threshold of 80%80\%.; Configure a scale-in rule based on the Memory Percentage metric with a threshold of 35%35\%.

Cevap

Configure a scale-out rule based on the Memory Percentage metric with a threshold of 80%, and configure a scale-in rule based on the Memory Percentage metric with a threshold of 35%.
To handle the memory spike, a scale-out rule must be configured to trigger at 80%80\% Memory Percentage. To prevent flapping when scaling between 1 and 2 instances, the scale-in threshold must be set below the post-scale-out load level. If 1 instance runs at 80%80\% memory, scaling out to 2 instances redistributes the load to approximately 40%40\% per instance. Therefore, a scale-in threshold of 35%35\% is safe because it is below 40%40\%, whereas a threshold of 55%55\% would trigger immediate scale-in and cause flapping.

Adım Adım Çözüm

1
Analyze the scaling metric and autoscale capability of the current hosting plan.
The application runs on a Standard (S2) App Service plan, which supports autoscaling. The load spike is memory-bound, so the Memory Percentage metric is the correct scaling metric.
Ensures that the resource metrics match the bottleneck and that the plan tier supports automated scaling.
2
Calculate the post-scale-out load level to prevent flapping.
At the scale-out threshold of 80%80\% memory usage with 1 instance, a scale-out event adds 1 instance (total of 2). The load is redistributed, dropping the memory usage per instance to approximately 40%40\% (calculated as 80%×1/280\% \times 1 / 2).
Prevents the system from entering a flapping loop where scale-in is triggered immediately after scale-out.
3
Determine the correct scale-in threshold.
The scale-in threshold must be set below 40%40\% to prevent flapping. A threshold of 35%35\% is safe, while a threshold of 55%55\% is too high and would trigger immediate scale-in.
Ensures stable scaling behavior under load.

Anahtar Kavram

Azure App Service autoscale rules require careful configuration of scale-in thresholds relative to scale-out thresholds to prevent flapping, and they require a pricing tier (Standard or higher) that supports autoscaling.
Soru 255Soru

You are configuring a lifecycle management policy for a Standard General Purpose v2 (GPv2) storage account to automate data tiering for diagnostic logs. The logs are stored as block blobs.

You define the following JSON policy rule:

{
"rules": [
{
"enabled": true,
"name": "ArchiveAndCleanupLogs",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 30
},
"delete": {
"daysAfterModificationGreaterThan": 90
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"logs/daily"
],
"blobIndexMatch": [
{
"name": "environment",
"op": "==",
"value": "production"
}
]
}
}
}
]
}

Which two of the following statements regarding the behavior, configuration, and execution of this policy are correct?

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Blobs with the tag key 'Environment' (with a capital 'E') set to 'production' will not be transitioned or deleted by this rule because blob index tag names and values are case-sensitive.; The Azure storage platform executes the lifecycle management policy once every 2424 hours to evaluate the blobs and execute the defined actions.

Cevap

The correct statements are that blobs with the tag key 'Environment' set to 'production' will not be transitioned or deleted because blob index tag names and values are case-sensitive, and that the Azure storage platform executes the lifecycle management policy once every 2424 hours.
The correct statements describe the case-sensitivity of blob index tags, which prevents mismatching casings like 'Environment' from being processed, and the platform's execution schedule of once every 2424 hours for lifecycle policies.

Adım Adım Çözüm

1
Analyze the case-sensitivity of the blobIndexMatch filter defined in the policy.
The filter specifies a tag name of 'environment' and a value of 'production'.
Because blob index tags are case-sensitive in Azure Blob Storage lifecycle management, blobs with the tag 'Environment' (capital 'E') will not match this filter and will not be processed by this rule.
2
Evaluate the execution frequency of the Azure Blob Storage lifecycle management policies.
The platform runs these policies automatically once per day.
This is a platform-level constraint where policy rules are evaluated on a 2424-hour execution schedule.
3
Analyze the distractors regarding active leases and SAS tokens.
Lifecycle policies do not accept a leaseId parameter in the action schema and do not use SAS tokens for authentication.
Leased blobs will fail to delete during the lifecycle execution run without breaking the lease first, and the policy execution is a built-in platform mechanism requiring no SAS credentials.

Anahtar Kavram

Azure Blob Storage Lifecycle Management policy rules, tag case-sensitivity, and execution schedule on Standard GPv2 accounts.
Tahmini Süre:1m 30s
Soru 256Soru

You are developing a .NET application using the Azure Cosmos DB .NET SDK v3 to manage configuration settings for smart electricity meters. The container uses `/meterId` as its partition key.

You need to write a method that updates a meter's configuration status (updating an existing item) and creates a status transition audit log entry (creating a new item) for the same meter. Both operations must succeed or fail together as a single atomic unit. You must also implement Optimistic Concurrency Control (OCC) for the status update to prevent overwriting concurrent updates.

You have the following partially completed method:

csharp
public async Task<bool> UpdateMeterStatusAndLogAsync(
Container container,
string meterId,
MeterStatus updatedStatus,
string expectedETag)
{
// Initialize the transactional batch
// Add the status update operation using OCC

// (Remaining operations to add the audit log and execute the batch are implemented elsewhere)
}

Which two code segments should you use to perform these actions? (Select two.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: TransactionalBatch batch = container.CreateTransactionalBatch(new PartitionKey(meterId));; batch.ReplaceItem<MeterStatus>(meterId, updatedStatus, new TransactionalBatchItemRequestOptions { IfMatchEtag = expectedETag });

Cevap

The transactional batch must be initialized by passing a PartitionKey object to container.CreateTransactionalBatch, and the update operation must be added using batch.ReplaceItem with TransactionalBatchItemRequestOptions specifying the ETag.
To create an atomic transaction across multiple documents in the same partition, you must use the TransactionalBatch class. This batch is initialized via the container using a PartitionKey struct (demonstrated in the correct initialization option). To perform an update with Optimistic Concurrency Control (OCC) within the batch, you append a ReplaceItem operation using TransactionalBatchItemRequestOptions containing the expected ETag. The signature of ReplaceItem on a TransactionalBatch demands the item ID as the first parameter and the item object as the second (demonstrated in the correct replace option).

Adım Adım Çözüm

1
Initialize the Transactional Batch
Use container.CreateTransactionalBatch(new PartitionKey(meterId))
The Cosmos DB SDK v3 scopes all transactional batches to a single partition key. The CreateTransactionalBatch method requires an instance of the PartitionKey struct, not a raw string.
2
Configure Optimistic Concurrency Control
Instantiate TransactionalBatchItemRequestOptions and set IfMatchEtag
Transactional batch operations use TransactionalBatchItemRequestOptions to apply request configurations like ETags. ItemRequestOptions cannot be used inside a transactional batch.
3
Add the point replace operation to the batch
Call batch.ReplaceItem<MeterStatus>(meterId, updatedStatus, options)
Unlike Container.ReplaceItemAsync which takes the item first, TransactionalBatch.ReplaceItem requires the string ID as the first parameter, followed by the item. It also does not accept a partition key parameter because the batch scope is predefined.

Anahtar Kavram

Transactional batch operations and optimistic concurrency control using Cosmos DB .NET SDK v3
Soru 257Soru

An organization is developing a globally distributed collaborative document editing application. The database is hosted on an Azure Cosmos DB Core (SQL) API account configured with two write regions (East US and West US) and multi-region writes enabled.

A background analytical microservice has independent instances running in both regions to process document updates. These worker instances do not share a client session or session tokens.

The application requirements are as follows:
- The worker instances must always read document updates in the exact order they were written.
- The configuration must minimize write latency and consume the fewest Request Units (RUs).

You need to configure the Cosmos DB account and application.

Which two actions should you perform? (Select two.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Set the default consistency level of the Cosmos DB account to Consistent Prefix.; Set the default consistency level of the Cosmos DB account to Session.

Cevap

Configuring the account to use Consistent Prefix or Session consistency guarantees that updates are read in order while minimizing latency and RU cost. Relying on Session consistency without sharing tokens, selecting Strong consistency, or choosing low-cardinality partition keys are incorrect.
Consistent Prefix and Session consistency levels are correct because they both guarantee that reads will see updates in the order they were written (Consistent Prefix guarantee) while offering the lowest write latency and lowest RU cost. For Session consistency, reads outside the session scope automatically fall back to Consistent Prefix behavior. Both levels are fully supported in accounts with multiple write regions.

Adım Adım Çözüm

1
Analyze the database configuration and region write settings.
Identify that the Azure Cosmos DB account has multi-region writes enabled, which immediately rules out Strong consistency.
Strong consistency is not supported for multi-region write accounts.
2
Evaluate the consistency level ordering guarantees for client instances that do not share session tokens.
Determine that the Session and Consistent Prefix levels both guarantee Consistent Prefix (reads never see out-of-order writes) for independent sessions.
When a client reads from Cosmos DB without a session token under Session consistency, it falls back to Consistent Prefix guarantees.
3
Compare the latency and RU costs of the supported ordered consistency levels.
Session and Consistent Prefix provide lower latency and lower RU costs compared to Bounded Staleness.
Bounded Staleness requires replicating updates across regions within a defined window, which increases write latency and RU consumption.

Anahtar Kavram

Azure Cosmos DB Consistency Levels and Multi-Region Writes
Soru 258Soru

You are developing a C# application using the Azure.Storage.Blobs SDK (v12). You need to add a new custom metadata tag to an existing blob while preserving all existing metadata on that blob. How should you order the steps to perform this update?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

To update the custom metadata on an existing blob while preserving its current metadata, you must first call GetPropertiesAsync() on the BlobClient, extract the Metadata dictionary, update the dictionary with the new key-value pairs (omitting the x-ms-meta- prefix), and finally call SetMetadataAsync() with the updated dictionary.
To preserve existing metadata, the application must read the existing metadata first. This is done by calling GetPropertiesAsync() and accessing the Metadata dictionary. After modifying or adding entries to this dictionary (without adding the 'x-ms-meta-' prefix), the dictionary is passed to SetMetadataAsync() to update the blob.

Adım Adım Çözüm

1
Retrieve current blob properties.
Obtained properties including the existing Metadata dictionary.
This is necessary to know the current metadata key-value pairs and avoid overwriting them entirely.
2
Access the Metadata dictionary.
An IDictionary<string, string> containing the current metadata is ready for modification.
By modifying the existing dictionary rather than creating a new one, existing metadata keys are preserved.
3
Modify the dictionary entries.
The dictionary contains new or updated metadata keys.
The key names should be clean (e.g., 'Project') rather than prefixed (e.g., 'x-ms-meta-Project') as the SDK handles the prefix internally.
4
Call SetMetadataAsync().
The metadata is saved to the blob on Azure Storage.
This uploads the updated metadata dictionary, completing the update operation.

Anahtar Kavram

Read-modify-write pattern for Azure Blob metadata operations
Soru 259Soru

You are developing a lifecycle management policy for a Standard General Purpose v2 (GPv2) storage account to automate data tiering for telemetry log blobs. The storage account is configured with the following policy:

{
"rules": [
{
"name": "cool-rule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 14
}
}
},
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["telemetry/"]
}
}
},
{
"name": "archive-rule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 90
}
}
},
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["telemetry/"],
"blobIndexMatch": [
{
"name": "Archivable",
"op": "==",
"value": "true"
}
]
}
}
}
]
}

A new block blob is uploaded to `telemetry/log1.txt`. You need to trace the lifecycle transitions of this blob based on the actions taken by the client application and the lifecycle execution engine. What is the correct sequence of events from the initial upload to the archiving of the blob? Arrange the events in chronological order.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct chronological sequence is: 1) Uploading the blob to the Hot tier on Day `00`, 2) Modifying the blob content on Day `1010` (resetting the Last-Modified time), 3) Transitioning to the Cool tier on Day `2424` after `1414` days of no modification, 4) Tagging the blob as Archivable=true on Day `5050` (without updating Last-Modified), and 5) Transitioning to the Archive tier on Day `100100` after `9090` days of no modification.
The correct order follows the chronological progression of the blob's lifecycle. Content modifications reset the Last-Modified timestamp, whereas setting blob index tags does not. This means the transition to Cool happens `1414` days after the content update (Day `2424`), and the transition to Archive happens `9090` days after the content update (Day `100100`), provided the index tag filter matches.

Adım Adım Çözüm

1
Upload the blob to initialize the lifecycle.
The blob is placed in the Hot tier, and the Last-Modified time is set to Day `00`.
Lifecycle management calculations are relative to the Last-Modified timestamp.
2
Modify the blob content on Day `1010`.
The Last-Modified timestamp updates to Day `1010`, resetting the age calculation.
Modifying content alters the blob and resets the `daysAfterModificationGreaterThan` counter.
3
Evaluate the cool rule after `1414` days.
The blob transitions to the Cool tier on Day `2424`.
The blob has been unmodified for `1414` days since Day `1010`, matching the first rule's filter.
4
Tag the blob with index tags on Day `5050`.
The tag `Archivable=true` is applied, but the Last-Modified timestamp remains Day `1010`.
Tag updates do not alter the Last-Modified property, meaning the clock does not reset.
5
Evaluate the archive rule after `9090` days.
The blob transitions to the Archive tier on Day `100100`.
The blob has been unmodified for `9090` days since Day `1010`, and it matches the index tag filter required by the second rule.

Anahtar Kavram

Understanding how blob lifecycle transitions are calculated using the Last-Modified timestamp, how content modifications reset this timestamp, and how metadata/tag operations do not affect it.
Soru 260Soru

You are troubleshooting an intermittent database connection timeout that occurs once every few days in an ASP.NET Core web application hosted on a Windows Azure App Service. You need to configure application logging to capture diagnostic traces written via the ILogger interface. The logging must remain active continuously for at least a week to ensure the event is captured.

Which configuration should you implement?

Cevabı ve açıklamayı göster

Cevap: Enable Application Logging (Blob) in the App Service Logs blade, set the level to Verbose, and select a storage container using a connection string that does not expire.

Cevap

Enable Application Logging (Blob) in the App Service Logs blade, set the level to Verbose, and select a storage container using a connection string that does not expire.
The correct option is to enable Application Logging (Blob) in the App Service Logs blade, set the level to Verbose, and select a storage container using a connection string that does not expire. Unlike filesystem logging on Windows App Service, which is designed for temporary troubleshooting and automatically disables after 12 hours, Blob-based logging remains enabled indefinitely. Using a persistent connection string ensures the logs are gathered continuously for the entire week.

Adım Adım Çözüm

1
Analyze the requirements for the logging duration.
The logging must remain active continuously for at least a week to capture an intermittent issue.
Since the issue occurs once every few days, temporary file-system based logging (which turns off after 12 hours on Windows App Services) is insufficient.
2
Evaluate the authentication and authorization prerequisites.
Using a SAS token with a 12-hour expiration or a Key Vault reference without appropriate access policy permissions will cause the logging mechanism to fail prematurely.
Security configurations must persist and allow read/write access to the destination storage for the entire test duration.
3
Select a logging destination that supports persistent collection.
Application Logging (Blob) with a non-expiring connection string provides the necessary persistence.
Blob-based application logging does not automatically disable after a set timeframe and stays active until manually turned off.

Anahtar Kavram

App Service Application Logging Persistence and Security Configurations
Tahmini Süre:2m 0s
ÖncekiSayfa 13 / 49Sonraki