Azure Free Account, Credits and Spending Caps: Start Learning Without a Surprise Bill

Every cloud-learning story has the same villain: the surprise bill. You signed up “for free”, spun up a VM to follow a tutorial, got distracted, and three weeks later a card statement showed a charge you did not expect. It is the single most common reason people abandon Azure before they have learned anything — not difficulty, but fear of the meter. Azure actually gives you generous free allowances and real cost-control tools, but the free account and the word “cap” mean something narrower than beginners assume, and the one button people search for — “stop all spending when I hit ₹0” — does not exist for most services.

This guide fixes that gap honestly. You will learn what an Azure free account gives you — a time-limited credit, a set of 12-month free services, and a list of always-free services — and what happens at each boundary. Then, the part that actually keeps you safe, you will set up the controls Azure does offer: a budget with cost alerts that email you before you overspend, an action group that can react automatically, and the two places a genuine hard spending cap exists (the Azure Functions Consumption plan’s daily quota, and credit-only offers like Azure for Students with no payment method to charge). We do everything end to end in the portal, the az CLI, and a reusable Bicep template. Read the prose once, then keep the budget-and-cap tables open the day you sign up.

What problem this solves

The pain is concrete and financial. A learner reads “free account” as “Azure will never charge me,” deploys resources that are not in the free tier (a Standard SQL database, a B2ms VM left running overnight, a public IP, some egress), and silently burns the $200 credit in days — or the credit expires after 30 days, the account converts to pay-as-you-go, and the same resources now bill to a real card. Nothing warned them, because by default Azure does not stop your resources when a budget is hit. A budget is an alert, not a switch — and discovering that on a card statement is the worst possible time.

What breaks is trust. People conflate three things — the credit (a prepaid balance), the free service tiers (monthly allowances that exist regardless of credit), and a spending cap (an automatic stop) — and blurred together they leave beginners either over-restricting out of fear or under-protecting out of optimism. This bites every first-time user, every student on a course, and every lead who hands a junior a subscription. The fix is not to avoid Azure — it is twenty minutes on guardrails before you deploy anything. This article is those twenty minutes.

The whole field in one frame:

Learning objectives

By the end of this article you can:

• Open an Azure free account and explain what the $200 credit, the 12-month free services, and the always-free services each include and when each ends.
• Tell the three apart — credit vs free tier vs spending cap — and predict what Azure will (and will not) do at each boundary.
• Create a budget at subscription scope in the portal, with az, and with Bicep, complete with percentage alert thresholds and recipients.
• Wire a budget to an action group for automation, and configure the two real caps Azure has: the Functions Consumption daily quota (dailyMemoryTimeQuota) and the credit-only nature of Azure for Students.
• Read Cost analysis to catch a runaway resource within hours, not weeks.
• Apply a beginner-safe checklist that lets you follow any tutorial without fear of a surprise bill — and tear everything down cleanly afterwards.

Prerequisites & where this fits

You need almost nothing: an email, a phone number, and a payment card (identity verification only — you are not charged while on credit). Be comfortable navigating the Azure portal and willing to run a few az commands in Cloud Shell (no local install). No prior Azure experience is assumed; this is meant to be the first article you read, before you deploy anything that costs money.

This sits at the very start of the cost-and-governance track, upstream of everything: set the guardrails here before you follow Your First Azure Virtual Machine: A Step-by-Step Deployment in Portal, CLI and PowerShell or Your First Azure SQL Database: Create, Configure Firewall Rules and Connect Securely. To know where a budget attaches, understand the Azure Resource Hierarchy Explained: Subscriptions, Resource Groups and Resources — budgets live at subscription, resource-group, or management-group scope. When you outgrow one learning subscription, graduate to Azure FinOps and Cost Management: Controlling Cloud Spend at Scale; and to pick services inside the free allowances, Azure Storage Account Fundamentals: Blobs, Files, Queues and Tables and Azure App Service Plans Demystified: From Free and Basic to Premium v3 and Isolated v2 show which tiers stay cheap.

Core concepts

Four mental models make every later decision obvious.

