Short, honest write-ups of the ideas that come up in interviews and on the job. Each one teaches the concept properly, cites the Microsoft documentation, and points back to the class that drills it until it sticks.
Three letters that turn up on every architecture diagram and every security checklist, usually with no explanation attached. Here is what a WAF is, where it sits, the one OSI layer that makes it useful — and the honest reason turning one on is not the end of the story.
Everyone reaches for "Azure WAF" like it's a box you deploy. It isn't. It's a feature you switch on in front of something else — and the interesting question is which something else.
Strip away the marketing and a web application firewall is a bouncer reading every request at the door. Here is exactly what it reads, how it decides, and the part the product page will not tell you — that the rules are the easy 20 percent and tuning them is the job.
A question that trips up almost everyone new to Azure networking, because the names overlap and the marketing pages don't help. The short version: it can be, but it isn't by default — and that gap has burned more teams than I can count.
The first time you go looking for WAF logs in Azure, you find nothing — and assume you're in the wrong blade. You're not. There is nothing there yet, and that is the whole answer.
Two modes with almost identical config screens and completely different consequences. One watches and writes everything down. The other stops the attack — and, if you rushed it, stops your customers too.
Two managed web application firewalls that get compared as if they were the same product. They are not. One keeps everything inside Azure; the other is a global edge that happens to do a lot more than filter requests. The choice comes down to where your app lives.
Azure cloud security best practices for beginners: turn on MFA, use least-privilege RBAC, keep secrets out of code, lock down network exposure, and switch on the free Secure Score. The boring, high-impact list — not exotic tooling.
Defender for Cloud secures your resources; Sentinel is your SIEM across everything. How they connect, and which you actually need.
Azure Firewall guards the network; a WAF guards the web app. Different layers, and serious apps run both — not either/or. Where each one sits.
Application Gateway routes and load-balances your HTTP traffic, but it does not read the request for an attack — the WAF is the part that inspects every request against the OWASP rules and blocks the SQL injection before it reaches your database.
Every Azure customer already has always-on DDoS protection at the platform level, at no cost — so the real question is not whether you are protected, but whether the paid tier buys you anything your workload actually needs.
The oldest sin in web apps is a password in a config file. Key Vault references delete it with no code change: the app setting stops holding the secret and starts pointing at it, resolved at runtime by a managed identity.
Most traffic is encrypted now, which is great for privacy and terrible for a firewall reading nothing. The Premium tier adds TLS inspection and a signature-based IDPS so it can open the tunnel and match what is really flowing against known attacks.
You need to let one client read one blob for one hour — without handing over the master key to your whole storage account. A shared access signature is exactly that: scoped, time-limited access baked into a URL.
"Is our cloud secure?" is really three questions — are we configured well, is our pipeline safe, are our workloads under attack? Defender for Cloud answers all three, and gives your posture a number you can move.
A connection string in a config file is a breach waiting for a git push. Key Vault is the central, access-controlled store those secrets go instead — so your code holds a reference, never the secret itself.
One short, honest Azure note at a time — plus the occasional hiring signal. No spam, no card, unsubscribe in one click.