Microsoft Azure Developer Associate Practice Test (AZ-204)

Access tokens obtained through delegated flows include the scp (scope) claim, which lists the delegated permissions that the user and client app have for the target API. Tokens obtained through the client-credentials flow never carry scp; instead they include the roles claim that lists the application roles (app-only permissions) granted to the calling service principal. Therefore, the API should inspect the scp claim when the call is on behalf of a user and the roles claim when the call is made by a daemon or background service. Inspecting roles for delegated tokens or scp for app-only tokens will always fail, because those claims are not issued in those contexts. Other claims such as aud, appid, or groups do not directly convey the permission being requested.

The v2.0 endpoint issues access tokens that include a version 2 issuer (…/v2.0). A Web API app registration that was created before the v2 endpoint was introduced is configured to accept only v1 tokens. To allow the API to validate v2 tokens you must set the manifest property accessTokenAcceptedVersion to 2. No other manifest setting affects issuer validation for v2 tokens, and properties such as oauth2AllowImplicitFlow or knownClientApplications relate to different scenarios (SPA implicit grant and pre-authorized clients, respectively). Setting accessTokenAcceptedVersion to null or 1 continues to limit the API to v1 tokens, so the issuer validation error would remain.

The az acr import command lets you copy images from an external registry directly into your Azure Container Registry, removing the need to pull them locally or provide Docker Hub credentials for public images. Using --source specifies the origin image, and --image defines the target repository and tag inside ACR. Other options shown either require a local pull and push (docker pull/tag), rely on a non-existent az acr repository copy command, or attempt to run az acr build, which is meant to build images from source code or Dockerfiles, not to copy existing images.

The overload of TelemetryClient.TrackException that accepts an Exception plus two dictionaries lets you attach both custom string properties and numeric metrics in the same call. Passing the exception object, a dictionary that contains the "CustomerId" key, and another dictionary that contains the "ElapsedMs" key ensures all requested data is included in the exception telemetry sent to Application Insights. The other options either omit the metric, use TrackTrace, or use TrackEvent, none of which satisfy the requirement to record both the exception and the custom metric in a single exception telemetry item.

Because the console application runs without a signed-in user, it must authenticate as an application (daemon). The web API therefore needs an application permission that represents the Tasks.Read operation. After you expose this application permission, you assign it to the console app registration and grant tenant-wide admin consent. The console app can then use the OAuth 2.0 client credentials flow to request a token whose audience is the API. Delegated permissions, implicit grant, or public-client settings rely on a user context and are not suitable. Adding the managed identity to a group does not satisfy the permission/consent requirements for Azure AD tokens.

The az webapp create command provisions the Web App. The --plan parameter places the app in an existing App Service plan, and --os-type Linux enforces the operating system. For a .NET 7 workload on App Service for Linux, the runtime identifier must be "DOTNETCORE|7.0". Omitting --plan would create the app in a free plan, using a Windows OS type would violate the requirement, and the value "DOTNET:7.0" is not a valid runtime string.

The Standard test is the only built-in Application Insights availability test that lets you configure advanced options such as SSL certificate validation and custom request headers while still being codeless. A URL ping test is limited to a simple GET operation with no header customization or certificate checks. A custom TrackAvailability test does support any logic you write, but it requires adding code to the application and therefore does not meet the "without writing code" requirement. A multi-step web test is deprecated for new resources and is no longer the recommended choice.

When you enable Continuous Deployment for an ACR-based image in the App Service Deployment Center, the portal creates a webhook in the registry that targets the web app. Every time the specified tag is pushed, ACR sends the webhook, which triggers App Service to pull and start the new image automatically. Changing WEBSITES_CONTAINER_START_TIME_LIMIT only affects the startup timeout and does not trigger image refreshes. Run-From-Package deploys code, not containers. Autoswap between deployment slots orchestrates slot traffic changes but does not cause the app to detect a new image in the registry.

The TimerTrigger attribute supports an optional RunOnStartup property. When set to true, the runtime executes the function once when the host starts and then continues following the defined schedule. AlwaysOn only keeps the Function App warm but does not invoke the function, useMonitor controls checkpointing and does not affect startup execution, and no WEBSITE_TIME_TRIGGER app setting exists. Therefore adding RunOnStartup = true to the TimerTrigger attribute is the correct approach.

Tokens obtained through the client-credentials flow carry application permissions. Microsoft Entra ID does not include the scp (scope) claim in these tokens. Instead, it places granted application roles in the roles claim. Therefore, the API should verify that the roles claim contains the expected application role value ("inventory.read.all").

The other options are incorrect:

• scp is absent in client-credentials tokens.
• aud identifies the audience, not permissions.
• appid is the caller's client ID and unrelated to role validation.

