DEV Community: Abhishek Kadlii

Finding the Needle in the Cloud Haystack: Real-Time Observability & Log Diagnostics with KQL

Abhishek Kadlii — Fri, 18 Sep 2026 10:45:06 +0000

Finding the Needle in the Cloud Haystack: Real-Time Observability & Log Diagnostics with KQL

When an enterprise cloud application drops database transactions or encounters severe latency spikes across active availability zones, relying on legacy operational methods—like opening manual terminal sessions to SSH into individual virtual machines one by one to comb through raw flat-text log files—is an infrastructure failure. It wastes critical troubleshooting hours and drastically inflates your Mean Time to Resolution (MTTR).

To establish real-time operational velocity, I engineered a centralized cloud observability perimeter. By aggregating distributed data-plane streams into a high-capacity Azure Log Analytics Workspace and configuring the native Azure Monitor Agent (AMA) extension pipeline, I developed advanced Kusto Query Language (KQL) diagnostic matrices to automatically isolate hardware stress vectors, audit security compromises, and wire them up to an automated alert engine.

🏰 The Analogy: The Building CCTV Control Room

To appreciate the structural value of a centralized telemetry workspace, look at how facility protection maps out in a physical corporate skyscraper:

Manual Incident Diagnostics (The Flashlight Search): Walking through a massive 50-story commercial office building, manually opening every single individual storage room and office suite door one by one with a handheld flashlight to search for a single failed lightbulb.
Centralized Observability (The System Video Wall): Sitting inside a high-tech facility security control room equipped with a unified central video display. The monitoring array instantly flags the exact malfunctioning office room, graphs the precise real-time electrical voltage drop value, and routes an automated incident notice directly to the on-call engineer's mobile device.

[ Central India VM Node 1 ] ──┐
[ Core Compute Engine VM  ] ──┼──► [ Log Analytics Workspace ] ──► (KQL Engine) ──► [ Automated Email Alert ]
[ Infrastructure Node 3   ] ──┘

🛠️ The Step-by-Step Command-Line Execution Blueprint

The telemetry data collection and query analysis perimeter was deployed inside the Central India datacenter region using the Azure CLI:

1. Provisioning the Cloud Monitoring Sandbox Workspace

First, I initialized an isolated resource group container and spun up the primary big data logging storage cluster:

# Initialize the tracking resource group container in Central India
az group create --name "Marathahalli_Monitoring_India_RG" --location "centralindia"

# Deploy the high-capacity central Log Analytics Workspace cluster
az monitor log-analytics workspace create \
  --resource-group "Marathahalli_Monitoring_India_RG" \
  --workspace-name "CentralOpsWorkspaceIndia" \
  --location "centralindia"

2. Deploying the Ingestion Fleet via Azure Monitor Agent (AMA)

Next, I provisioned an approved workload generator node and connected its internal diagnostic engine straight to our central logging workspace using the operational Linux collection agent extension:

# Provision an approved compute host inside the local group boundary
az vm create \
  --resource-group "Marathahalli_Monitoring_India_RG" \
  --name "Hub-Mgmt-VM" \
  --image "Ubuntu2204" \
  --size "Standard_B2ats_v2" \
  --location "centralindia" \
  --admin-username "abhishek" \
  --generate-ssh-keys

# Bind the operational Linux collection agent extension to stream metrics
az vm extension set \
  --resource-group "Marathahalli_Monitoring_India_RG" \
  --vm-name "Hub-Mgmt-VM" \
  --name "AzureMonitorLinuxAgent" \
  --publisher "Microsoft.Azure.Monitor"

📊 Lab Verification Artifact 1: Infrastructure Deployment Status
Below is the successful live control plane verification output proving our tracking asset bypasses policy blocks and runs actively in production:

3. Engineering the Automated Proactive Alerting Perimeter

To shift from reactive analysis to proactive mitigation, I configured a corporate Action Group tied directly to an automated metric threshold alert rule:

# Register the automated corporate Action Group communication channel
az monitor action-group create \
  --resource-group "Marathahalli_Monitoring_India_RG" \
  --name "OpsAlertsGroup" \
  --short-name "OpsAlerts" \
  --action email "AzureAdmin" "sukithaagowda31@outlook.com"

# Extract the live virtual machine resource identification token string
VM_ID=$(az vm show --resource-group "Marathahalli_Monitoring_India_RG" --name "Hub-Mgmt-VM" --query id --output tsv)

# Bind the metric alert threshold rule live to evaluate system stress over a 5m window
az monitor metrics alert create \
  --resource-group "Marathahalli_Monitoring_India_RG" \
  --name "High_CPU_Alert_Rule" \
  --scopes "$VM_ID" \
  --condition "avg Percentage CPU > 85" \
  --description "Triggers an automated notice when CPU performance thresholds cross 85 percent over a 5-minute window." \
  --evaluation-frequency "1m" \
  --window-size "5m" \
  --action "OpsAlertsGroup"

📊 Lab Verification Artifact 2: Automated Alert Rule Architecture
Visual proof showing our active threshold metric criteria parameters successfully bound to the Azure Action Group mapping plane:

⚙️ Production Kusto Query Language (KQL) Diagnostic Matrix

Once telemetry arrays began populating our central workspace datastores, I built production-grade KQL routines to parse system behavior trends and isolate hidden engineering anomalies:

🔍 Scenario 1: Pinpointing Elevated Compute Strain (> 80% CPU)

This analytical monitoring script continuously filters through high-frequency processor telemetry counters (Perf), packages historical data records into clean 5-minute aggregation buckets (bin), averages out processing values, and structures trends by the highest strain peaks to surface hardware degradation instantly:

Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where CounterValue > 80
| summarize AvgCPU = avg(CounterValue) by Computer, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

🔍 Scenario 2: Auditing Rogue Host Authentication Failures

This security compliance routine tracks raw server operating logs (Syslog), filtering specifically for internal authentication facilities (auth) that record failed password entries. It uses regular expressions (regex) to rip the hostile actor's source IP address straight out of unformatted text strings into its own auditable field for immediate firewall blocking:

Syslog
| where Facility == "auth" and SyslogMessage contains "Failed password"
| summarize FailedAttempts = count() by HostName, SourceIP = extract(@"\d+\.\d+\.\d+\.\d+", 0, SyslogMessage)
| order by FailedAttempts desc

🚙 KQL Code Logic Decoder (In Plain, Simple Words)

KQL Structural Keyword	Tactical Operational Purpose	Plain-English Logic Translation
`Perf / Syslog`	Dynamic Data Table Targeting	Tells the query engine which database storage table to read from first.
`bin(TimeGenerated, 5m)`	Telemetry Window Aggregation	Chops the messy time stream into neat, summarized 5-minute buckets.
`extract()` / Regex	Log Pattern Interception	Rips out values (like raw hacker IP addresses) out of messy text lines.
`summarize count()`	Aggregate Event Profiling	Math engine that groups and sums metrics by computer or host identifier strings.

📓 The TAC Engineer's Troubleshooting Journal

Real infrastructure tracks in production introduce complex cascading errors. Resolving these blockers requires structural troubleshooting discipline:

🚨 1. Subscription Governance Interception Block (`Code: RequestDisallowedByPolicy`)

The Challenge: Initial attempts to stand up the log generator host (az vm create) crashed with a fatal pre-flight API block indicating policy constraints were breached.
The Root Cause: Prior architectural tracks implemented a broad subscription-wide policy restricting VM shapes to low-cost configurations (Standard_B2s or Standard_B2ats_v2). Attempting a standard Standard_B1s test deployment breached this rule, triggering an immediate gate block.
The Fix: Changed the CLI hardware argument explicitly to an approved whitelisted shape (--size Standard_B2ats_v2), matching global tenant governance rules.

🚨 2. Cross-Region Datacenter Capacity Exhaustion (`Code: SkuNotAvailable`)

The Challenge: The adjusted VM build failed a second time inside the Singapore (southeastasia) datacenter, throwing an active capacity restriction error.
The Root Cause: High computing resource usage across Southeast Asia fully exhausted the physical datacenter hardware frames for both whitelisted B-series shapes simultaneously.
The Fix: Migrated the deployment target room entirely to the Central India region (centralindia), accessing open computing clusters while remaining inside subscription policy bounds.

📊 Lab Verification Artifact 3: Multi-Region Datacenter Capacity Deficit
Live terminal capture showcasing the data plane capacity gridlock on B-series resource nodes across standard regional landing zones:

💡 Top Takeaways for the AZ-104 Exam & Monitoring Architecture

Data Collection Rules (DCR): Aggregating continuous data-plane streams can inflate ingestion costs. In enterprise setups, deploying targeted Data Collection Rules to filter out verbose system events before they reach storage tables preserves credit profiles.
Metric Alert Threshold Actions: Marrying programmatic KQL conditions to automated Azure Alert Rules allows organizations to bind metrics directly to Azure Action Groups, instantly triggering email responses or execution webhooks when production tolerances are breached.

Stopping Rogue Deployments: How I Programmed Azure API Guardrails to Protect the Cloud Wallet

Abhishek Kadlii — Fri, 18 Sep 2026 09:49:58 +0000

Every cloud architect knows the sudden wave of anxiety that comes with opening a billing dashboard and seeing an unexpected cost spike. In large enterprise environments, these spikes rarely happen due to malicious attacks—they happen due to human error. A junior developer spinning up a high-performance compute or GPU node for a minor test case and forgetting to deprovision it over the weekend can vaporize a sandbox budget in hours.

Instead of relying on warning emails, training manuals, or reactive cleanup scripts, I stepped up as a DevSecOps engineer to solve this problem at the source. I programmed the Azure Resource Manager (ARM) API gateway itself to automatically intercept and decline unauthorized resource allocations using Azure Policy and Custom RBAC Least-Privilege roles.

