Examkin

Tüm alıştırma soruları

972 soru

Tüm türler972Çoktan seçmeli497Çoklu seçim269Eşleştirme9Sıralama171Boşluk doldurma26
Soru 261Soru →

You are developing a software release pipeline using Azure Durable Functions. The workflow is written in C# (.NET Isolated process) and must implement a gated approval step. The orchestrator must send an approval notification to a release manager, wait for up to 24 hours for a response via an external event, and then either proceed with the deployment or cancel it. If the manager responds before the timeout, the workflow must prevent the timer from running to completion to avoid unnecessary execution.

Move the steps required to implement this gated approval pattern within the orchestrator function into the correct execution sequence.

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

Cevabı ve açıklamayı göster

Cevap

The correct sequence begins with notifying the manager, setting up the timer and event tasks, waiting for either task to resolve, canceling the timer if the event is received first, and finally triggering the appropriate deployment or cleanup activity.
In a C# Durable Functions orchestrator implementing a human interaction pattern with a timeout, the orchestrator first calls an activity to send the notification. Next, it must define the timer (linked to a cancellation token) and the external event listener. It then blocks execution using Task.WhenAny to wait for whichever occurs first. If the event occurs first, it is critical to cancel the timer using the CancellationTokenSource to prevent it from executing at a later time. Finally, the orchestrator calls the corresponding activity based on the outcome.

Adım Adım Çözüm

1
Call the activity function to send the approval request notification.
The manager is notified, and the workflow is ready to wait for input.
This initiates the human interaction process.
2
Create a CancellationTokenSource and instantiate both the durable timer and the external event tasks.
Two unresolved Task objects represent the timer and the external event.
Both tasks must exist in memory before they can be evaluated concurrently.
3
Await Task.WhenAny with both the timer and event tasks as inputs.
The orchestrator yields and remains suspended until either the timer expires or the external event is received.
This allows the orchestrator to resume immediately upon the first completed action.
4
Check if the external event task resolved first; if so, call Cancel on the CancellationTokenSource.
The durable timer is canceled in the Azure Functions backend.
This prevents the timer from firing, which is a best practice to avoid billing overhead and storage leaks.
5
Examine the result of the completed task and call either the deployment or cleanup activity.
The deployment is executed if approved, or the release is cancelled/notified if rejected or timed out.
This completes the lifecycle of the approval gate workflow.

Anahtar Kavram

Implementing the Human Interaction pattern with timeouts in Azure Durable Functions using CancellationTokenSource and Task.WhenAny.
Tahmini Süre:2m 30s
Soru 262Soru →

You are deploying updates to an Azure Function App (V4 runtime) running on an Elastic Premium hosting plan. The function app connects to an Azure SQL Database.

You must implement a deployment process that meets the following requirements:
- Updates must be tested in a staging environment before being routed to production.
- Zero downtime must occur during the deployment transition.
- The staging and production environments must use different database connection strings.
- Database connection strings must not be swapped when the update goes live.

You need to configure the deployment slots and perform the deployment.

Which sequence of actions should you perform? To answer, move all 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

First, create a deployment slot named staging under the Function App. Second, define the database connection string application setting in both slots and configure it as a deployment slot setting. Third, deploy the updated function code to the staging slot. Fourth, verify the function behavior and warm up the instance in the staging slot. Finally, swap the staging slot with the production slot.
The correct sequence begins with creating the staging deployment slot, then marking the connection string setting as a deployment slot setting (sticky) to prevent it from swapping. Next, the updated function code is deployed to the staging slot and verified/warmed up. Finally, the staging slot is swapped with production, achieving a zero-downtime release with slot-specific database connections intact.

Adım Adım Çözüm

1
Create the staging deployment slot.
An isolated staging slot environment is established under the Function App.
This establishes the target environment for the staging deployments and configurations.
2
Configure the connection string setting as a deployment slot setting.
The setting is marked as 'sticky' to the slot.
Marking it as a deployment slot setting ensures the database connection strings are not swapped when slot swap occurs, keeping each slot connected to its correct database.
3
Deploy the updated function code to the staging slot.
The staging slot runs the new version of the function.
Deploying to the staging slot first prevents immediate exposure of unverified code to production users.
4
Verify behavior and warm up the function.
The staging instances are initialized and verified.
Warming up the instances prevents cold-start latency when traffic is switched, and verification ensures the code functions correctly under staging settings.
5
Swap the staging slot with the production slot.
Production traffic is routed to the new code, while the database connection strings remain in their respective slots.
Swapping the slots updates the production environment with zero downtime.

Anahtar Kavram

Azure Functions deployment slots configuration and swap process
Soru 263Soru →

An organization is developing a multi-tenant web application. You register the application in your home Microsoft Entra ID tenant. Which resource is automatically created in a customer's tenant when their administrator consents to allow your application to access their resources?

Cevabı ve açıklamayı göster

