Secure, Monitor, and Troubleshoot Azure Solutions practice questions

Answer: A) Query the ContainerAppSystemLogs table for the revision, filtered to entries where EventSource is KEDA

Azure Container Apps scales through KEDA, and KEDA's scale events are recorded in ContainerAppSystemLogs (EventSource == "KEDA"). Query that table to see why each scale-out or scale-in happened. Metrics show only the resulting replica count, and Azure Monitor autoscale history doesn't apply to Container Apps.

• ACorrect. Container Apps uses KEDA for scaling, and the KEDA scale log is in the ContainerAppSystemLogs table. Filtering by revision and EventSource == "KEDA" shows the type, reason, and message for each scaler event over time.
• BIncorrect. Container Apps doesn't use Azure Monitor autoscale settings; its scaling is driven by declarative scale rules implemented with KEDA. So there is no Azure Monitor autoscale run history for these decisions.
• CIncorrect. Console logs contain the stdout and stderr output of your own containers and Dapr sidecars. Platform scaling events come from the service and appear in system logs, not console logs.
• DIncorrect. The Replica count metric shows how many active replicas a revision had over time, so it shows that scaling happened. It doesn't record the scaler events or reasons behind each change, which is what the team needs.

Answer: A) retry-after-ms

Azure OpenAI 429 responses include a retry-after-ms header with the recommended wait in milliseconds before retrying. The x-ratelimit-limit-* and x-ratelimit-remaining-* headers report limits and remaining capacity, not a retry delay.

• ACorrect. Azure OpenAI includes retry-after-ms in 429 responses as the recommended wait time, in milliseconds, before retrying. The documentation advises using this value when it's present and falling back to exponential backoff with jitter when it isn't.
• BIncorrect. This header reports how many tokens remain before the rate limit is reached. It helps with proactive throttling but doesn't give a wait time.
• CIncorrect. This header reports the maximum tokens per minute currently allowed for the deployment. It can reveal a temporary rate-limit adjustment but doesn't say how long to wait.
• DIncorrect. This header reports how many requests remain before the request-based limit is reached. It's a count, not a recommended retry delay.

Answer: A) Put each dependency's fault action in its own branch within the same step, so both faults are injected at the same time

In Chaos Studio Experiments (classic), steps run one after the other and the branches within a step run at the same time. To test overlapping dependency failures, put each fault in a parallel branch of the same step.

• ACorrect. In Experiments (classic), the branches within a step run at the same time. Putting each fault in a separate branch of one step injects both failures together, which exercises interactions that a single-dependency test never reaches.
• BIncorrect. Steps in an experiment run one after the other, so the two faults would happen in sequence rather than overlapping. That doesn't test the case where both dependencies fail at once.
• CIncorrect. Availability tests check whether endpoints respond, but they don't inject failures. They can't show how the application behaves when both dependencies are down.
• DIncorrect. A load test measures behavior under heavy traffic. It doesn't make the vector store and cache unavailable, so it doesn't validate fallback logic for a compound dependency failure.

Answer: A) Set networking to selected networks and add the offices' public CIDR blocks as IP rules

To allow only specific public internet sources, set the resource's network default action to deny (Selected Networks and Private Endpoints) and add IP network rules for those public ranges. Private endpoints, NSGs, and virtual network rules solve different problems.

• ACorrect. Switching the resource to Selected Networks and Private Endpoints changes the default action to deny. Adding IP network rules for the offices' public IPv4 addresses or CIDR ranges then lets only those sources reach the public endpoint and blocks general internet traffic.
• BIncorrect. A private endpoint gives private connectivity from clients in a virtual network. Disabling public access blocks the public endpoint completely, so the offices, which connect over the internet, couldn't reach it at all.
• CIncorrect. NSGs filter traffic for subnets and network interfaces inside an Azure virtual network. They don't control inbound access to a PaaS resource's public endpoint.
• DIncorrect. Virtual network rules admit traffic from specific Azure virtual network subnets that use a service endpoint. They don't admit on-premises clients identified by public IP addresses. That's what IP network rules are for.

Answer: A) The vault's AuditEvent resource logs in Log Analytics, filtered to SecretGet operations on that secret's URI, using the identity and time fields

Only Key Vault resource logs (the AuditEvent category) record which identity read a secret and when. They're collected only after a diagnostic setting routes them somewhere, such as Log Analytics, which the scenario says was already in place.

• ACorrect. Key Vault AuditEvent logs record each data-plane operation (for example, SecretGet) with the time in UTC, the identity from the presented token, the caller IP address, and the request URI. Because the diagnostic setting was already collecting them, the team can query them with KQL.
• BIncorrect. The activity log holds subscription-level events seen from outside the resource, such as creating or updating the vault. It doesn't record individual secret reads.
• CIncorrect. Platform metrics are aggregated numbers for tracking performance and volume. They show how many requests occurred, not which identity read a particular secret.
• DIncorrect. Version attributes show when the secret was created or changed. They don't record who retrieved the secret or when it was read.