🏰 The Analogy: The Bouncing Corporate Credit Card

To understand this architecture, look at how corporate spending is managed in the physical world:

The Weak Setup (The Honor System): Handing a corporate credit card with a ₹5,00,000 limit to an employee, giving them a policy handbook, and hoping they do not buy a luxury watch. If they make a mistake, the money is already gone, and you are left doing damage control.
The Guardrail Setup (The Terminal Lock): Programming the payment terminal directly at the cash register. If the employee attempts to swipe the card for anything outside approved inventory codes or locations, the transaction is forcefully declined on the spot before a single rupee leaves the corporate account.

                               ┌──► [ Approved SKU: B-Series Only ] ──► ✅ ALLOWED (Passes Gate)
                               │
[ Deployment Request ] ──► [ Azure Policy ARM Gate ]
                               │
                               └──► [ Prohibited SKU: D-Series Node ] ──► ❌ DENIED (Declined at Register)

🛠️ The Step-by-Step Command-Line Execution Blueprint

To demonstrate a production-grade governance implementation, I configured the deployment ring via the Azure CLI inside the Southeast Asia datacenter region using an isolated sandbox perimeter scope:

1. Designing the Custom Policy Criteria (`allowed-skus.json`)

I engineered a strict JSON rule block that targets virtual machine resources, setting the active evaluation flag to a forceful deny effect if the requested hardware profile falls outside of approved low-cost shapes:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "field": "Microsoft.Compute/virtualMachines/sku.name",
        "notIn": [
          "Standard_B1s",
          "Standard_B2ats_v2"
        ]
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

2. Provisioning and Binding the Policy Scope

I initialized the baseline target resource group perimeter and registered the schema with the control plane, passing metadata parameters as explicit flags to satisfy the Azure CLI parser rules:

# Initialize the target perimeter container
az group create --name "Marathahalli_Lab_RG" --location "southeastasia"

# Register the core custom definition rule container
az policy definition create \
  --name "restrict-vm-skus" \
  --display-name "Restrict VM SKUs to B-Series" \
  --rules allowed-skus.json \
  --mode "Indexed"

# Assign the policy enforcer live to the specific Resource Group scope
az policy assignment create \
  --name "Enforce_B_Series_Only" \
  --policy "restrict-vm-skus" \
  --display-name "Enforce B-Series Only" \
  --resource-group "Marathahalli_Lab_RG"

⚙️ Forging a Custom Least-Privilege RBAC Identity Role

Governance is incomplete without identity isolation. Instead of granting wide open contributor rights, I constructed a tailored JSON permission schema (vm-operator-role.json) defining a custom VM Restart Operator role. This role explicitly limits identity capabilities to virtual machine visibility and reboot actions, leaving write actions, configurations changes, and resource deletions sealed shut.

{
  "Name": "VM Restart Operator",
  "IsCustom": true,
  "Description": "Can only read and restart virtual machines inside the environment.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/restart/action"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/YOUR_SUBSCRIPTION_ID"
  ]
}

I programmatically extracted the subscription context and registered the custom RBAC identity blueprint live with the Azure identity control plane API:

# Dynamically fetch current active subscription ID text string
SUB_ID=$(az account show --query id --output tsv)

# Inject the active subscription path into our assignable scopes payload
sed -i "s|YOUR_SUBSCRIPTION_ID|$SUB_ID|g" vm-operator-role.json

# Register the custom RBAC identity blueprint live in the active directory tenant
az role definition create --role-definition vm-operator-role.json

📓 The TAC Engineer's Troubleshooting Journal

Engineering in production means breaking things and solving real conflicts. During this implementation lab, I ran into two distinct runtime errors that provided vital architectural insights:

🚨 1. Top-Level Schema Mismatch Failures (`Code: InvalidPolicyRule`)

The Challenge: The initial registration utility rejected the code payload, throwing a fatal syntax validation error pointing to a schema failure on the "properties" and "mode" parameters.
The Root Cause: The az policy definition create engine expects the underlying --rules file configuration to start directly with the structural logic parameters (if and then). Wrapping these keys in metadata tags violates the parser's expected payload format.
The Fix: Stripped the outer property layers out of the allowed-skus.json file completely, and passed meta properties like --mode "Indexed" out to explicit command-line flags.

🚨 2. Scope Binding Failures via Missing Context Containers (`Code: ResourceGroupNotFound`)

The Challenge: The policy assignment mapping crashed, returning a terminal exception indicating that the target resource group room could not be found.
The Root Cause: Strict cost-control practices dictate tearing down all sandbox groups immediately after structural validations. Running an active policy assignment against an environment scope that doesn't exist crashes the engine call.
The Fix: Refactored the command execution queue to explicitly guarantee the presence of the resource group container (az group create) before executing assignment mappings.

🚀 Live Workload Validation: The RequestDisallowedByPolicy Block

To prove the automated guardrails work perfectly under load, I simulated an accidental budget breach by forcing a deployment command for an unauthorized, high-tier enterprise instance shape (Standard_D4s_v3) directly against the protected resource group perimeter:

az vm create \
  --resource-group "Marathahalli_Lab_RG" \
  --name "Rogue_VM" \
  --image "Ubuntu2204" \
  --size "Standard_D4s_v3" \
  --admin-username "abhishek" \
  --generate-ssh-keys

📸 Defensive Proof Point: The Wallet Secured

The deployment call spun for a brief moment, hit the ARM API gateway checkpoint, evaluated against the active assignment metadata constraints, and was violently rejected! The core control plane blocked resource generation immediately:

azure.core.exceptions.HttpResponseError: (InvalidTemplateDeployment) The template deployment failed because of policy violation. 
Code: InvalidTemplateDeployment
Message: The template deployment failed because of policy violation. Please see details for more information.

Exception Details: (RequestDisallowedByPolicy) Resource 'Rogue_VM' was disallowed by policy 'Enforce_B_Series_Only'.

💡 Core FinOps & AZ-104 Exam Lessons Learned

Deny vs. Audit Effects: The deny effect completely halts non-compliant resource allocation at the gate, protecting the budget instantly. The audit effect, conversely, allows deployments to succeed but flags them inside a compliance dashboard—ideal for mapping out production estates without creating application downtime risks.
RBAC Scoping Precision: Security parameters inside custom role definitions require pinpoint precision. Explicitly matching actions to granular tasks ensures teams maintain access velocity without breaking zero-trust boundaries.

# 🚀 The Self-Healing Server Fleet: How I Mastered Automation, Beat Global SKU Crushes, and Solved Azure's Cloud Racing Conditions

Abhishek Kadlii — Thu, 17 Sep 2026 09:29:25 +0000

Every network engineer knows the absolute dread of the "Black Friday Surge." Imagine a popular grocery store on a festival weekend. There is only one cashier working the register. Suddenly, a bus drops off 100 hungry customers. The line backs up, the cashier is overwhelmed, and the store grinds to a complete halt.

In traditional infrastructure, fixing this meant buying another expensive physical server, mounting it in a rack, and wiring it manually—hours or days too late.

Today, I engineered an automated, self-healing server fleet using an Azure Virtual Machine Scale Set (VMSS) under Uniform Orchestration Mode backed by an automatic metric sensor. When a traffic surge hits, the cloud instantly detects the load and spawns identical backup server instances completely on its own.

🏰 The Analogy: The Overworked Cashier vs. The Automated Queue

The Static State (1 Node): You have a single server running your application. When traffic spikes, CPU utilization hits 100%, packets get dropped, and your users experience timeouts.
The Automated State (Scale-Out Fleet): You program a metric sensor to monitor the workload. The moment the average CPU capacity crosses a 70% threshold, the platform dynamically provisions a second identical node behind an Azure Load Balancer to distribute the weight.

                                    ┌──► [ Active Server Node 01 ] (CPU Spikes >70%)
                                    │
[ High Traffic Crowds ] ──► [ Load Balancer ]
                                    │
                                    └──► 🚀 (Autoscale Rules Trigger Spawn) ──► [ Active Server Node 02 ]

🛠️ The Fault-Tolerant Implementation Blueprint

To ensure absolute environment control, I deployed the high-availability compute architecture directly inside the Central India data center region using the Azure CLI:

# 1. Spin up the dedicated lab container
az group create --name Marathahalli_Lab_RG_V2 --location centralindia

# 2. Build the production network foundation and application subnet
az network vnet create \
  --resource-group Marathahalli_Lab_RG_V2 \
  --name Sec_Hub_SEA_VNet \
  --location centralindia \
  --address-prefixes 10.0.0.0/16 \
  --subnet-name Prod_App_Subnet \
  --subnet-prefixes 10.0.2.0/24

# 3. Deploy the Uniform High-Availability Virtual Machine Scale Set fleet
az vmss create \
  --resource-group Marathahalli_Lab_RG_V2 \
  --name WebAppVMSS \
  --location centralindia \
  --image Ubuntu2204 \
  --vm-sku Standard_D2s_v5 \
  --instance-count 1 \
  --vnet-name Sec_Hub_SEA_VNet \
  --subnet Prod_App_Subnet \
  --lb WebAppLB \
  --backend-pool-name WebAppBackendPool \
  --orchestration-mode Uniform \
  --admin-username abhishek \
  --generate-ssh-keys

📸 Proof Point 1: Baseline Deployment Established

Here is the verification screen in the Azure Portal showing our high-availability fleet initialized with exactly 1 baseline active instance:

⚙️ Programming the Metrics Sensor (Autoscale Policies)

Next, I programmed the metric sensor logic to track the infrastructure and scale out by 1 instance if the average CPU exceeds 70% for a brief 3-minute aggregation window:

# 4. Initialize the Autoscale Profile Container
az monitor autoscale create \
  --resource-group Marathahalli_Lab_RG_V2 \
  --resource WebAppVMSS \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name CPU_Autoscale_Policy \
  --min-count 1 \
  --max-count 3 \
  --count 1

# 5. Inject the Automatic Scale-Out Trigger rule logic
az monitor autoscale rule create \
  --resource-group Marathahalli_Lab_RG_V2 \
  --autoscale-name CPU_Autoscale_Policy \
  --scale out 1 \
  --condition "Percentage CPU > 70 avg 3m"

📸 Proof Point 2: Visual Metric Sensor Configured

This screenshot inside the Availability + scale rules dashboard shows our metric collection rules are armed, active, and tracking the fleet:

📓 The TAC Engineer's Troubleshooting Journal: 3 Massive Roadblocks Solved

This project was a massive lesson in cloud operations. Here are the three production-grade engineering blocks I faced and how I engineered around them:

🚨 Block 1: The Global SKU Capacity Crunch (`Code: SkuNotAvailable`)

The Challenge: My initial deployment targets (Standard_B2s and Standard_B2s) failed preflight checks across multiple data center regions due to strict free-trial resource pool capacity restrictions enforced by Azure during regional peak traffic.
The Resolution: I pivoted the architecture parameters to use Standard_D2s_v5—a mainstream enterprise-grade tier shape. Azure maintains deep hardware capacity pools for this size, allowing the fleet to provision cleanly on the very first try.

🚨 Block 2: Hostname Syntax Validation Fault (`Code: InvalidHostNamePrefix`)

The Challenge: My scale set name originally contained underscores (WebApp_VMSS). Linux operating systems strictly forbid underscore characters inside virtual computer hostnames, causing Azure's orchestration manager to drop the deployment at the gate.
The Resolution: I refactored the infrastructure naming convention completely to use clean CamelCase formatting (WebAppVMSS), passing validation instantly.

🚨 Block 3: The Deprovisioning Cloud Racing Condition (`Code: ResourceGroupBeingDeleted`)

The Challenge: While rebuilding my lab, I issued a resource teardown command. Because I used the --no-wait flag, Azure's background deletion thread was still clearing out old network paths. When my new script immediately tried to claim the network domain, it crashed because the resource group container was locked in a deprovisioning state.
The Resolution: I bypassed the locks seamlessly by appending _V2 to my Resource Group parameters, creating a brand new isolated deployment space instantly without sitting around waiting for background processes to clean up.

🚀 Live Workload Stress Simulation & Validation

To test the resilience of the architecture without worrying about external firewall rules or load balancer SSH blocks, I leveraged Azure's global Run Command infrastructure to trigger a synthetic traffic spike directly inside the running compute node:

az vmss run-command invoke \
  --resource-group Marathahalli_Lab_RG_V2 \
  --name WebAppVMSS \
  --instance-id 0 \
  --command-id RunShellScript \
  --scripts "sudo apt-get update && sudo apt-get install stress -y && stress --cpu 4 --timeout 240"

The command successfully pulled down the stress utility binaries and pinned all virtual processors at 100% load.

📸 Proof Point 3: Automatic Backup Arrives!

Exactly 3 minutes later, the autoscale engine registered the CPU breach, evaluated the threshold rules, and automatically spawned WebAppVMSS_1 entirely on its own to support the environment:

💡 Core AZ-104 Exam Lessons Learned

Uniform vs. Flexible Orchestration: Uniform mode forces strict identical virtual machine instances from a pre-defined image template, which is ideal for stateless web app clusters.
Layer 4 Load Balancing Integration: High-availability computing sets handle internal address assignment automatically, abstracting node pools completely behind a single virtual front gate.
Metric Cooldown Metrics: Setting appropriate cooldown aggregation time grains prevents "flapping conditions"—where nodes continuously scale up and down rapidly due to volatile traffic ripples.

⏱️ Cost Management Rule (FinOps Discipline)

To preserve promotional cloud tier credits, the high-availability resource infrastructure group was entirely wiped out the moment verification proofs were saved:

az group delete --name Marathahalli_Lab_RG_V2 --yes --no-wait

The Underground Tunnel: How I Locked Down Enterprise Storage Without Breaking the App

Abhishek Kadlii — Thu, 17 Sep 2026 07:24:43 +0000

Many people think securing data in the cloud just means setting a strong password. But in enterprise cloud security, leaving a storage account accessible via the public internet—even with a strong password—is like putting a heavy steel bank vault right on a busy public street. Anyone walking by can try to pick the lock or scan it.

To solve this, I completely smashed that front public door shut and dug a private underground tunnel—known as an Azure Private Endpoint—connecting my application server directly to the vault.

🏰 The Analogy: Public Street Vault vs. Underground Tunnel

The Public Endpoint (Vulnerable): Your bank vault sits on a busy highway. Even though it is locked, hackers worldwide can knock on the door, scan your firewall mechanisms, and bombard it with traffic.
The Private Endpoint (Secured): You disable the public street door completely. Then, you dig a private access tunnel from the basement of your internal app building straight into the vault. No one on the public street can even see that the door exists.

[ Internet / Hackers ] ───► ❌ (Public Access Blocked at Edge)

[ App Subnet: 10.0.1.0/24 ] ──(Private IP: 10.0.1.4)──► [ Blob Storage Vault ]
                                      ▲
                                      │ (Resolved via Private DNS Zone)

🛠️ Step-by-Step Implementation

1. Locking the Vault (Disabling Public Access)

First, I created the storage account and explicitly revoked public network access from the outside world using the Azure CLI:

# Create the Storage Account
az storage account create -g Marathahalli_Lab_RG -n storevaultsea20949 -l southeastasia --sku Standard_LRS

# Block all public network access at the front gate
az storage account update -g Marathahalli_Lab_RG -n storevaultsea20949 --public-network-access Disabled

📸 Proof Point 1: Smashed Front Gate

This verification step in the Azure Portal shows that public network entry points are 100% disabled:

2. Digging the Underground Tunnel (Private Endpoint)

Next, I carved out a dedicated, internal private IP address on my virtual network subnet and wired it directly to the Blob storage service:

az network private-endpoint create \
  -g Marathahalli_Lab_RG \
  -n Storage_Private_Endpoint \
  --vnet-name Sec_Hub_SEA_VNet \
  --subnet Management_SEA_Subnet \
  --private-connection-resource-id $(az storage account show -g Marathahalli_Lab_RG -n storevaultsea20949 --query id -o tsv) \
  --group-id blob \
  --connection-name Blob_Private_Conn

📸 Proof Point 2: The Private Interface Allocation

By inspecting the network interface generated by the private link endpoint, we can see that it grabbed the internal IP 10.0.1.4 straight out of our virtual network subnet:

3. Overriding the Map (Private DNS Zone Integration)

Normally, when a computer looks up a storage URL, the internet returns a public IP address. To force traffic through our underground tunnel, I built an internal Private DNS zone to override that lookup map locally:

# Create the Private DNS Zone mandated for Azure Blobs
az network private-dns zone create -g Marathahalli_Lab_RG -n privatelink.blob.core.windows.net

# Link the Private DNS Zone to our Virtual Network
az network private-dns link vnet create \
  -g Marathahalli_Lab_RG \
  -z privatelink.blob.core.windows.net \
  -n Link_Hub_VNet \
  -v Sec_Hub_SEA_VNet \
  --registration-enabled false

# Bind the Private Endpoint configuration to register the internal A-record automatically
az network private-endpoint dns-zone-group create \
  -g Marathahalli_Lab_RG \
  --endpoint-name Storage_Private_Endpoint \
  --name Storage_DNS_Group \
  --private-dns-zone privatelink.blob.core.windows.net \
  --zone-name blob

📸 Proof Point 3: The Private Route Record Mapping

This is the ultimate verification. In the Private DNS Recordsets grid, our unique cloud storage endpoint URL maps perfectly onto our internal private IP address:

🛑 The Real-World Blocker: The 403 Forbidden Shock

During initial testing from inside an application server, trying to fetch a file threw a glaring error: AuthorizationFailure: This request is not authorized to perform this operation.

The Root Cause: The server was still asking public internet DNS servers for the location, resolving the blocked public interface instead of using the private endpoint.
The Fix: I properly linked the Private DNS zone configuration to the Private Endpoint. Azure automatically created an internal A Record pointing the storage link straight to our internal IP address (10.0.1.4). The request instantly traversed the private network backbone safely.

💡 Core AZ-104 Exam Takeaways

Public Network Access Drop: Setting this to Disabled tells Azure's edge routing layer to drop incoming public packets immediately before they reach your data.
Private Endpoints: This injects a Virtual Network Interface Card (vNIC) into a subnet, giving a multi-tenant platform service a dedicated private entry point.
Conditional Forwarding Override: Azure uses the specific privatelink.blob.core.windows.net namespace internally to override standard internet routing routes cleanly.

⏱️ Sandbox Cleanup

To ensure compliance with strict cloud sandboxing constraints and avoid lingering costs on the tier, the resources were immediately deleted using:

az group delete --name Marathahalli_Lab_RG --yes --no-wait

Shifting to IaC: Writing the 183-Line Central Firewall Engine in Bicep When the Portal Hits a Wall | Day 9 & 10

Abhishek Kadlii — Wed, 27 May 2026 06:45:25 +0000

In my Day 8 lab, we successfully executed a classic data-plane traffic hijack. By forging a User Defined Route (UDR) for 0.0.0.0/0 on our Spoke network (Sec_Spoke_SEA_VNet), we successfully ripped traffic away from its default internet path and funneled it straight into a virtual appliance placeholder IP at 10.0.1.4 inside our Hub. As my terminal verification tests proved, outbound internet transit hit a hard 100% packet hole.