Cevap: A service principal

Cevap

A service principal
A service principal is the local representation of the application in a specific Microsoft Entra ID tenant. When an administrator consents to a multi-tenant application, a service principal is created in that tenant to hold the permissions and access configuration.

Adım Adım Çözüm

1
Differentiate between the global application object and local tenant identities.
The application registration acts as the global template created in the home tenant, while the service principal acts as the local instance.
Understanding this distinction helps clarify which object is created in the target tenant to hold the local consent and permissions.
2
Analyze the consent workflow for multi-tenant applications.
When a customer administrator grants consent, Microsoft Entra ID creates a local instance of the application to authorize access to resources within that specific tenant.
This shows how the local representation is instantiated to manage permissions.
3
Select the correct Azure identity resource that represents this local instance.
The local instance created in the customer tenant is a service principal.
Service principals are the security identities used to define access policies and permissions for applications within specific Microsoft Entra ID tenants.

Anahtar Kavram

The relationship between Application Registrations and Service Principals in Microsoft Entra ID.
Tahmini Süre:45s
Soru 264Soru →

You are developing a cloud-native solution using the Azure Cosmos DB .NET SDK v3. You need to implement the Change Feed Processor to process changes from a product catalog container in real-time.

Which two of the following resources must you reference or configure to initialize and run the Change Feed Processor?

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

Cevabı ve açıklamayı göster

Cevap: The monitored container, which contains the source data from which the change feed is generated.; The lease container, which stores the state of the feed and coordinates partition processing across multiple host instances.

Cevap

The monitored container containing the source data, and the lease container storing state and coordinating partition processing.
The Change Feed Processor requires two Cosmos DB containers: the monitored container (which contains the source data) and the lease container (which coordinates the work and stores state). The lease container must be partitioned by '/id'.

Adım Adım Çözüm

1
Identify the source container containing the documents to be monitored.
This is the monitored container.
The change feed processor monitors this container for any changes (inserts or updates).
2
Identify the container used to maintain state and coordinate distribution of work.
This is the lease container.
The lease container manages lease state per partition and coordinates distribution of workload across multiple hosts.

Anahtar Kavram

Required containers for Cosmos DB Change Feed Processor setup
Soru 265Soru →

An organization uses a Standard General Purpose v2 (GPv2) storage account to store compliance reports in a container. A lifecycle management policy is active with a rule that transitions all blobs in the container to the Archive tier 30 days after they are last modified. The lifecycle management policy executes once every 24 hours.

You need to rehydrate an archived blob named `reports/2025_audit.pdf` to the Hot tier to perform a 5-day audit analysis. You must ensure that the lifecycle management policy does not transition the blob back to the Archive tier during the 5-day analysis period.

Which sequence of actions should you perform? To answer, arrange the actions in the correct order.

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

Cevabı ve açıklamayı göster

Cevap

To safely rehydrate the blob and prevent it from being immediately re-archived, first initiate the rehydration by setting the blob's tier to Hot. Next, wait for the rehydration process to complete and the blob's status to transition to Hot. Then, perform a metadata write operation to update the Last-Modified timestamp. Finally, begin the 5-day audit analysis and perform the required read operations.
The correct order requires first initiating the rehydration of the blob to the Hot tier because it is currently offline and metadata writes are blocked. Once rehydration completes, you must perform a metadata write operation (such as setting dummy metadata properties) to update the Last-Modified timestamp. Since the lifecycle management policy evaluates the last-modified time and runs once every 24 hours, updating the metadata resets the lifecycle clock and prevents the policy from re-archiving the blob during the 5-day audit analysis.

Adım Adım Çözüm

1
Call Set Blob Tier to transition the blob to the Hot tier.
The blob status changes to rehydrate-pending-to-hot.
The blob must be rehydrated from the Archive tier before its data can be read or its metadata updated.
2
Monitor the blob properties and wait for the tier to transition to Hot.
The blob tier becomes Hot and the pending status clears.
You must wait for the blob to be online in the Hot tier before any metadata write operations can be performed.
3
Update the blob's metadata or properties.
The blob's Last-Modified timestamp is updated to the current date and time.
Changing a blob's tier via Set Blob Tier does not update its Last-Modified time. Because the policy archives blobs older than 30 days and runs every 24 hours, the policy would archive the blob again on its next execution unless the Last-Modified timestamp is refreshed.
4
Perform the required read operations for the 5-day audit analysis.
The audit analysis is completed while the blob remains in the Hot tier.
The updated Last-Modified timestamp ensures the lifecycle policy will not archive the blob for another 30 days.

Anahtar Kavram

Rehydrating blobs from the Archive tier and preventing immediate re-archiving by updating the Last-Modified timestamp via metadata modifications.
Soru 266Soru →

