Task 1.1: Design solutions for logging and monitoring

• AOne workspace in East US that collects logs from both regions

  Incorrect

  A single East US workspace would store European operational logs outside Europe, which breaks the location requirement.

• BOne workspace for each application in each region

  Incorrect

  Per-application workspaces also keep data in region, but they multiply the workspaces to manage without meeting any extra requirement.

• COne workspace in each of the two regions, queried together by the central team

  Correct

  Each workspace resides in one region, so a European workspace keeps European data in Europe, and the team can query across workspaces.

• DA storage account in each region, filled by data export rules from one central workspace

  Incorrect

  Data would first land in the single workspace's region, and exported blobs can't be queried with log queries the way a workspace can.

The workspace design guidance treats the Azure region as a criterion: each workspace lives in one region, and compliance rules about data location can require a workspace per region. A query can reference several workspaces, so a central team still gets one view.

• AA longer retention value on the activity log blade of the subscription

  Incorrect

  The activity log's own retention isn't configurable; longer storage comes from sending it to a destination.

• BAn activity log diagnostic setting to a workspace with two-year retention

  Correct

  The activity log keeps events for 90 days; a diagnostic setting sends them to a workspace, where retention can be set and KQL works.

• CA monthly CSV download of the activity log to a file share

  Incorrect

  Manual downloads aren't queryable with KQL and depend on someone remembering to run them.

• DMicrosoft Entra audit logs streamed to an event hub and kept by the SIEM for two years

  Incorrect

  Entra audit logs record directory changes, not Azure resource operations in a subscription.

Azure keeps activity log entries for 90 days. To keep them longer and analyze them with other monitoring data, create a diagnostic setting that sends the activity log to a Log Analytics workspace and set the table retention to meet the audit period.

• AA Log Analytics workspace whose tables use the Analytics plan

  Incorrect

  A workspace doesn't keep the logs in a write-once state that nobody can alter, which the archive requires.

• BAn Azure Event Hubs namespace

  Correct

  Event Hubs is the diagnostic setting destination for streaming logs to external systems such as a third-party SIEM.

• CThe Azure Monitor metrics database of each resource

  Incorrect

  Metrics aren't a destination for resource logs in a diagnostic setting.

• DA storage account container with a locked time-based retention policy

  Correct

  A storage destination is the low-cost archive, and a locked time-based retention policy keeps the blobs in a WORM state.

• EAn Azure Data Explorer cluster named as the setting's destination

  Incorrect

  Azure Data Explorer isn't one of the diagnostic setting destinations; it would need its own ingestion pipeline.

A diagnostic setting can send resource logs to a Log Analytics workspace, a storage account, an event hub and supported partner solutions. Event Hubs feeds the external SIEM; storage is the cheap long-term archive, and immutable storage with a locked time-based retention policy makes it write once, read many.

• AAzure Monitor Agent with a data collection rule using XPath filters

  Correct

  A data collection rule can use XPath queries to collect only the listed event IDs, and one rule can be associated with many VMs.

• BA daily cap on the workspace set below the current ingestion volume

  Incorrect

  A daily cap stops collecting data when it's reached, so the required events would be lost for the rest of the day.

• CA diagnostic setting on each VM resource that sends its logs to the workspace

  Incorrect

  A VM's diagnostic setting covers platform data, not the guest operating system's event logs, and it has no event ID filter.

• DVM insights enabled on every VM with the default data collection rule

  Incorrect

  VM insights collects performance data; it doesn't filter the Security event log.

Azure Monitor Agent collects guest data according to data collection rules. A rule for Windows events can use XPath queries to keep only specific event IDs, which lowers ingestion while keeping every needed event, and it's associated with machines at scale.

• ADiagnostic settings that send each app's platform logs to one workspace

  Incorrect

  Platform logs from each resource aren't correlated into one request across services, and they don't time each dependency call.

• BApplication Insights for every service, instrumented with OpenTelemetry

  Correct

  Application Insights collects requests, dependencies and traces and correlates them across services into one end-to-end transaction.