Event Hubs Capture is a built-in feature of Standard and Dedicated namespaces that automatically writes all arriving events to Azure Blob Storage or Azure Data Lake Storage in Avro format. Because Capture runs inside the Event Hubs service, no additional code is required in producers or consumers. A storage lifecycle policy can delete files older than 90 days, meeting the retention requirement. An Azure Function or Stream Analytics job would work but adds custom components. Diagnostic settings forward only service logs and metrics, not event payloads, so they do not satisfy the audit requirement.

When a PFX certificate is stored in Azure Key Vault, the private key material is kept in a hidden secret that shares the certificate's name. To obtain the complete PFX payload (public certificate and private key), the application must call SecretClient.GetSecretAsync on the secrets collection, then convert the returned Base-64 string into a byte array and pass it to the X509Certificate2 constructor.

CertificateClient.GetCertificateAsync only returns the public part of the certificate in DER format, so the resulting X509Certificate2 will lack a private key. KeyClient works with cryptographic keys, not certificates, and GetKeyAsync cannot return a PFX. The Azure CLI is irrelevant inside application code.

Session consistency guarantees that a client will always read its own writes and reads will honor monotonic reads and writes within the same session token. Because the guarantee is scoped to the caller's session, the database does not have to coordinate all replicas, so it incurs lower latency and RU charges than the globally enforced Strong and Bounded Staleness levels. Eventual and Consistent Prefix offer even lower latency but cannot guarantee that a client will immediately observe its own writes. Therefore, the microservice should set Session consistency for its requests.

A Key Vault reference placed in the application settings of the Function app keeps the actual secret inside Azure Key Vault, where it can be rotated centrally. The reference is resolved by the platform, so your code still reads the value from standard configuration providers with no changes. Using a plain application setting or local.settings.json stores the secret in the Function's configuration, not in a dedicated secret store. Storing the value directly in Azure App Configuration as a key-value keeps it out of Key Vault and requires additional code or policies to handle rotation securely.

The Consumption tier is designed for serverless, per-execution billing and always scales automatically. Because there are no dedicated units, the capacity property must be omitted (or set to 0) in the ARM template. Any positive value is rejected. Other tiers (Developer, Basic, Standard, Premium) require capacity to specify the number of units (or a fixed value of 1 for Developer). Therefore, removing the capacity property (or setting it to 0) is the only way to deploy an APIM instance that keeps the Consumption pricing model.

The Users blade in Application Insights usage analytics focuses on unique user identities. It automatically separates results into new and returning users and allows you to filter by a specific custom event (such as FeatureToggleButton) and by time range.

• The Sessions blade shows the number and characteristics of sessions, not distinct users.
• The Events blade lists occurrences of events but does not break them down into new versus returning users unless you write queries.
• Live Metrics Stream provides real-time server metrics and has no concept of new or returning users. Therefore, opening the Users blade is the fastest way to answer the product owners' question.

The Change Feed Processor coordinates work by writing lease documents that map logical partition ranges to individual processor instances. When all pods point to the same lease container (and the same processorName / leasePrefix), the SDK assigns each partition range to only one pod at a time and records checkpoints in the corresponding lease documents. Separate lease containers create isolated processor groups, which can lead to the same change being processed concurrently by multiple pods. Setting unique instance IDs, calling CheckpointAsync frequently, or changing the start time do not provide cross-pod coordination; they affect only local behavior.

Azure Monitor alerts do not send notifications directly; instead, they invoke one or more action groups. An action group can contain several receiver types, such as email, SMS, push, voice, ITSM, webhooks, or logic apps. By attaching an action group that includes an SMS receiver (the engineer's phone number) to the availability-based metric alert, the alert engine automatically places the SMS when the alert condition is met. Simply enabling an option on the availability test, editing Application Insights properties, or changing the alert type does not create the notification path-only an action group with the required receiver ensures delivery.

Because the service has no signed-in user, delegated permissions are impossible. The Microsoft identity platform recommends the OAuth 2.0 client credentials grant for daemon or service applications. This grant issues a token on behalf of the application itself, so it must request an application permission such as User.Read.All. Authorization code, device code, and implicit grants are user-interactive and use delegated permissions, which would fail when no user is present. Application permissions in the implicit flow are not supported.

Azure Service Bus can automatically discard messages that have the same MessageId as one that was previously accepted during a specified time interval. Enabling duplicate detection and setting a 10-minute duplicate detection history window satisfies the requirement because the broker will remove any retries that arrive within that window, ensuring the order is processed only once. Sessions provide ordered, state-full processing but do not eliminate duplicates. Setting MaxDeliveryCount to 1 limits how many times a single message is delivered after a processing failure; it does not address multiple identical messages with different identifiers. Increasing the lock duration only gives the consumer more time to finish processing a single delivery and does not prevent duplicate messages from being received.