Credit is a prepaid wallet; free tiers are coupons. The $200 credit is a balance you can spend on almost anything — including paid services — and when it hits zero (or 30 days pass), it is gone. Free service tiers are different: recurring monthly allowances (like 750 hours of a B1S Linux VM or 5 GB of Blob storage) independent of the credit. You can be months past your credit, on pay-as-you-go, and still get the always-free allowances monthly. Beginners burn money by assuming the credit and the free tiers are the same pot. They are not.

A budget notifies; it does not enforce. The most important sentence in this article. An Azure budget is a number plus alert thresholds (“warn me at 50%, 80%, 100% of ₹2,000”); when actual or forecast spend crosses one, Azure sends an alert (and optionally fires an action group). It does not delete resources, stop VMs, or block deployments — out of the box it is a smoke detector, not a sprinkler.

A spending cap is a hard stop, and Azure only has a few. Three places a beginner cares about: while on the free credit, paid resources are blocked until you upgrade; the Functions Consumption plan has a daily quota in GB-seconds (dailyMemoryTimeQuota) that stops the app until midnight UTC once exceeded; and credit-only offers (Azure for Students) have no payment instrument, so exhausted credit means paid usage just stops. Everywhere else, your guardrail is budgets-plus-alerts.

The meter runs on existence, not just use. A stopped-but-not-deallocated VM still bills for its disk and reserved compute; a provisioned SQL database bills whether or not a query runs; a public IP bills hourly while it exists. This is why “I wasn’t even using it” surprises people — Azure charges for allocated resources, so the cheapest resource is the one you deleted, and teardown is a cost control, not just tidiness. (The Glossary repeats each term for lookup.)

What the free account actually includes

“Free account” is three offers stacked together, each with its own clock. The credit (commonly $200, ~₹16,300) spends on nearly any service and expires 30 days after signup. The 12-month free services (compute, storage, databases) are free up to a monthly quantity for the first year, then bill at standard rates. The always-free services — 55+ of them — stay free up to a monthly allowance forever. A slice of the 12-month free list — the trap is always the over-the-allowance usage:

And a slice of the always-free services that keep learning free long after the credit is gone:

Two money-saving notes: the credit and the free tiers are independent clocks (exhaust the $200 and you still get the always-free allowances monthly); and free-tier quantities are per subscription, per month and do not roll over — two B1S VMs all month is not covered by “750 hours” (~1,460 hours needed), so one is free and the second bills.

Budgets vs alerts vs caps — the distinction that protects you

Most “surprise bill” stories trace to confusing these. Side by side — what each does, what it cannot do, where it lives:

The shortcut: budgets + alerts are your general net (they catch everything, but only by telling you), while a hard cap is specific (it truly stops, but exists only for Functions Consumption and credit-only offers). A safe setup uses both, plus the discipline of staying on credit until you are ready to pay. To make an alert behave like a cap, wire it to an action group running a script (a 100% alert firing a runbook that deallocates VMs) — the legitimate “auto-stop” recipe, but it is your automation reacting to a periodic notification, not a built-in cap.

How to read the offer at signup

The offer type determines whether you even have a spending cap to toggle — know your row. The key reading: a standard free account protects you only while the cap is on (i.e. before you upgrade), whereas Azure for Students is credit-only with no card, so its worst case is “things stop,” never “a bill arrives.”

Architecture at a glance

Picture your subscription as a container with a meter on it. Three things flow in: resources you create (each ticking while they exist), the credit wallet (which pays the meter first until empty or 30 days pass), and the free-tier allowances (which zero out the first slice of eligible usage each month). Two rings of protection wrap the meter. The inner ring is the budget: it watches the running total and, at your percentages, sends a cost alert outward — optionally tugging an action group that runs automation — but it only signals, never touching resources. The outer ring is the hard caps, deliberately thin: only the Functions daily quota (stops one app) and the credit-only block (refuses paid usage until you upgrade). Read it left to right — usage enters → credit and free tiers absorb what they can → the budget watches and warns → the two narrow caps stop what they cover → and the only universal stop is you deleting the resource. Your safety comes from combining the sensor (budget) and the narrow caps with the discipline of tearing down.

