Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 281Question →

A healthcare provider uses a Standard General Purpose v2 (GPv2) storage account to store patient medical records in a container named `patient-records`.

You need to define an Azure Blob Storage lifecycle management policy that meets the following requirements:
* Automatically transitions block blobs from the Hot tier to the Cool tier 180 days after they were last modified.
* Automatically transitions block blobs to the Archive tier 365 days after they were last modified.
* Automatically deletes block blobs 3650 days after they were last modified.
* Restricts the policy rules to apply only to blobs in the `patient-records` container that have a blob index tag named `ArchiveStatus` set to a value of `Ready`.

Which two of the following configuration fragments or statements are correct for this policy implementation? Select two.

Select all that apply

Show answer & explanation

Answer: "actions": {
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 180
},
"tierToArchive": {
"daysAfterModificationGreaterThan": 365
},
"delete": {
"daysAfterModificationGreaterThan": 3650
}
}
}; "filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "patient-records/" ],
"blobIndexMatch": [
{
"name": "ArchiveStatus",
"op": "==",
"value": "Ready"
}
]
}

Answer

The correct configuration fragments are the actions block specifying the tiering and deletion thresholds using 'daysAfterModificationGreaterThan', and the filters block matching the case-sensitive 'ArchiveStatus' tag with value 'Ready' for block blobs in the 'patient-records/' container prefix.
The correct configuration fragments define the appropriate actions and filters using the official Azure Blob Storage lifecycle management schema. The actions block correctly uses 'daysAfterModificationGreaterThan' to specify the duration in days for transitioning blobs to Cool, Archive, and deleting them. The filters block correctly applies a case-sensitive 'blobIndexMatch' matching the tag name 'ArchiveStatus' and the value 'Ready' on block blobs in the 'patient-records' container.

Step-by-Step Solution

1
Select the correct transition and deletion actions using the standard lifecycle management schema.
Identify that the actions block must configure 'tierToCool', 'tierToArchive', and 'delete' under 'baseBlob', specifying 'daysAfterModificationGreaterThan' with values 180, 365, and 3650 respectively.
Lifecycle rules require 'daysAfterModificationGreaterThan' to evaluate when to move or delete blobs based on their last modified time.
2
Select the correct filter block to limit policy execution to the specific container and tag.
Identify that the filter block must define 'prefixMatch' as 'patient-records/' and configure the 'blobIndexMatch' array with case-sensitive name 'ArchiveStatus' and value 'Ready'.
Lifecycle filters allow prefix matching and key-value blob index tag matching. These matches are case-sensitive.

Key Concept

Azure Blob Storage Lifecycle Management policy schema configuration, including action definitions, prefix filtering, and case-sensitive blob index tag matching.
Question 282Question →

You register a new application in Microsoft Entra ID to integrate authentication into a custom web app. Which object is created in your home tenant to serve as the global configuration and blueprint for the application across all tenants?

Show answer & explanation

Answer: Application object

Answer

The application object is the global configuration and template representing the registered application.
The application object represents the global configuration of the registered application and acts as the template from which its local service principal representations are generated.

Step-by-Step Solution

1
Analyze the requirements for the object
The target object must represent the global configuration and act as a template/blueprint for all tenants.
Microsoft Entra ID separates the global definition of an application from its local instantiations.
2
Differentiate between Application Objects and Service Principals
An application registration creates an Application Object (global template) in the home tenant. A Service Principal represents the local instance of that application in a specific tenant.
This differentiation ensures that the application's configuration can exist once globally, while permissions and local settings can be managed per tenant.

Key Concept

Application Object vs. Service Principal
Question 283Question →

You are deploying a containerized application to Azure Container Instances (ACI). The container image is stored in a private Azure Container Registry (ACR). You create a user-assigned managed identity and assign it the AcrPull role on the ACR. However, when you attempt to deploy the container group, the deployment fails with an error indicating that the image cannot be pulled. What is the most likely cause of this failure?

Show answer & explanation

Answer: The container group deployment configuration is missing the identity reference within the image registry credentials section.

Answer

The container group deployment configuration is missing the identity reference within the image registry credentials section.
The correct option is correct because assigning a user-assigned managed identity to the container group is a two-step process: you must define the identity on the container group, and you must explicitly link that identity to the registry credentials under the image registry credentials section in the deployment template or command. If the second step is omitted, ACI will attempt to pull the image anonymously, which fails for private registries.

Step-by-Step Solution

