Microsoft Azure Developer Associate Practice Test (AZ-204)

Azure API Management preserves the metadata contained in an OpenAPI specification. Any examples defined for an operation are imported and automatically surface in the developer portal as sample requests and responses that developers can inspect or replay. Summary and description fields are also preserved, tags are used only for grouping operations (not for versioning), and externalDocs links are kept as external references rather than being converted to policies. Therefore, the statement about examples being shown as samples is the only accurate one.

Azure Monitor alerts use action groups to define who is notified and how. In the portal you first create a metric alert rule that targets the availability test metric Failed locations and sets the threshold to greater than 0. During alert creation you select (or create) an action group. Inside the action group you add two Email/SMS/Push/Voice receivers: one configured for the engineer's phone number (SMS) and another for the help-desk distribution list (email). When the alert fires Azure Monitor automatically delivers the notifications through the channels defined in that single action group. Adding owners to the resource only grants access and does not send notifications. The availability test blade itself has no place to list recipients; it relies on Azure Monitor alerts. Using Event Grid and a Logic App would work but is unnecessary overhead when the built-in action group can deliver both SMS and email directly.

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 OnFailure restart policy instructs Azure Container Instances to monitor the main process running inside the container. If the process exits successfully (exit code 0), the container stops and remains stopped, so billing for CPU and memory ceases. If the process exits with a non-zero code, ACI interprets this as a failure and restarts the container automatically. The Always policy keeps restarting the container even after successful completion, incurring unnecessary cost. The Never policy prevents any automatic restart, so a failure would leave the container stopped. UnlessStopped is not a valid ACI restart policy.

To satisfy least-privilege policy, the token must grant only the permissions needed to upload files. Write (w) permits creating and overwriting blobs, and Create (c) is optional because Write already covers creation. Listing the container would require the List (l) permission, which must be excluded. The token sp=cw&st=2024-10-15T02:00Z&se=2024-10-15T03:00Z grants only Create and Write and is valid solely during the 02:00-03:00 UTC window. The other tokens either include List (l), grant unnecessary permissions such as Delete (d), or have a much broader validity period, violating the stated security requirements.

Only the Premium tier supports all three stated capabilities simultaneously. Internal virtual-network connectivity is available in both the Developer and Premium tiers, but the Developer tier is limited to a single capacity unit and is intended only for non-production use. The Basic and Standard tiers allow scaling but do not support internal VNet integration. Custom hostnames are available in several tiers, but the Premium tier is the only production tier that combines custom hostnames, internal VNet support, and horizontal scalability.

The service name becomes part of the public endpoint (.azure-api.net) that Azure assigns to the API Management gateway. Because this DNS name must remain stable for client applications, Azure locks the service name once the resource is created. Organization (publisher) name, administrator email, and pricing tier can all be changed later through the APIM settings or by scaling the service.

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.

BlobClient.GetPropertiesAsync issues a single HEAD request to the blob and returns a BlobProperties object. The object contains both system properties such as ContentLength and the complete Metadata dictionary, allowing you to read the "department" value without downloading content.

DownloadContentAsync retrieves the full blob data, which is unnecessary and incurs additional network cost.

GetTagsAsync returns only tags, not system properties or metadata.

SetMetadataAsync is used to write metadata-calling it with an empty dictionary would overwrite existing metadata and still would not return the blob's size.

The ip-filter policy must run first to exempt traffic from the internal address space. The rate-limit-by-key policy is designed for short-term rolling windows and evaluates each request against a moving counter keyed to a value such as the caller's subscription key. When calls exceed the configured limit (50) inside the renewal period (60 seconds), API Management automatically returns HTTP 429 to the offending caller. The quota-by-key policy is intended for longer-term usage quotas, a simple rate-limit policy cannot distinguish tenants, and header manipulation alone does not enforce throttling.

The Azure Cosmos DB Change Feed Processor library automatically distributes change-feed ranges by using leases, guaranteeing at-least-once processing without duplicates across scaled-out workers. It persists its position in a separate lease container, so after a restart it continues from the last saved checkpoint. When you keep the default StartFromBeginning value (false) or explicitly set ChangeFeedStartFrom.Now, the processor begins reading only future changes, so historic items are ignored. The other options either re-read existing data, rely on manual and volatile token tracking, or misuse TTL/deletion semantics, and therefore cannot satisfy all three requirements.