You are developing a multi-tenant web application that will be hosted in Azure. The application must access Microsoft Graph API on behalf of signed-in users from various external Microsoft Entra ID tenants. When a customer's tenant administrator consents to the application, a local representation of your application must be created in their tenant to define permissions and access controls. Which object is created in the customer's tenant to represent this local instance of the application?

Cevabı ve açıklamayı göster

Cevap: A service principal

Cevap

A service principal
A service principal is the local instance of a global application object in a specific Microsoft Entra ID tenant. It is created when consent is granted to the application, serving as the security identity that defines permissions and policies for the app within that tenant.

Adım Adım Çözüm

1
Analyze the requirement for multi-tenant applications in Microsoft Entra ID.
The application needs a local representation in each tenant where it is consented to by an administrator.
To govern permissions and security configuration local to that customer's tenant.
2
Differentiate between application registration and service principal.
The application registration is the global template (in the home tenant), whereas the service principal is the local instance representing the application in a target tenant.
This determines which object is actually instantiated in the target customer tenant.
3
Exclude managed identities as options.
Managed identities are designed for Azure resources to authenticate to other Azure services, not for representing multi-tenant external SaaS apps.
Managed identities cannot be shared or instantiated dynamically in customer tenants through user/admin consent flows.

Anahtar Kavram

The relationship between Application Registrations (global template) and Service Principals (local tenant-specific instance) in Microsoft Entra ID.
Soru 267Soru →

You are configuring a deployment of a containerized web application to Azure Container Instances (ACI). The container image is stored in a private Azure Container Registry (ACR) named `myregistry.azurecr.io`. During container startup, the web application must retrieve a database password from an Azure Key Vault named `mykeyvault`. You want to use a managed identity to authenticate both the image pull from ACR and the secret retrieval from Key Vault, without storing any credentials in the deployment configuration files. Which configuration strategy should you implement?

Cevabı ve açıklamayı göster

Cevap: Configure a user-assigned managed identity. Assign the identity the AcrPull role on the registry and access policy permissions to read secrets from the Key Vault. Reference this user-assigned identity in both the container group's identity configuration and container registry credentials.

Cevap

Configure a user-assigned managed identity, assign it the AcrPull role on the Azure Container Registry and access policy permissions to read secrets from Key Vault, and reference the identity in the container group's configuration.
A user-assigned managed identity is required because Azure Container Instances must authenticate to the private Azure Container Registry before the container group is created and started. A system-assigned managed identity is only created after the container group is provisioned and therefore cannot be used for the initial image pull. Furthermore, granting the user-assigned identity the necessary roles/permissions on both the registry and Key Vault ensures secure, passwordless access throughout the application lifecycle.

Adım Adım Çözüm

1
Identify the authentication requirements for the image pull phase.
Determine that ACI requires credentials or an identity that exists prior to container group provisioning, making user-assigned managed identities necessary.
System-assigned identities do not exist until the resource creation is complete, so they cannot be used to authenticate the pull of the image used to create the resource.
2
Identify the authentication requirements for the runtime phase (Key Vault access).
Determine that the same user-assigned managed identity can be granted permissions in Key Vault.
Using a single user-assigned managed identity simplifies resource management and security configuration.
3
Grant permissions and configure the ACI container group definition.
Assign the user-assigned identity the AcrPull role on the registry, Secret GET permission in Key Vault, and configure the container group YAML or CLI command to use this identity for registry credentials and group identity.
This satisfies all authorization requirements securely using the principle of least privilege without hardcoding secrets.

Anahtar Kavram

Using user-assigned managed identity for private registry image pull in Azure Container Instances
Soru 268Soru →

An online multiplayer gaming platform stores active player session state and shopping cart data in an Azure Cosmos DB for NoSQL container. The platform experiences a high volume of writes (30,00030,000 operations per second) from players globally. Each document in the container has the following structure:

{
"sessionId": "a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d",
"playerId": "p9o8i7u6-y5t4-r3e2-w1q0-l9k8j7h6g5f4",
"region": "US-East",
"cartItems": [ { "itemId": "item-993", "quantity": 1 } ],
"lastUpdated": 1781568000
}

The application has the following operational requirements:
- Query transactions must update multiple session and cart documents for a single player within the same region atomically using transactional batches.
- Read queries must retrieve session history for a specific player in a given region with the lowest possible Request Unit (RURU) consumption.
- The partitioning strategy must distribute throughput and storage demand evenly to prevent hot partitions.

Which two actions should you take to design and implement this partitioning strategy? (Select two.)

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

Cevabı ve açıklamayı göster

Cevap: Create a synthetic partition key by concatenating the playerId and region properties (e.g., playerId_region), and set this as the partition key of the container.; Include the concatenated value of playerId and region in the filter clause of all read queries retrieving session history.

Cevap

Create a synthetic partition key by concatenating the playerId and region properties, and ensure that all read queries for session history include this concatenated value in their filters.
To satisfy the transactional requirements, the partition key must encompass the transaction boundary, meaning all documents updated together (for a single player in a region) must share the same partition key. Combining the player ID and the region creates a synthetic key with high cardinality, distributing the workload evenly. To keep read query RU costs low, queries must target a single logical partition by including the synthetic partition key value in the filter.