1
Assign the user-assigned managed identity to the container group.
The identity is attached to the container group resource, but not yet linked to the private registry credentials.
This establishes the identity relationship with the container group, making it available for Azure resource operations.
2
Configure the imageRegistryCredentials property in the deployment definition.
The configuration links the private ACR registry login server with the resource ID of the user-assigned managed identity.
ACI needs explicit instructions to map the registry pull request to the specific user-assigned identity.
3
Deploy the container group.
The ACI resource provider successfully authenticates against the private ACR using the specified identity and pulls the image.
With both the identity assigned and the credentials mapping configured, ACI has the necessary context to authenticate.

Key Concept

Azure Container Instances image pull authentication using managed identities
Question 284Question →

You are developing a telemetry ingestion service that processes device events using the Azure Cosmos DB .NET SDK v3. The service uses a container configured with a partition key path of `/tenantId`.

You need to implement a helper method that performs two operations as a single transaction:
1. Create a new telemetry record of type `DeviceLog`.
2. Upsert a summary record of type `TenantSummary`.

Both records share the same `tenantId` value.

Which two of the following code segments should you use to complete the implementation?

Select all that apply

Show answer & explanation

Answer: TransactionalBatch batch = container.CreateTransactionalBatch(new PartitionKey(tenantId))
.CreateItem<DeviceLog>(log)
.UpsertItem<TenantSummary>(summary);; using (TransactionalBatchResponse response = await batch.ExecuteAsync())

Answer

The correct segments are the one that initializes the transactional batch by passing the partition key to the CreateTransactionalBatch method and fluently chains CreateItem and UpsertItem, and the one that executes the batch using await batch.ExecuteAsync() within a using block.
The correct segments are the one that initializes the batch with a partition key and chains the operations, and the one that executes the batch asynchronously in a using block. In the .NET SDK v3, a transactional batch is created on a container by passing the PartitionKey to CreateTransactionalBatch. Operations are chained without specifying partition keys because the entire batch is restricted to the same partition. The execution of the batch is asynchronous and returning a response that should be disposed.

Step-by-Step Solution

1
Initialize the transactional batch on the container by passing the shared partition key.
A TransactionalBatch object is created and configured for the specific partition key value.
In SDK v3, transactions are scoped to a single partition key, which must be declared during batch creation.
2
Chain the desired item operations onto the transactional batch object without specifying the partition key for individual items.
The create and upsert operations are added to the transaction definition.
Fluent methods like CreateItem and UpsertItem on the batch do not accept a partition key parameter.
3
Execute the batch asynchronously using the ExecuteAsync method and manage its lifecycle with a using statement.
The batch executes atomically, and the TransactionalBatchResponse is properly disposed of.
The response object implements IDisposable and must be disposed to avoid resource leaks.

Key Concept

Transactional batch execution in Azure Cosmos DB .NET SDK v3 requires declaring the partition key at the batch initialization level and executing the batch asynchronously using the correct request options.
Question 285Question →

You are developing a C# application that processes documents uploaded to Azure Blob Storage using the Azure SDK for .NET. The application needs to retrieve custom metadata from blobs and update it as processing progress is tracked. Which two of the following statements correctly describe the behavior of blob metadata in this scenario?

Select all that apply

Show answer & explanation

Answer: Metadata name-value pairs are returned as lowercase keys by the Azure Blob Storage service, regardless of the casing used when they were created.; Metadata is retrieved along with system properties by calling GetPropertiesAsync on a BlobClient instance, which populates the Metadata dictionary property.

Answer

Metadata names are returned in lowercase from Azure Blob Storage, and metadata can be retrieved along with system properties by calling GetPropertiesAsync on a BlobClient instance.
The correct statements describe how custom metadata behaves when queried or manipulated. The Azure Blob Storage service returns all user-defined metadata keys in lowercase due to HTTP header case-insensitivity rules. Additionally, custom metadata is retrieved along with system properties using the GetPropertiesAsync method on the BlobClient, which automatically fills the Metadata dictionary properties on the client side.

Step-by-Step Solution

1
Examine how custom metadata is retrieved in the Azure SDK for .NET.
Calling GetPropertiesAsync on the BlobClient retrieves both system properties and custom metadata, populating the Metadata dictionary.
This is the standard API call to fetch a blob's current properties and metadata without downloading the content.
2
Analyze how casing and naming constraints affect metadata returned by Azure Blob Storage.
The Azure Blob Storage service returns all custom metadata keys in lowercase, even if they were defined with uppercase letters.
Custom metadata is transmitted as HTTP headers, which are case-insensitive, and the service converts keys to lowercase.

Key Concept

Azure Blob Storage custom metadata behaves as case-insensitive HTTP headers that are returned as lowercase keys, and must be updated with active lease IDs if the blob is leased.
Estimated Time:1m 0s
Question 286Question →