Real-world scenario

ContosoLearn, a fictional three-person dev shop in Pune, wanted to upskill two juniors without risking the company card. The lead, Priya, did what most people do: created a free account, told the juniors “it’s free for a year,” and moved on. Three weeks later finance flagged a ₹9,400 charge.

The post-mortem was textbook. Following a tutorial, the juniors span up a Standard-tier Azure SQL Database (not the free instance), two B2ms VMs (above the free B1S), and a public IP each, then logged off for the weekend with everything running. The $200 credit covered the first days — which is what made it dangerous, since nothing failed and nothing warned while the meter quietly drained. On day 11 the credit hit zero; because Priya had earlier clicked “Upgrade” to dismiss the expiry banner, the subscription was now pay-as-you-go on the company card, and the still-running resources billed straight through. No budget existed, so no alert fired.

The fix took twenty minutes and cost nothing. Priya rebuilt with guardrails first: a ₹2,000 monthly budget with 80% and 100% alerts to all three; an action group on the 100% alert running an Automation runbook that deallocates every VM tagged env=learning; a Functions daily quota; and a rule that juniors deploy only B1S VMs and the free-tier SQL instance, torn down at end of day. The behavioural change mattered most: because the budget emails at 80%, the team now hears “you are at ₹1,600” with room to react, and a forgotten weekend deployment self-heals via the runbook. Six months on, their largest monthly spend has been ₹70 — a deliberate storage experiment, caught the same day in Cost analysis. Nothing changed except the order of operations: guardrails before the first deployment.

Advantages and disadvantages

The free account plus budgets is the right starting posture, but it has real limits:

The credit + cap is ideal for month one, after which free tiers + a low budget become your posture. The disadvantage to internalise above all is the upgrade trap — the click that removes your only broad hard cap is labelled “keep your resources running.”

Hands-on lab

The centrepiece. We open the account, confirm free status, create a subscription budget with alerts (portal, then az, then Bicep), wire an action group, set the Functions daily cap, validate, and tear it all down. Every step lists the expected result.

Prerequisites for the lab

You need: an email + phone (for the verification code); a payment card (identity verification only — not charged on credit); the Azure portal (https://portal.azure.com); and either Azure Cloud Shell (nothing to install) or a local az login. Bicep is optional and bundled with recent az (check with az bicep version). All of this is free.

Step 1 — Create the free account (portal)

1. Go to https://azure.microsoft.com/free and choose Start free.
2. Sign in with (or create) a Microsoft account. Expected: the signup wizard opens.
3. Enter your profile and verify by phone. Expected: a green check on the phone step.
4. Add a card for identity verification. Expected: Azure states you will not be charged unless you move to pay-as-you-go (a temporary authorisation may appear and reverse).
5. Accept the agreement and finish. Expected: the portal opens with a new subscription (e.g. “Azure subscription 1”) and a banner showing remaining credit and days left.

If the card step fails, it is almost always a virtual/prepaid card or a name/address mismatch — use a standard card matching your profile.

Step 2 — Confirm your free status and credit (portal + CLI)

In the portal, Subscriptions → your subscription → Overview shows a free/trial offer with a remaining-credit figure and expiry date. Now confirm from the CLI — open Cloud Shell (the >_ icon) or run locally:

# Confirm the subscription, then capture its ID for later steps
az account list --query "[].{Name:name, Id:id, State:state, IsDefault:isDefault}" --output table
SUB_ID=$(az account show --query id --output tsv)
echo "Subscription: $SUB_ID"

Expected: one subscription with State = Enabled and IsDefault = True, and $SUB_ID populated.

Step 3 — Create a subscription budget with alerts (portal)

1. In the portal, search for and open Cost Management + Billing, then Cost Management → Budgets.
2. Confirm the scope at the top is your subscription (change it here to scope to a resource group instead).
3. Click + Add. Name: learning-monthly-budget; Reset period: Monthly; leave dates at defaults.
4. Amount: enter a deliberately low number — e.g. ₹2,000 (or $25). Expected: the form shows recent/forecast spend against it.
5. Click Next to Set alerts and add three conditions to your email: Actual > 50%, Actual > 80%, and Forecasted > 100%. (Optionally attach an action group from Step 6.)
6. Create. Expected: the budget appears with a progress bar; you receive an email confirming the alert subscription. (Actual alerts fire on spend so far; Forecasted alerts fire on projected end-of-period spend — use both.)

Step 4 — Create the same budget with az

Budgets are created via az consumption budget — pick an amount, a time period, and thresholds:

# Subscription-scoped monthly budget of 2000 (your billing currency),
# with email alerts at 80% and 100% of ACTUAL cost.
az consumption budget create \
  --budget-name "learning-monthly-budget" \
  --amount 2000 \
  --category Cost \
  --time-grain Monthly \
  --start-date 2026-06-01 \
  --end-date 2027-06-01 \
  --notifications '{
    "Actual_GreaterThan_80_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 80,
      "contactEmails": ["you@example.com"],
      "thresholdType": "Actual"
    },
    "Forecast_GreaterThan_100_Percent": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 100,
      "contactEmails": ["you@example.com"],
      "thresholdType": "Forecasted"
    }
  }'

