The invoice as telemetry
Class One ended with a manager asking why the invoice was three times the estimate. The answer begins with usage: a running VM, stored data, and collected logs can all add charges. Cost Management groups those charges so you can see which service and resource produced them. It is useful evidence, but its reports can lag actual usage; it is not a live safety switch.
- FinOps
- The practice of treating cloud spend as an engineering signal with named owners — measured continuously, attributed to teams, and acted on weekly — rather than as a finance document reviewed after the money is gone.
The tooling is Microsoft Cost Management, and it is free, on by default, and sitting in the portal under every subscription. It answers three questions in ascending order of maturity: what did we spend (cost analysis, §2), will we be told before it goes wrong (budgets and alerts, §3), and who does each dollar belong to (tags, §5). One honest caveat before you trust it in a meeting: cost data is not real-time — usage takes several hours to a day to land in the reports, so this morning's experiment shows up tomorrow, not at lunch.1 That lag is why §3's alerts include a forecast, and why cost review is a weekly habit, not a live dashboard you stare at.
Here is the career note, stated once: nearly every engineer you will compete with can deploy infrastructure, and almost none of them can read an invoice. The person who walks into the monthly review able to say which line grew, why, and what it buys is usually the most senior-sounding person in the room, regardless of their title — because money is the one telemetry stream leadership is fluent in.
Cost analysis — group, filter, find the suspects
Cost analysis is the query surface over the invoice, and using it is a two-move pattern you already know from Class Twenty-Nine's KQL: group, then filter. Group the month by service to see what kind of thing costs money; regroup by resource group to see which application it belongs to; regroup by tag to see which team owns it; then filter into the biggest bar and repeat one level down. Three groupings and two filters take you from "the bill is $9,400" to "the storefront's log ingestion doubled on the 12th" in about four minutes — and the 12th, you may recall, is a deploy you can look up in Git.
Use the four examples below as places to investigate, not as a claim that every subscription has the same waste:
| Suspect | How it hides | The fix |
|---|---|---|
| Orphaned resources | Deleting a VM does not delete its disks or public IP; they bill on, attached to nothing, owned by nobody. Invisible unless you go looking. | A monthly sweep for unattached disks and unassociated IPs; snapshot, confirm, delete. Advisor lists them for you. |
| Oversized compute | The VM was sized for a guess in week one and never revisited; it idles at 8% CPU with a straight face. | Right-size against the Class 28 metrics you already collect. Advisor again suggests candidates. |
| Non-production running 24/7 | Dev and test environments bill nights, weekends, and holidays for work done nine to five. Two-thirds of their hours serve nobody. | Auto-shutdown schedules, or — the Class 27 pattern — platforms that scale to zero on their own. |
| Data movement & ingestion | Egress charges and log ingestion grow with traffic and verbosity, not with any deploy decision anyone remembers making. | Class 28's warning, now with a price on it: sample, filter at source, and cap what nobody queries. |
Actual and amortized — the same money, two lenses
Cost analysis offers a toggle most people never touch and then misread the first time they do: actual cost against amortized cost. Actual shows money the way the bank does — on the day it leaves. Buy a one-year reservation and actual cost draws a cliff: one large charge on the purchase date, then months that look suspiciously cheap, because the compute those months burned was paid for in advance. Amortized undoes the accounting illusion. It spreads the reservation's up-front cost evenly across the term and books each day's slice against the resource that actually consumed it. For the question what did the storefront cost to run in March, amortized is the honest number; for the question what left our account in March, actual is. And group by amortized and a third thing surfaces that actual hides entirely: unused reservation — the committed hours you never filled, the §4 silence finally given a line of its own. If you buy a commitment, you read amortized from then on, or you are flying on the wrong instrument.
Rightsizing without the guess
Azure Advisor may recommend shutting down or resizing an underused VM and show an estimated saving. Its shutdown recommendation uses CPU and outbound network, not memory, so a quiet database may still need the RAM it uses. Resize recommendations consider memory as well, but neither recommendation knows every application requirement, future traffic peak, or recovery obligation. Check a representative history of CPU, memory, network, and business use, then test the change and monitor the result. Advisor's estimate is a candidate for investigation, not guaranteed savings.
Notice what the suspects have in common: none of them is a pricing problem. They are all attention problems — resources nobody looked at after the week they were created. Which is why the fix for all four is the same fix wearing different clothes: a recurring review with a named owner, the §3 alerts to summon it early, and the §5 tags so the findings land on the right desk.
Budgets and alerts — the shout before the bill
A budget in Azure is an alert rule wearing a finance costume, and the single most-tested fact about it is what it does not do: a budget never stops anything. Crossing it deallocates no VM, throttles no service, blocks no deployment. It notifies the people you name, at the thresholds you set, and that is all.2 First encounter, this reads as a design flaw. It is the opposite: the storefront going dark at 3am because November traffic pushed a counter past an arbitrary number would be a self-inflicted outage — Class Two's whole argument for elasticity, cancelled by a spreadsheet cell. Azure declines to build that footgun; the shout is the feature.
A budget stops the surprise, not the spend.
Two threshold types help you notice a problem. Actual compares recorded spend with the budget. Forecasted compares Microsoft's projection for the period with the budget. For a practice subscription, try actual alerts at 80% and 100% and a forecasted alert at 100%, sent to an email address you check. Confirm which subscription or resource group the budget covers. Because cost data and projections can lag, neither alert guarantees notice before an overrun. If a team needs to stop spending, it must separately design and test automation for resources that are safe to shut down; a budget by itself does not do that.
The alert you did not have to configure
A budget tests a threshold you chose. Anomaly detection looks for unusual cost changes compared with recent history. If the feature is available for your account, configure an anomaly alert and a recipient, then investigate any message in Cost analysis. An unusual change may come from a legitimate launch or a mistake. Detection depends on billing data arriving and a recognizable pattern, so keep reviewing the cost report even when no alert arrives.
Play it through
Three minutes, one dev VM and an illustrative compute counter. Schedule deallocation, then set a budget notification. The budget does not stop spend, and disks can still bill after the VM stops.
Commitments — reservations and savings plans, honestly
Everything so far cuts waste. The other lever cuts price: commit to Microsoft for one or three years, and the meter rate drops — steeply. A reservation commits you to a specific shape of usage (this VM size family, in this region, or a set capacity of SQL or storage) for headline discounts that reach into the 60–70% range against pay-as-you-go. A savings plan for compute commits you to an hourly dollar amount — "we will spend at least $10 an hour on compute" — and applies a smaller discount across nearly any compute, any family, any region. Two facts keep engineers out of trouble here. First, both are billing constructs: a reservation discounts matching usage, it does not deploy, guarantee, or hold hardware for anything.3 Second, both are use-it-or-lose-it, per hour: an hour in which nothing matches the commitment is an hour you paid for silence.
| Pay-as-you-go | Savings plan | Reservation | |
|---|---|---|---|
| You commit to | Nothing | $/hour of compute, 1 or 3 years | A resource shape, 1 or 3 years |
| Discount depth | None — this is the list price | Meaningful | Deepest |
| Flexibility | Total | High — follows your compute across families and regions | Low — the workload must keep matching the shape you named |
| Right for | Spikes, experiments, anything that might not exist next quarter | A compute floor that is steady in dollars but shifting in shape | The workload you would bet a year's roadmap on staying put |
The honest comparison, then, is not "which discount is biggest" but "how certain are you." The method: chart three months of usage and find the flat floor — the spend that was there every hour of every day. Reserve the most stable, specific slice of that floor; lay a savings plan over the steady-in-dollars, shifting-in-shape remainder; leave everything spiky on pay-as-you-go, because elasticity was the point of Class Two and a commitment is elasticity's opposite. And commit after the cleanup, never before: a reservation bought against §2's waste locks in the price of the mistake. Azure will even do the arithmetic for you — Advisor and the reservation blade recommend purchases from your own usage history, which beats any vendor slide claiming 72%.
Two more levers: Hybrid Benefit and Spot
Commitments discount the rate. Two other levers change what you are billed for at all. Azure Hybrid Benefit is the one finance forgets it has already paid for: if the company owns Windows Server or SQL Server licences with Software Assurance, you can carry them into Azure and stop renting the operating system by the hour — you pay the bare compute rate, near the Linux price, and the Windows tax comes off. On a fleet of Windows VMs that is often thirty to forty percent, it stacks on top of a reservation, and it is a checkbox and a licence-count promise rather than a migration. The trap is honesty about entitlement: the benefit is an attestation that you hold enough licences, and switching it on for more cores than you actually own is a licensing finding waiting for an audit, not a saving.
Spot VMs are the opposite temperament — the clearance rack of Azure capacity, discounted as steeply as ninety percent because the deal comes with an eviction notice. When Azure wants the hardware back, or the going rate passes the cap you set, your VM is deallocated on roughly thirty seconds' warning, with no SLA to appeal to. That makes Spot wrong for the storefront and right for anything that can die and be retried without a customer noticing: batch jobs, nightly renders, CI runners, the fault-tolerant slice of a Class Twenty-Seven container pool. The rule of thumb writes itself — reservations for what must always run, Spot for what may run, pay-as-you-go for what must run now but not for long.
Tags — the currency of accountability
Every mechanism in this class eventually collides with the same question: whose is this? Cost analysis can group by resource group, but resource groups answer "which application", not "which budget line". The answer is one you met in Class Seven and have been half-using since: tags — and in cost work they stop being metadata and become the join key between the invoice and the org chart. cost-center, env, owner: three keys, consistently applied, turn "the bill is $9,400" into a per-team statement finance can post against real budgets.
The failure mode is voluntary tagging. Ask forty stores' worth of engineers to please remember the tags, and within a quarter you have CostCenter, cost_centre, and a plurality of resources with nothing at all — and an untagged dollar is an unattributable dollar. The fix is Class Eight, reapplied: Azure Policy enforces the taxonomy. One subtlety does the most work: tags are not inherited — a tag on the resource group does not flow to the resources inside it — so the standard pattern is a policy with a modify effect that copies cost-center from the group onto every resource in it automatically. Engineers tag one object, the group, at creation; policy does the rest; and deny is reserved for exactly one gate, requiring the tag on new resource groups. Denying every untagged resource sounds rigorous and mostly teaches people to type tbd.
One habit separates teams that report from teams that screenshot: scheduled exports. Cost Management will drop the full usage detail into a storage account on a daily cadence — increasingly in FOCUS, the open cross-cloud billing format — and that exported data is where finance tooling, the warehouse, and the monthly one-pager actually live. The portal blade is for the afternoon of the autopsy; the export is the reporting cadence.
The loop: inform, optimise, operate
Everything in this class is one turn of a cycle the FinOps discipline names in three words, and the words are worth holding because they order the work. Inform comes first and cannot be skipped: no team optimises a bill it cannot see or attribute, so the visibility and tagging of §2 and §5 are the ground everything else stands on. Optimise is the acting phase — the waste sweep, the rightsizing, the commitments, the two price levers above. Operate is the unglamorous phase that decides whether any of it lasts: the budgets that shout, the policy that holds the taxonomy, the monthly one-pager, the named owner who runs the review whether or not the bill jumped. The sequence is the lesson. A team that buys reservations before it can attribute spend has optimised in the dark; a team that informs and optimises once, then never operates, watches the savings erode back to the pilot-month number inside two quarters.
- Inform
- See it and own it. Cost analysis grouped down to a named resource, tags held by policy, showback before chargeback. Nothing downstream works until this does.
- Optimise
- Act on what you can now see. Sweep the orphans, right-size the idle, retire always-on non-production, then commit to the flat floor and fit Hybrid Benefit and Spot where each belongs.
- Operate
- Make it a habit, not an event. A budget that shouts, a policy that holds, a weekly read and a monthly page — because the number stays down only while someone is keeping it down.
The loop is also the answer to a question asked in every senior interview and every promotion case: how do you keep cost down after the cleanup? The junior answer names a tool. The answer that lands names the cadence — who reads the bill on Monday, which policy holds the tags, what meeting the anomaly goes to — because leadership has watched one-time savings evaporate before, and is really asking whether you understand that this is an operating discipline, not a project with an end date.
Savings are a state you maintain, not a task you finish.
The 3× invoice, autopsied at last
The pilot-month invoice that arrived at three times the estimate never got a real autopsy — the team was too new to run one. This class runs it. Cost analysis, grouped by service, then by resource group, finds the money in an afternoon: the pilot's "temporary" VMs — sized generously for a load test that ended in week two — ran twenty-four hours a day for a month; the load test's disks and public IPs outlived their VMs and were still billing, $660 of Figure 1's bar; and Log Analytics, configured in the enthusiasm of Class Twenty-Eight with verbose collection, was ingesting debug logs nobody had ever queried. Not one line of the overage was Azure mispricing anything. Every line was a decision nobody revisited — which is what the manager's question actually meant, and the answer she was owed: cloud is cheaper when someone runs it like a utility; nobody was yet.
The findings become machinery the same week. Budgets on the subscription and on each application's resource group — actual at 80 and 100 percent, forecast at 100 — each routed to the owning team's action group. Auto-shutdown on every dev VM; the orphan sweep on the monthly calendar; ingestion trimmed at the Class Twenty-Eight valves. Policy inherits cost-center from resource groups and requires it on new ones. And one page goes to the manager monthly: spend by team, trend against last month, one anomaly explained, one action taken. The first such report shows the bill down 38 percent from the pilot peak — and for the first time since Class One, she forwards it with a different one-liner: "keep sending these."
The official pages, and a CAMPUX overview
Explore and analyze costs with cost analysis
learn.microsoft.com/azure/cost-management-billing/costs/quick-acm-cost-analysis
What are Azure Reservations?
learn.microsoft.com/azure/cost-management-billing/reservations/save-compute-costs-reservations
Read your own bill, then make it shout
You scheduled the shutdown and the alert above. Now read your own bill and make it shout for real. Run the §2 group-and-filter drill on your own subscription, check what Advisor already knows about your waste, and leave a budget behind that will out-shout any future surprise.
In the portal, open your subscription → Cost Management → Cost analysis. Set the period to the current month.
What to notice: a new or nearly empty subscription may show little data. Cost reports can lag usage, and a deleted VM may leave billable disks or network resources behind. If you cannot see the view, check your billing and Cost Management permissions.Little or no spend yet? Run the same drill on this supplied month instead. It is fictional and small on purpose:
Service Resource group Resource Cost Virtual Machines rg-shop-test vm-legacy-till $41.60 Storage rg-shop-test disk-vm-legacy-os $6.14 Container Apps rg-shop-prod ca-storefront $11.20 Log Analytics rg-shop-prod campux-logs $9.75 Bandwidth rg-shop-prod (outbound data) $2.31 Total $71.00Your sentence: group by service, then by resource group, then name the biggest line with its owner. One answer: "the test VM in rg-shop-test is 59% of the month, and its disk keeps billing even when the VM is stopped". Then set the budget below at a figure just above $71.Run the drill: group by Service name, then regroup by Resource group, then click into the largest bar and group by Resource.
What to notice: three groupings take you from a total to a named resource. Say the finding as a sentence with an owner in it — "the Class 27 container environment is 60% of my spend" — because that sentence is the entire skill.Open Advisor → Cost and read its recommendations for your subscription.
What to notice: Advisor may show no recommendations if there is too little history or no eligible resource. If it suggests a VM shutdown, check the workload and memory use before acting: that recommendation uses CPU and outbound network, not memory.Create the shout: Cost Management → Budgets → Add. Monthly budget, an amount just above your normal spend (say $10 for a lab subscription); alert conditions at Actual 80%, Actual 100%, and Forecasted 100%, to your email.
Verify: confirm the budget scope, amount, notification email or action group, and saved conditions. It does not stop spending, and delayed cost data means the message may arrive after the threshold is crossed. Choose a realistic amount and an owner who will respond.
Zoom out: cost is an engineering control, and controls need a loop
You can set a budget and read the bill. Now reason about what cost does as a system, because spend that is frictionless to grow will grow until something forces a reckoning.
Cloud spend is frictionless to grow, so it grows, so a shock invoice triggers a clampdown, so teams under-provision and something breaks — then it grows again. What balancing control shouts before the bill does?
Every cost line is a decision someone made and nobody revisited; the bill is coupled to choices, not to Azure mispricing anything.
A budget shouts but never stops spend; the real limit is the automation — auto-shutdown, lifecycle rules, rightsizing — that acts without waiting for a human.
Verbose logging, an orphaned disk, an idle test VM — each is a small convenience that compounds into a line item; savings are a habit, not an event.
Cost anyone can eyeball at ten resources is unattributable at a thousand without tags enforced by policy; you cannot manage what you cannot attribute.
The engineer who ships is asked "what did it cost?" The engineer who gets promoted is asked "and which decision, that nobody revisited, made it that?" — and could name it.
A line item with an owner
The monthly Azure bill spikes and a VP wants to know why by lunch. You open Cost Analysis, group by tag, and find the runaway resource in minutes — then set a budget with an alert so the next surprise arrives as an email while there is still time to act. You turn "the cloud is expensive" from a complaint into a line item with an owner.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — a reservation is a billing construct, and both halves of that sentence bite. It deploys nothing (C), and — the one that surprises people in incidents — it holds no hardware: capacity guarantees are a separate product, and a region can run short of a size you hold reservations for. D is the expensive misunderstanding: the discount is use-it-or-lose-it per hour, so an hour with no matching usage is an hour of commitment paid for silence — nothing banks, nothing rolls over. That is why §4's method starts from the flat floor of measured usage rather than from the discount percentage on the slide: the 60-odd percent is real, but only for hours in which the matching workload actually runs. Buy certainty you have, not certainty you hope for.
C — the budget shouts; it never touches the workload. Picture the alternative and the design makes itself: it is mid-November — Campux's peak — and the traffic that pushed spend past $5,000 is revenue. A budget that behaved like A, B, or D would convert the best sales day of the year into an outage, triggered by a number typed in July. Azure refuses to build that, so enforcement is never implicit; if spend truly must stop, you wire the alert to automation you wrote, aimed at resources you chose in advance. The exam and interview shape is the flat question "do Azure budgets stop spending?" — and the two-word answer, no, notify, is one the majority of candidates get wrong in the confident direction.
Orphans, always-on non-production, and unrevisited ingestion. The rejects both smuggle in the same wrong idea — that the bill is something done to you. Meter rates do not drift mid-month; the published price is the published price, and reaching for "Azure must have raised rates" delays the real autopsy by a week. And an untagged resource bills at exactly the normal rate — the penalty is not on the invoice, it is in the meeting: the dollar is unattributable, so nobody owns it, so it recurs. Notice the pattern in the three correct answers: each is a decision that was reasonable the day it was made and simply never revisited. Waste is not made of mistakes; it is made of expired decisions.
# memo: Q3 cost reduction plan — platform team
1. Sweep and delete unattached disks and idle public
IPs monthly, after snapshot review.
2. Auto-shutdown schedules on all dev/test VMs:
off 19:00–07:00 and weekends.
3. Purchase 3-year reserved instances for the dev/test
VMs to discount their remaining hours.
4. Budgets per resource group: actual 80%/100% and
forecasted 100%, routed to each owning team.
Line three — and the memo defeats itself. Line two just cut the dev VMs to roughly a third of the week's hours; line three then commits to paying for those VMs' shape every hour for three years. A reservation's discount only lands on hours with matching usage, so two-thirds of this commitment buys silence — arithmetic that routinely turns a "60% discount" into spending more than pay-as-you-go. The deeper error is §4's rule reversed: commitments are for the flat floor that survives cleanup, and dev/test that shuts down nightly is the least reservation-shaped workload in the estate. Had this memo shipped, Q4's cost review would open with an unused-reservation line nobody can delete, three years long.
The distractors are the plan working: a snapshot-first orphan sweep is exactly the §2 procedure (A), shutdown schedules have no bearing on SLA (B — that objection is invented), and line four is §3 verbatim (D). Read cost memos the way you read the Class 31 config: the wrong line is usually the one applying a good tool to the wrong workload.
Start with the ledger, not the tags. Chargeback fails when the taxonomy is designed from the org chart's ambitions instead of finance's actual ledger — so the first meeting is asking finance what lines they post to, and the answer becomes a closed list of valid cost-center values, published somewhere versioned. Three keys suffice: cost-center (finance's join key, from the closed list), env, and owner. Every key beyond what someone will actually query is future inconsistency: a taxonomy's failure rate rises with its ambition.
Then make the tags involuntary. Humans tag the resource group once, at creation — policy does everything else. One deny policy requires a valid cost-center on new resource groups (deny at the group level is cheap; nobody creates groups mid-incident); one modify policy inherits the tag from group to every resource inside, because tags do not flow downhill on their own and hand-tagging ten thousand resources is a project that never finishes. Existing estate: a remediation task backfills, and the leftovers get one afternoon of archaeology. What you never do is deny individual untagged resources — that gate teaches engineers to type garbage values under deadline, and a wrong tag is worse than a missing one because nobody knows to fix it.
The warnings buy your credibility. First: run one quarter of showback — reports without money moving — before chargeback, because the first report always contains attribution surprises, and you want those argued over a PDF, not an invoice. Second: some spend is genuinely shared — networking, the Class 28 workspace, Defender — so agree the allocation rule for it up front; the alternative is every team disputing the remainder monthly. Third: report the untagged percentage as its own line and drive it toward zero in the open. The sentence for finance: tags make the invoice attributable; policy makes the tags reliable; and the first quarter is for finding out where we were wrong quietly.
Concede the discount before you argue the shape. The 72% is not vendor fiction — deep commitment discounts on the right workload are the single largest price lever in the cloud, and leadership is right to want them. What the slide omits is the condition: the discount pays out only for hours in which usage matches the committed shape, and it is use-it-or-lose-it hour by hour. "Up to 72% off" is accurate; "off usage identical in size, family, and region for thirty-six consecutive months" is the clause. So the response is not "no" — it is "yes, on the slice of the estate that can honestly sign that clause."
Then show them this bootcamp's own history as the risk register. In thirty-two classes Campux has moved workloads from VMs toward containers that scale to zero, resized machines, and changed regions for private connectivity — each move a good decision, and each one would have stranded a three-year reservation bought the week before it. Estates that are still improving are precisely the estates that should commit narrowly. The method, from §4: chart ninety days of usage; reserve only the flat floor that survived the §2 cleanup (commitments bought before cleanup lock in the price of the waste); lay a savings plan over the steady-but-shifting middle, trading discount depth for the flexibility to keep re-architecting; leave the spikes on pay-as-you-go. Advisor's purchase recommendations, computed from your own usage, are the honest version of the slide.
Close with the number they actually want. Leadership asked for savings, not for reservations — reservations were just the slide they saw. So return a portfolio with expected savings attached: cleanup already banked (free, no commitment), a narrow reservation on the proven floor, a savings plan over the middle, reviewed quarterly as the estate settles — typically most of the slide's promise at a fraction of its risk. The closing sentence: the discount is rent we collect on predictability — we should sell Microsoft exactly as much predictability as we truly have, and not a dollar more.
Five things worth carrying out of this class
- The invoice is telemetry — every meter emits hourly, Cost Management charts it for free, and the data lags by hours to a day, which is why the forecast alert and the weekly review exist.
- Cost analysis is group-then-filter, and the waste hides in four usual suspects: orphaned resources, oversized compute, always-on non-production, and unrevisited ingestion. All four are expired decisions, not pricing problems.
- Budgets notify; they never stop anything — by design, because implicit enforcement is an outage waiting for a peak. Actual 80/100, forecasted 100, routed to the owning team's action group.
- Commitments are billing constructs, use-it-or-lose-it per hour: reservations buy the deepest discount on a fixed shape, savings plans a smaller one on flexible compute. Commit to the measured flat floor, after cleanup, never to the slide.
- Tags are the join key between the invoice and the org chart: a closed cost-center list, inherited from resource groups by policy — because tags do not flow downhill on their own — with deny reserved for the one gate at group creation.
- The lag between usage and its appearance in cost reports varies by service and billing account type — figure hours for most meters, up to a day or two for some, with the month's final invoice reconciling small differences. Treat any same-day cost number as provisional, and treat the specific dollar figures in this class's examples the same way you treat all of our numbers: the amounts are illustrative; the proportions and the failure modes are the settled part. ↩
- One genuine exception exists: certain subscription types with hard caps — notably some free-tier and credit-based subscriptions like Visual Studio benefits — can suspend when credit runs out. On the pay-as-you-go and enterprise subscriptions you will run at work, the statement holds without asterisk: budgets notify, nothing more. ↩
- Reservation mechanics beyond this class's scope, worth knowing exist: instance-size flexibility lets a reservation's discount cover other sizes within the same VM family; reservations can be scoped to a subscription, a resource group, or shared across the billing account; and exchanges and refunds are possible within limits Microsoft has changed before and will change again. Check the current exchange policy before you rely on it in a purchase decision — it is the fine print that determines how reversible your commitment really is. ↩
Set a budget and an alert, read a cost report, and find the three biggest savings on a real bill.
Play the lesson above to stamp this class.