A healthcare organization is designing a monitoring application that collects real-time telemetry from wearable patient devices and stores the data in an Azure Cosmos DB for NoSQL container. The application hosts 100,000100,000 active patient devices, each sending health metrics every 10 seconds10\text{ seconds}, resulting in a high volume of continuous writes. The primary query pattern retrieves telemetry data for a specific patient for a single calendar day to populate a daily dashboard. Telemetry data for a single patient is expected to grow by approximately 30 GB30\text{ GB} per year. Which partition key strategy should you implement to support the query requirements while preventing partition size limits and write hot spotting?

Show answer & explanation

Answer: Create a synthetic partition key by concatenating the patientId and date values (for example, patientId_YYYY-MM-DD).

Answer

Create a synthetic partition key by concatenating the patientId and date values (for example, patientId_YYYY-MM-DD).
Concatenating the patient identifier and the date creates a synthetic partition key with high cardinality that distributes writes evenly across partitions. Because each logical partition contains only one day of telemetry for a single patient, it easily fits within the 20 GB partition limit. This partition key also aligns with the primary read query pattern, allowing the system to serve the daily dashboard through an efficient point read or single-partition query.

Step-by-Step Solution

1
Analyze logical partition size limits in Azure Cosmos DB.
Each logical partition has a maximum limit of 20 GB.
Choosing patientId as a partition key would cause the data for a single patient to grow to 30 GB in a year, violating this hard limit.
2
Analyze write distribution and hot partitioning patterns.
Choosing date as the partition key would route all 100,000 patient writes to a single partition for the current day.
This creates a severe throughput bottleneck (hot partition) where all write operations compete for the same allocated request units (RUs).
3
Evaluate the synthetic partition key approach using patientId and date.
Concatenating patientId and date (patientId_YYYY-MM-DD) scopes each logical partition to a single day's data for a single patient.
This guarantees that logical partitions stay well below the 20 GB limit, distributes daily write ingestion across 100,000 distinct partitions, and allows single-partition queries for the daily dashboard.

Key Concept

Selecting or constructing a partition key in Azure Cosmos DB to distribute storage and throughput workloads evenly while satisfying application query patterns.
Question 287Question →

You are developing a web application that will be hosted on an Azure App Service. The application must securely retrieve database connection strings from an Azure Key Vault. You decide to use a managed identity to authenticate to the Key Vault. The identity must be dedicated to this specific App Service instance, and its lifecycle must be tied directly to the App Service so that deleting the App Service automatically deletes the identity. Which identity type should you implement?

Show answer & explanation

Answer: A system-assigned managed identity

Answer

A system-assigned managed identity
A system-assigned managed identity is directly associated with a single Azure resource instance. Enabling it creates an identity in Azure Active Directory (Microsoft Entra ID) that is tied to that resource's lifecycle. When the App Service is deleted, the identity is automatically removed by Azure, fulfilling the scenario's lifecycle requirement without manual management.

Step-by-Step Solution

1
Analyze the lifecycle requirement
The identity's lifecycle must match the App Service lifecycle, deleting when the App Service is deleted.
This requirement determines whether a system-assigned or user-assigned identity is appropriate, as system-assigned identities share their lifecycle with the host resource.
2
Evaluate identity characteristics
System-assigned identities are automatically deleted when the parent resource is deleted. User-assigned identities exist as independent Azure resources and must be manually deleted.
Selecting the system-assigned option satisfies the automatic cleanup and exclusive access requirements.

Key Concept

Managed Identity Lifecycle Boundaries
Question 288Question →

You are designing a deployment architecture for a set of five independent Azure App Service web apps. Each web app must access a shared Azure Key Vault to retrieve common application settings. Each web app is managed and scaled independently, and some may be deleted or recreated during routine updates. You need to configure a managed identity solution that minimizes administrative overhead for granting Key Vault permissions and ensures that the identity credentials persist even if individual web apps are deleted.

Which managed identity configuration should you implement to meet these requirements?

Show answer & explanation

Answer: A single user-assigned managed identity assigned to all five App Services, with that identity granted the necessary access permissions on the Key Vault.

Answer

A single user-assigned managed identity assigned to all five App Services, with that identity granted the necessary access permissions on the Key Vault.
Using a single user-assigned managed identity is the optimal choice because it exists as a standalone Azure resource. It can be shared across multiple Azure App Services, allowing you to configure a single access control rule (RBAC role or Key Vault access policy) on the Key Vault. Additionally, its lifecycle is independent of the App Services; deleting or recreating the web apps does not delete the user-assigned identity, avoiding the need to reconfigure Key Vault permissions.

Step-by-Step Solution