Expected: a JSON object describing the budget, including amount, timeGrain, and your two notifications. Read it back any time with az consumption budget show --budget-name "learning-monthly-budget" or list all with az consumption budget list -o table. The flags you will actually tune:

Step 5 — Create the budget with Bicep (repeatable)

To recreate the budget across subscriptions, define it as code. Budgets are subscription-scoped, so the template targets the subscription:

targetScope = 'subscription'

param budgetAmount int = 2000
param contactEmails array = [ 'you@example.com' ]
param startDate string = '2026-06-01'   // monthly budgets must start on day 1
param endDate string = '2027-06-01'

resource learningBudget 'Microsoft.Consumption/budgets@2023-11-01' = {
  name: 'learning-monthly-budget'
  properties: {
    category: 'Cost'
    amount: budgetAmount
    timeGrain: 'Monthly'
    timePeriod: {
      startDate: startDate
      endDate: endDate
    }
    notifications: {
      Actual_GreaterThan_80_Percent: {
        enabled: true
        operator: 'GreaterThan'
        threshold: 80
        thresholdType: 'Actual'
        contactEmails: contactEmails
      }
      Forecast_GreaterThan_100_Percent: {
        enabled: true
        operator: 'GreaterThan'
        threshold: 100
        thresholdType: 'Forecasted'
        contactEmails: contactEmails
      }
    }
  }
}

Deploy it at subscription scope and confirm:

# Subscription-scoped deployment ('az deployment sub', not 'group'), then confirm
az deployment sub create --name deploy-learning-budget --location eastus \
  --template-file budget.bicep
az consumption budget show --budget-name "learning-monthly-budget" --output table

Expected: a successful deployment, then the budget echoed back. Re-running the deployment is idempotent — it updates the existing budget rather than erroring.

Step 6 — Wire an action group so a budget can do something

A budget that only emails is fine for learning, but to make a threshold react (notify Teams, trigger a stop-VM runbook) you attach an action group. Create one with an email receiver:

# Create a resource group to hold monitoring objects
az group create --name rg-cost-guardrails --location eastus

# Create an action group with a single email receiver
az monitor action-group create \
  --name ag-budget-alerts \
  --resource-group rg-cost-guardrails \
  --short-name budgetag \
  --action email primaryEmail you@example.com

Expected: JSON describing the action group, including the email receiver. Now reference it from the budget (portal: re-open the budget → Manage alert conditions → select the action group). An action group can invoke more than email:

Step 7 — Set the one real spending cap: the Functions daily quota

The Azure Functions Consumption plan is the rare service with a built-in hard cap: a daily quota in GB-seconds (dailyMemoryTimeQuota) that stops the app until the next UTC day once exceeded — the closest thing to a native “stop spending when I hit a limit.” Create a Consumption Function app (storage + app), then set the cap:

# A storage account is required by Functions
az storage account create \
  --name stfunccap$RANDOM \
  --resource-group rg-cost-guardrails \
  --location eastus \
  --sku Standard_LRS

# Create a Consumption-plan Function app (consumption is implied by --consumption-plan-location)
az functionapp create \
  --name func-cap-demo-$RANDOM \
  --resource-group rg-cost-guardrails \
  --consumption-plan-location eastus \
  --runtime node \
  --functions-version 4 \
  --storage-account <the-storage-account-name-from-above>

Now set the daily quota. Portal path: Function App → Settings → Function runtime settings → Daily Usage Quota (GB-s). Via CLI:

# Set the daily memory-time quota to 50,000 GB-seconds (well within the free grant)
az functionapp update \
  --name <your-function-app> \
  --resource-group rg-cost-guardrails \
  --set dailyMemoryTimeQuota=50000

# Confirm it
az functionapp show --name <your-function-app> --resource-group rg-cost-guardrails \
  --query "dailyMemoryTimeQuota" --output tsv

Expected: the quota value echoes back (e.g. 50000). For reference, the always-free grant is 400,000 GB-s/month; a daily cap below your comfort line guarantees a single runaway loop cannot blow the monthly grant. In Bicep it is one property on the site:

resource functionApp 'Microsoft.Web/sites@2023-12-01' = {
  name: 'func-cap-demo'
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: consumptionPlan.id
    dailyMemoryTimeQuota: 50000   // hard daily GB-s cap; app stops for the day when exceeded
  }
}

What this cap does and does not do: it applies only to Consumption Function apps, metered in GB-seconds (memory × execution time); at the limit the app is stopped for the rest of the UTC day and resets automatically at midnight UTC; and it caps that one Function app only — nothing else.

Step 8 — Validate the whole setup

Step 9 — See where money goes (Cost analysis)

Open Cost Management → Cost analysis, group by Service name, and switch to the Daily view to catch a spike the day it happens. Expected: during free-tier learning this is near zero, dominated by anything outside the free allowance. For an audit trail, schedule a recurring cost export to storage with az costmanagement export create. The habit of looking is the cheapest cost control — noticing early beats every alert.

Step 10 — Tear down (the most important cost control)

Deleting is the only way to stop a resource billing for its existence. Tear down everything you created:

# Delete the monitoring/function resource group and everything in it
az group delete --name rg-cost-guardrails --yes --no-wait

# Delete the budget (budgets are not in a resource group)
az consumption budget delete --budget-name "learning-monthly-budget"

# (Optional) delete any cost export
az costmanagement export delete --name daily-cost-export --scope "/subscriptions/$SUB_ID"

Expected: the resource group and its contents are removed and the budget disappears from the list; confirm in Cost analysis the next day that spend dropped to zero. Leaving the budget in place is harmless and free — many people keep a low standing budget permanently as a tripwire.

Common mistakes & troubleshooting

The failure modes here are financial, not technical, but each has an exact symptom, cause, and fix. Scan the playbook, then read the detail for whichever bit you.

Mistake 4 in depth — “I set a budget, why did it still charge me?”

The most common misunderstanding in Azure cost management. A budget is a notification mechanism: a ₹2,000 budget says “email me at these percentages,” not “stop at ₹2,000” — there is no “stop resources” toggle. For enforcement use Step 6’s pattern (an action group on the 100% alert running a runbook that deallocates resources), accepting it lands minutes-to-hours after the breach, not instantly.

Mistake 8 in depth — stopped vs deallocated

Beginners click “Stop” and assume billing ends. In Azure, Stopped (still allocated) continues to bill; only Stopped (deallocated) releases the compute — and even then the managed disk and any public IP keep billing. The VM Overview status line distinguishes the two. Fix: az vm deallocate, and if you are done, delete the VM, its disks, and its public IP.

Best practices

Crisp, production-grade rules for learners:

• Set the budget before the first deployment, not after the first bill — twenty minutes of guardrails beats a refund request.
• Keep one low standing budget (e.g. ₹2,000/month) on every subscription as a permanent tripwire — it is free.
• Use both Actual and Forecasted alerts: forecast warns before you overspend, actual confirms what happened.
• Stay on the credit/cap until you are ready to pay. Do not click Upgrade to dismiss the expiry banner — that removes your hard cap.
• Prefer free SKUs by default: B1S VMs, F1 Free App Service, the free-tier SQL instance, Consumption Functions. Check the tier before you click Create.
• Set a Functions daily quota so a runaway trigger cannot blow the free grant.
• Tag learning resources (env=learning) so a runbook or query can find and delete them in bulk.
• Glance at Cost analysis daily during active learning, grouped by service, Daily view.
• Deallocate, then delete at the end of each session — the cheapest resource is the deleted one.
• Use a separate subscription per learner/project so one mistake stays scoped to one budget.

Security notes

Cost and security overlap more than beginners expect — a runaway bill and a breach can be the same event (a leaked credential mining crypto on your credit is both).

• Least privilege on the subscription. A learner does not need Owner — grant Contributor, and reserve Cost Management Contributor for whoever manages budgets. The Azure Resource Hierarchy Explained: Subscriptions, Resource Groups and Resources shows where these roles attach.
• Protect the account with MFA. The free account’s Microsoft account is the keys to the wallet; enable MFA so a phished password cannot run up spend.
• Treat an unexpected cost spike as a security signal. Compute or egress you did not start can mean a compromised resource (a public VM with a weak password, an exposed key) — investigate the source, not just the cost.
• Never commit secrets that grant spend. A service-principal secret or storage key in a public repo can be abused to create billable resources. Use Azure Key Vault and managed identities; see Azure Key Vault: Secrets, Keys and Certificates.
• Secure the cost-export storage. If you schedule exports, lock the destination container (private access, RBAC) so billing detail is not world-readable.
• Scope action-group automation carefully. A runbook that can stop/delete resources should have only the rights it needs, tagged and bounded.

Cost & sizing

The point is to keep this near zero, so “sizing” means staying inside the free allowances. The drivers of any learner’s bill:

Right-sizing for a learner: one B1S VM, one free-tier SQL instance, a few GB of storage, and Consumption Functions keep you at ₹0 essentially forever. The classic learning budget is ₹2,000/month — high enough not to nag, low enough to catch a forgotten VM within a day or two. Students on Azure for Students need not even worry (credit-only, no card).

Interview & exam questions

These map to AZ-900 (Azure Fundamentals), which covers cost management, the free account, and the pricing/TCO tools.

1. Difference between the free account’s credit and its free services? The credit is a ~$200 prepaid balance spendable on nearly any service, expiring after 30 days; free services are recurring monthly allowances tied to specific quantities. They are independent — you can exhaust the credit yet keep the always-free allowances each month.

2. Does an Azure budget stop you from spending money? No. A budget notifies you (and can trigger an action group) when spend crosses a threshold, but it does not stop, delete, or throttle resources by default. Enforcement requires wiring it to automation such as a Logic App or runbook.

3. Where does Azure provide a genuine, built-in spending cap? While on the free credit, paid usage is blocked until you upgrade; and the Functions Consumption daily quota (dailyMemoryTimeQuota) stops the app until midnight UTC when exceeded. Credit-only offers also cap by having no payment instrument.

4. What happens when the $200 credit expires or is exhausted? The credit is gone. If you have not upgraded, the cap keeps paid resources blocked; if you upgraded to pay-as-you-go, resources keep running and bill to your card — which is why the “Upgrade” click removes the hard cap.

5. A stopped VM is still charging you. Why? It is Stopped (still allocated), not Stopped (deallocated) — allocated compute keeps billing. Even deallocated, the managed disk and any public IP keep billing, so deleting is the only way to reach ₹0.

6. Difference between an Actual and a Forecasted budget alert? Actual fires when spend so far crosses the percentage; Forecasted fires when projected end-of-period spend crosses it. Forecast warns earlier; use both. Budgets attach at subscription, resource-group, or management-group scope.

