LEARN. PRACTICE. GROW.1. Look for the right record
An application stops working after a configuration change. The Activity Log helps investigate Azure control-plane operations, including changes made through Resource Manager. Filter by resource, time, and operation, and confirm the available detail. The existence of that record does not establish that every data read or application request appears there. Before production handover, define the questions support needs to answer and where the corresponding signals are collected. Insufficient retention or an unconfigured source can prevent later investigation. In this exercise, clearly distinguish an administrative change from a failed business request rather than treating all logs as interchangeable evidence.
2. Correlate application and platform
Application Insights, within Azure Monitor, supports application performance and behavior analysis with suitable telemetry. One example is relating failed requests to dependency calls in an instrumented API. Resource Health provides an assessment of specific resources such as a VM. These signals answer complementary questions. An instance’s health does not prove that a business report was produced correctly, just as an application exception does not establish a general platform failure. During an incident, record the timeline, affected resource, and observed impact. The manager coordinates owners and communication; technical hypotheses need evidence rather than temporal coincidence alone.
3. Read the state that determines consumption
A VM was shut down inside the operating system and appears as Stopped (Allocated). The team no longer runs the batch, but compute resources remain allocated and instance usage remains billed. Deallocated is different: instance compute usage stops being billed, although disks and other resources may retain charges. Do not confuse application activity with billable allocation. Before changing state, check availability requirements, dependencies, and restart capability. This lesson’s examples exclude usage commitments and use supplied fictional costs. A real decision needs the applicable configuration and commercial conditions alongside operational state. The exercise is a reasoning aid and does not execute a shutdown or deallocation.
4. Compare quantity, time, and retained costs
Use a teaching model: compute costs two units per billed hour and storage costs thirty units per month. For sixty billed hours, the total is 60 × 2 + 30 = 150. If compute remains billed for 720 hours, the total becomes 1470. The difference of 1320 comes exclusively from the assumed hours; it is not an Azure savings forecast. If storage rises to fifty units, the first total becomes 170. This small exercise requires separating rate, quantity, and retained cost. In a FinOps meeting, confirm the usage window and service requirements before converting an opportunity into a budget commitment.
5. Choose how capacity and data change
Moving from two to four identical instances is scale out; increasing CPU or memory per instance is scale up. Neither choice alone demonstrates that the application distributes work correctly or that a shared dependency can handle the load. Record the constraint motivating the change and how it will be observed. A large-volume migration faces a different limit: available bandwidth. If the window cannot accommodate transferring tens of terabytes and physical shipping is approved, evaluate Azure Data Box. Confirm model, availability, logistics, and validation without assuming universal capacity or guaranteed timing. A copy tool over the same connection does not remove the physical limit.
6. Retain responsibility in managed services
Moving to PaaS reduces tasks involving the underlying platform, but a team developing an application still handles code, data, and configuration within its responsibility. In a SaaS application, customer owners still make decisions about their data and access. Serverless also requires observation and failure handling: compute resources exist even when server management is abstracted. Azure Functions offers different hosting options; do not infer a universal price or billing rule from the serverless name alone. Finish the lesson by connecting service model, operational evidence, and cost assumptions. A usable delivery needs clear owners and confirmation that the business task works.
In the fictional model, 60 hours at two units plus thirty storage units total 150. Retaining 720 billed hours would raise the total to 1470 even if application activity were low.
Common pitfalls
Treating Stopped (Allocated) as Deallocated, adding hours to costs, assuming all logs contain the same evidence, or treating PaaS as removing application responsibility.
Related topics: Azure Monitor and Resource Health · Consumption and capacity models · Shared responsibility
Choose evidence according to the question, confirm billable state, and keep responsibilities explicit when the provider takes over platform management.
Reference: Activity Log in Azure Monitor · AZ-900 skills measured July 20, 2026