1
Analyze resource sharing and lifecycle requirements.
The identity must support sharing across five App Services to minimize administrative overhead and survive the deletion and recreation of the individual App Service instances.
Identifying these parameters determines whether a system-assigned or user-assigned identity is appropriate.
2
Compare managed identity lifecycles and sharing features.
User-assigned managed identities are standalone resources that can be shared, while system-assigned identities are tied 1-to-1 to a single resource instance's lifecycle.
Selecting a user-assigned managed identity satisfies the independent lifecycle and cross-resource sharing requirements.
3
Determine the required access policy configuration.
Grant Key Vault access explicitly to the selected user-assigned managed identity.
Security credentials provided by managed identities do not have access by default, and access must be explicitly granted on the target resource.

Key Concept

Architectural and lifecycle differences between system-assigned and user-assigned managed identities.
Estimated Time:1m 30s
Question 289Question →

You are configuring a V4 Azure Function App that needs to connect to an external service. The external service requires all incoming requests to originate from a single, static public IP address. The Function App is currently running on an Elastic Premium plan.

Which two actions should you perform to configure the Function App for static outbound IP addresses? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure regional virtual network (VNet) integration for the Function App to a delegated subnet.; Associate an Azure NAT Gateway with a public IP address to the integrated subnet.

Answer

Configure regional virtual network (VNet) integration for the Function App to a delegated subnet, and associate an Azure NAT Gateway with a public IP address to the integrated subnet.
To route outbound traffic from a V4 Azure Function App through a static public IP address, you must first configure regional virtual network (VNet) integration. This places the outbound traffic of the Function App within a delegated subnet. Next, you associate an Azure NAT Gateway (which has an assigned static public IP address) with that delegated subnet. Any outbound internet-bound traffic from the subnet will use the NAT Gateway's static public IP.

Step-by-Step Solution

1
Configure regional virtual network (VNet) integration for the Function App.
The Function App is connected to a delegated subnet, enabling outbound network traffic from the Function App to route into the VNet.
By default, Azure Functions route outbound traffic through a shared pool of dynamic public IP addresses. Integrating with a subnet is the necessary first step to control and route outbound network traffic.
2
Deploy an Azure NAT Gateway with a static public IP address and associate it with the delegated subnet.
All outbound internet-bound traffic originating from the subnet, including the Function App's outbound calls, is routed through the NAT Gateway.
The NAT Gateway translates all outbound traffic from the subnet to use its own assigned static public IP address, satisfying the external service's firewall requirement.

Key Concept

Configuring static outbound IP addresses for Azure Functions using virtual network integration and NAT Gateway.
Estimated Time:2m 0s
Question 290Question →

You are a developer implementing a data retention strategy for a Standard General Purpose v2 (GPv2) storage account. You need to configure Azure Blob Storage Lifecycle Management to automatically transition older, historical versions of blobs (noncurrent versions) to the Cool tier. You plan to configure and test this policy using the Azure CLI.

Arrange the steps in the correct order to configure the storage account, define the policy, and verify that a blob version is subject to the policy.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To implement lifecycle management for noncurrent blob versions, first enable blob versioning on the storage account. Next, define the lifecycle rules targeting the noncurrent versions in a local JSON policy file. Then, use the Azure CLI command to deploy the policy. Finally, overwrite a blob to create a noncurrent version to test the policy.
The correct sequence begins with enabling versioning on the storage account so that history tracking is active. Then, the JSON policy is defined to target noncurrent versions. This JSON file is then deployed using the Azure CLI. Finally, a blob is overwritten to create a noncurrent version, which will be processed by the lifecycle management rules during the next execution cycle.

Step-by-Step Solution

1
Enable blob versioning on the Standard GPv2 storage account.
The storage account is configured to preserve previous states of blobs as noncurrent versions when they are updated or deleted.
Lifecycle rules cannot act on noncurrent versions unless versioning is enabled first to track those versions.
2
Create a JSON policy file defining rules that specify actions under the version block.
A policy document is prepared that targets noncurrent versions for tiering (e.g., transition to Cool).
The Azure CLI requires a local JSON file path to apply the policy configuration.
3
Execute the az storage account management-policy create command referencing the JSON file.
The lifecycle policy is successfully applied to the Azure Storage account.
The policy must be applied in Azure before any data modifications can be evaluated against it.
4
Overwrite an existing blob.
A new current version is written, and the previous content is preserved as a noncurrent version.
This generates the target version entity required to test the lifecycle transition rule.

Key Concept

Azure Blob Storage Lifecycle Management with Blob Versioning
Question 291Question →

You are configuring CPU-based autoscale rules for an Azure App Service web application to handle variable traffic spikes while preventing service instability caused by rapid, back-to-back scaling actions (flapping). Which of the following configuration settings should you implement? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: A scale-out rule triggered when CPU utilization exceeds 85%85\%, and a scale-in rule triggered when CPU utilization drops below 50%50\%.; A scale-cool-down duration of 1010 minutes to allow metrics to stabilize after any scaling operation.