Answer: A) An initiative definition (policySet) that contains the three policy definitions, assigned at the required scope

An Azure Policy initiative (policySet) groups related policy definitions so they can be assigned and tracked as one item. Policies added to it later are covered by the existing assignment.

• ACorrect. An initiative definition groups a set of policy definitions as one item that you assign and evaluate together. Policies added to the initiative later become part of its existing assignments, so the number of assignments doesn't grow.
• BIncorrect. Separate assignments work, but each one has to be managed and tracked on its own, and every new policy would need another assignment. That is the opposite of what the company wants.
• CIncorrect. Parameters make a single definition reusable with different values, such as different allowed locations. They don't merge separate rules for keys and diagnostics into the same definition.
• DIncorrect. A management group organizes subscriptions into a scope that you can assign policies to. It groups resources, not policy definitions, so you would still need separate assignments for each policy.

Answer: A) Back up each secret individually, for example with az keyvault secret backup, and restore the encrypted blob into a vault in the same subscription and Azure geography

Soft delete and purge protection only protect against deletion inside the existing vault. When you need an offline copy, back up each object separately. The resulting encrypted blob can only be restored into a vault in the same subscription and Azure geography.

• ACorrect. Key Vault backups are per object (secret, key, or certificate) and download as an encrypted blob. Microsoft lists an offline copy for regulatory or compliance reasons as a valid reason to use backups. The blob can only be restored into a key vault in the same Azure subscription and Azure geography.
• BIncorrect. Soft delete and purge protection guard against accidental or malicious deletion inside the existing vault. They don't create an offline copy that can be stored separately and restored into another vault.
• CIncorrect. Key Vault can't back up an entire vault in one operation; each key, secret, and certificate has to be backed up separately. A restore also has to target a vault in the same subscription and Azure geography, not any subscription or region.
• DIncorrect. The backup blob is encrypted and can't be decrypted outside Azure. You can only get usable data from it by restoring it into a key vault.

Answer: A) Application Insights

Application Insights is the APM feature of Azure Monitor. It tracks request latency, exceptions and dependency calls from within an instrumented application, which Service Health, Network Watcher and Advisor do not do.

• ACorrect. Application Insights is Azure Monitor's application performance monitoring (APM) feature. Once the app is instrumented (for example, with the Azure Monitor OpenTelemetry Distro), it collects request, exception and dependency telemetry and shows it in the Performance, Failures and Application map views.
• BIncorrect. Service Health reports Azure platform incidents, planned maintenance and advisories that affect your subscriptions. It does not collect telemetry from your own application code.
• CIncorrect. Connection monitor checks network reachability and latency between endpoints at the network level. It does not record application requests, exceptions or SDK dependency calls from inside the code.
• DIncorrect. Azure Advisor gives best-practice recommendations on cost, security, reliability and performance. It is not a source of live request, exception or dependency telemetry.

Answer: A) The deployment stops serving requests, and inference calls to the retired model version return HTTP 410 Gone.

A Standard deployment set to NoAutoUpgrade stops working when its model version retires, and inference returns 410 Gone. Model lifecycle changes are one reason a configuration needs regular review after launch, for example by watching Service Health advisories and the Models API.

• ACorrect. With NoAutoUpgrade, the deployment never auto-upgrades and stops working at retirement. Retired models are removed from service, and all inference requests return 410 Gone. The team needed to watch retirement notices and migrate before that date.
• BIncorrect. Automatic upgrade at retirement depends on the upgrade option (for example, OnceCurrentVersionExpired). NoAutoUpgrade explicitly means the deployment never auto-upgrades.
• CIncorrect. That describes the Deprecated stage, which comes before retirement. Once a model is Retired, existing deployments stop working too.
• DIncorrect. Microsoft states that retirement dates can't be extended. Teams have to plan migration using the published retirement schedule and the Models API.

Answer: A) A monthly budget with an alert condition of type Forecasted, set at 100% of the budget amount

Cost Management budgets support both actual and forecasted alert conditions. A forecasted alert fires when projected spending exceeds the threshold, so the team is warned before actual costs reach the budget.

• ACorrect. Forecasted budget alerts use forecasted cost predictions. They're generated when the projected cost exceeds the threshold, which warns the team that spending is likely to exceed the budget before actual costs get there.
• BIncorrect. Actual-cost budget alerts fire based on cost already accrued. A 100% actual threshold only fires once the budget has already been reached, not when the trend first predicts an overrun.
• CIncorrect. Anomaly alerts notify you when Cost Management detects unusual spending. They don't compare a projected end-of-period total against a budget amount.
• DIncorrect. Credit alerts track how much Azure Prepayment has been consumed, are generated automatically at 90% and 100%, and are available only for Enterprise Agreements. They don't project spending against a monthly budget.