New challenge, acquire all DevOps certifications in 3 popular public cloud providers, Azure is the first target of mine. Let's fucking go!!!

I will try to refer to AWS as much as I can because AWS is the first cloud I learned.

This article could contains some wrong information since I'm new to this, correct me if I'm wrong, thanks xD

Prepare for the exam

Useful resources:

• https://learn.microsoft.com/en-us/training/paths/az-104-administrator-prerequisites/
• https://udemy.com/course/70533-azure/

Some section need to be understand before taking the exam.

• Domain 1 — Identity & Governance (20–25%)
• Domain 2 — Compute (20–25%)
• Domain 3 — Storage (15–20%)
• Domain 4 — Networking (15–20%)
• Domain 5 — Monitor & Backup (10–15%)
• Exam Tip/Tricks
• Secure Weapons

Ok, let's take them one by one!

Domain 1 - Identity & Governance

Hierarchy

We can simply understand it by following (Generated by Sonnet 4.6 xD):

RBAC

It likes IAM Roles of AWS but can be assign in multiple levels:

Management Group  →  inherit all belows
  └── Subscription  →  inherit all Resource Groups belows
        └── Resource Group  →  inherit all resources belows
              └── Resource  →  only that resource

Here are common built-in roles of Azure RBAC:

Resource reference: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview

Inheritance: very very very important, assigned 1 time in Management Group, all sub resource inherit.

Azure Policy vs IAM Policy

Totally different versus AWS IAM Policy. Azure Policy enforce rules on resources, not permissions.

Example about Azure Policy:

• VM only created in Southeast Asia.
• Storage Account must enable encryption.
• All resources must have tag Environment

Management Groups

Like AWS Organization, group Subscription for apply policies/RBAC

Root Management Group
  ├── Production
  │     ├── Subscription: prod-app1
  │     └── Subscription: prod-app2
  └── Development
        └── Subscription: dev-sandbox

Policy/RBAC assigned in Management Group, inherit to all subscription. Easy to understand, right?

Resource reference:

https://learn.microsoft.com/en-us/azure/governance/management-groups/overview

Little concept comparison

Entra ID (Azure AD) vs AWS IAM

B2B: Business to Business

B2C: Business to Consumer

System-Assigned Managed Identity (SAMI) vs User-Assigned Managed Identity (UAMI)

Resource reference:

https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/managed-identity-best-practice-recommendations

Control Plane vs Data Plane