The BlobClient.GetPropertiesAsync method issues a properties call to the service that returns the blob's system properties and any user-defined metadata without transferring the blob's content. DownloadContentAsync streams the data itself; GetTagsAsync returns blob index tags rather than metadata; SetMetadataAsync is used to write, not read, metadata.

The Azure Cosmos DB Change Feed Processor library creates a dedicated lease container that stores checkpoints for each logical partition. Because the processor persists its state in the lease container, it can resume from the exact position where it stopped, ensuring at-least-once (effectively exactly-once) processing across restarts. The same lease mechanism also handles automatic partition ownership and load balancing among multiple concurrent hosts, so the workload is evenly distributed without extra code. Reading the change feed manually with an iterator would require custom persistence logic, while analytical store queries or SQL triggers do not provide ordered, scalable change-feed semantics.

Key Vault references are evaluated by the client application. The identity that the application presents to Azure Key Vault must have permission to read secrets. Enabling a system-assigned managed identity on the App Service instance allows the runtime to obtain an Azure AD token automatically. Granting that identity the Key Vault Secrets User (or Secret Reader via an access policy) role gives it "Get" permission on the secrets, so the reference can be resolved. The other options either do not provide authentication to Key Vault or grant an unrelated permission.

A user delegation SAS is created by first obtaining a user delegation key through an Azure AD authenticated call to GetUserDelegationKey, then constructing the signature with BlobSasBuilder (or equivalent). Because the SAS is tied to the Azure AD principal, disabling that identity or revoking the delegation key immediately invalidates the token. A service or account SAS is signed with a storage account key; revoking it later would require regenerating the account keys, which the scenario forbids. Making the container public would not meet the security constraints.

The Azure CLI authenticates an Azure Container Instance to a private Azure Container Registry in one of two ways: explicit registry credentials or a managed identity attached to the container group. To use a user-assigned managed identity you add the --assign-identity parameter and supply the identity's resource ID or name. The CLI then sets the identity property on the container group, allowing the identity (once granted AcrPull permission) to obtain an access token for the registry. None of the other parameters are valid for enabling managed-identity based registry authentication; they either refer to username/password authentication or are not recognized by az container create.

Session consistency provides read-your-writes, monotonic reads, monotonic writes, and write-follows-reads guarantees within a single client session, so a user always sees their own latest cart changes. Because the guarantee is scoped to the session, the database can serve reads from the nearest replica, keeping latency low. Strong consistency would satisfy all users but incurs the highest latency across regions. Bounded staleness limits lag to a configured window but does not guarantee that a read immediately reflects the caller's last write. Consistent prefix preserves the order of writes yet can still return data that is missing the most recent update, violating the requirement.

The rate-limit-by-key policy is designed to throttle traffic for each distinct value of a caller-supplied key. By setting calls="1000" and renewal-period="3600" you define a sliding counter of 1 000 calls per 3 600 seconds (one hour). Supplying counter-key="@(context.Principal.Claims["tenantId"]?.Value)" uses the tenantId claim from the already validated JWT as the discriminator, so each tenant gets an independent counter. The simpler rate-limit policy cannot separate traffic by tenant, quota policies accumulate over a subscription's lifetime, and adding an extra variable with a separate quota step is unnecessary because rate-limit-by-key performs the task in a single policy statement.

Because the client application authenticates with the client-credentials flow, the access token will not contain user delegated scopes. Instead, the token can carry application roles that are granted to the calling service principal. Defining an application role in ContosoApi's app registration and assigning that role to the client application causes Entra ID to issue a roles claim (Orders.ReadWrite) in every token that the client obtains, regardless of user context. Defining delegated scopes would only work in flows that involve a user, optional claims do not create or control role issuance, and Azure RBAC on the App Service is unrelated to token claims used by a custom API.

Azure App Service exposes a setting called Minimum TLS Version in the TLS/SSL settings blade. Setting this value to 1.2 instructs the platform to refuse hand-shakes that attempt to use TLS 1.0 or 1.1, thereby satisfying the compliance requirement. Changing web.config SSL flags only affects IIS-level requirements inside the sandbox and does not block older TLS versions at the front door. Application settings such as WEBSITE_DISABLE_TLS12 do not exist, and enforcing a protocol version through an external Application Gateway listener would protect only traffic routed through that gateway, not direct requests that resolve to the app's default endpoint.