7. How would you make a budget actually stop resources at 100%? Attach an action group to the 100% alert that runs a runbook or Logic App to deallocate tagged resources — the legitimate auto-stop pattern, with the caveat that alerts evaluate periodically, so there is latency.

8. Which Azure tools help estimate and track cost, and what is each for? The Pricing Calculator estimates a design before you build; the TCO Calculator compares on-prem versus Azure; Cost analysis shows actual spend; Budgets alert against thresholds.

9. Why is Azure for Students “safer” than a standard free account? It is credit-only and needs no card, so paid usage stops when credit is exhausted — worst case is “things stop,” never “a surprise bill,” removing the upgrade-trap risk.

10. Cheapest possible state for a resource you are done with, and why? Deleted. Azure bills allocated resources by their existence — disks, IPs, databases, allocated VMs all cost money whether used or not — so deletion (not stopping) is the only state that reaches zero. If you see a spike you did not cause, check Cost analysis (Daily, by Service name), then treat it as a possible security event.

Quick check

1. True or false: an Azure budget will automatically stop your resources when you hit the amount.
2. Your $200 credit is gone after 11 days but it has only been a week and a half — has the 30-day clock anything to do with it? What ended your credit?
3. Name the one Azure compute service with a genuine built-in daily spending cap, and the unit it is measured in.
4. You clicked “Upgrade” to remove the expiry banner. What protection did you just lose?
5. A teammate says “I stopped the VM so it’s not costing anything.” Under what condition are they wrong?

Answers

1. False. A budget only alerts (and can trigger an action group); it does not stop, delete, or throttle anything by itself.
2. Spending did, not the 30-day clock. Credit ends when it is either fully spent or 30 days old, whichever comes first — burning it in 11 days means you deployed paid (non-free) resources.
3. Azure Functions on the Consumption plan, via the daily quota in GB-seconds (dailyMemoryTimeQuota); the app stops until midnight UTC when exceeded.
4. The spending cap from the free credit. On pay-as-you-go there is no hard cap — resources keep running and bill to your card; budgets/alerts are now your only guardrail.
5. They are wrong if the VM is Stopped but not Stopped (deallocated) — allocated compute still bills, and even deallocated its disk and public IP keep billing, so only deletion reaches ₹0.

Glossary

• Free account — The signup offer combining a time-limited credit, 12-month free services, and always-free services.
• Credit — A prepaid balance (~$200 / ₹16,300) spendable on nearly any service, expiring 30 days after signup.
• 12-month free services — Services free up to a stated monthly quantity for the first year (e.g. 750 hrs B1S VM).
• Always-free services — 55+ services with a perpetual monthly free allowance (e.g. 1M Functions requests).
• Budget — A Cost Management threshold with alert conditions; notifies but does not enforce.
• Action group — A reusable set of notification/automation targets (email, webhook, Logic App, runbook) a budget alert can trigger.
• Spending cap — A genuine automatic hard stop; on Azure, the free credit and the Functions daily quota.
• dailyMemoryTimeQuota — The Function-app property setting the daily GB-seconds (memory × time) cap on Consumption.
• Pay-as-you-go (PAYG) — The standard billed-for-usage plan a free account converts to on upgrade.
• Cost analysis — The dashboard showing actual spend, sliceable by service, resource, and time.
• Deallocated — A VM state that releases (and stops billing) the compute, unlike merely “Stopped”.
• Azure for Students — A credit-only offer (no card) for verified students; effectively self-capping.

Next steps

• With guardrails in place, deploy something safely (B1S SKU): Your First Azure Virtual Machine: A Step-by-Step Deployment in Portal, CLI and PowerShell.
• Understand where a budget attaches and how scopes nest: Azure Resource Hierarchy Explained: Subscriptions, Resource Groups and Resources.
• Pick free-friendly compute tiers: Azure App Service Plans Demystified: From Free and Basic to Premium v3 and Isolated v2.
• Try a free-tier database: Your First Azure SQL Database: Create, Configure Firewall Rules and Connect Securely.
• Scale cost discipline org-wide: Azure FinOps and Cost Management: Controlling Cloud Spend at Scale.