Adım Adım Çözüm

1
Determine the transactional boundary requirement.
Since multiple documents for a single player in a single region must be modified atomically in a transactional batch, they must reside within the same logical partition. Therefore, the partition key must contain both playerId and region.
Transactional batches in Azure Cosmos DB are scoped to a single logical partition.
2
Address the hot partition risk for write throughput.
Using playerId or region alone is insufficient; region has low cardinality, and playerId alone might not distribute the load if specific players have highly frequent sessions. A synthetic key combining playerId and region provides high cardinality with thousands of unique values.
High cardinality partition keys distribute storage and throughput (RUs) evenly across physical partitions.
3
Optimize query routing for read operations.
Ensure that the client query includes the partition key filter (playerId_region) to target a single logical partition.
Queries that do not filter on the partition key run as cross-partition queries, which consume significantly more RUs.

Anahtar Kavram

Synthetic partition keys and single-partition query routing in Azure Cosmos DB
Soru 269Soru →

You are deploying an Azure Container App named report-generator to an Azure Container Apps Environment. The Container App must read template files and write generated reports to a persistent, shared file share. You have already created an Azure Storage account. You need to configure the Container App to mount the Azure file share. Which sequence of steps should you perform?

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

Cevabı ve açıklamayı göster

Cevap

First, create an Azure file share in the Storage account. Second, link the file share to the Container Apps Environment. Third, define a volume in the Container App configuration referencing the environment storage. Fourth, configure a volume mount in the container template to bind the volume to a directory path.
The correct sequence starts with provisioning the physical Azure File Share, registering it at the environment level to expose it to the container apps, defining the volume resource in the container app's template, and finally mapping that volume to a path within the container.

Adım Adım Çözüm

1
Create the Azure file share in the Azure Storage account.
A physical file share is created and ready for connection.
The file share must exist before the Container Apps Environment can connect to it.
2
Run the az containerapp env storage set command to link the share to the Environment.
The file share is registered as an environment-level storage resource.
This makes the storage share accessible by any Container App running in that specific environment.
3
Define a volume under the template properties of the Container App configuration.
The volume is defined and linked to the registered environment storage.
The Container App must declare the volume at the template level before any container can mount it.
4
Add a volumeMounts entry in the container definition pointing to the volume.
The volume is mounted to a specific container path.
This maps the template volume to a path in the container's file system where the application can read and write files.

Anahtar Kavram

Azure Container Apps storage mounting requires linking the Azure file share at the Container Apps Environment level before defining it as a volume and mounting it inside individual containers.
Soru 270Soru →

You are developing a multi-tenant web application that will be used by other organizations. The application requires delegated access to Microsoft Graph. You need to configure the application registration and ensure that a customer's tenant administrator can consent to the application and assign users to it.

Which sequence of actions should you perform? To answer, move all actions from the list of actions to the active 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 is to register the application as multi-tenant, configure the delegated API permissions, direct the customer's tenant administrator to grant consent to instantiate the service principal, and finally assign users or groups to the service principal in the customer's tenant.
The correct sequence begins by registering the application as multi-tenant to establish its identity. Next, the developer defines the required delegated API permissions on the application registration. After deployment, the customer's administrator must grant consent, which instantiates the service principal in the customer's tenant. Only after the service principal exists can the customer administrator assign users or groups to it.

Adım Adım Çözüm

1
Register the application in the home tenant as multi-tenant.
Creates the application object with a unique Application (client) ID that is accessible by other tenants.
You must establish the identity of the application before you can configure its permissions or seek consent.
2
Configure the required delegated API permissions in the application registration.
Defines the specific access scopes (such as Microsoft Graph) that the application will request.
The permissions must be declared on the application registration so that administrators can consent to them.
3
Direct the customer's tenant administrator to the admin consent endpoint.
The administrator consents, which automatically instantiates a service principal (enterprise application) in the customer's tenant.
A service principal must exist in the customer's tenant to represent the application and hold permissions within that tenant.
4
Assign users or groups to the service principal in the customer's tenant.
Limits or delegates application access to specific users or groups within the customer's organization.
Users cannot be assigned to an application in the customer's tenant until the service principal has been created in that tenant.

Anahtar Kavram

Multi-tenant application registration, consent flow, and service principal instantiation
Tahmini Süre:2m 0s
Soru 271Soru →

You are designing the security architecture for a suite of internally developed Azure microservices. One of the backend services, OrderProcessor, is registered as a Web API in Microsoft Entra ID. You must enforce a policy where other client microservices (which authenticate daemon-to-daemon using the client credentials flow) cannot acquire an access token for OrderProcessor unless they have been explicitly assigned permission by an administrator. If an unassigned client service attempts to request a token for OrderProcessor, Microsoft Entra ID must deny the token request at the token endpoint. Which configuration step must you perform to enforce this behavior?

