Microsoft AZ-204 Practice Test - Questions Answers, Page 13

Box 1: SecretClient

Box 2: DefaultAzureCredential

In below example, the name of your key vault is expanded to the key vault URI, in the format "https://<your-key-vault-name>.vault.azure.net". This example is using 'DefaultAzureCredential()' class from Azure Identity Library, which allows to use the same code across different environments with different options to provide identity.

string keyVaultName = Environment.GetEnvironmentVariable("KEY_VAULT_NAME"); var kvUri = "https://" + keyVaultName + ".vault.azure.net";

var client = new SecretClient(new Uri(kvUri), new DefaultAzureCredential());

Reference:

https://docs.microsoft.com/en-us/azure/key-vault/secrets/quick-create-net

A: You can use the Azure AD REST APIs in Microsoft Graph to create unique workflows between Azure AD resources and third-party services.

Enterprise developers use Microsoft Graph to integrate Azure AD identity management and other services to automate administrative workflows, such as employee onboarding (and termination), profile maintenance, license deployment, and more.

C: API Management (APIM) is a way to create consistent and modern API gateways for existing back-end services.

API Management helps organizations publish APIs to external, partner, and internal developers to unlock the potential of their data and services.

Reference:

https://docs.microsoft.com/en-us/graph/azuread-identity-access-management-concept-overview

A: Revoke a user delegation SAS

To revoke a user delegation SAS from the Azure CLI, call the az storage account revoke-delegation-keys command. This command revokes all of the user delegation keys associated with the specified storage account. Any shared access signatures associated with those keys are invalidated.

B: To revoke a stored access policy, you can either delete it, or rename it by changing the signed identifier. Changing the signed identifier breaks the associations between any existing signatures and the stored access policy. Deleting or renaming the stored access policy immediately effects all of the shared access signatures associated with it.

Reference:

https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/storage/blobs/storage-blob-user-delegation-sas-create-cli.md

https://docs.microsoft.com/en-us/rest/api/storageservices/define-stored-access-policy#modifying-or-revoking-a-stored-access-policy

To perform a key transfer, a user performs following steps:

Generate KEK.

Retrieve the public key of the KEK.

Using HSM vendor provided BYOK tool - Import the KEK into the target HSM and exports the Target Key protected by the KEK.

Import the protected Target Key to Azure Key Vault.

Step 1: Generate a Key Exchange Key (KEK).

Step 2: Retrieve the Key Exchange Key (KEK) public key.

Step 3: Generate a key transfer blob file by using the HSM vendor-provided tool.

Generate key transfer blob using HSM vendor provided BYOK tool

Step 4: Run the az keyvault key import command

Upload key transfer blob to import HSM-key.

Customer will transfer the Key Transfer Blob (".byok" file) to an online workstation and then run a az keyvault key import command to import this blob as a new HSM-backed key into Key Vault.

To import an RSA key use this command:

az keyvault key import

Reference:

https://docs.microsoft.com/en-us/azure/key-vault/keys/byok-specification

To give a managed identity access to an Azure resource, you need to add a role to the target resource for that identity.

Note: To easily authenticate access to other resources that are protected by Azure Active Directory (Azure AD) without having to sign in and provide credentials or secrets, your logic app can use a managed identity (formerly known as Managed Service Identity or MSI). Azure manages this identity for you and helps secure your credentials because you don't have to provide or rotate secrets.

If you set up your logic app to use the system-assigned identity or a manually created, user-assigned identity, the function in your logic app can also use that same identity for authentication.

Reference:

https://docs.microsoft.com/en-us/azure/logic-apps/create-managed-service-identity

https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates-for-clients

Box 1: Yes

Box 2: Yes

Box 3: Yes

Box 4: Yes

Azure Functions is the simplest option if you are just getting started using the change feed. Due to its simplicity, it is also the recommended option for most change feed use cases. When you create an Azure Functions trigger for Azure Cosmos DB, you select the container to connect, and the Azure Function gets triggered whenever there is a change in the container. Because Azure Functions uses the change feed processor behind the scenes, it automatically parallelizes change processing across your container's partitions.

Note: You can work with change feed using the following options:

Using change feed with Azure Functions

Using change feed with change feed processor

Reference:

https://docs.microsoft.com/en-us/azure/cosmos-db/read-change-feed

Box 1: No You set the highest, or maximum RU/s Tmax you don't want the system to exceed. The system automatically scales the throughput T such that 0.1* Tmax <= T <= Tmax.

In this example we have autoscaleMaxThroughput = 5000, so the minimum throughput for the container is 500 R/Us.

Box 2: No

First query: SELECT * FROM c WHERE c.EmployeeId > '12345'

Here's a query that has a range filter on the partition key and won't be scoped to a single physical partition. In order to be an in-partition query, the query must have an equality filter that includes the partition key:

SELECT * FROM c WHERE c.DeviceId > 'XMS-0001'

Box 3: Yes

Example of In-partition query:

Consider the below query with an equality filter on DeviceId. If we run this query on a container partitioned on DeviceId, this query will filter to a single physical partition.

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001'

Reference:

https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-choose-offer

https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-query-container

Box 1: ConfidentialClientApplicationBuilder

Here's the code to instantiate the confidential client application with a client secret:

app = ConfidentialClientApplicationBuilder.Create(config.ClientId)

.WithClientSecret(config.ClientSecret)

.WithAuthority(new Uri(config.Authority))

.Build();

Box 2: scopes

After you've constructed a confidential client application, you can acquire a token for the app by calling AcquireTokenForClient, passing the scope, and optionally forcing a refresh of the token.

Sample code: result = await app.AcquireTokenForClient(scopes)

.ExecuteAsync();

Reference:

https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-configuration

https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-acquire-token