For Days 9 & 10, the mission was clear: replace that placeholder IP with a live, stateful Azure Native Firewall (Basic SKU) to intercept, inspect, and enforce rule collections on those hijacked packets.

Then, reality hit. Mid-sprint, my active 30-day promotional credit pool hit its expiration safety boundary. My portal dashboard flagged a paused state with an absolute balance of ₹0.00.

In a production enterprise environment, infrastructure blockers like this happen all the time. Budgets freeze, subscription terms shift, or portal access gets locked down. As a Network Security Engineer transitioning into DevSecOps, you don’t stop the roadmap; you change your delivery mechanism. Instead of manually clicking buttons inside the billing-active Azure Portal GUI, I pivoted immediately. I abstracted our entire physical network, routing states, peering hooks, and stateful security rules into a single, declarative Infrastructure-as-Code (IaC) deployment blueprint using Azure Bicep.

By moving from the GUI to local code, I built and validated the complete security engine architecture entirely for free inside Visual Studio Code with zero out-of-pocket financial risk.

The Network Logic: What Are We Architecting?

Before looking at the codebase, let’s map out exactly how data packets traverse this topology during runtime:

[ Private Spoke Subnet: 10.1.1.0/24 ]
│
▼ (User Defined Route: 0.0.0.0/0 ➔ Next Hop: 10.0.2.4)
[ AzureFirewallSubnet: 10.0.2.0/24 ] ──► Stateful Inspection Engine
│
├──► Matched Rule (UDP Port 53) ──► Allowed ──► Source NAT (SNAT) ➔ Internet
└──► Unmatched Rule (TCP 80/443) ──► Dropped ➔ Implicit Deny Posture

If you are coming from a traditional Network Security TAC background (like managing Palo Alto Prisma Access service connections or security zones), this setup mimics a centralized Next-Generation Firewall (NGFW) deployment.

The private Spoke VM does not have a public interface or an internet gateway. When it tries to talk to the outside world, our UDR acts as a mandatory signpost forcing the packet across the VNet Peering highway into the Hub's AzureFirewallSubnet at coordinate 10.0.2.4. The firewall then parses the packet from Layer 3 up to Layer 7, cross-references it with our rule policy, and decides whether to let it transit or drop it on the floor.

Complete Enterprise-Grade Bicep Security Blueprint

Below is the complete, unedited 183-line Bicep file that builds the entire baseline network fabric and trains the central firewall's inspection engine:

param location string = 'southeastasia'

// ===================================================================
// 1. CENTRAL ROUTE TABLE (THE TRAFFIC HIJACK SIGNPOST)
// ===================================================================
resource spokeRouteTable 'Microsoft.Network/routeTables@2023-09-01' = {
  name: 'Spoke_To_Hub_RT'
  location: location
  properties: {
    routes: [
      {
        name: 'Route_To_Hub'
        properties: {
          addressPrefix: '0.0.0.0/0'         // Intercepts all outbound internet traffic
          nextHopType: 'VirtualAppliance'     // Overrides default system provider routing
          nextHopIpAddress: '10.0.2.4'       // Core internal private IP of our Azure Firewall
        }
      }
    ]
  }
}

// ===================================================================
// 2. CORE HUB NETWORK (MANAGEMENT, FIREWALL, AND GATEWAY SEGMENTS)
// ===================================================================
resource hubVnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: 'Sec_Hub_SEA_VNet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [ '10.0.0.0/16' ]
    }
    subnets: [
      {
        name: 'Management_SEA_Subnet'
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
      {
        name: 'AzureFirewallSubnet'         // Mandated structural name for native engine binding
        properties: {
          addressPrefix: '10.0.2.0/24'
        }
      }
      {
        name: 'GatewaySubnet'               // Reserved segment for future VPN/ExpressRoute Gateways
        properties: {
          addressPrefix: '10.0.3.0/24'
        }
      }
    ]
  }
}

// ===================================================================
// 3. SPOKE PRODUCTION NETWORK (BOUND TO TRAFFIC HIJACK UDR)
// ===================================================================
resource spokeVnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: 'Sec_Spoke_SEA_VNet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [ '10.1.0.0/16' ]
    }
    subnets: [
      {
        name: 'App_Prod_Subnet'
        properties: {
          addressPrefix: '10.1.1.0/24'
          routeTable: {
            id: spokeRouteTable.id           // Associates the traffic-hijacking UDR table
          }
        }
      }
    ]
  }
}

// ===================================================================
// 4. BIDIRECTIONAL NETWORK PEERING: HUB TO SPOKE
// ===================================================================
resource hubToSpokePeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  parent: hubVnet
  name: 'Hub_To_Spoke_Peer'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
    remoteVirtualNetwork: {
      id: spokeVnet.id
    }
  }
}

// ===================================================================
// 5. BIDIRECTIONAL NETWORK PEERING: SPOKE TO HUB
// ===================================================================
resource spokeToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  parent: spokeVnet
  name: 'Spoke_To_Hub_Peer'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
    remoteVirtualNetwork: {
      id: hubVnet.id
    }
  }
}

// ===================================================================
// 6. CENTRAL FIREWALL PUBLIC EGRESS INTERFACE (PUBLIC IP)
// ===================================================================
resource firewallPublicIP 'Microsoft.Network/publicIPAddresses@2023-09-01' = {
  name: 'Sec_Hub_FW_PIP'
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
  }
}

// ===================================================================
// 7. CENTRAL FIREWALL POLICY CONTAINER (THE SECURITY RULEBOOK)
// ===================================================================
resource firewallPolicy 'Microsoft.Network/firewallPolicies@2023-09-01' = {
  name: 'Hub_Central_FW_Policy'
  location: location
  properties: {
    sku: {
      tier: 'Basic'
    }
  }
}

// ===================================================================
// 8. CENTRAL NATIVE FIREWALL ENGINE PROVISIONING
// ===================================================================
resource azureFirewall 'Microsoft.Network/azureFirewalls@2023-09-01' = {
  name: 'Central-Security-Engine'
  location: location
  properties: {
    sku: {
      name: 'AZFW_VNet'
      tier: 'Basic'
    }
    firewallPolicy: {
      id: firewallPolicy.id
    }
    ipConfigurations: [
      {
        name: 'fw-ip-config'
        properties: {
          publicIPAddress: {
            id: firewallPublicIP.id
          }
          subnet: {
            id: '${hubVnet.id}/subnets/AzureFirewallSubnet' // Drops interface into reserved subnet
          }
        }
      }
    ]
  }
}

// ===================================================================
// 9. STATEFUL RULE COLLECTION GROUP (LAYER 4 NETWORK FILTER RULES)
// ===================================================================
resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2023-09-01' = {
  parent: firewallPolicy
  name: 'Outbound_Traffic_RCG'
  properties: {
    priority: 1000
    ruleCollections: [
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Allow_Core_Network'
        priority: 1100
        action: {
          type: 'Allow'
        }
        rules: [
          {
            ruleType: 'NetworkRule'
            name: 'Allow_DNS'
            ipProtocols: [
              'UDP'
            ]
            sourceAddresses: [
              '10.1.1.0/24'                  // Permits packets originating from Spoke Prod Subnet
            ]
            destinationAddresses: [
              '8.8.8.8'                      // Target: Google Primary DNS
              '8.8.4.4'                      // Target: Google Secondary DNS
            ]
            destinationPorts: [
              '53'                           // Limits traffic strictly to DNS query protocols
            ]
          }
        ]
      }
    ]
  }
}

Deep-Dive: Code Logic & Packet Inspection Mechanics

When discussing this topology in enterprise cloud security interviews, you must be able to trace how this specific code handles packet state:

The UDR Override Mechanics (Resource 1): By declaring a custom route for 0.0.0.0/0 with a nextHopType of VirtualAppliance, we explicitly override default systemic routing. The infrastructure forces the next-hop IP mapping to match 10.0.2.4, which is the exact internal interface of our upcoming firewall engine.
The API Subnet Constraint (Resource 2): The Azure resource provider imposes a strict naming policy. A native firewall cannot attach to an arbitrarily named subnet profile. It searches exclusively for a subnet token string labeled AzureFirewallSubnet. We carved out a dedicated /24 block (10.0.2.0/24) to handle the private clustering interfaces of the engine.
Stateful Layer 4 Filtering (Resource 9): This section defines our firewall policy rulebook. The engine operates on an Implicit Deny architecture—if a packet parameter profile does not explicitly match an allowed rule entry, it drops dead at the gate.
- The Allowed Execution Flow: A workload inside our Spoke network (10.1.1.0/24) generates a standard domain name lookup request toward external DNS resolver 8.8.8.8 over UDP Port 53. The firewall parses the packet headers, finds an exact match inside our Allow_DNS rule matrix, permits the transit, and executes Source NAT (SNAT) using our public IP (Sec_Hub_FW_PIP) to preserve private topology boundaries.
- The Implicit Deny Flow: A background process or a user inside that same Spoke network attempts to establish an outbound web session over HTTP (Port 80) or HTTPS (Port 443). The packet hit the firewall interface. The stateful inspector reviews the policy definitions, encounters an absolute absence of any rule mapping ports 80/443, and silently drops the connection instantly.

Code Logic & Traffic Processing Deep-Dive

To demonstrate absolute operational mastery during cloud engineering interviews, we must break down how this file behaves during active network runtime:

Resource 1 (spokeRouteTable): This object overrides default routing behavior. By creating a custom route entry for 0.0.0.0/0 (all internet traffic) with a nextHopType parameter explicitly declared as VirtualAppliance, we disrupt standard network isolation. Any server on this subnet that tries to reach an external resource is automatically pointed directly to 10.0.2.4.
Resource 2 (hubVnet) Subnet Naming Constraint: The Azure API dictates that a native firewall appliance cannot bind to an arbitrary subnet profile. It requires an exact structural string identifier named AzureFirewallSubnet. We carved out a dedicated /24 block (10.0.2.0/24) to handle the clustering interfaces of the underlying infrastructure.
Resource 9 (ruleCollectionGroup) Layer 4 Parsing: This is where our packet filtering criteria are established. The firewall runs a stateful inspection engine, matching source vectors against destination coordinates.
- The Evaluated Match: When a compute host inside our Spoke network (10.1.1.0/24) generates an upstream lookup request toward 8.8.8.8 on UDP Port 53, the firewall validates an exact parameter match in its rule collection and permits egress traffic while executing Source NAT (SNAT).
- The Implicit Deny Enforcement: If an active process on that same workload attempts to create an outbound HTTP web session on port 80 or an HTTPS connection on port 443, the data packet hits the firewall interface. The engine reviews the policy rules, encounters a total absence of any rule covering ports 80/443, and instantly drops the connection with zero response back to the client.

Compilation Verification & Local Quality Control

To ensure the technical validity, reference bindings, and compliance of this 183-line enterprise design without launching live, billing-active resources, I leveraged the built-in Microsoft Bicep language compilation workspace inside Visual Studio Code.

The compiler ran an extensive static validation analysis across our declared topography configurations, network peering structures, and rule groups, verifying a completely flawless design layout:

The local IDE output officially confirmed: No problems have been detected in the workspace.

The Live Traffic Intercept: Bringing the Cloud Fortress to Life (Day 8)

Abhishek Kadlii — Mon, 25 May 2026 06:49:22 +0000

As I was curious after reading and implementing the User-Defined Routing (UDR) and subnet-slicing concepts previously, I couldn't wait to test this out under live traffic conditions. Theory is fine on paper, but as an infrastructure engineer, I don't truly trust a network design until I break it, throw live packets at it, and look at the raw terminal logs.

Tonight, I stepped completely out of the textbooks and moved assets onto the cloud field. I deployed two live virtual servers inside my Singapore network sandbox, faced down strict regional quota walls, bypassed local internet restrictions, and operationally proved that my traffic hijacking detour rule works perfectly under real production conditions.

Here is the step-by-step engineering log of how I did it, the real-world troubleshooting steps I took, and the underlying mechanics explained so simply that anyone can understand it.

🏛️The Day 8 Deployment Strategy: Setting the Field

To safely test our custom detour signpost without opening our network to the public internet, I had to deploy two distinct virtual machines into my sandbox environment. To keep my billing running at exactly ₹0/hour, I utilized Microsoft's newer, high-performance AMD free-tier eligible engine size (Standard_B2ats_v2).

💡The Analogy: The Front Security Lobby vs. The Locked Back Vault

Hub-Mgmt-VM (The Front Lobby Desk): This machine sits right inside the public entryway of our network (Management_SEA_Subnet). It is given an official, fixed public street address (Static Public IP) so that administrators can find it and log into it from the outside world.
Spoke-App-VM (The Hidden Back Vault): This machine sits deep inside the isolated production floor (App_Prod_Subnet) within the Spoke VNet. To maintain strict security, this machine is given absolutely no public front door. It has no public IP address, making it completely invisible to the internet and dependent on our hub-and-spoke bridge to talk to the world.

🛠️The Step-by-Step Command-Line Execution

Instead of clicking through the graphics of the Azure Portal GUI, I typed the deployment scripts manually into the Azure Cloud Shell to burn the syntax directly into my muscle memory.

Generating the Golden Cryptographic Login Keys

Before spinning up the servers, I generated a pair of secure cryptographic keys. In professional enterprise security, we completely ban weak, guessable text passwords. Instead, we use advanced mathematics to generate an interconnected Private Golden Key (kept in our pocket) and a matching Public Lock (bolted onto the server door).

`bash

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""
`

🚙Code Decoder (Line-by-Line):

ssh-keygen - Starts the security engine tool to manufacture secure digital keys and locks.

-t rsa - Tells the computer to use the industry-standard RSA math algorithm for maximum security.

-b 2048 - Makes the lock 2,048 bits thick, which would take supercomputers billions of years to crack.

-f ~/.ssh/id_rsa - Saves your private golden key as id_rsa and your public lock as id_rsa.pub in a hidden folder.

-N "" - Assigns a blank passphrase so our automation code can read the keys instantly without annoying prompts.

Provisioning the Entryway Jump Box (Hub Machine)

I launched the administrative entryway machine directly inside the Singapore network layout using our AMD free-tier compute profile:

`bash 

az vm create -g Marathahalli_Lab_RG -n Hub-Mgmt-VM --location southeastasia --vnet-name Sec_Hub_SEA_VNet --subnet Management_SEA_Subnet --image Ubuntu2204 --size Standard_B2ats_v2 --admin-username abhishek --ssh-key-values ~/.ssh/id_rsa.pub --public-ip-address-allocation static
`

🚙Code Decoder (Line-by-Line):

az vm create - Orders Azure to go to its physical hardware racks and carve out a new virtual server.

-g Marathahalli_Lab_RG - Groups all the server assets (disks, cards) inside my regional resource folder.

-n Hub-Mgmt-VM - Labels this machine "Hub-Mgmt-VM" so we can easily track it in logs.

--location southeastasia - Bypasses local data center hardware shortages by building the machine straight in Singapore.

--vnet-name Sec_Hub_SEA_VNet - Plugs this machine's network card directly into our central Hub network.

--subnet Management_SEA_Subnet - Drops the machine into the dedicated room reserved for administrative management desks.

--image Ubuntu2204 - Installs a clean, production-ready version of the Ubuntu Linux 22.04 operating system.

--size Standard_B2ats_v2 - Our Zero-Cost Safeguard; chooses a dual-core AMD size that is 100% free-tier eligible.

--admin-username abhishek - Creates the master administrator user profile inside the Linux operating system.

--ssh-key-values ~/.ssh/id_rsa.pub - Takes the public lock file we created earlier and bolts it onto the server login gate.

--public-ip-address-allocation static - Gives this lobby desk a fixed, unchanging internet address so we can always connect from home.

Provisioning the Completely Private Workload (Spoke Machine)

Next, I launched our isolated application instance. Notice the empty quotes at the very end of the script—this explicitly commands Azure to deny this machine a public IP door, keeping it completely private:

`bash

az vm create -g Marathahalli_Lab_RG -n Spoke-App-VM --location southeastasia --vnet-name Sec_Spoke_SEA_VNet --subnet App_Prod_Subnet --image Ubuntu2204 --size Standard_B2ats_v2 --admin-username abhishek --ssh-key-values ~/.ssh/id_rsa.pub --public-ip-address ""
`

🚙Code Decoder (Line-by-Line):

--vnet-name Sec_Spoke_SEA_VNet - Targets our Spoke Network instead of our Hub network.

--subnet App_Prod_Subnet - Drops this machine onto our isolated production factory floor block.

--public-ip-address "" - The Isolation Shield; passing empty quotes forbids Azure from giving this server a public IP address.

📊 The Routing Validation Blueprint: The Live Tests

Once both servers were live, it was time to run our live validation test plan. We need to mathematically and operationally prove that our traffic hijacking detour rules are working.

`    ===================================================================================
    =                         THE LIVE TRAFFIC FLOW DIAGRAM                           =
    ===================================================================================

     [ Home/Cloud Terminal ] --(Passes Through)--> [ Hub Lobby Jump Box: 10.0.1.4 ]



                                                            |
                                                   (VNet Peering Bridge)
                                                            |
                                                            v
     [ Internet: 8.8.8.8 ] <---(100% PACKET LOSS!)--- [ Private Spoke VM: 10.1.1.4 ]
          ^                                                 |



          |                                        (User-Defined Route)
          |                                                 |
          +=========== (HIJACKED TO BLACK HOLE!) ===========+
`

Test 1: The Master Itinerary Manifest Audit (Effective Routes Query)

Before sending a packet, I queried Azure’s network routing engine directly to show me what map the Spoke network interface was using under the hood:

`bash

az network nic show-effective-route-table -g Marathahalli_Lab_RG -n Spoke-App-VMVMNic -o table
`

🚙Code Decoder (Line-by-Line):

az network nic - Targets the virtual Network Interface Card attached to our private Spoke server.

show-effective-route-table - Interrogates Azure's live routing processor to show the active traffic map.

-n Spoke-App-VMVMNic - Targets the specific system name of our Spoke machine's network adapter card.

-o table - Orders the output messy code to cleanly rearrange itself into a beautiful grid with headers.

The result was an absolute architectural victory! The table showed our manual detour route for 0.0.0.0/0 sitting as Active, while Azure’s native, unmonitored default highway to the internet was marked as completely Invalid.

Test 2: The Inner Private Walkway Check (The Peering Bridge Jump)

I used secure SSH Agent Forwarding (ssh -A) to pass through my public entryway lobby box and jump straight onto the internal private IP of our isolated Spoke machine (10.1.1.4).

Once inside the Spoke machine's shell prompt, I executed an internal connectivity check back to the Hub:

`bash

ping -c 4 10.0.1.4
`

🚙Code Decoder (Line-by-Line):

ping - Sends small network test packets to an IP address to see if it is awake.

-c 4 - Sets a count limit flag; stops sending test packets automatically after 4 attempts.

10.0.1.4 - Targets the private internal IP coordinate of our Hub management desk room.

