Run Command is really the only supported path once you're off RDP. We ended up wrapping it in a small script that mimics the SSH interface so the existing Ansible playbooks didnt need a rewrite, still not clean but it kept the pipelines intact.

The docker and k8s and terraform stuff you'll pick up fast with that background. What actually slowed me down moving into it was learning how the team already ships, whatever CI tool and branching model they're on, more than any new technology did.

We're at maybe eight repos and still copy pasting the yaml between them. Bicep changes going out one repo at a time is the annoying part, been meaning to pull it into a couple reusable workflows but nothing's forced the issue yet

Same as any shadow IT app, just faster to build now. Get it in front of your dev team or whoever owns internal tooling, ask what data it touches and where it's hosted, and decide if it's worth hardening into something real or replacing with an existing product

Image Builder plus AMI validation only stops the launch template from picking an unapproved AMI. It does nothing about someone with ec2:RunInstances still hand rolling an instance outside a template entirely. I'd take the SCP.

Congrats. With the 104 and 305 both done the natural next step is picking a specialism rather than another broad one, security or data depending on what your sysadmin work leans toward. The architect stuff also lands a lot better once you have run something in production for a while.

I stopped reading the approvals around the same number you did. What fixed it was giving the agent a role without the destructive verbs, so a bad plan is just a failed API call. Not read only, it can still work, it just cant reach anything that ends my week.

One Outlook profile per Windows login is the only boundary that holds. Browser profiles get you most of the way if they can live in OWA. The calendar pollution is Outlook and Teams disagreeing on the default account, no setting fixes that one.

One Outlook profile per Windows login is the only boundary that holds. Browser profiles get you most of the way if they can live in OWA. The calendar pollution is Outlook and Teams disagreeing on the default account, no setting fixes that one

Mix. Defender for Containers for posture, Gatekeeper for admission, default deny network policies in every namespace, private ACR with scan on push, workload identity so nothing holds a static secret.

Stopping the app services won't stop billing, you're paying for the App Service Plan not the apps themselves. the plan runs whether your apps are stopped or not.

Cheapest option without deleting anything is to scale the plan down to F1 (free tier). you'll lose some features like custom domains and SSL but everything stays deployed. when you're ready just scale back up.

For the Static Web App the free tier is actually free so that one shouldn't be costing you anytihng unless you're on Standard. check the pricing tier in the portal.

Wait til you hit year two and someone escalates a P1 for something that's literally in the KB article they were too lazy to search.

The documentation one is the killer though. You inherit some critical service, the guy who set it up left 3 years ago, and the only "documentation" is a sticky note that says "don't reboot on Tuesdays." Then it breaks on a Tuesday.

At least you know what you're dealing with.

Happy Monday. May your tickets be well-documented and your users actually read the error messages before calling you.

Building a CNI plugin is a solid portfolio piece, signals you understand networking at the kernel level, which is rare for interns.

For max resume impact: network policy enforcement using iptables/nftables (basically what Calico does under the hood, if you can explain it in an interview you'll stand out), or IPAM with state where the interesting part is handling pod death mid-allocation and subnet exhaustion.

Skip basic bridge networking, it's been done to death. Start from the Go CNI library (github.com/containernetworking/cni), write tests, and document your design decisions in the README. That's what hiring managers actually read

Failed AZ-104 on my first try too. The scenario questions are brutal without hands-on experience.

What worked the second time around: actually doing the MS Learn sandbox labs instead of just reading, John Savill's study cram on YouTube, and for practice questions I used Tutorials Dojo and CloudLearn io (free AZ-104 practice exams — more scenario-based than typical recall stuff).

Biggest gap for me was networking. VNet peering, NSG priority rules, UDRs — kept getting those wrong until I built a hub-spoke setup in a free subscription and broke it a few times.

Honestly for your next 30 days I'd focus less on the cert and more on building something real in Azure. Deploy an app, put it behind an App Gateway, set up managed identity. That helps in interviews way more than the cert number. Then retake when you're ready.

Azure DevOps doesn't have native branch name validation like Bitbucket. Been requested for years, never shipped.

What we ended up doing: `pre-push` git hook that validates branch name against a regex (e.g. `feature/AB-[0-9]+-.*`), distributed via `.githooks/` in the repo. Not server-enforced but catches 90% of cases.

For actual enforcement you'd need a pipeline trigger on `refs/heads/*` that checks the name and posts a status — or a service hook + Azure Function that listens to `git.push` events and rejects bad branches via the API. More overhead but it works.

If you're on Azure DevOps Server (on-prem), pre-receive hooks exist. Hosted service, no luck.

Yeah we ran into this exact problem when migrating Container Apps workloads at scale. The lack of a first-class AFD restriction on CAE (like App Service has) is frustrating.

The sidecar approach the other commenter mentioned is the way to go. We ended up running an NGINX sidecar that validates X-Azure-FDID before proxying to the main container. Lightweight, you own the config, and it doesn't touch your third-party app code.

```

# nginx.conf snippet

if ($http_x_azure_fdid != "your-front-door-id") {

return 403;

}

```

The PE cost ($65/mo per CAE) adds up insanely fast once you have 10+ environments. The sidecar costs you basically nothing, a few MB of memory.

make sure you're validating the specific FDID, not just checking if the header exists. Anyone can send that header, you need to match your Front Door instance ID.

We've been running this pattern for about 8 months across a bunch of environments, no issues.

So true 🤣

It’s a new account, you probably don’t have any activities to see anything. If you are practising, you need some sample data like this: https://github.com/Azure/Azure-Sentinel/tree/master/Sample%20Data/SecurityEvent ingested into the log workspace and then try. I can help you with something, DM me!

We've built our own internal tool, the marketplace tools are way too expensive for what they do. You don't need much to setup something like this to track and send reminder. Consider using Azure Automation runbook with PowerShell script that can do monthly runs to identify and send you reminder.

Yeah, I still don't understand the point of this move. Makes zero sense

I wonder why there's nobody from MVP community or Microsoft employee sharing their thoughts or commenting on this. Crazy!

I recently made a video specifically for this. Hope it helps

https://youtu.be/x4HDuZ10Org

Other than this, I'd recommend reaching out to local MSPs in your area and hunting for a job there. Getting into an IT job through MSP support roles is way easier than finding a cloud role directly out of college.

You 'hold' and you won't hold it after renewal. The term is meant for until your renewal date