Azure cloud security best practices for beginners
The security that protects a beginner's Azure account is boring and high-impact — and it is nothing like the tooling the ads sell you.
Start with MFA, least-privilege roles, managed identities, controlled public access and security monitoring. These reduce common risks; they do not prevent every attack. Security defaults and foundational Defender CSPM are available without extra license cost, while Conditional Access, private endpoints, logging and some Key Vault operations can require licenses or incur usage charges.
I have watched more beginner Azure accounts get burned than I can count, and the cause is never something clever. Nobody gets hit by a nation-state zero-day on their first storage account. They get hit because MFA was off and a password leaked, or because a connection string sat in a public GitHub repo, or because a storage container was set to "anonymous read" for five minutes to make a demo work and then forgotten. The fixes are equally unglamorous. This is the whole list, grounded in the one idea that makes sense of all of it.
Start with who owns what
Before any checklist, one concept: the shared-responsibility model. Microsoft secures the things underneath you — the physical datacenter, the hypervisor, the network fabric, the host operating system of the managed services. You secure the things you put on top — your data, your identities, your access rules, your network exposure, your keys. Microsoft will never leak your storage account for you. You will, if you configure it wrong.
Everything below is in your half of that split. That is deliberate. There is no point worrying about the datacenter's locks when your own front door is propped open. So the whole list is the set of doors that are yours to close.
The cloud provider secures the cloud. You secure what you run in it. Every practice here is on your side of that line — which is exactly the side a certification tests you on and an interviewer expects you to have actually configured, not just recognized on a multiple-choice question.
The checklist, at a glance
Here is the whole thing in one place: the practice, the specific attack it kills, and where in Azure you set it. Read it, then take the paragraphs below for the why and the one-line how.
| Practice | Risk it kills | Where in Azure |
|---|---|---|
| MFA on every account | Stolen / reused passwords — the #1 cause of account takeover | Microsoft Entra ID → Security → per-user MFA or a Conditional Access policy |
| Conditional Access | Logins from impossible locations, unmanaged devices, legacy protocols | Entra ID → Protection → Conditional Access |
| Least-privilege RBAC | One compromised account able to delete or read everything | Subscription / resource group → Access control (IAM) → role assignments |
| Managed identities | Keys and connection strings living in code and config | Resource → Identity → System-assigned, then grant it an RBAC role |
| No public storage / DB by default | Anonymous internet reads of your data | Storage account → Networking + "allow blob anonymous access" = off |
| NSGs + private endpoints | Databases and VMs exposed to the whole internet | Virtual network → NSG rules; resource → Private endpoint |
| Key Vault for secrets | Leaked API keys in Git history | Azure Key Vault → Secrets, read at runtime via managed identity |
| Logging & monitoring on | A breach you never notice until it is far too late | Azure Monitor + diagnostic settings → Log Analytics workspace |
| Budget alert (as breach signal) | Crypto-mining on a hijacked account draining your card | Cost Management → Budgets → alert at a low threshold |
1. MFA on everything, starting with you
What: protect user and administrator sign-ins with MFA. How: use security defaults for a basic free tenant configuration, or Conditional Access for granular policies when you have the required licensing. Conditional Access generally requires Entra ID P1; risk-based policies require P2. Test policies and emergency access before enforcing changes.
If you do exactly one thing after reading this, do this one. No other control matters if an attacker can simply log in as you.
2. Conditional Access — MFA with judgment
What: policies that decide when to demand MFA or block a login based on signals — location, device, risk. Why: it lets you block the obviously-bad (sign-ins from a country you have never been to, ancient protocols that skip MFA entirely) without punishing normal use. How: Entra ID → Protection → Conditional Access, start with a policy that blocks legacy authentication and requires MFA for admins. Identity is the real perimeter in cloud, which is why the tenant, subscription, and groups class comes so early — get the structure right and access rules become obvious.
The perimeter is not the network anymore. It is the identity. Guard the login and you have guarded most of the account.
3. Least-privilege RBAC — stop handing out Owner
What: give each person and app the smallest role that lets them do their job, scoped to the smallest slice of the account. Why: the beginner reflex is to assign Owner or Contributor at the subscription level to make the error go away. Then one phished account can delete or exfiltrate everything. Scoped roles turn a full breach into a contained one. How: on the resource group or resource, use Access control (IAM) to assign a specific built-in role — Reader, Storage Blob Data Reader, whatever fits — at the narrowest scope that works.
This is the practice most people nod at and never do, and it is the single biggest gap between "I passed AZ-104" and "I can be trusted with production." The RBAC and Azure Policy class walks the full model; the short version is that "read-only to one storage account" is a real answer and "Owner on the subscription" almost never is.
4. Managed identities instead of stored keys
What: give your app its own Azure identity so it authenticates to other Azure services with no key at all. Why: a key you never store is a key that can never leak. Managed identities remove the entire class of "connection string in code" mistakes. How: turn on a system-assigned identity on your App Service or VM, then grant that identity an RBAC role on the resource it needs. Azure rotates the credential for you.
This is worth understanding properly because it is genuinely a beginner superpower — the fix that deletes a whole category of risk rather than mitigating it. The service principals and managed identity class is the one to sit with.
5. Nothing public by default
What: storage accounts, databases, and admin ports closed to the open internet unless there is a deliberate reason. Why: automated scanners find a newly-public storage container or an open database port in minutes, not days. "Allow anonymous blob access" is off by default now for good reason — leave it off. How: on the storage account, keep public network access disabled or restricted to selected networks, and confirm anonymous access is off. On databases, never leave the "allow all Azure services" or 0.0.0.0 firewall rule in place.
6. Keep the network tight — NSGs and private endpoints
What: use NSGs and private endpoints to control network access. A private endpoint provides a private path; it does not automatically disable the service’s public endpoint. Configure public-network access separately and test DNS, authorized access and denied access. A private network path also does not replace identity authorization.
7. Secrets in Key Vault, not in Git
What: for the secrets you genuinely must hold — third-party API keys, tokens — store them in Azure Key Vault and read them at runtime. Why: a key committed to a repo lives in Git history forever, and bots scrape public repos for exactly this. It is one of the most common ways a beginner account gets drained. How: put the secret in Key Vault, give your app's managed identity the "Key Vault Secrets User" role, and fetch it at startup. Nothing sensitive touches the codebase.
MFA first, this afternoon. Then a budget alert (five minutes, catches disaster). Then walk your RBAC assignments and remove every Owner you do not need. Then turn on Defender for Cloud's free tier and let Secure Score hand you the rest of the list, ranked. You do not have to do all nine at once — you have to start at the top.
8. Turn on logging before you need it
What: diagnostic logs flowing to a Log Analytics workspace, and the free tier of Microsoft Defender for Cloud giving you a Secure Score. Why: you cannot investigate a breach you never recorded, and Secure Score turns "am I secure?" into a ranked to-do list with a number that goes up as you fix things. How: enable diagnostic settings on your key resources pointed at a Log Analytics workspace, and open Defender for Cloud — the foundational tier is on by default and free. Work the recommendations top-down.
9. A budget alert is a breach detector
A cost budget can help surface unexpected resource usage, including possible misuse. It is not a spending cap, immediate breach detector or guaranteed same-day notification: cost data and budget evaluation are delayed. Use security alerts and identity logs alongside it, and investigate the actual resources and identities behind a cost spike.
Own the gap
Recognizing security controls in an exam is different from configuring them. Practise enabling an identity, granting a scoped role and verifying allowed and denied access in a lab. Check Microsoft’s current certification catalog when choosing an exam; this security checklist does not depend on a particular exam’s retirement date.
None of these are hard. They are a portal blade and a few minutes each. The reason accounts still get breached is not that the controls are difficult — it is that "I will secure it later" is the most expensive sentence in cloud. Do the boring list. It is the whole game at this level.
Common questions
What is the single most important Azure security setting for a beginner?
Multi-factor authentication on every account, starting with the admin. Most account compromises are stolen or reused passwords, and MFA stops nearly all of them. It is free, it takes minutes, and no other control matters if an attacker can just log in as you. Turn it on before you do anything else.
Is Microsoft Defender for Cloud free?
The foundational tier is free and on by default. It gives you Secure Score, security recommendations, and an inventory of misconfigurations across your subscription at no cost. The paid plans add threat detection per resource type and are billed per resource per hour. For a beginner, start with the free tier and work your Secure Score up before paying for anything.
How do I keep secrets out of my code in Azure?
Two moves. First, prefer managed identities so your app gets an Azure identity and never holds a key at all. Second, for the secrets you genuinely must store — third-party API keys, connection strings — put them in Azure Key Vault and read them at runtime, never in the repo. A leaked key in Git history is one of the most common ways beginner accounts get drained.
Why is a budget alert a security control?
A cost budget can help surface unexpected resource usage, including possible misuse. It is not a spending cap, immediate breach detector or guaranteed same-day notification: cost data and budget evaluation are delayed. Use security alerts and identity logs alongside it, and investigate the actual resources and identities behind a cost spike.
Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.
It worked for them.
Sources and review
Reviewed 1 October 2026. Network, identity and cost controls work together. Private endpoints and budget alerts do not automatically disable public access or stop charges.