The packets zoomed across the private VNet Peering footbridge instantly, returning a perfect 0% packet loss statistic. This proved that our internal private communication lines were completely healthy and operational.

Test 3: The Black Hole Validation Check (The Ultimate Hijack Proof)

Now, the grand finale. While standing inside the private Spoke machine, I attempted to send a packet out to Google's public internet server:

`bash

ping -c 4 8.8.8.8
`

🚙Code Decoder (Line-by-Line):

8.8.8.8 - Targets a well-known public internet server (Google's Public DNS infrastructure).

The terminal hung for a moment, and then returned exactly 100% packet loss.

In ordinary desktop computing, losing all your packets looks like a failure. But in Cloud Network Security Engineering, this is a spectacular win! It operationally proves that our custom detour sign successfully intercepted the outbound internet packet at the subnet boundary and shoved it down our secure detour corridor. Because we haven't built the actual firewall software engine at that destination endpoint yet, the traffic terminates safely at that empty boundary, confirming that our perimeter isolation is working flawlessly.

💰Financial Discipline Check: Protecting the Trial Runway

By maintaining strict enterprise resource boundaries and leveraging Azure's dual-core AMD free-tier eligible compute allocations, our active sandbox running cost sits at exactly ₹0 per hour. This leaves my full promotional credit balance safe at ~₹18,909 for our upcoming security engine deployments.

🏁Day 8 Wrap-Up

Tonight was a massive architectural leap forward. By typing out raw CLI statements, resolving core quotas, and validating data-plane packet paths step by step, I am locking in the exact hands-on engineering confidence needed for senior enterprise technical panels.

The isolated sandbox field is fully verified. Next up, we deploy our central security engine—the live Azure Native Firewall—to capture that black-holed traffic, inspect it, and safely bridge our secure fortress out to the public web!

🛠️Safe Infrastructure Resting Script

To keep our active billing runway perfectly protected while we draft our notes, I executed a master deallocation script from the Cloud Shell Control Tower to put both machines into deep freeze at zero cost:

`bash

az vm deallocate -g Marathahalli_Lab_RG --ids $(az vm list -g Marathahalli_Lab_RG --query "[].id" -o tsv) --no-wait
`

🚙Code Decoder (Line-by-Line):

az vm deallocate - Commands Azure to stop compute billing entirely by releasing our CPU/RAM chips back into the shared datacenter pool.

$(az vm list ... --query "[].id" -o tsv) - Automatically compiles a neat list of every single virtual machine ID inside our resource group folder.

--no-wait - Forces the command to process silently in the background so we can instantly turn off our computer.

Onward and upward! 🚀🔥

Sunday Double-Header: Erecting Checkpoints and Traffic Hijacking in the Cloud (Day 6 & 7)

Abhishek Kadlii — Mon, 25 May 2026 03:57:40 +0000

Continuing the weekend grind into Sunday night, I shifted my focus to a fundamental truth of enterprise cloud security: never trust a clear road. For the Day 6 and 7 double-header of my career transition blueprint, I decided to take the automatic, unmonitored highways that cloud providers build behind the scenes and completely tear them up. I moved away from simply connecting networks to executing a tactical traffic intercept—focusing on breaking down complex routing math into plain English and carving out clean, industrial-grade security checkpoints without spending a single rupee of my trial credit.

By stepping completely out of the default cloud configuration mindset, I learned how to manually intercept global network traffic patterns and carve out specialized infrastructure zones to prepare my central cloud fortress for future Next-Generation Firewalls.

Here is the technical blueprint of what I built, the real-world engineering constraints I had to solve, and the core routing mechanics broken down so simply that anyone can grasp them.

🏛️Day 6: Setting the Detour (User-Defined Routes)

Up until yesterday, our Hub VNet (the central terminal) and Spoke VNet (the application floor) were connected by a private footbridge called VNet Peering.

💡The Analogy: The Unmonitored Highway vs. The Mandatory Detour

The Default State (System Routes): By default, Azure automatically hands a GPS map to every packet traveling between networks. If a machine inside the Spoke wants to talk to the Hub, the GPS takes it across a direct highway with zero checks, zero gates, and zero security guards. If a hacker breaches an application server, they can walk right into the corporate data center.
The Secured State (User-Defined Routes / UDR): Imagine erecting a massive concrete jersey barrier across that highway and placing a giant Mandatory Detour Sign right at the exit gate of the Spoke subnet. The sign states: "You are no longer allowed to use the direct highway. All traffic leaving this building must exit down a side road and report straight to the Security Guard Post inside the Hub first."

In the cloud world, we call this Traffic Hijacking or packet interception. We are manually ripping up Azure's automatic mapping instructions and overriding them with our own strict routing rules to force data into a secure checkpoint queue.

🛠️The Day 6 Command-Line Blueprint

I cleared my terminal and typed these out manually to build the detour signpost and bolt it down to the application floor:

`bash

# 1. Create the physical wooden signpost frame (Route Table)
az network route-table create -g Marathahalli_Lab_RG -n Spoke_To_Hub_RT -l southeastasia

# 2. Paint the specific "Hijack" instruction onto the signpost
az network route-table route create -g Marathahalli_Lab_RG --route-table-name Spoke_To_Hub_RT -n Intercept_All_Traffic --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.1.4

# 3. Bolt the signpost down to the exit door of our production application road
az network vnet subnet update -g Marathahalli_Lab_RG --vnet-name Sec_Spoke_SEA_VNet -n App_Prod_Subnet --route-table Spoke_To_Hub_RT
`

🔍Deep-Dive Concept: The Rule of the Longest Prefix Match (LPM)

When an individual router handles a packet, it might look at its manual and see multiple matching instructions. Azure resolves this conflict using a strict mathematical law: The most specific rule (the one with the longest bitmask number) ALWAYS wins.

The Interview Trap to Watch Out For:

If a packet leaves our Spoke subnet heading toward an IP address like 10.0.1.5, it matches two rules:

Our custom catch-all UDR: 0.0.0.0/0 (Length: 0)
Azure's default peering route: 10.0.0.0/16 (Length: 16)

Because 16 is a longer, more precise match than 0, Azure will prioritize the default route and completely bypass our custom detour sign! To successfully force local traffic through our future firewall, we must explicitly write a highly specific UDR targeting the 10.0.0.0/16 corporate range directly.

🚀 Day 7: Carving Out the Hub Infrastructure Containment Zones

Once the detour signpost was securely bolted down, I immediately pivoted to Day 7 to prepare the landing pads inside the central Hub network (Sec_Hub_SEA_VNet). Perimeter security engines cannot simply be dropped into regular network subnets alongside administrative tools. They require completely clean, walled-off infrastructure zones.

💡The Analogy: The Airplane Cockpit and the Loading Dock

The Firewall Zone (AzureFirewallSubnet): Think of this like the Cockpit of a commercial airliner. It is a highly restricted room built for exactly one purpose: holding the pilots and the flight controls. Regular passengers are physically banned from walking inside or pulling up a desk there. If they do, they could accidentally hit a control lever and crash the plane.
The Gateway Zone (GatewaySubnet): Think of this like a heavy-duty corporate Loading Dock at the back of the facility. It is fenced off exclusively to receive massive cargo trucks coming from your physical on-premise headquarters or your home network testing labs via secure underground transit tunnels.

🛠️The Day 7 Command-Line Blueprint

I opened up my ledger book and manually carved out these two specialized rooms, making sure to use the exact case-sensitive names strictly required by Azure's background automated logic:

`bash

# 1. Carve out the restricted Cockpit zone on Page 2 of our ledger
az network vnet subnet create -g Marathahalli_Lab_RG --vnet-name Sec_Hub_SEA_VNet -n AzureFirewallSubnet --address-prefixes 10.0.2.0/24

# 2. Carve out the secure Loading Dock zone on Page 3 of our ledger
az network vnet subnet create -g Marathahalli_Lab_RG --vnet-name Sec_Hub_SEA_VNet -n GatewaySubnet --address-prefixes 10.0.3.0/24
`

📊The Evolving Network Topology Map

`       ===================================================================
       =                       MARATHAHALLI_LAB_RG                       =
       ===================================================================

         [ SEC_SPOKE_SEA_VNET ]                  [ SEC_HUB_SEA_VNET ]
             (10.1.0.0/16)                           (10.0.0.0/16)
        +-----------------------+               +-----------------------+



        |  [ App_Prod_Subnet ]  |               | [Management_SEA_Subnet|
        |     10.1.1.0/24       |               |     10.0.1.0/24       |
        +-----------+-----------+               +-----------+-----------+



                    |                                       |
                    | (Outbound Traffic)                    v
                    v                           +-----------------------+
         +---------------------+                |  AzureFirewallSubnet  |



         |  Spoke_To_Hub_RT    |                |  (The Cockpit Zone)   |
         |  (Route Table / UDR)|                |     10.0.2.0/24       |
         |   [0.0.0.0/0]------ | -----\         +-----------------------+
         +---------------------+       |                    |



                                       |                    v
             XXXXXXXXXXXXXXXXX         |         +-----------------------+
             X DEFAULT VNET  X         |         |     GatewaySubnet     |
             X PEERING ROUTE X         |         |  (The Loading Dock)   |
             X  (HIJACKED!)  X         |         |     10.0.3.0/24       |
             XXXXXXXXXXXXXXXXX         |         +-----------------------+



                    |                  |
                    \------------------+----> [ Future Firewall Appliance IP ]
                                                  (Placeholder Location: 10.0.1.4)
`

💰Financial Discipline Check: Protecting the Trial Runway

By adhering to strict enterprise resource management principles, all infrastructure components deployed over this double-header consist purely of logical network definitions, software route tables, and placeholder rule assignments.

Because no heavy virtual machine CPUs, hardware firewalls, or static public IPs were active during this configuration phase, my sandbox running cost sits at exactly ₹0 per hour. This leaves my ~₹18,909 Azure free trial credit pool 100% intact and optimized for our upcoming operational deployment labs.

🏁 Weekend Wrap-Up

This Sunday was a massive structural leap forward. By typing out raw CLI paths manually, mastering IP allocation constraints, and designing a secure perimeter architecture block by block, I am solidifying the muscle memory needed to sit across from senior infrastructure panels with real confidence.

The foundation is ready. Next week, we bring this network fortress to life by launching live testing workloads and configuring the traffic validation rules!

Onward and upward! 🚀🔥

Weekend Grind: Breaking the GUI Habit and Building a Scalable Cloud Fortress in Azure (Day 4 & 5)

Abhishek Kadlii — Sat, 23 May 2026 13:56:49 +0000

It is Saturday night in Bengaluru. While most people are out roaming around the outer ring road or chilling in cafes, I made a conscious choice to sit at my desk, open up my terminal, and grind. I want to be part of that 1% crowd—the professionals who don’t just talk about growth but are genuinely curious, willing to put in the hours, and execute.

Over this intense weekend session, I successfully shattered my dependency on the visual Azure Portal (GUI), moved completely into command-line infrastructure automation, and expanded my secure digital sandbox into an enterprise-grade network topology.

Here is exactly how I built it, the real-world bugs I encountered, and the core architectural concepts broken down so simply that even a non-technical person can understand them.

🛑Day 4: Moving from "Pointing-and-Clicking" to Code

Up until yesterday, I built my cloud infrastructure by manually clicking buttons, menus, and checkboxes inside the Azure Portal web interface.

💡The Analogy: The Hand-Carved Bakery vs. The Smart Machine

The Manual Way (Days 1–3): Imagine baking a cake where you have to manually measure flour, crack every egg, and closely watch the oven dial. This works great for one cake. But what if a major corporate company in Whitefield orders 500 identical cakes for an event? If you try to do it all by hand, it will take forever, you will get exhausted, and some cakes will inevitably taste different due to human error.
The Automation Way (Day 4): Imagine programming a digital, industrial smart-mixer. You type in the exact measurements into a script once, press a button, and the machine perfectly outputs 500 identical cakes with zero errors.

In the cloud world, we call this Infrastructure as Code (IaC). Enterprise networks are massive; we cannot scale by clicking buttons in a browser. We use text-based scripts to deploy identical, flawless environments in seconds.

🛠️ The Simplified Command-Line Blueprint

I opened up the browser-based Azure Cloud Shell and used Azure CLI to fire up my infrastructure using tight, professional shortcut flags:

-g stands for the Resource Group (our logical container).
-n stands for the Name of our resource.
-l stands for the Location (Southeast Asia/Singapore datacenters).

Here are the exact three direct commands that built my perimeter security:

BASH
# 1. Create the Security Guard Shack (Network Security Group)
az network nsg create -g Marathahalli_Lab_RG -n Sec_Hub_SEA_NSG -l southeastasia

# 2. Program the Guard to strictly allow my home ISP IP on Port 22 (SSH)
az network nsg rule create -g Marathahalli_Lab_RG --nsg-name Sec_Hub_SEA_NSG -n Allow_SSH_Home_Only --priority 100 --source-address-prefixes 205.254.163.132 --destination-port-ranges 22

# 3. Create the Private Network and bind it to the Guard Shack instantly
az network vnet create -g Marathahalli_Lab_RG -n Sec_Hub_SEA_VNet -l southeastasia --address-prefixes 10.0.0.0/16 --subnet-name Management_SEA_Subnet --subnet-prefixes 10.0.1.0/24 --nsg Sec_Hub_SEA_NSG

🔍 The Day 4 Troubleshooting Story: Defeating the Location Clash

When I first ran my script, Azure halted everything and threw a glaring red error:

[InvalidResourceLocation] The resource 'Sec_Hub_VNet' already exists in location 'centralindia' in resource group 'Marathahalli_Lab_RG'. A resource with the same name cannot be created in location 'southeastasia'

The Lesson:

During my early labs, I had manually created a network named Sec_Hub_VNet inside India. Today, my script tried to create a new network with the exact same name inside Singapore, but within the same resource group wrapper.

Azure taught me an important architectural lesson here: While a single Resource Group can hold assets from different cities around the world, it absolutely cannot hold two items that share the exact same name.

The Fix: I modified my automation script variables, changing the name to Sec_Hub_SEA_VNet. The script instantly cleared the validation check and deployed flawlessly.

🏛️Deep-Dive Concept: How Firewalls Process Cloud Traffic

As a Network Security Engineer, I had to understand exactly how Azure evaluates firewall rules when we bind them programmatically.
In Azure, you can attach Network Security Groups (NSGs) at two distinct boundaries: the Subnet level (the whole road) and the NIC level (the specific house's front door).

💡The Analogy: The High-Security Corporate Tech Park

Imagine visiting a secure corporate client office in Marathahalli:

The Subnet Gate: First, you drive up to the main outer gate of the tech park. Security checks your vehicle. If you are on the list, they let you drive onto the campus (Allow).
The NIC Gate: Next, you walk up to the glass door of Building 3 inside that campus. The security guard at that specific door checks your ID badge and says, "You don't have access to this particular building" (Deny).

Result? You get dropped right there on the floor. You cannot enter. For a packet to reach an application, both security checkpoints must say "Allow".

INBOUND PACKET FLOW:
[Public Internet] ---> ( Subnet NSG: ALLOW ) ---> ( NIC NSG: DENY ) ---> [ Packet Dropped! ]

🚀Day 5: Scaling Out to a Hub-and-Spoke Topology

Once Day 4's automation was rock solid, I immediately jumped into Day 5 to scale my lab into a production-grade architecture. Enterprise companies do not dump everything into a single network. They isolate environments using a Hub-and-Spoke Topology.

💡The Analogy: The International Airport Terminal

The Hub (Sec_Hub_SEA_VNet): Think of this like the main central airport terminal building. This is where customs officers stand, passport control happens, and bags are scanned. Everything entering or leaving the airport must go through here.
The Spoke (Sec_Spoke_SEA_VNet): Think of this like the isolated airplane boarding gates far down the hallway. Gate A houses domestic flights; Gate B houses cargo. These gates do not need their own expensive customs setups; they rely entirely on the main central terminal (The Hub) to keep them secure.

📊 The Network Topology Map (Architecture Layout)

                    [ PUBLIC INTERNET ]

                                |
                                | (Strict Port 22 Lockdown Rule)
                                v
     =================== HUB VNET (10.0.0.0/16) ===================

     |                                                            |
     |   [ Sec_Hub_SEA_NSG ] ---> Applied to Subnet Layer         |
     |            |                                               |
     |            v                                               |
     |   [ Management_SEA_Subnet ] (10.0.1.0/24)                  |
     |                                                            |
     ==============================================================

               |                                      ^
               |                                      |
               |-----> [ Hub-to-Spoke Peering ] ------|
               |       (Status: Connected)            |
               |                                      |
               |-----> [ Spoke-to-Hub Peering ] ------|
               v                                      |
     ================== SPOKE VNET (10.1.0.0/16) ==================

     |                                                            |
     |   [ App_Prod_Subnet ] (10.1.1.0/24)                        |
     |   (Production Database / App Microservices workloads)      |
     |                                                            |
     ==============================================================

💻 Day 5 Code: Line-by-Line Technical Breakdown

To build this architecture, I executed three specific commands. Here is exactly what each line does under the hood:

Creating the Spoke Network Space

`BASH
az network vnet create -g Marathahalli_Lab_RG -n Sec_Spoke_SEA_VNet -l southeastasia --address-prefixes 10.1.0.0/16 --subnet-name App_Prod_Subnet --subnet-prefixes 10.1.1.0/24
`

az network vnet create: Tells the Azure Resource Manager to carve out a new software-defined virtual network fabric.

-g Marathahalli_Lab_RG: Places this new network inside my existing resource group container.

-n Sec_Spoke_SEA_VNet: Names this specific network space our "Spoke".

--address-prefixes 10.1.0.0/16: Allocates a massive pool of over 65,000 private IPs. Critical detail: This does not overlap with our Hub network (10.0.0.0/16), completely preventing routing collisions.

--subnet-name App_Prod_Subnet --subnet-prefixes 10.1.1.0/24: Instantly slices out a subset corridor within the Spoke where our actual production application databases and web servers will live.

Building the Walkway: From Hub to Spoke

`BASH
az network vnet peering create -g Marathahalli_Lab_RG --vnet-name Sec_Hub_SEA_VNet -n Hub-to-Spoke --remote-vnet Sec_Spoke_SEA_VNet --allow-vnet-access
`

az network vnet peering create: Tells Azure to construct a low-latency, private routing bridge directly across the Microsoft backbone network.

--vnet-name Sec_Hub_SEA_VNet: Specifies the starting point of our bridge (The Hub).

-n Hub-to-Spoke: Labels this directional leg of the bridge.

--remote-vnet Sec_Spoke_SEA_VNet: Connects the other end of the bridge straight into our Spoke network asset.

--allow-vnet-access: Programmatically permits the virtual machines inside the Hub to talk across this bridge natively.

Completing the Two-Way Street: From Spoke to Hub

`BASH
az network vnet peering create -g Marathahalli_Lab_RG --vnet-name Sec_Spoke_SEA_VNet -n Spoke-to-Hub --remote-vnet Sec_Hub_SEA_VNet --allow-vnet-access
`

Why this line is mandatory: In cloud architecture, a peering connection is not automatically bidirectional. It is a one-way street until you configure the return path. This command sets the starting point at the Spoke (--vnet-name Sec_Spoke_SEA_VNet) and maps it right back to the Hub (--remote-vnet Sec_Hub_SEA_VNet), completing the secure loop.

💰Financial Discipline Check

Since I only deployed logical networking paths, subnets, and routing bridges without provisioning any heavy virtual machine CPU power today, my automated environment runs at a cost of exactly ₹0 per hour. My Azure free trial credits remain 100% optimized and safe.

🏁Weekend Wrap-Up

This weekend was a massive leap forward. By stepping completely out of the comfort zone of the graphical portal, writing raw CLI scripts, conquering real-world resource location bugs, and standing up a verified Hub-and-Spoke enterprise topology, I am actively building the real-world skills needed to command senior cloud security roles.

The grind continues, where we will start hijacking these default routing paths using User-Defined Routes (UDRs) to force all traffic through a centralized firewall!

Onward and upward!🚀🔥

🚀 My First Day in the Cloud: How I Built a Secured Digital Fortress in Azure

Abhishek Kadlii — Fri, 22 May 2026 07:41:14 +0000

Many people think learning "Cloud Computing" means watching videos and memorizing words. But to actually become a real engineer, you have to get your hands dirty.

Today was my very first day building live systems inside Microsoft's global network (Azure). I didn't just build a cloud computer; I wrapped it in high-tech security gates to protect it from hackers.

Here is exactly what I did, told in plain, simple English.

🏰 The Analogy: Building a Secret Bank Vault

To understand what I built today, imagine you want to rent a secure vault inside a giant, high-tech fortress (the Cloud Data Center) to store important data.

[ Hacker / Stranger ] ────► ❌ Main Security Guard
│
[ Abhishek's Laptop ] ────► ✅ Private Gatehouse
│
▼ (Bypassed Router Block via Secret Tunnel)
┌──────────────┐
│ Inside Vault │ ──► [ Your Ubuntu Linux Server ]
└──────────────┘
Here are the 4 steps I took to build it:

🚪 Step 1: Hiring the Ultimate Security Guard (MFA)

Before building my vault, I hired a digital security guard for my main account. I turned on a feature called Security Defaults.

What it means: Think of it like a guard at the front door who checks IDs. If anyone tries to guess my password, the guard stops them instantly and sends a verification code straight to my personal phone. This keeps the bad guys completely out of my account.

🧱 Step 2: Building a Private Gatehouse (The Firewall / NSG)Next, I built a private wall around my vault. In the tech world, this is called a Network Security Group (NSG). It acts like a smart gatehouse with a very specific rulebook.

The Rule: I told the gatehouse, "Only let someone in if they are coming from Abhishek's exact home Wi-Fi address." If a hacker from anywhere else in the world tries to knock on the door, the gatehouse completely ignores them.

💻 Step 3: Launching the Computer (The Virtual Machine)Once the security walls were up, I ordered a fresh Linux computer (called a Virtual Machine) to live inside my vault.

The Real-World Twist: At first, the local data centers in India were completely full because so many people were using them! Instead of giving up, I used the power of the cloud to instantly teleport my project across the ocean to Singapore, where there was plenty of room. It worked perfectly and cost me next to nothing from my free credits.

🛠️ Step 4: Solving a Hidden Problem (The Serial Console)This was the most exciting part of the day. When I tried to log into my new Singapore computer from my laptop, the connection kept freezing.

The Problem: It turns out my home internet router is highly restrictive. It blocks the standard pipe (called Port 22) used to connect to Linux computers.

The Fix: Instead of calling my internet provider to complain, I used a secret Azure back-door tool called the Serial Console. It allowed me to bypass my home router's restriction and open a direct command-line window to my server right inside my Google Chrome browser tab!

💰 Saving Money: Turning off the Lights

Because the cloud operates on a "pay-for-what-you-use" model, keeping the computer running when I'm not using it would waste my free credits. To practice good discipline, I hit the Stop (Deallocate) button. This completely shuts down the physical computer in Singapore, dropping my hourly cost to exactly ₹0 until I turn it back on tomorrow.

🏆 Why this matters

Today, I proved that I can:

Lock down a cloud environment so hackers can't get in.
Adapt and move my infrastructure across the globe when resources are full.
Troubleshoot tricky network blocks like a real professional.

DEV Community: Abhishek Kadlii

Finding the Needle in the Cloud Haystack: Real-Time Observability & Log Diagnostics with KQL

Finding the Needle in the Cloud Haystack: Real-Time Observability & Log Diagnostics with KQL

🏰 The Analogy: The Building CCTV Control Room

🛠️ The Step-by-Step Command-Line Execution Blueprint

1. Provisioning the Cloud Monitoring Sandbox Workspace

2. Deploying the Ingestion Fleet via Azure Monitor Agent (AMA)

3. Engineering the Automated Proactive Alerting Perimeter

⚙️ Production Kusto Query Language (KQL) Diagnostic Matrix

🔍 Scenario 1: Pinpointing Elevated Compute Strain (> 80% CPU)

🔍 Scenario 2: Auditing Rogue Host Authentication Failures

🚙 KQL Code Logic Decoder (In Plain, Simple Words)

📓 The TAC Engineer's Troubleshooting Journal

🚨 1. Subscription Governance Interception Block (Code: RequestDisallowedByPolicy)

🚨 2. Cross-Region Datacenter Capacity Exhaustion (Code: SkuNotAvailable)

Stopping Rogue Deployments: How I Programmed Azure API Guardrails to Protect the Cloud Wallet

🏰 The Analogy: The Bouncing Corporate Credit Card

🛠️ The Step-by-Step Command-Line Execution Blueprint

1. Designing the Custom Policy Criteria (allowed-skus.json)

2. Provisioning and Binding the Policy Scope

⚙️ Forging a Custom Least-Privilege RBAC Identity Role

📓 The TAC Engineer's Troubleshooting Journal

🚨 1. Top-Level Schema Mismatch Failures (Code: InvalidPolicyRule)

🚨 2. Scope Binding Failures via Missing Context Containers (Code: ResourceGroupNotFound)

🚀 Live Workload Validation: The RequestDisallowedByPolicy Block

📸 Defensive Proof Point: The Wallet Secured

💡 Core FinOps & AZ-104 Exam Lessons Learned

# 🚀 The Self-Healing Server Fleet: How I Mastered Automation, Beat Global SKU Crushes, and Solved Azure's Cloud Racing Conditions

🏰 The Analogy: The Overworked Cashier vs. The Automated Queue

🛠️ The Fault-Tolerant Implementation Blueprint

📸 Proof Point 1: Baseline Deployment Established

⚙️ Programming the Metrics Sensor (Autoscale Policies)

📸 Proof Point 2: Visual Metric Sensor Configured

📓 The TAC Engineer's Troubleshooting Journal: 3 Massive Roadblocks Solved

🚨 Block 1: The Global SKU Capacity Crunch (Code: SkuNotAvailable)

🚨 Block 2: Hostname Syntax Validation Fault (Code: InvalidHostNamePrefix)

🚨 Block 3: The Deprovisioning Cloud Racing Condition (Code: ResourceGroupBeingDeleted)

🚀 Live Workload Stress Simulation & Validation

📸 Proof Point 3: Automatic Backup Arrives!

💡 Core AZ-104 Exam Lessons Learned

⏱️ Cost Management Rule (FinOps Discipline)

The Underground Tunnel: How I Locked Down Enterprise Storage Without Breaking the App

🏰 The Analogy: Public Street Vault vs. Underground Tunnel

🛠️ Step-by-Step Implementation

1. Locking the Vault (Disabling Public Access)

📸 Proof Point 1: Smashed Front Gate

2. Digging the Underground Tunnel (Private Endpoint)

📸 Proof Point 2: The Private Interface Allocation

3. Overriding the Map (Private DNS Zone Integration)

📸 Proof Point 3: The Private Route Record Mapping

🛑 The Real-World Blocker: The 403 Forbidden Shock

💡 Core AZ-104 Exam Takeaways

⏱️ Sandbox Cleanup

Shifting to IaC: Writing the 183-Line Central Firewall Engine in Bicep When the Portal Hits a Wall | Day 9 & 10

The Network Logic: What Are We Architecting?

Complete Enterprise-Grade Bicep Security Blueprint

Deep-Dive: Code Logic & Packet Inspection Mechanics

Code Logic & Traffic Processing Deep-Dive

Compilation Verification & Local Quality Control

The Live Traffic Intercept: Bringing the Cloud Fortress to Life (Day 8)

Sunday Double-Header: Erecting Checkpoints and Traffic Hijacking in the Cloud (Day 6 & 7)

Weekend Grind: Breaking the GUI Habit and Building a Scalable Cloud Fortress in Azure (Day 4 & 5)

🚀 My First Day in the Cloud: How I Built a Secured Digital Fortress in Azure

🚨 1. Subscription Governance Interception Block (`Code: RequestDisallowedByPolicy`)

🚨 2. Cross-Region Datacenter Capacity Exhaustion (`Code: SkuNotAvailable`)

1. Designing the Custom Policy Criteria (`allowed-skus.json`)

🚨 1. Top-Level Schema Mismatch Failures (`Code: InvalidPolicyRule`)

🚨 2. Scope Binding Failures via Missing Context Containers (`Code: ResourceGroupNotFound`)

🚨 Block 1: The Global SKU Capacity Crunch (`Code: SkuNotAvailable`)

🚨 Block 2: Hostname Syntax Validation Fault (`Code: InvalidHostNamePrefix`)

🚨 Block 3: The Deprovisioning Cloud Racing Condition (`Code: ResourceGroupBeingDeleted`)