Answer

Configure a scale-out threshold that is significantly higher than the scale-in threshold, and set an adequate cool-down duration to allow the system metrics to stabilize.
Implementing a scale-out threshold of 85%85\% and a scale-in threshold of 50%50\% ensures there is a wide enough gap to prevent immediate scaling-in after scale-out. A cool-down duration of 1010 minutes allows metrics to stabilize before another scaling event is considered.

Step-by-Step Solution

1
Evaluate the relationship between scale-out and scale-in thresholds.
Confirm that the scale-out threshold is set higher than the scale-in threshold with a sufficient margin.
If the scale-in threshold is higher than or too close to the scale-out threshold, the additional capacity from scaling out will immediately reduce average CPU usage and trigger a scale-in event, causing a flapping loop.
2
Establish a cool-down period.
Implement a positive cool-down duration (such as 1010 minutes).
This allows newly provisioned instances enough time to boot, initialize, and begin handling incoming requests, stabilizing telemetry metrics before another autoscale decision is evaluated.

Key Concept

Azure App Service Autoscale Rule and Flapping Prevention Configuration
Question 292Question →

Match each application scenario to the most appropriate Azure Cosmos DB consistency level that satisfies the requirements with the lowest resource overhead.

Click a left item, then click its matching right item

Items

A financial ledger application deployed to a single write region with multiple read regions that requires all clients to immediately read the most recently committed state before any subsequent transaction is processed.
A globally distributed multiplayer game using a multi-region write account that requires player updates to be viewed in chronological order by all players globally, with a guaranteed lag of no more than 100,000100,000 updates or 55 minutes.
An e-commerce shopping cart service where a user must always see the items they just added to their cart immediately upon refreshing their browser session, while other users can tolerate propagation delay.
A video streaming platform's trending list where updates must never appear out of order to readers, but no strict real-time lag bounds are required, optimizing for resource cost.

Matches

Show answer & explanation

Answer

The correct matches associate the financial ledger with Strong, the multiplayer game with Bounded Staleness, the shopping cart with Session, and the trending video list with Consistent Prefix.
The correct matching aligns the strict linearizability requirement of the financial ledger to Strong consistency; the time/version bounded ordering on multi-region writes to Bounded Staleness; the user-scoped write-read cycle to Session consistency; and the out-of-order prevention without time bounds to Consistent Prefix.

Step-by-Step Solution

1
Analyze the financial ledger requirement.
It requires absolute global consistency ('immediately read the most recently committed state') which can only be satisfied by Strong consistency.
Strong consistency guarantees that any read returns the most recent write globally, preventing stale reads across regions.
2
Analyze the multiplayer game requirement.
It runs on a multi-region write account and requires a bound on replication lag (100,000100,000 updates or 55 minutes) along with ordered reads. This corresponds to Bounded Staleness consistency.
Bounded Staleness allows multi-region writes while ensuring that reads outside the write region do not lag beyond the configured threshold of KK versions or TT time.
3
Analyze the shopping cart requirement.
It requires read-your-own-writes for a single user's browser session. Session consistency provides this guarantee within the client session.
Session consistency scope guarantees read-your-own-writes and monotonic reads for the specific client using the session token.
4
Analyze the trending list requirement.
It requires updates to never appear out of order but has no strict lag bounds. Consistent Prefix meets this ordering requirement with lower resource overhead.
Consistent Prefix ensures that readers see updates in the order they were written without incurring the higher RU cost and latency of Bounded Staleness.

Key Concept

Azure Cosmos DB consistency levels and their trade-offs regarding replication latency, throughput, ordering guarantees, and availability.
Question 293Question →

An enterprise is migrating a legacy batch processing system to Azure. The system consists of an on-premises scheduler service that must securely upload transaction logs to an Azure Blob Storage container. Corporate security policies strictly prohibit storing passwords, client secrets, or access keys in the service configuration. You must establish authentication using a Microsoft Entra ID service principal configured with a client certificate.

You need to configure the required Microsoft Entra ID and Azure resources to establish this secure communication flow.

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Generate a self-signed certificate locally and export the public key -> Create an application registration in Microsoft Entra ID -> Upload the public key certificate to the application registration -> Assign the Storage Blob Data Contributor role to the application's service principal -> Configure the scheduler service to authenticate using the client certificate's private key.
Establishing a secure connection without secrets requires a certificate-based flow. First, the certificate pair must be generated on the client machine to create the public key. Next, the application is registered in Microsoft Entra ID to establish its identity. After registration, the public key is uploaded to Microsoft Entra ID to associate the credential with the registration. Next, the Storage Blob Data Contributor role is assigned to the service principal in the tenant to allow data plane access. Finally, the daemon scheduler is configured with the private key locally to acquire access tokens using the client credentials flow.