Subscription Owner
├── Control plane: create/delete/manage resource (Microsoft.Storage/*, Microsoft.KeyVault/*)
└── Data plane: No — must assign role explicitly

For example:

• Owner can create Storage Account
• Owner access blob (Binary Large Object) -> need role "Storage Blob Data Reader"
• Owner can create Key Vault
• Owner access secret -> need role "Key Vault Secrets User"

Resource Reference:

• Azure Control Plane and Data Plane
• RBAC for Storage
• RBAC for Key Vault

Managed Identity + Key Vault

Pattern:

App Service → [SAMI] → Key Vault Reference → Secret

Setup step:

• Enable SAMI in App Service
• Assign role Key Vault Secrets User for managed identity in Key Vault
• App setting uses @Microsoft.KeyVault(SecretUri=...)

No need to store credentials anywhere, managed identity auto get token from Azure AD

K8s analogy: This pattern is identical to Workload Identity (AKS/GKE) or IRSA (EKS — IAM Roles for Service Accounts):

K8s:    Pod → [ServiceAccount] → IAM Role / Managed Identity → AWS/Azure resource
Azure:  App Service → [SAMI] → RBAC role → Key Vault secret

Same idea: workload is bound to an identity, the identity is granted permissions, and the runtime auto-exchanges tokens (via OIDC / IMDS endpoint). Code only calls the SDK — no secrets or keys needed anywhere. When Pod/App restarts, the identity persists — no manual credential rotation.

It also applies to in-cluster K8s RBAC: a Pod runs as a ServiceAccount, that SA is bound via Role/RoleBinding (or ClusterRole/ClusterRoleBinding), and calls to the K8s API server (default endpoint https://kubernetes.default.svc inside the Pod) are authenticated using the projected token at /var/run/secrets/kubernetes.io/serviceaccount/token. Same identity-binds-to-workload pattern, just scoped to the cluster instead of cloud resources.

Resource Reference:

• Use Key Vault references for App Service and Azure Functions
• How to use managed identities for App Service and Azure Functions
• Azure AD Workload Identity for AKS

Conclusion and Gotchas

• RBAC = IAM Roles.
• Azure Policy = Service Control Policies (but have more flexibility)
• SAMI is often prefer because it will not make orphaned identities xD
• Subscription owner can not read KV secret by default. Owner only have control plane permissions — need to self-grant data plane role (e.g. Key Vault Secrets User) if access is needed
• Key Vault Contributor = manage vault configuration (control plane), NOT read secret
• Key Vault Administrator = full data plane access (read/write/delete secrets, keys, certs)
• For vault access model best practice: pick RBAC!

Resource Reference:

• Built-in roles for Key Vault data plane operations

Domain 2 - Compute

Virtual Machine (VM) Availability

Exam Gotchas

• SLA 99.99% → must pick Zones, not Set
• Can not combine Availability Set and Availability Zones
• Availability Set: Fault Domain (FD): different physical rack (power, switch) — max 3, default 2
• Availability Set: Update Domain (UD): group VM not going to restart together when Azure patch — max 20

Resource Reference:

• Availability options for Azure Virtual Machines
• SLA for Online Services

VM Encryption

Verdict: SSE almost ready for everything. ADE only when compliance is required.

Resource Reference:

• Overview of managed disk encryption options
• Server-side encryption of Azure Disk Storage
• Azure Disk Encryption for VMs and VMSS

Note: ADE is scheduled for retirement on September 15, 2028. Microsoft recommends migrating to encryption at host for new VMs.

Deployment slot

Azure App Service deployment slots are live, distinct environments for your web apps. They allow you to test changes, warm up instances, and achieve zero-downtime deployments. By managing configurations independently, you can deploy updates to a staging slot, verify them, and instantly swap them into production. (from AI Overview when google search xD).

Some note for exam:

• Deployment slot is not available in Free/Basic plan. If question related to staging environment, pick Standards.
• After slot swap, both slot still running, for rolling back, just simple by swap back.
• App Service Plan = compute resource.

Resource Reference:

• Set up staging environments in Azure App Service

ARM (Azure Resource Manager) and Bicep

• ARM Template = Cloudformation Template of AWS
• Bicep still is ARM but better syntax (Azure only)
• Still prefer to use Terraform instead of this fucking shit when it comes to production!

Containers

Comparison between 3 services

Resource Reference:

• What is Azure Container Instances?
• What is Azure Container Apps?

Domain 3 - Storage

Azure Storage Account vs AWS S3 — Mental Model

AWS                              Azure
───────────────────────────────────────────────────
(No)                         →   Storage Account (wrap layer)
S3 Bucket                    →   Blob Container
S3 Object                    →   Blob
S3 Bucket Policy             →   Container Access Policy / RBAC
S3 Lifecycle Rules           →   Lifecycle Management
S3 Versioning                →   Blob Versioning
S3 Storage Classes           →   Access Tiers (Hot/Cool/Archive)
S3 Presigned URL             →   SAS Token
S3 Static Website            →   Static Website (in Blob)
───────────────────────────────────────────────────
EFS                          →   Azure Files
SQS                          →   Queue Storage
DynamoDB (simple use)        →   Table Storage

Key Differences:

Example:

AWS:
  - s3://my-images-bucket        (Create)
  - s3://my-backup-bucket        (Create)  
  - EFS: my-team-share           (Other service)

Azure:
  - mystorageaccount
      ├── container: images      (Like S3 bucket)
      ├── container: backups     (Like S3 bucket)
      └── fileshare: team-share  (Like EFS)

Immutable vs Mutable Settings

Can not change after created:

• Storage Account name
• Location/Region
• Performance tier (Standard ↔ Premium)
• Hierarchical namespace (For exam, but in fact we have migration tool)

Can be change after created:

• Redundancy (LRS/ZRS/GRS) - but limit
• Access tier (Hot/Cool)
• Network/Firewall rules
• Data protection (soft delete, versioning)
• Encryption settings

We need to pick Name, Region, Performance tier right for the first damn time!

Replication Types

In single region:

Cross-region:

Pick replication by keyword:

Resource Reference:

• Azure Storage redundancy
• Change how a storage account is replicated
• Hot, cool, cold, and archive access tiers for blob data
• Grant limited access to data with shared access signatures (SAS)

Exam Tricks for Storage Features (non-replication)

For replication keywords (LRS/ZRS/GRS/RA-GRS/GZRS/RA-GZRS), see the Replication Types section above.

Domain 4 - Networking

Resource Reference:

• AWS to Azure services comparison - Networking
• Azure Virtual Network (VNet) Overview

Quick Mapping from AWS VPC xD

AWS                              Azure
───────────────────────────────────────────────────
VPC                          →   VNet
Subnet                       →   Subnet
Security Group               →   NSG (Network Security Group)
Elastic IP                   →   Public IP (Static)
ENI                          →   NIC (Network Interface Card)
VPC Peering                  →   VNet Peering
NAT Gateway                  →   NAT Gateway
Route Table                  →   Route Table

But there is still some little different. And we will go one by one

Subnet and Availability Zones (AZs)

• AWS: each Subnet locked into 1 AZ. To achieve HA, we need to create multiple subnet in different AZ.
• Azure: Subnet expanded to all AZ in single region. We can place VM in AZ 1, AZ 2, AZ 3 into same subnet.

NSG (Network Security Group) vs SG (Security Group) / NACL

• AWS: Use SG (applied at ENI/Instance) and Network ACL (NACL) (applied at Subnet)
• Azure: Use only NSG. NSG Can be applied both to NIC or Subnet
• NSG is stateful, NACL is stateless

Stateful vs Stateless — what does it mean?

• Stateful (NSG, AWS SG): firewall remembers connections. When outbound traffic is allowed, the return traffic is automatically allowed — the firewall tracks the session in a connection table.
• Stateless (AWS NACL): firewall has no memory. Every packet is evaluated independently → you must define rules for both directions (inbound AND outbound).

Quick example — VM calling GitHub API (HTTPS port 443):

VM (random port 54321) ──[request]──→ GitHub (port 443)
VM (random port 54321) ←──[response]── GitHub (port 443)

That's why Azure only needs one NSG instead of AWS's two-layer SG + NACL model — simpler, no need to open wide ephemeral port ranges, less misconfiguration risk.

Resource Reference:

• Azure network security groups overview

VNet Peering & Gateway

AWS                              Azure
───────────────────────────────────────────────────
VPC Peering (same region)    →   VNet Peering
VPC Peering (cross-region)   →   Global VNet Peering
VPN Gateway                  →   Virtual Network Gateway
Transit Gateway              →   Virtual WAN / VNet Gateway
Site-to-Site VPN             →   VPN Gateway Connection
Direct Connect               →   ExpressRoute

Resource Reference:

• Azure Virtual Network peering
• About Azure VPN Gateway
• Azure ExpressRoute overview

Azure DNS

AWS                              Azure
───────────────────────────────────────────────────
Route53                      →   Azure DNS
Route53 Hosted Zone (public) →   Public DNS Zone
Route53 Private Hosted Zone  →   Private DNS Zone
Route53 Domain Registration  →   App Service Domain
Route53 Health Checks        →   Traffic Manager
Route53 Routing Policies     →   Traffic Manager

Azure separates health checks + traffic routings via Traffic Manager, not built-in like Route53.

Azure Load Balancing

AWS                              Azure
───────────────────────────────────────────────────
NLB (Layer 4)                →   Azure Load Balancer
ALB (Layer 7)                →   Application Gateway
CloudFront + ALB (global)    →   Azure Front Door
Route53 routing policies     →   Traffic Manager (DNS-based)

Resource Reference:

• Load-balancing options — Official Microsoft comparison

Azure Network Watcher (Debug tools)

AWS                              Azure
───────────────────────────────────────────────────
VPC Flow Logs                →   NSG Flow Logs
VPC Reachability Analyzer    →   IP Flow Verify / Connection Troubleshoot
VPC Traffic Mirroring        →   Packet Capture

Verdict: Almost 1:1 with AWS VPC/Route53/ELB, just a fucking name different.

Resource Reference:

• Azure Network Watcher overview

Exam Gotchas

• ExpressRoute does not go via internet → question "secure private connection" = ExpressRoute.
• VPN Policy-based not support Point-to-Site.
• Active-Active VPN Gateway = 2 tunnel, high availability.
• ExpressRoute Global Reach: connect 2 on-prem sites via Azure backbone (no need internet).
• Question "consistent latency, high bandwidth" = ExpressRoute.
• Question "quick setup, cost-effective" = VPN Gateway.

Domain 5 - Monitor & Backup

Quick Mapping from AWS for Backup xD

AWS                              Azure
───────────────────────────────────────────────────
AWS Backup                   →   Azure Backup
Backup Vault                 →   Recovery Services Vault
AWS DRS / CloudEndure        →   Azure Site Recovery (ASR)
EBS Snapshots                →   VM Backup (disk snapshots)

Backup Services

Verdict: Azure Backup = AWS Backup, ASR = DRS (AWS Elastic Disaster Recovery).

Resource Reference:

• What is Azure Backup?
• About Azure Site Recovery

Quick Mapping from AWS CloudWatch

AWS                              Azure
───────────────────────────────────────────────────
CloudWatch                   →   Azure Monitor
CloudWatch Metrics           →   Metrics
CloudWatch Logs              →   Log Analytics Workspace
CloudWatch Logs Insights     →   Kusto Query Language (KQL)
CloudWatch Alarms            →   Alerts
CloudWatch Agent             →   Azure Monitor Agent
X-Ray                        →   Application Insights

Resource Reference:

• Azure Monitor overview
• Kusto Query Language (KQL) overview

Exam Tip/Tricks

Summary of common pitfalls, this is not study guide. Only pattern to drop wrong answer xD

1. "X replaces NSG/Firewall"

This is always wrong. Bastion, Private Endpoint, VPN Gateway, Front Door, App Gateway... not replace NSG. NSG is layer filter , always apply together.

2. VNet Peering

3. Storage Replication

See Domain 3 — Replication Types for the full picker table.

Pitfalls: "highest availability within a region" → ZRS (not GRS). GRS is cross-region. G stands for GEO

4. Backup vs Site Recovery

• Azure Backup = data recovery (file, VM disk, DB) — RPO calculate by hour/day
• Azure Site Recovery (ASR) = disaster recovery (replicate VM into another region) — RPO/RTO low

Question "recover deleted file" → Azure Backup. "Region down, switch to another region" → ASR.

5. Recovery Services vault vs Backup vault (naming pitfall )

Keyword "files, folders, system state" → alway are Recovery Services vault (Because attach with MARS agent). Don't be wrong with "Azure Backup vault"

Resource Reference:

• Overview of Backup vaults
• Recovery Services vaults overview

6. RBAC vs Azure Policy

• RBAC = who did what (access)
• Policy = resource allows to exist or not (compliance, deny tag missing, deny SKU ...)

If questions are "enforce tag", "block region" → Policy. Otherwise "grant read access" → RBAC.

7. Four built-in roles

Common pitfalls: exam question "full manage resources but no assign roles" → answer is Contributor, NOT User Access Administrator (UAA). UAA is reversed role — Only assign roles, not going to have permissions to touch resources.

Trick:

• Owner = Contributor + UAA
• Contributor = Everything but not able to give permissions
• UAA = Only able to give permissions

8. RBAC scope — 4 levels

Management Group  (top, contains multiple subscription)
    ↓ inherit
Subscription
    ↓ inherit
Resource Group
    ↓ inherit
Resource          ← VNet, VM, Storage, Key Vault... individual resource.

Rules: Anything that contains Resource ID can be scope. Role assigned at higher scope, inherit to lower scope.

Pitfalls: List specific like "Virtual Network", "Storage Account" make distractor, it still is valid scope (Level Resource).

Least privilege pattern: Instead assign Contributor at Subscription, assign role lower scope, like Network Contributor at that damn Virtual Network.

9. Locks

Gotcha: ReadOnly lock can break some operations thought it was "read".

Example: list keys of Storage Account actually is post request.

Resource Reference:

• Considerations before applying your locks

10. Cost Management Pitfalls

• Reserved Instance = commit 1/3 year, reduced up to 72%
• Spot VM = cheap but can be evicted
• Hybrid Benefit = bring license Windows/SQL on-prem to Azure

If question "predictable workload, lowest cost" → Reserved Instance. "Batch job, can be restart" → Spot.

Resource Reference:

• What are Azure Reservations?
• Use Azure Spot Virtual Machines

11. An overly absolute answer → 90% chance of being a distractor

"red flag" in answers xD:

12. Network Watcher — choose the right tool

Need to remember:

• If question "between two VMs" + "network" → reflex Network Watcher.
• If question "continuous/monitor over time" → Connection Monitor.
• If question "one-time test" → Connection Troubleshoot.

13. Azure Monitor — Metrics vs Logs vs Insights

Pitfalls: exam ask "diagnostic between 2 specific VM" → Hell No, it is NOT Insights. Insights is overview, not deep-dive.

Differentiation Insights vs Log Analytics when exam have "analyze":

14. Private DNS + Private Endpoint + Hybrid resolution

Questions around "Can VM/on-prem resolve name of private or not?". Need to remember scope of each components.

Pitfall 1: Peering not share DNS

• VNet-A have Private Endpoint + zone already link → VM-A resolve OK. VM-B in VNet-B (peered) fail because zone haven't link to VNet-B.

• Fix: link zone to both VNet. Zone is global, link is unlimit

Pitfall 2: Hybrid DNS need Private Resolver

• On-prem need to resolve mystorage.privatelink.blob... →

On-prem DNS  ──conditional fwd──→  DNS Private Resolver
                                   (inbound endpoint, region X)
                                          ↓
                                   linked Private DNS Zones
                                          ↓
                                   return IP private endpoint

• Inbound endpoint = on-prem DNS forward query into Azure (resolve privatelink zones)
• Outbound endpoint = Azure VM resolve DNS on-prem via conditional forwarding rules.
• HA cross-region → deploy resolver in 2 region

Common Scenario:

Resource Reference:

• Azure DNS Private Resolver overview
• What is an Azure Private DNS zone?