• CAzure Monitor metric alerts on the response time of each app

  Incorrect

  An alert can show that an app is slow but not which call inside the request is slow.

• DResource change analysis in Azure Resource Graph for the five apps

  Incorrect

  Change analysis lists resource changes; it doesn't trace a request through the services.

Application Insights, the application performance monitoring feature of Azure Monitor, uses OpenTelemetry to collect requests, dependencies, exceptions and traces, and its transaction view follows one operation across components.

• ANSG flow logs on every network security group

  Incorrect

  NSG flow logs are retiring on September 30, 2027 and no longer support new creation; they also miss traffic no NSG evaluates.

• BConnection monitor tests between every pair of subnets

  Incorrect

  Connection monitor runs synthetic tests between endpoints; it doesn't record the real traffic flowing through the networks.

• CPlatform metrics of each virtual network sent to a workspace

  Incorrect

  Metrics give counts and volumes, not a record of each flow with its source, destination and decision.

• DVirtual network flow logs with traffic analytics

  Correct

  Virtual network flow logs record flows at the network level, whether or not an NSG applies, and traffic analytics visualizes them.

Virtual network flow logs capture IP traffic at the virtual network level and address limitations of NSG flow logs, which retire on September 30, 2027 and can't be created anymore. Traffic analytics processes the flow logs into maps and insights.

• AAn Azure Monitor Private Link Scope connected to a private endpoint in the network

  Correct

  A private link scope groups the workspaces and components behind one private endpoint for ingestion and queries over private IPs.

• BA separate private endpoint created on each Log Analytics workspace and Application Insights resource

  Incorrect

  Azure Monitor resources connect through a private link scope rather than individual private endpoints per workspace.

• CService endpoints for Microsoft.Insights on the VM subnets

  Incorrect

  Service endpoints don't give Azure Monitor a private IP in the network, and these networks have no internet path.

• DDiagnostic settings that send the logs to a storage account first

  Incorrect

  Diverting to storage doesn't get the data into the workspaces or Application Insights privately.

Azure Monitor uses an Azure Monitor Private Link Scope (AMPLS): you add workspaces and Application Insights components to the scope and connect it to a private endpoint, so ingestion and queries use private IPs.

• AService Health alerts for those services and regions, sent to an action group

  Correct

  Service Health alerts fire on service issues, planned maintenance and advisories for chosen services and regions and notify an action group.

• BMetric alerts on the CPU usage of every VM

  Incorrect

  CPU alerts report load on your VMs, not Azure-wide incidents or maintenance.

• CAn Azure Status page bookmark checked each morning

  Incorrect

  The public status page shows broad outages only and needs someone to look at it.

• DAvailability tests in Application Insights for each app, alerting the team when one fails

  Incorrect

  Availability tests detect that an app is down, not that Azure has announced an incident or planned maintenance.

Azure Service Health gives a personalized view of service issues, planned maintenance and health advisories for the services and regions you use, and Service Health alerts send them to action groups.

• AA self-hosted Prometheus server and Grafana inside each cluster

  Incorrect

  Self-hosted servers are what the engineers don't want to operate, and retention depends on cluster storage.

• BAzure Monitor managed service for Prometheus with Azure Managed Grafana

  Correct

  Managed Prometheus collects and stores cluster metrics with no servers to run, and Managed Grafana hosts dashboards with Entra sign-in.

• CDiagnostic settings on each cluster sending control plane logs to a workspace

  Incorrect

  Control plane resource logs aren't the Prometheus metrics from workloads and nodes that the dashboards need.

• DAzure Monitor workbooks built from the platform metrics of each cluster

  Incorrect

  Workbooks aren't Grafana dashboards, and platform metrics don't include the Prometheus metrics the team queries with PromQL.

Azure Monitor managed service for Prometheus scrapes and stores Prometheus metrics in an Azure Monitor workspace, queryable with PromQL. Azure Managed Grafana is a managed Grafana instance with Entra authentication that uses it as a data source.