Step-by-Step Solution

1
Generate a self-signed certificate locally and export the public key certificate (.cer) file.
A public/private key pair is created, and the public key is saved in a .cer file.
This establishes the cryptographic trust foundation where the private key remains secure on-premises.
2
Create an application registration in Microsoft Entra ID.
An application object is created globally, and a corresponding service principal is generated in the home tenant.
A directory identity must exist before you can assign credentials or configure access permissions.
3
Upload the public key (.cer) file to the Certificates & secrets section of the application registration.
The public key is bound as a credential to the Entra ID application object.
This allows Microsoft Entra ID to validate signed JSON Web Tokens (JWTs) presented as client assertions during authentication.
4
Assign the Storage Blob Data Contributor role to the application's service principal at the storage account scope.
The service principal is granted read/write permissions to the blob storage data plane.
Security permissions are evaluated against the service principal (the local instance of the app in the tenant), not the application object itself.
5
Configure the scheduler service to authenticate using the client certificate's private key to acquire an Entra ID token.
The service requests and receives an access token from the Microsoft Entra ID token endpoint to perform authorized blob operations.
The client application uses the private key to sign a client assertion locally, preventing any secret or key transmission over the network.

Key Concept

Configuring certificate-based client credentials flow using Microsoft Entra ID application registrations, local service principals, and role assignments.
Estimated Time:3m 0s
Question 294Question →

An on-premises daemon application needs to access a secure Web API protected by Microsoft Entra ID. The application is registered in Microsoft Entra ID and has a client secret configured. Arrange the steps in the correct chronological order to authenticate the application and access the Web API using the client credentials flow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, the daemon application requests an access token by sending its client credentials to the token endpoint. Next, Microsoft Entra ID validates the credentials and returns the token. The daemon application then includes this token in the Authorization header of its request to the Web API. Finally, the Web API validates the token and returns the requested data.
In the client credentials flow, the application must first request an access token from Microsoft Entra ID by presenting its own credentials (client ID and client secret). Once Microsoft Entra ID validates these credentials, it issues an access token. The application then uses this token in the Authorization header of its request to the Web API, and finally, the Web API validates the token to authorize the access.

Step-by-Step Solution

1
Submit client credentials to the Entra ID token endpoint.
The authentication request is initiated using client_credentials grant type.
Daemon applications run without user interaction and must authenticate using their own identity (the service principal) via client ID and client secret.
2
Receive the token from Microsoft Entra ID.
An access token is obtained by the client application.
Microsoft Entra ID acts as the identity provider, verifying the credentials and generating the access token containing the authorized roles.
3
Present the token to the Web API.
The HTTP request is sent with the Authorization header set to 'Bearer <token>'.
The Web API requires a valid bearer token to authenticate and authorize the incoming request.
4
Process the request at the Web API level.
The token is validated and the resource is returned.
The Web API must verify that the token was signed by Microsoft Entra ID and contains the necessary permissions before granting access to the resource.

Key Concept

The client credentials flow enables a daemon application (represented by an application registration and service principal) to acquire an access token to call a Web API without user interaction.
Estimated Time:1m 0s
Question 295Question →

You are deploying a containerized background worker to Azure Container Instances (ACI) using a YAML template. The containerized application requires a database connection string that contains sensitive credentials. You must ensure that the connection string is passed to the container as an environment variable, but the plaintext value of the connection string must not be visible to users who run the 'az container show' command or view the container properties in the Azure portal. Which of the following configurations should you define in the YAML template to meet this requirement?

Show answer & explanation

Answer: Define the connection string in the container's environmentVariables array using the secureValue property.

Answer

Define the connection string in the container's environmentVariables array using the secureValue property.
The correct approach is to define the connection string using the secureValue property inside the environmentVariables list. Azure Container Instances treats secureValue objects as write-only, masking their values in the Azure Portal, CLI command output (such as 'az container show'), and resource logs, while still presenting them to the running container as standard environment variables.

Step-by-Step Solution

1
Analyze how environment variables are handled in ACI YAML templates.
Standard environment variables use the 'value' property, which displays the plaintext configuration in the portal and CLI outputs.
To identify that the default value property exposes sensitive data.
2
Select the correct mechanism for securing environment variables.
ACI supports 'secureValue' to mask the variable's value from the control plane while leaving it accessible to the container process.
This meets the security requirement of masking the connection string from administrative users.
3
Apply the secureValue property in the environmentVariables definition.
The connection string is securely passed to the container's environment.
To correctly configure the deployment template according to Azure Resource Manager and ACI schemas.