Cevabı ve açıklamayı göster

Cevap: Set the appRoleAssignmentRequired property to true on the OrderProcessor service principal.

Cevap

Set the appRoleAssignmentRequired property to true on the OrderProcessor service principal.
The correct action is to set the appRoleAssignmentRequired property to true on the OrderProcessor service principal. In Microsoft Entra ID, the service principal represents the local instance of an application within a tenant. Setting this property to true restricts token issuance for that API/resource to only those users and service principals that have been explicitly assigned to one of the application's defined roles.

Adım Adım Çözüm

1
Identify the authentication flow and requirements.
The scenario describes daemon-to-daemon authentication (client credentials flow) without a signed-in user context.
This establishes that the solution requires application permissions and service principal-level access controls rather than user-delegated scopes.
2
Select the correct location for enforcing token block policies.
The policy must be applied to the resource's representation in the tenant (its service principal object).
Microsoft Entra ID evaluates token requests against the target resource's service principal properties in the executing tenant, not the client's application registration.
3
Configure the assignment requirement property.
Set the appRoleAssignmentRequired property (visible as 'Assignment required?' in the Azure Portal) to true on the service principal.
This explicitly instructs Microsoft Entra ID to validate that the requesting service principal has an active app role assignment before issuing an access token.

Anahtar Kavram

Enforcing application assignment requirements on service principals for daemon-to-daemon token acquisition.
Soru 272Soru →

You are developing a web application named webapp1 hosted on a Windows-based Azure App Service in resource group rg1. During a testing phase, you need to diagnose startup crashes by enabling filesystem-based application logging, establishing a real-time log monitoring pipeline, triggering runtime execution, and obtaining the complete diagnostic log archive for offline verification. Which sequence of actions should you perform? Arrange the actions in the correct order.

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

Cevabı ve açıklamayı göster

Cevap

First, configure application logging to the file system using the `az webapp log config` command. Next, start the live log stream with `az webapp log tail`. Following that, make HTTP requests to the web application to generate traffic and write to the logs. Finally, download the historical log archive using `az webapp log download`.
The correct order proceeds from configuring the underlying log system, setting up the observer stream, triggering the target event, and finally downloading the persistent historical records. File-system application logging must first be enabled because it is disabled by default. Running the tail command next ensures that any live events generated during the subsequent HTTP requests are captured in the terminal stream. Finally, downloading the log bundle retrieves the full persistent log folder for subsequent analysis.

Adım Adım Çözüm

1
Enable and configure application filesystem logging using Azure CLI.
App Service configures the application log buffer to write errors to the local virtual filesystem.
By default, application logging to the filesystem is disabled, so configuring it is a prerequisite for capturing log traces.
2
Initiate the log streaming pipeline in the terminal.
A streaming channel is opened to capture stdout/stderr and trace events from the App Service.
To observe real-time startup errors or execution traces, the stream tail must be active before triggering the workflow.
3
Generate traffic to the application.
The web application processes the requests, encountering errors that are outputted to the active streaming session.
Without HTTP request traffic or application runtime events, no logs will be generated to populate the active log stream.
4
Download the diagnostic log zip file.
A zip file containing all log subdirectories (such as LogFiles/Application/) is downloaded locally.
Downloading the archive is the final step to keep a permanent offline record of all generated diagnostic files.

Anahtar Kavram

Azure App Service Application Diagnostics and CLI Logging Commands
Tahmini Süre:2m 0s
Soru 273Soru →

An organization is developing an automated data synchronization tool that runs on an on-premises physical server. The tool must run as a background service without user interaction and read files from an Azure Blob Storage container. You register an application named DataSyncApp in your Microsoft Entra ID tenant. You need to configure the required identity and credentials to allow the synchronization tool to authenticate and access the storage container. What should you do?

Cevabı ve açıklamayı göster

Cevap: Create a client secret or upload a certificate for the application registration, and assign the Storage Blob Data Reader role to the corresponding service principal.

Cevap

Create a client secret or upload a certificate for the application registration, and assign the Storage Blob Data Reader role to the corresponding service principal.
To support unattended authentication for on-premises services, the application registration must be configured with a client secret or certificate credential. Permissions are then granted by assigning the appropriate Azure RBAC role to the service principal that represents the application in the tenant.

Adım Adım Çözüm

1
Add a credential (client secret or certificate) to the DataSyncApp application registration in Microsoft Entra ID.
Allows the on-premises background service to authenticate securely with Microsoft Entra ID.
On-premises resources cannot use Azure Managed Identities natively, so they require client credentials to authenticate.
2
Locate the service principal (enterprise application) created automatically in the tenant during registration.
Identifies the local representation of the application registration used for security policy enforcement.
Permissions in Microsoft Entra ID are assigned to the service principal object, not the application object itself.
3
Assign the Storage Blob Data Reader role to the service principal at the scope of the target storage container or storage account.
Grants the tool the necessary read-only permissions on Azure Blob Storage data plane resources.
Azure Role-Based Access Control (RBAC) is the standard method for managing secure access to Azure Storage services.

