Introduction — Why Week-3 mattered
Until this week, my Azure learning mostly revolved around making things work.
If something failed, the question was:
Why didn’t this work?
Week-3 forced me to ask a very different question:
What should be allowed to talk to what — and why?
This week wasn’t about VNets, NSGs, or firewalls.
It was about boundaries, trust, and blast radius — and realizing how much Azure assumes unless we design intentionally.
Day-1: Understanding boundaries and blast radius
The first realization was simple, but uncomfortable:
A subnet is not automatically a boundary.
I always associated boundaries with Azure resources — VNets, subnets, IP ranges.
But a boundary is not a resource.
A boundary is an intentional limit on trust, access, or impact.
Blast radius changed how I think
Blast radius is not about how small a lab is today.
It’s about how far damage can spread when something goes wrong tomorrow.
Even with a single AVD session host:
- Implicit trust exists
- Outbound access exists
- Future scale is silently allowed
The risk is rarely visible in the present state — it’s hidden in what the design allows.
Day-2: Control vs assumption (shared responsibility reality)
On Day-2, I listed every component involved in an AVD setup and asked a simple question:
Do I actually control this, or do I just assume it’s safe?
What stood out immediately was how many critical components are only partially controlled:
- Identity
- Security services
- DNS
- Updates
- Management access
The risk is not that these services are bad.
The risk is assuming they behave safely without validating:
- Access paths
- Visibility
- Dependencies
This made me realize that many architectural risks don’t come from things we don’t control —
they come from things we partially control and silently trust.
Day-3: Who talks to whom (and the identity mental model shift)
Day-3 was the biggest mindset correction of the week.
I initially thought of identity in terms of network communication —
who talks to whom, and whether it’s bidirectional.
That assumption was wrong.
Identity does not initiate trust
Identity does not roam around authenticating resources.
It does not initiate connections.
Instead:
- Users, devices, applications, and services go to identity
- Authentication follows a request–response pattern
- Identity is a trust decision point, not a network participant
This clarified something important:
Most Azure workloads rely heavily on outbound trust, not inbound access.
Once I saw this, it became clear why:
- Default outbound access is dangerous
- NSGs often feel ineffective
- Hidden dependencies matter more than obvious ones
Day-4: Designing boundaries by intent
By Day-4, the question became:
If something is compromised, where should the damage stop?
One boundary decision became very clear to me:
Session hosts should not have implicit east-west trust.
Instead of thinking in terms of individual VMs, I started thinking in terms of roles:
- Session host is a role
- Multiple VMs are just instances of that role
If one session host is compromised, it should not affect others in the same role.
This shifted my thinking from:
“How do I secure this?”
to:
“What failure do I refuse to let spread?”
Day-5: The boundary mistake — management access
The final and most important realization came from management access.
Initially, I thought management access was simply about:
- RBAC roles
- Owner vs Contributor
- Granting permissions carefully
But that wasn’t the real mistake.
The real mistake
I treated management access as a single flat trust zone.
In reality:
- Management access is a high-risk role
- It deserves its own boundaries
- Blast radius matters more than power
Instead of one powerful admin role reused everywhere, management access should be:
- Intentionally split
- Limited in scope
- Isolated in access paths
- Designed with failure in mind
You don’t secure management access by making it powerful.
You secure it by making it rare, isolated, and visible.
Key takeaways from Week-3
- Boundaries are decisions, not Azure resources
- Blast radius matters more than configuration correctness
- Identity is trust, not traffic
- Most risk hides in assumed paths and partial control
- Management access is a role with its own blast radius
Week-3 changed how I look at Azure architecture — not by adding tools, but by removing assumptions.
Closing thought
This week wasn’t about becoming “more secure”.
It was about becoming more intentional.
And that feels like the real shift from operating systems
to designing architectures.