Key Concept

Secure environment variables in Azure Container Instances
Estimated Time:1m 30s
Question 296Question →

A developer needs to configure passwordless authentication for a GitHub Actions workflow to deploy resources to an Azure subscription using Microsoft Entra Workload Identity. In which order should the developer perform the steps to establish trust and grant the necessary permissions? To answer, arrange the steps in the correct sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, register the application. Second, create the service principal. Third, configure the federated identity credential on the application registration. Fourth, grant the service principal permissions on the target subscription. Finally, update the GitHub Actions workflow YAML file.
Establishing Workload Identity federation requires a sequential chain of trust. First, the application object is registered globally. Second, a local service principal is created to represent it in the home tenant. Third, a federated identity credential is added to the application registration to trust GitHub's OIDC issuer. Fourth, the service principal is assigned an RBAC role to grant resource management permissions. Finally, the GitHub Actions workflow YAML is configured with the target client and tenant IDs, and the required `id-token: write` permission to exchange its GitHub OIDC token for an Entra access token.

Step-by-Step Solution

1
Register the application in Microsoft Entra ID.
An application object is created, generating a unique Application (Client) ID.
This establishes the identity template that defines the application.
2
Create the service principal.
A service principal object is created in the local tenant.
This represents the application instance in the tenant and is required to assign roles and permissions.
3
Create a federated identity credential.
Trust is established between Entra ID and the external OIDC token issuer (GitHub).
This allows Entra ID to trust security tokens issued by GitHub Actions for this specific repository and branch.
4
Assign the RBAC role.
The service principal is authorized to manage resources.
Roles must be assigned to the service principal in the tenant so that the authenticated session has the necessary execution permissions.
5
Configure the GitHub Actions workflow YAML.
The workflow can successfully obtain an Entra ID access token and login.
The workflow must request the OIDC token (`id-token: write`) and present the client and tenant IDs during authentication.

Key Concept

Microsoft Entra Workload Identity federation utilizes an application registration, its corresponding service principal, and federated identity credentials to allow external workloads (like GitHub Actions) to authenticate securely without maintaining client secrets or certificates.
Question 297Question →

You are developing a Python microservice that updates a shared configuration file named `process_state.json` in Azure Blob Storage. The microservice uses the `azure-storage-blob` library (v12). To prevent multiple workers from modifying the file simultaneously, you must implement a lease-based locking mechanism. Additionally, the service must be able to recover and force-release the lock if a worker crashes while holding the lease. Which two of the following actions must you implement to perform these operations using the SDK? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Initialize a BlobLeaseClient for the target blob and call break_lease(lease_break_period=0) to immediately terminate any active lease held by a failed worker.; Pass the active lease ID as the lease keyword argument when calling upload_blob on the BlobClient.

Answer

Initialize a BlobLeaseClient for the target blob and call break_lease(lease_break_period=0) to immediately terminate any active lease held by a failed worker, and pass the active lease ID as the lease keyword argument when calling upload_blob on the BlobClient.
To modify a leased blob, you must authorize the request by passing the active lease ID as the lease parameter during write operations such as upload_blob. If a worker holding a lease crashes and the lease ID is lost, the lease can be broken administratively by initializing a BlobLeaseClient and calling break_lease(lease_break_period=0), which ignores the lease ID and immediately frees the resource.

Step-by-Step Solution

1
Manage Write Access to Leased Blobs
Upload succeeds without Precondition Failed errors
When a blob has an active lease, write operations like upload_blob require the active lease ID to be passed as a keyword argument (lease=lease_id) to verify ownership of the lock.
2
Handle Crashed Leases
Active lease is terminated immediately
If a worker crashes and the lease ID is lost, you cannot call release() because it requires the exact lease ID. Calling break_lease(lease_break_period=0) on the BlobLeaseClient breaks the lease administrative-wise without needing the lease ID.

Key Concept

Azure Blob Storage SDK Lease Operations and Concurrency
Question 298Question →

You are writing a C# method using the Azure SDK for .NET (`Azure.Storage.Blobs`) to set custom metadata on an existing block blob. You need to add a custom metadata name-value pair where the key is `Department` and the value is `Engineering`.

Which key-value pair should you add to the metadata dictionary passed to the `BlobClient.SetMetadataAsync` method?

Show answer & explanation

Answer: "Department" as the key and "Engineering" as the value

Answer

Provide "Department" as the key and "Engineering" as the value in the metadata dictionary.
When using the Azure SDK for .NET, developers work with raw keys and values because the SDK automatically adds the protocol-required 'x-ms-meta-' prefix to the HTTP headers before sending the request to the Azure Storage service.

Step-by-Step Solution