Anahtar Kavram

Configuring non-interactive daemon authentication for on-premises applications using application registration client credentials and service principal role assignments.
Soru 274Soru →

An organization is deploying a globally distributed fleet management application. The database is hosted on an Azure Cosmos DB API for NoSQL account configured with multi-region writes enabled across three regions: East US, West US, and North Europe. Each region handles local telemetry data ingestion and updates from fleet vehicles. The application has the following requirements:
- Readings from vehicles must be processed with low write latency.
- Across all regions, telemetry readings must be read in the exact order they were written.
- The read lag between the write region and other regions must not exceed a maximum of 55 minutes or 10,00010,000 updates.

Which consistency level should you configure as the default for the Azure Cosmos DB account?

Cevabı ve açıklamayı göster

Cevap: Bounded Staleness

Cevap

Bounded Staleness
Bounded Staleness consistency is the correct choice because it allows the developer to define a maximum lag in terms of time (up to 55 minutes) and updates (up to 10,00010,000 updates). It is fully supported on Azure Cosmos DB accounts with multi-region writes enabled and ensures that reads from any region are guaranteed to see updates in the correct order (Consistent Prefix).

Adım Adım Çözüm

1
Analyze the write distribution model of the Azure Cosmos DB account.
The account is configured with multi-region writes enabled across three regions.
This configuration immediately rules out Strong consistency, which is not supported for multi-region write accounts.
2
Evaluate the ordering and staleness requirements.
Reads must be guaranteed to be stale by no more than 55 minutes or 10,00010,000 updates, and must maintain order (Consistent Prefix).
Bounded Staleness is the only consistency level that allows configuring a maximum staleness bound of TT (time) and KK (operations) while guaranteeing Consistent Prefix ordering.
3
Evaluate Session consistency under the multi-client/multi-region scenario.
Session consistency only guarantees read-your-writes and ordering within the same client session, not across independent client sessions globally.
Without passing session tokens between clients, Session consistency cannot guarantee the maximum lag requirements across different regions/sessions.

Anahtar Kavram

Azure Cosmos DB Consistency Levels in Multi-Region Write Configurations
Soru 275Soru →

You are deploying a web application to Azure App Service named app-checkout. You want to configure the web app to access a database connection string stored in an Azure Key Vault named vault-checkout using a Key Vault reference.

