{"id":3019,"date":"2026-10-08T12:09:15","date_gmt":"2026-10-08T12:09:15","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/microsoft-az-305-azure-logging-architecture\/"},"modified":"2026-10-17T10:57:14","modified_gmt":"2026-10-17T10:57:14","slug":"microsoft-az-305-azure-logging-architecture","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/microsoft-az-305-azure-logging-architecture\/","title":{"rendered":"Microsoft AZ-305: Azure Logging Architecture"},"content":{"rendered":"<p>Azure logging architecture is not a matter of enabling every available diagnostic category. The design problem is deciding <strong>which signals matter, where they should be routed, how long they should remain searchable, and which teams or systems need them<\/strong>.<\/p>\n<p>Azure Monitor gives architects several telemetry paths. Diagnostic settings can route supported platform logs and metrics to Log Analytics, Event Hubs, and Azure Storage, while the Activity Log, application telemetry, guest operating-system logs, and service-specific signals have their own collection characteristics. When working through independent <a href=\"https:\/\/www.examtopics.biz\/az-305\">AZ-305 architecture practice<\/a> scenarios, decide which signals need investigation, streaming, or archival retention before selecting a particular diagnostic setting. Microsoft\u2019s current AZ-305 objectives assess logging and monitoring design rather than indiscriminate collection.<\/p>\n<p>A useful logging design therefore begins with questions, not destinations: What incident must this data help reconstruct? How quickly must an operator query it? Must another platform consume it? Is the record subject to long-term retention or immutability? The answers determine whether a signal belongs in a query store, a stream, an archive, or some combination of those destinations.<\/p>\n<h2>Start with evidence requirements, not log categories<\/h2>\n<p>Logging becomes expensive and difficult to operate when teams collect data without connecting it to an operational or security decision. Before selecting a destination, define the question each signal must answer.<\/p>\n<p>An operations team might need to determine why an API became slow during a deployment. A security team might need to correlate firewall, identity, and workload events during an incident. A compliance team might need proof that administrative changes were retained for a prescribed period. A downstream analytics platform might need a continuous feed of selected events rather than an interactive Azure query experience.<\/p>\n<p>Those are different requirements. They can justify different paths for the same Azure environment.<\/p>\n<p>A sound inventory normally separates at least these signal classes:<\/p>\n<ul>\n<li>control-plane changes and administrative operations<\/li>\n<li>resource-specific platform logs<\/li>\n<li>metrics and health indicators<\/li>\n<li>application traces, requests, dependencies, and exceptions<\/li>\n<li>guest operating-system logs<\/li>\n<li>identity and security events<\/li>\n<li>audit records that require long retention<\/li>\n<\/ul>\n<p><a href=\"https:\/\/www.examtopics.biz\/blog\/introduction-to-azure-monitoring-tools-a-beginners-guide\/\">Azure monitoring tools<\/a> expose different evidence: a resource metric can show saturation, an activity log can show a management operation, and workspace queries can correlate collected diagnostics after ingestion. Assign an owner, retention requirement and troubleshooting purpose to each signal. A healthy resource metric does not prove that the expected application-level event was captured or retained.<\/p>\n<h2>Diagnostic settings are a routing mechanism<\/h2>\n<p>Azure Monitor diagnostic settings are commonly used to export supported resource logs and metrics. They do not constitute a storage system by themselves. They define which categories are selected and where those categories are sent.<\/p>\n<p>Typical destinations include a Log Analytics workspace, an Event Hubs namespace, Azure Storage, and supported partner integrations. A resource can use multiple diagnostic settings when the architecture genuinely needs separate paths. For example, security-relevant logs might go to Log Analytics for investigation while a selected subset also streams through Event Hubs to an enterprise security platform.<\/p>\n<p>This distinction matters because architects sometimes treat \u201cdiagnostic settings enabled\u201d as equivalent to \u201clogging solved.\u201d It is not. A diagnostic setting can successfully export data while the destination still has the wrong retention, access controls, region, cost model, or downstream processing design.<\/p>\n<p>Another consideration is category and metric-export behavior. Azure resource-log categories differ by service, and some services support resource-specific Log Analytics tables while others may use AzureDiagnostics depending on configuration. Not every platform metric is exportable through diagnostic settings; exported multidimensional metrics can lose their dimensions. Check the documented <a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/azure-monitor\/data-collection\/diagnostic-settings\" rel=\"nofollow\">Azure diagnostic-settings limitations<\/a> before promising attribute-level analysis. Schema, exportability, and query design therefore belong in the architecture review.<\/p>\n<h2>Use Log Analytics when people need to investigate and correlate<\/h2>\n<p>A Log Analytics workspace supports interactive search, <a href=\"https:\/\/www.examtopics.biz\/blog\/az-104-azure-monitor-kql-alerts-action-groups\/\">KQL queries<\/a>, workbooks and log-based alerts when the relevant records are actually being ingested. Before concluding an operation never occurred, check the data collection rule, table, retention window and event timestamp. A successful KQL search tests the stored data and query, not whether a service emitted every expected event.<\/p>\n<p>That makes it appropriate for questions such as:<\/p>\n<ul>\n<li>Which resources produced errors after a deployment?<\/li>\n<li>Did a network change coincide with an application outage?<\/li>\n<li>Are repeated authentication failures appearing across several services?<\/li>\n<li>Which hosts or resources show the same exception pattern?<\/li>\n<\/ul>\n<p>Workspace architecture should follow the operating model. Centralizing data can simplify cross-resource investigation and standardize alerting. Separating workspaces can make sense when there are strong tenant, regional, regulatory, ownership, or cost-allocation boundaries.<\/p>\n<p>The tradeoff is not merely technical. If every business unit creates isolated workspaces, incident correlation can become cumbersome. If every signal is centralized without governance, a small platform team can inherit excessive cost and broad access responsibilities. The right workspace model balances query scope, administration, data residency, role separation, and chargeback needs.<\/p>\n<p>Retention also requires deliberate design. Frequently queried data may need a hot interactive period, while older data can move into lower-cost retention or archive options where appropriate. The fact that a signal is valuable for one year does not mean it needs one year of high-performance interactive retention.<\/p>\n<h2>Stream through Event Hubs when another system owns the next step<\/h2>\n<p>Event Hubs is useful when Azure telemetry must feed an external or custom processing path. The destination is especially valuable when a SIEM, data platform, or stream processor should receive events continuously without querying Azure Monitor for each record.<\/p>\n<p>Examples include:<\/p>\n<ul>\n<li>forwarding selected Azure logs to an enterprise security platform<\/li>\n<li>feeding a real-time analytics pipeline<\/li>\n<li>integrating cloud telemetry into an established central logging service<\/li>\n<li>allowing multiple independent consumers to process the same event stream<\/li>\n<\/ul>\n<p>Event Hubs should be viewed as an ingestion and transport layer, not as the final answer to retention or investigation. Consumer groups, throughput, downstream checkpoints, failure handling, and the ultimate storage system remain part of the architecture.<\/p>\n<p>A <a href=\"https:\/\/www.examtopics.biz\/blog\/what-is-siem-in-cybersecurity-full-guide-to-security-information-and-event-management\/\">SIEM<\/a> can then correlate Azure events with identity, endpoint, network, SaaS, and on-premises telemetry. That correlation is valuable only if the stream is complete enough for the use case and the downstream platform has a clear ownership and retention model.<\/p>\n<h2>Archive to Storage when durable retention matters more than fast query<\/h2>\n<p>Azure Storage is well suited to audit, archive, backup, or static-analysis scenarios where records must remain available but are not expected to be queried interactively every day.<\/p>\n<p>Long-retention architecture should define the storage account independently from the diagnostic setting. Lifecycle-management policies can move or delete data according to organizational requirements, and immutability features can strengthen protection when audit evidence must not be altered during a retention period.<\/p>\n<p>This is also where cost discipline matters. Keeping years of high-volume telemetry in an interactive analytics tier can be expensive. Moving infrequently accessed records to an archive-oriented destination can preserve evidence while reducing the cost of keeping everything immediately searchable.<\/p>\n<p>The design should state how archived evidence would actually be used. If an incident occurs eighteen months later, who retrieves the data? How is it parsed? How long does restoration or rehydration take? A retention requirement is incomplete until the organization understands the recovery path.<\/p>\n<h2>Separate control-plane, resource, and application evidence<\/h2>\n<p>Azure exposes several telemetry layers that answer different questions.<\/p>\n<p>The <strong>Azure Activity Log<\/strong> records subscription-level control-plane events, such as resource creation, deletion, policy changes, and many administrative operations. It is useful for determining <em>who changed what in Azure Resource Manager<\/em>.<\/p>\n<p><strong>Resource logs<\/strong> are emitted by individual Azure services and expose service-specific operational events. A firewall resource, Key Vault, storage account, or gateway can produce evidence that does not appear in the Activity Log.<\/p>\n<p><strong>Metrics<\/strong> are numeric time-series signals such as latency, throughput, utilization, queue depth, or error rates. They are often the fastest way to detect a condition but may not contain the detail needed for root-cause analysis.<\/p>\n<p><strong>Application and guest telemetry<\/strong> adds still another layer. Application Insights, OpenTelemetry instrumentation, VM agents, syslog, Windows events, and workload-specific logs can explain what happened inside the application or operating system.<\/p>\n<p>A reliable investigation often crosses several of these layers. An Activity Log might show that a rule changed, a resource log might show how the service handled traffic afterward, and application telemetry might show the resulting user impact.<\/p>\n<h2>Design retention, cost, and access together<\/h2>\n<p>A logging strategy should document more than \u201ckeep logs for X days.\u201d Different data sets can have different value curves.<\/p>\n<p>For each important signal, define:<\/p>\n<ul>\n<li>how long it must remain quickly searchable<\/li>\n<li>how long it must be retained in total<\/li>\n<li>whether immutability is required<\/li>\n<li>whether deletion must occur after a regulatory period<\/li>\n<li>whether the data contains sensitive information<\/li>\n<li>which roles may query or administer it<\/li>\n<li>whether another platform requires a real-time stream<\/li>\n<li>how much data volume is expected under normal and incident conditions<\/li>\n<\/ul>\n<p>High-volume telemetry deserves special attention. Network flow records, verbose application traces, and frequently emitted resource logs can dominate ingestion costs. Selective collection is not the same as blind data loss: it means retaining the categories and fields that support known operational, security, and compliance use cases.<\/p>\n<p>Cost controls should not undermine incident response. A design that saves money by dropping the only evidence needed to reconstruct a breach is not efficient; it is incomplete. The goal is to match data value to retention tier and destination.<\/p>\n<h2>Protect the logging plane as evidence infrastructure<\/h2>\n<p>Logs often become most important after an account, application, or network boundary has been compromised. The architecture should therefore reduce the chance that the same identity that changes a workload can also erase its evidence.<\/p>\n<p>Useful controls include Azure RBAC separation, dedicated monitoring resource groups or subscriptions, restricted workspace administration, immutable storage where required, private networking for sensitive destinations, and policy-based deployment of required diagnostic settings.<\/p>\n<p>Central policy can also reduce drift. If a regulated resource type must always export a defined category, that requirement is stronger when it is enforced or audited automatically instead of relying on each deployment team to remember the setting.<\/p>\n<p>The logging environment itself needs monitoring. Failed exports, quota pressure, disabled diagnostic settings, broken stream consumers, and unexpected ingestion drops can all create silent evidence gaps.<\/p>\n<h2>Build an architecture that follows the life of a signal<\/h2>\n<p>A complete Azure logging design can be reviewed as a data path:<\/p>\n<ol>\n<li><strong>Collection:<\/strong> identify the platform, resource, identity, application, and guest signals that matter.<\/li>\n<li><strong>Routing:<\/strong> use diagnostic settings, agents, or service integrations to move those signals.<\/li>\n<li><strong>Analysis:<\/strong> retain the data that operators and security teams need to query in Log Analytics or another analytics platform.<\/li>\n<li><strong>Streaming:<\/strong> forward selected events through Event Hubs when another system needs them continuously.<\/li>\n<li><strong>Archive:<\/strong> preserve long-term evidence in Storage or another compliant repository.<\/li>\n<li><strong>Alerting:<\/strong> define which conditions need automated detection and response.<\/li>\n<li><strong>Governance:<\/strong> assign owners for access, retention, schema changes, cost, and evidence integrity.<\/li>\n<\/ol>\n<p>The most effective architecture is not the one with the most logs. It is the one in which each important signal has a justified route, a known consumer, an appropriate retention model, and enough protection to remain trustworthy when an investigation begins.<\/p>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Azure logging architecture is not a matter of enabling every available diagnostic category. The design problem is deciding which signals matter, where they should be [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[125,29,30,47],"tags":[],"class_list":["post-3019","post","type-post","status-publish","format-standard","hentry","category-exam-az-305","category-certifications","category-cloud-computing","category-microsoft-certifications"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3019","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3019"}],"version-history":[{"count":3,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3019\/revisions"}],"predecessor-version":[{"id":4720,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3019\/revisions\/4720"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}