1
Determine how the Azure SDK for .NET manages metadata HTTP header formatting.
The SDK automatically handles the REST protocol details, including prepending the required 'x-ms-meta-' prefix to custom metadata key-value pairs.
This simplifies developer usage by allowing the use of clean, simple key strings in code.
2
Select the dictionary configuration containing only the raw metadata key and value.
Using the key 'Department' with the value 'Engineering'.
This avoids double-prefix errors and formats the request correctly for Azure Blob Storage.

Key Concept

Azure SDK for .NET automatically prepends the 'x-ms-meta-' header prefix to keys in the metadata dictionary, so developers must only supply the raw key name.
Question 299Question →

A public transit agency is designing an Azure Cosmos DB for NoSQL database to store real-time telemetry from a fleet of 5,000 buses. The system ingests 10 million location updates daily. The database must optimize for high-throughput write ingestions while ensuring fleet managers can perform ACID-compliant transactional batch updates to modify the status of a specific bus on a given calendar day. Using the bus ID alone as the partition key would optimize reads for individual buses but will eventually exceed the 20 GB logical partition storage limit due to historical accumulation. Which two of the following design decisions should you make to satisfy these requirements?

Select all that apply

Show answer & explanation

Answer: Configure a synthetic partition key by concatenating the bus ID and the date portion of the timestamp (for example, busID_YYYYMMDD) to define the partition key for the container.; Execute the status updates using the TransactionalBatch class in the SDK, ensuring all operations in the batch target the same synthetic partition key value.

Answer

To satisfy these requirements, you must configure a synthetic partition key by concatenating the bus ID and the date portion of the timestamp (for example, busID_YYYYMMDD) to define the partition key, and execute the status updates using the TransactionalBatch class in the SDK, ensuring all operations in the batch target the same synthetic partition key value.
Concatenating the bus ID with the date creates a synthetic partition key that guarantees a high cardinality distribution while keeping the size of each logical partition well under the 20 GB storage limit, as data is divided into daily chunks. Since all status documents for a specific bus on a given day share this key, they can be updated atomically using the TransactionalBatch class in the SDK.

Step-by-Step Solution

1
Evaluate the partition size constraints and query scope.
Using the bus ID alone as the partition key will lead to an unbounded partition size over time, which will eventually exceed the 20 GB logical partition limit. A synthetic partition key combining the bus ID and date is necessary to keep partition sizes within bounds.
Azure Cosmos DB restricts each logical partition to a maximum size of 20 GB.
2
Determine the transactional scope requirements.
ACID transactions using TransactionalBatch require all items in the batch to share the same partition key value.
TransactionalBatch transactions cannot span multiple logical partitions.
3
Evaluate the feasibility of consistency levels for transactional boundaries.
Consistency levels like Session do not govern transaction boundaries across independent client sessions.
Session consistency only guarantees read-your-writes behavior for the client executing the writes.

Key Concept

Synthetic partition keys and TransactionalBatch boundaries in Azure Cosmos DB
Question 300Question →

You need to configure an Azure App Service web app to retrieve secrets from an Azure Key Vault by using a user-assigned managed identity. Which sequence of steps should you perform? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: first, create the user-assigned managed identity; second, associate the user-assigned managed identity with the Azure App Service web app; third, assign the role or access policy to the identity on the Key Vault; and fourth, configure the application code to authenticate using the client ID of the user-assigned managed identity.
To successfully authenticate an App Service using a user-assigned managed identity, you must first provision the identity resource. Once created, it must be linked to the web app so the runtime environment can access its credentials. You then grant the identity permissions on the target Key Vault via role-based access control or access policies. Finally, since multiple user-assigned identities can exist on a resource, you must explicitly supply the client ID in your code configuration (e.g., using DefaultAzureCredentialOptions) to specify which identity to use.

Step-by-Step Solution

1
Create the user-assigned managed identity.
A standalone Azure identity resource is provisioned with its own client ID.
Since user-assigned identities exist independently of resources, they must be created before they can be configured or assigned.
2
Associate the identity with the App Service web app.
The App Service web app is configured to use the user-assigned identity.
This allows the host environment of the App Service to present the identity's credentials when requesting tokens.
3
Configure permissions on the Key Vault for the identity.
The identity is authorized to access Key Vault secrets.
By default, identities have no access to Azure resources; authorization must be explicitly granted.
4
Update the web app application code.
The code successfully authenticates and retrieves secrets.
Because multiple user-assigned identities can be associated with a single resource, the code must specify which user-assigned identity to use by providing its client ID to the credential class.

Key Concept

Provisioning, assigning, and authorizing a user-assigned managed identity to access Azure resources.
Estimated Time:1m 0s
PreviousPage 15 / 49Next