You perform the following actions:
1. Enable a system-assigned managed identity for app-checkout.
2. In the App Service App Settings, add a setting named DbConnectionString with the value @Microsoft.KeyVault(SecretUri=https://vault-checkout.vault.azure.net/secrets/db-conn).

At runtime, the application fails to connect to the database, and the App Service configuration portal shows the status of the Key Vault reference as 'Access Denied'.

Which of the following actions is required to resolve this issue?

Cevabı ve açıklamayı göster

Cevap: Configure an access policy or Azure role-based access control (RBAC) role assignment on the Key Vault to grant the web app's system-assigned managed identity the Get secret permission.

Cevap

Configure an access policy or Azure role-based access control (RBAC) role assignment on the Key Vault to grant the web app's system-assigned managed identity the Get secret permission.
The correct answer is to configure an access policy or Azure RBAC role assignment on the Key Vault to grant the web app's system-assigned managed identity the Get secret permission. When an App Service web app is configured with a Key Vault reference, it uses its managed identity to authenticate and fetch the secret. An 'Access Denied' error indicates that the web app's identity is authenticated but does not have permission to read the secret.

Adım Adım Çözüm

1
Identify the identity used by the web app for Key Vault references.
The web app is configured to use its system-assigned managed identity.
By default, App Service uses the system-assigned managed identity to resolve Key Vault references if no user-assigned identity is specified.
2
Grant the required permissions on the Key Vault to the identified identity.
Create a Key Vault access policy with the Get secret permission or assign an Azure RBAC role (such as Key Vault Secrets User) to the system-assigned managed identity.
The 'Access Denied' status indicates that the web app's identity successfully reached the Key Vault but lacks authorization to read the secret.

Anahtar Kavram

Azure App Service Key Vault references require both a valid reference syntax and appropriate access policies granted to the app's managed identity.
Tahmini Süre:1m 30s
Soru 276Soru →

You are developing a microservice using the Azure Cosmos DB .NET SDK v3 to process product updates from a source container partitioned by `/productId`. The microservice is deployed as multiple instances in an Azure Kubernetes Service (AKS) cluster to handle high-throughput workloads.

You notice that when multiple instances of the service run concurrently, they all process the exact same partition updates, resulting in duplicate processing and database write conflicts in downstream services.

The microservice initializes the Change Feed Processor using the following code:

csharp
Container source = client.GetContainer("Db", "Catalog");
Container leases = client.GetContainer("Db", "LeaseStore");

ChangeFeedProcessor processor = source
.GetChangeFeedProcessorBuilder<Product>(
processorName: $"SyncProcessor-{Environment.MachineName}",
onChangesDelegate: HandleChangesAsync)
.WithInstanceName(Guid.NewGuid().ToString())
.WithLeaseContainer(leases)
.Build();

You need to ensure that the partition workload is dynamically distributed across all running replicas, and that each partition is leased and processed by exactly one instance at any given time.

Which modification should you make to resolve this issue?

Cevabı ve açıklamayı göster

Cevap: Set the `processorName` argument in `GetChangeFeedProcessorBuilder` to a constant string value shared by all host instances, and ensure the `LeaseStore` container is partitioned by `/id`.

Cevap

Set the processor name argument in the builder to a constant string value shared by all host instances, and ensure the lease container is partitioned by the ID property.
The correct answer resolves the issue by standardizing the processor name to a constant value across all running instances. In the Azure Cosmos DB Change Feed Processor SDK, the processor name defines the logical consumer group. Replicas sharing the same processor name will coordinate via the lease container to divide the partitions of the source container amongst themselves, ensuring each partition is processed by only one instance at a time. The lease container must also be partitioned by the ID property to function correctly.

Adım Adım Çözüm

1
Analyze the role of the processor name parameter in the Change Feed Processor builder.
The processor name acts as a logical grouping (consumer group). Instances sharing the same processor name work together to distribute the change feed partitions.
Because the code uses a dynamic string containing `Environment.MachineName`, each host instance receives a unique processor name, making them separate consumer groups that all process the entire change feed.
2
Define a constant processor name across all instances.
Changing `$"SyncProcessor-{Environment.MachineName}"` to a constant string like `"SyncProcessor"` groups the replicas together.
This allows the Change Feed Processor load-balancing logic to distribute leases for the partitions among the replicas instead of duplicate processing.
3
Configure the lease container partitioning.
Confirm that the lease container is partitioned by `/id`.
The Azure Cosmos DB .NET SDK v3 requires the lease container to use `/id` as its partition key to successfully write and manage individual lease documents for each monitored partition.

Anahtar Kavram

Azure Cosmos DB Change Feed Processor Scaling and Lease Configuration
Soru 277Soru →

You are creating a new lease container in Azure Cosmos DB to support a Change Feed Processor instance. Which partition key path must be defined on the lease container for it to function correctly?

Cevabı ve açıklamayı göster

Cevap: /id

Cevap

/id
The correct answer is /id because the Azure Cosmos DB Change Feed Processor requires the lease container to use the /id partition key path. This allows the processor to uniquely identify and lease individual partitions.

Adım Adım Çözüm

1
Identify the role of the lease container in Azure Cosmos DB Change Feed.
The lease container stores state and coordinates the processing of the change feed across multiple consumers.
This determines the design constraints for the container's partitioning.
2
Check the partitioning requirements for the lease container as defined by the Cosmos DB SDK.
The Cosmos DB SDK Change Feed Processor specifically requires the lease container's partition key path to be /id.
Using any other path prevents the SDK from executing partition-lease operations, causing initialization to fail.

Anahtar Kavram

Azure Cosmos DB Change Feed lease container partition key requirement
Soru 278Soru →

A developer is configuring a background service running on an on-premises server that must retrieve data from a custom Web API secured by Microsoft Entra ID. The background service runs autonomously without any user interaction and authenticates using its client secret.

The developer manually updates the Microsoft Entra ID application manifest of the background service to request access to the Web API. In the requiredResourceAccess section of the manifest, the developer adds the correct resource app ID and includes the permission ID in the resourceAccess array, setting the type property of the permission to Scope.

After the developer grants administrator consent, the background service successfully obtains an access token using the OAuth 2.0 client credentials grant flow. However, when the service presents the token to the Web API, the API rejects the request with an HTTP 403 Forbidden error.

What is the cause of this authentication issue?

Cevabı ve açıklamayı göster

Cevap: The permission was configured with a type of Scope instead of Role, which prevents the permission from being included in the token during a client credentials grant flow.

Cevap

The permission was configured with a type of Scope instead of Role, which prevents the permission from being included in the token during a client credentials grant flow.
The correct answer is correct because background daemon services do not have a signed-in user and must use application permissions, which are configured as type 'Role' in the application manifest. Setting the type to 'Scope' configures it as a delegated permission. When the client credentials flow is executed, only 'Role' permissions are included in the generated access token. Therefore, the token returned will lack the expected scopes/roles, resulting in an HTTP 403 Forbidden error when calling the API.

Adım Adım Çözüm

1
Analyze the application type and the authentication flow used in the scenario.
The application is a background daemon service running autonomously (no user logged in) and uses the OAuth 2.0 client credentials grant flow.
Daemon services rely on application permissions because there is no signed-in user to consent to delegated scopes.
2
Examine the configuration of the application manifest.
The permission in the manifest is configured with the type property set to Scope.
In Microsoft Entra ID, Scope indicates delegated permissions, while Role indicates application permissions.
3
Determine the impact of the manifest configuration on the client credentials flow token request.
Microsoft Entra ID will not include the permission in the access token because the client credentials grant flow only requests and issues application permissions (Roles).
Since the scope permission is not included in the token, the backend API rejects the token with an HTTP 403 Forbidden error.

Anahtar Kavram

Application permissions (Roles) vs. Delegated permissions (Scopes) in Microsoft Entra ID app registrations for daemon applications.
Tahmini Süre:2m 0s
Soru 279Soru →

An organization needs to deploy an Azure Function App running on runtime version 44 (V4) to process data files. The deployment must meet the following requirements:
- Individual function executions can take up to 2020 minutes to complete.
- The hosting plan must automatically scale out to handle spikes in traffic without manual configuration.
- The functions must securely connect to an Azure SQL Database that is isolated within a private virtual network.

Which hosting plan should you configure for the Function App?

Cevabı ve açıklamayı göster

Cevap: Azure Functions Premium plan

Cevap

The Azure Functions Premium plan satisfies all requirements by supporting executions up to 3030 minutes or unbounded, regional virtual network integration, and dynamic serverless scaling.
The Azure Functions Premium plan supports regional virtual network integration for secure database connectivity, scales dynamically to handle workload spikes, and allows execution limits to be configured up to 3030 minutes or unbounded, satisfying the 2020-minute execution requirement.

Adım Adım Çözüm

1
Evaluate the execution duration requirement of 2020 minutes.
The Consumption plan is eliminated because its execution timeout is capped at 1010 minutes. The Free tier of the Dedicated plan is also eliminated due to its 2.52.5-minute limit.
The selected hosting plan must support the maximum execution duration of the workload without timing out.
2
Evaluate the network connectivity requirement.
The Consumption plan and the Free/Basic App Service Dedicated plans are eliminated because they lack regional virtual network integration support.
Accessing resources inside a private virtual network requires a plan that supports outbound virtual network integration.
3
Evaluate the scaling requirement.
The Premium plan automatically scales out to meet demand, whereas Dedicated plans require configuring manual or metric-based autoscale rules.
The hosting plan must dynamically scale to handle spikes in traffic automatically.

Anahtar Kavram

Azure Functions hosting plans execution limits and network feature support
Soru 280Soru →

An Azure-based worker service processes high-priority queue messages and must run to completion and terminate. The service's container image is located in a private Azure Container Registry (ACR), and the service requires access to secret keys stored in Azure Key Vault during execution.

Which two settings should be configured in the container group deployment to satisfy these requirements?

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

Cevabı ve açıklamayı göster

Cevap: Set the restart policy of the container group to OnFailure.; Enable a user-assigned managed identity on the container group, authorize it to read secrets from the Key Vault and pull images from the registry, and reference the identity in the deployment configuration.

Cevap

Configure the restart policy of the container group to OnFailure, and use a user-assigned managed identity that has permission to both Key Vault and the Azure Container Registry.
For run-to-completion tasks, setting the restart policy of the container group to OnFailure ensures that the container is restarted if the process exits with a non-zero exit code due to transient failures, but stops executing and does not restart once it successfully processes all queue messages and exits with a zero exit code. To pull a container image from a private Azure Container Registry using a managed identity, Azure Container Instances requires a user-assigned managed identity. A system-assigned managed identity cannot be used for the image pull because the identity is not created until after the container group is deployed. The same user-assigned identity can also be granted access to the Key Vault to read secrets.

Adım Adım Çözüm

1
Select the correct restart policy for the task.
Setting the restart policy to OnFailure ensures that the container will restart if the process crashes or fails, but will terminate and stop consuming resources once it completes successfully.
Always restart policy is unsuitable for run-to-completion tasks, and Never would prevent retrying transient errors.
2
Configure authentication for the registry image pull.
A user-assigned managed identity is configured and linked to the container group deployment definition.
Azure Container Instances requires a user-assigned identity to authenticate against Azure Container Registry during the container group creation phase. A system-assigned identity does not exist yet at this stage.
3
Grant the user-assigned managed identity access to Key Vault secrets.
The identity is assigned Key Vault Secret User or custom reader role, allowing the container application to fetch secrets at runtime.
This establishes secure, passwordless authentication for both image pulling and secrets retrieval.

Anahtar Kavram

Azure Container Instances supports running container groups with specific restart policies (Always, OnFailure, Never) and using user-assigned managed identities to authenticate against secure resources like private container registries and Key Vaults.
ÖncekiSayfa 14 / 49Sonraki