4 of the 11 questions we have for this objective, shown with the answer and the reasoning.
Design solutions for logging and monitoring
Quillon Bank sends Windows security events and Linux Syslog from 600 VMs to a Log Analytics workspace named law-sec. Compliance requires that the SecurityEvent table be retained for two years, but analysts only run interactive queries against the most recent 90 days. The Syslog table is very high volume, is used only for occasional troubleshooting, and does not need alerting or interactive dashboards. The workspace default retention is 30 days. You must minimize cost.
Which two actions should you recommend? Each correct answer presents part of the solution.
- ASet table-level analytics (interactive) retention of 90 days and total retention of 730 days on the SecurityEvent tableTable-level retention lets you keep two years of SecurityEvent data while paying the full analytics rate for only the 90 days analysts actually query; the remainder sits in lower-cost long-term retention and can still be restored or retrieved with a search job.
- BIncrease the workspace default analytics retention to 730 daysThis keeps every Analytics table in the workspace at the full analytics retention price for two years, including tables that do not need it, which maximizes rather than minimizes cost.
- CChange the Syslog table to the Auxiliary table planThe Auxiliary plan has the lowest ingestion price and still allows ad-hoc KQL queries for troubleshooting, at the cost of slower queries and no alert rules, insights, or dashboards, which matches how Syslog is used here. The Syslog table supports the Auxiliary plan but not the Basic plan.
- DExport the SecurityEvent table continuously to a storage account and reduce the table's retention to 30 daysThis retains the data but removes the ability to query the most recent 90 days interactively in the workspace, and continuous export adds its own per-GB charge.
- ECreate a second workspace with 730-day retention and send SecurityEvent to both workspacesDuplicating ingestion doubles the most expensive component of the bill and adds a second workspace to administer.
Why: Log Analytics cost is driven by ingestion volume and the plan of each table (Analytics, Basic, or Auxiliary), then by how long data stays in analytics retention. The right design matches each table's plan and retention to how it is used: SecurityEvent needs 90 days of analytics retention plus long-term retention to two years, and Syslog needs the cheapest possible ingestion with occasional query and no alerting, which is exactly the Auxiliary plan. Raising the workspace default applies the most expensive setting to everything, and exporting or duplicating data either breaks the interactive requirement or doubles cost.
Design solutions for logging and monitoring
Marrowfield Energy operates an Azure Firewall named fw-hub. Three consumers need its logs: the network operations team runs Kusto queries in the central Log Analytics workspace, the security team's third-party SIEM must receive a raw copy within minutes, and auditors require an immutable five-year archive. The company wants to minimize both cost and the number of components to maintain.
What should you recommend?
- AOne diagnostic setting on fw-hub with three destinations: the Log Analytics workspace, an Event Hubs namespace, and a storage account with an immutability policyA single diagnostic setting can fan out the same log categories to all three destination types at once, so each consumer gets the format it needs with no intermediate processing, no extra export charges, and one object to maintain.
- BA diagnostic setting to the Log Analytics workspace only, with data export from the workspace to Event Hubs and to a storage accountWorkspace data export works, but it adds a per-GB export charge on top of ingestion and introduces a second configuration layer, which the scenario asks to avoid.
- CA diagnostic setting to Event Hubs only, with an Azure Stream Analytics job that writes to the workspace and to storageStream Analytics adds a continuously billed streaming job and custom query logic for something diagnostic settings do natively.
- DThree separate diagnostic settings on fw-hub, each sending to one destinationThis produces the same data flow but triples the configuration to maintain; one setting with multiple destinations is the simpler equivalent.
Why: A diagnostic setting is the routing control for resource logs, and a single setting may target a Log Analytics workspace, a storage account, and an Event Hubs namespace simultaneously. When different consumers need the same logs in different sinks, the lowest-cost and lowest-maintenance design is one setting with multiple destinations, because every other option adds a processing hop with its own bill. The audit requirement for an immutable archive is satisfied by an immutability policy on the storage container rather than by any extra routing.
Design solutions for logging and monitoring
Orrin Logistics has 300 Windows Server VMs in Azure. The security team needs only Windows event IDs 4624, 4625, and 4720 from the Security log, plus one custom performance counter, sent to a Log Analytics workspace. The company pays per gigabyte ingested and wants to send as little data as possible. New VMs must be onboarded automatically when they are created.
What should you recommend?
- ADeploy the Azure Monitor Agent through Azure Policy and associate a data collection rule that uses XPath queries to select the three event IDs and the counterData collection rules filter at the agent before data leaves the VM, so only the matching events and the single counter are ingested. The built-in Azure Policy initiatives install the agent and create the association for new VMs automatically.
- BDeploy the Azure Monitor Agent with a data collection rule that collects all Security log events, then filter to the three event IDs in Kusto queriesCollecting the whole Security log ingests every event and bills for it; filtering in the query happens after ingestion and does not reduce cost.
- CEnable the Azure Diagnostics extension on each VM and stream the Security log to a storage accountThe diagnostics extension writes to storage or Event Hubs, not to Log Analytics tables, and cannot be targeted at specific event IDs the way a data collection rule can.
- DInstall the Azure Monitor Agent manually on each VM and configure a workspace-level Windows event data sourceManual installation does not onboard new VMs automatically, and the Azure Monitor Agent is configured through data collection rules, not legacy workspace-level data sources.
Why: The Azure Monitor Agent collects only what its associated data collection rules specify, and Windows event data sources support XPath expressions that filter to specific event IDs at the source. That is what minimizes ingestion cost. Automatic onboarding of new VMs comes from the built-in Azure Policy definitions that install the agent and create the rule association. Collecting everything and filtering afterwards, or using legacy extensions and manual installs, misses either the cost or the automation requirement.
Design solutions for logging and monitoring
Pellridge Travel hosts a .NET booking API on Azure App Service that calls Azure SQL Database and a third-party payment service. The development team needs per-request response times, failure rates, distributed traces across the API and its dependencies, and alerts when the payment dependency slows down.
Which service should you recommend?
- AAzure Network WatcherNetwork Watcher diagnoses virtual network connectivity, NSG rules, and packet flows; it has no visibility into application requests or dependencies.
- BAzure Monitor platform metrics for App ServicePlatform metrics give aggregate CPU, memory, and HTTP counts for the plan, but not per-request traces or dependency-level latency.
- CApplication InsightsApplication Insights is the Azure Monitor feature for application performance monitoring; it records requests, dependencies, exceptions, and distributed traces and supports alerts on dependency duration.
- DVM insightsVM insights monitors guest OS performance and process maps on virtual machines and Arc-enabled servers, not App Service applications.
Why: Azure Monitor has layers: platform metrics and resource logs describe the Azure resource, VM insights and Container insights describe compute, Network Watcher describes network paths, and Application Insights describes the application itself. The requirement for per-request telemetry, dependency tracking, and distributed tracing is application-level, which only Application Insights provides. Recognizing which layer a requirement lives in is the core of recommending a monitoring solution.