❯ az deployment show --query "properties.details" --output detailed
Project Case Studies
Technical deep-dives into what was built, why it was built that way, and what it demonstrates.
❯ az deployment show --name nordvind-cloud-infrastructure nordvind-cloud-infrastructure
Running
A production-grade Azure environment designed and built from scratch for Nordvind Energi AS — a fictional Norwegian renewable energy company with 400 employees across Haugesund, Stavanger, and Bergen. The environment covers the full stack: governance, identity, networking, compute, storage, DNS, monitoring, backup, Key Vault, and hybrid identity. Every resource follows a deliberate naming convention, tagging standard, and access control model. The entire build is documented in an Azure DevOps Wiki as a living runbook. AZ-104 lab series complete — 15 labs.
// metrics
15 Labs completed
3 Office VNets
4 Resource groups
2 Policies enforced
6 VMs deployed
50 Azure resources
// what was built
◎ Governance foundation — management group hierarchy, subscription scoped under mg-nordvind, Azure Policy enforcing data residency (Norway East/West only) and mandatory tagging across all resources. Custom policy definition written in JSON, bundled into a reusable initiative.
◎ Three-tier network architecture — management, workload, and data subnets with dedicated NSGs enforcing least-privilege traffic flow. No workload VM is internet-reachable. Admin access flows exclusively through Azure Bastion over HTTPS.
◎ Full-mesh VNet peering across three office locations with non-overlapping address spaces (10.10/20/30.0.0/16). User-Defined Routes on the workload subnet direct inter-office traffic through a planned hub appliance at 10.10.0.4.
◎ Identity and RBAC — Entra ID users and groups reflecting Nordvind's org structure. Roles assigned to groups, never individuals. Management plane and data plane roles kept deliberately separate — Reader on a storage account does not grant blob access.
◎ Availability architecture — two dashboard VMs in an Availability Set across separate fault domains (FD0/FD1) for 99.95% SLA. VM Scale Set with CPU-based autoscaling (scale out >75%, scale in <25%) using Flexible orchestration mode.
◎ DNS — public and private — azure.get-karsten.cloud delegated to Azure DNS via Cloudflare subdomain NS records, preserving existing M365 records. Private zone nordvind.internal with auto-registration linked to the Haugesund VNet.
◎ Storage governance — blob containers restricted to snet-data via Service Endpoint. Lifecycle management policy automatically tiers SCADA sensor data from Hot → Cool → Cold → Archive as it ages. Soft delete enabled for 14-day recovery window.
◎ Load balancing — Standard SKU Azure Load Balancer distributing traffic across both dashboard VMs with health probes on HTTP port 80. Application Gateway deployed to demonstrate Layer 7 path-based routing. DNS A record pointing to load balancer frontend IP.
◎ Key Vault — RBAC-model vault with purge protection and 90-day soft delete. Network restricted to snet-data and admin IP. Secrets centralised: storage connection strings, VM credentials, and storage keys — nothing hardcoded anywhere in the environment.
◎ Backup and monitoring — Recovery Services Vault with daily backup policy for the jumpbox VM. Log Analytics workspace receiving Windows Security and Performance events via Data Collection Rule. Metric alerts for CPU threshold and VM availability, routed to an action group with email notification.
◎ Hybrid identity — On-premises Active Directory (nordvind.local) on a domain controller VM, synchronised to Entra ID via Microsoft Entra Connect with Password Hash Sync. On-premises users appear in Entra ID with sync status. AD is the authoritative source — changes must be made on-premises, not in the cloud portal.
// key design decisions
"Why a management group for a single subscription?"
Nordvind operates under NIS2 and may add an OT/SCADA subscription later. Policies assigned at the management group level are inherited by all future subscriptions automatically — the governance model scales without rework. Skipping this now creates technical debt under production pressure.
"Why Deny effect instead of Audit for the tagging policy?"
Audit produces a compliance report. Deny prevents deployment. Nordvind's finance team cannot track costs across departments if resources are deployed without tags — Audit relies on engineers noticing and fixing violations. Deny removes the dependency on human memory entirely.
"Why Availability Set and not Availability Zones for the dashboard VMs?"
Existing VMs cannot be moved to Availability Zones — they must be redeployed. The Availability Set was deployed intentionally to demonstrate fault domain and update domain mechanics for AZ-104. Zone migration is planned at the AZ-305 architecture review stage.
"Why subdomain delegation for DNS instead of full domain migration?"
The root domain get-karsten.cloud already carries active M365 records — MX, SPF, autodiscover, enterpriseenrollment. Moving all nameservers to Azure without first replicating every record would break email and Intune enrollment. Subdomain delegation to azure.get-karsten.cloud isolates the Azure lab namespace cleanly.
// stack
Azure Policy Azure RBAC Entra ID VNet Peering NSG Azure DNS Private DNS Azure VMs Availability Sets VM Scale Sets Blob Storage Lifecycle Management Azure Bastion User-Defined Routes Service Endpoints Azure CLI Load Balancer Key Vault Recovery Services Vault Log Analytics Entra Connect
❯ az deployment show --name nordvind-endpoint-management nordvind-endpoint-management
Running
A complete Microsoft Intune endpoint management environment built for Nordvind Energi AS as part of the MD-102 lab series. Covers the full device lifecycle: zero-touch provisioning via Autopilot, compliance enforcement, security hardening, app deployment, BYOD data protection without enrollment, and controlled Windows update management. All policies assigned to licensed user groups, verified on a real enrolled Windows 11 device.
// metrics
9 Labs completed
10 Intune policies
1 Real device enrolled
2 MAM platforms
5 Licensed users
2 Expert titles in scope
// what was built
◎ Zero-touch provisioning — Windows Autopilot deployment profile with dynamic device group targeting. User-driven mode, Entra ID join, standard user accounts, device naming convention NV-WIN-%RAND:4%. Devices configure themselves during OOBE with no IT involvement.
◎ Compliance enforcement — Windows compliance policy requiring BitLocker, Secure Boot, TPM, Defender real-time protection, firewall, minimum OS version, and alphanumeric password complexity. Non-compliant devices receive email notification on day 1 and are retired after 30 days.
◎ Security hardening — Microsoft security baseline profile, Edge browser hardening (SmartScreen, InPrivate disabled, extension blocking), Defender Antivirus policy, Attack Surface Reduction rules targeting ransomware and credential theft techniques, Windows Firewall policy blocking inbound on all three network profiles.
◎ BYOD data protection (MAM-WE) — App Protection Policies for iOS and Android protecting company data within Microsoft apps on personal devices without MDM enrollment. Cut/paste restrictions between managed and personal apps, PIN requirement, jailbreak detection, and selective wipe on company data only.
◎ Controlled updates — Windows Update for Business ring with 7-day quality update deferral and 60-day feature update deferral. Active hours 08:00–17:00. Users cannot pause updates. Verified greyed-out on enrolled device.
// key design decisions
"Why MAM without enrollment instead of full MDM for personal phones?"
Full MDM enrollment on a personal device gives the employer visibility into and control over the entire device — something most employees will refuse. MAM-WE protects company data inside specific apps without touching anything personal. The employee's photos, personal apps, and private communications are never visible to IT. Adoption is significantly higher when employees trust that the boundary is real.
"Why set Attack Surface Reduction rules to Audit before Block?"
Several ASR rules — particularly those blocking Office macros and WMI process creation — will trigger on legitimate business tools if deployed directly to Block. Setting Audit first logs everything the rule would have blocked without actually blocking it. After reviewing the logs for two to four weeks, IT can identify false positives, add exclusions for approved tools, and then switch to Block with confidence. Going straight to Block on a production fleet generates urgent helpdesk tickets.
"Why assign all policies to user groups instead of device groups?"
Compliance and configuration policies follow the user across all their enrolled devices when assigned to a user group. A device group assignment ties the policy to specific hardware — if a laptop is replaced, the new device must be manually added to the group. User group assignment is the correct default for corporate environments where one user has one device. Device groups are appropriate for shared or kiosk scenarios where no consistent user identity exists.
"Why disable the option to pause Windows updates?"
Under NIS2, Nordvind must demonstrate active patch management across its device fleet. An employee pausing updates for weeks or months creates a compliance gap that would be difficult to explain during an audit or after an incident. Removing the pause option ensures the deferral period defined by IT — seven days for quality updates — is the maximum delay, not a suggestion. The 7-day deferral already provides time for IT to validate patches before they reach users.
// stack
Microsoft Intune Windows Autopilot App Protection Policies MAM without Enrollment Defender for Endpoint Attack Surface Reduction Windows Update for Business Entra ID Dynamic Groups Group-based Licensing
❯ az deployment show --name azure-lab-tenant azure-lab-tenant
Running
The infrastructure underlying all lab work — a personal Azure Pay-As-You-Go subscription paired with a Microsoft 365 Business Premium tenant. Configured from scratch with a management group hierarchy, governance policies, and a custom domain. Used as the live environment for all AZ-104 through AZ-305 labs.
// configuration
◎ Management group mg-nordvind sits above the subscription — policies assigned here flow to all future subscriptions automatically.
◎ Custom domain get-karsten.cloud verified as primary in Entra ID. All user UPNs use this domain. DNS managed via Cloudflare with M365 records preserved.
◎ Two enforced Azure Policies at subscription scope — data residency (Norway East/West only) and mandatory tagging. Every deployment is blocked if non-compliant.
// stack
Azure Pay-As-You-Go M365 Business Premium Entra ID P1 Cloudflare DNS
❯ az deployment show --name cert-roadmap cert-roadmap
InProgress
A structured five-certification path through the Microsoft cloud stack. The sequence is deliberate — each certification builds on the one before it, and every lab produces a real, running environment rather than a series of isolated exercises. The goal is not certificates. The goal is the ability to design and operate production cloud infrastructure.
// certification sequence and rationale
1 AZ-104 — Azure Administrator — Labs complete. 15 labs across governance, identity, networking, compute, storage, DNS, monitoring, backup, Key Vault, and hybrid identity. Full Nordvind Energi AS infrastructure built and documented.
2 MD-102 — Endpoint Administrator — Labs complete. 9 labs covering Autopilot, compliance policies, configuration profiles, app deployment, endpoint security, MAM/BYOD, and Windows Update for Business. Full Intune environment built for Nordvind Energi AS.
3 MS-102 — Microsoft 365 Administrator Expert — Planned. Requires the Entra ID depth from AZ-104 and the device management context from MD-102. Full M365 tenant administration including compliance and security.
4 SC-300 — Identity and Access Administrator — Planned. Deep identity: Conditional Access, PIM, Identity Governance. Requires the full Entra ID and M365 context from the first three certifications.
5 AZ-305 — Solutions Architect Expert — Planned. Architect-level design and decision-making. Requires mastery of all four previous certifications. Every design decision in AZ-305 references something built in an earlier lab.
// approach
◎ Every lab runs against a real Pay-As-You-Go subscription — not sandbox environments. Real billing, real consequences, real governance.
◎ All labs build a single continuous environment rather than isolated exercises. Resources from Lab 01 are still running and referenced in Lab 09.
◎ Architecture decisions are documented with alternatives — not just what was chosen, but why, and when a different choice would be correct.
// status
AZ-900 — Passed AZ-104 — Labs Complete MD-102 — Labs Complete MS-102 — Planned SC-300 — Planned AZ-305 — Planned
❯ az deployment show --name get-karsten-cloud-site get-karsten.cloud
Running
This site. Static HTML, CSS, and JavaScript — zero dependencies, zero frameworks. Terminal-inspired aesthetic modelled on the Azure CLI output format. Every section is framed as an Azure resource type: Properties, Resources, Tags, Deployments, Activity Log, Policy, Service. Hosted on Azure Static Web Apps with GitHub Actions CI/CD — every push to main deploys automatically.
// what is notable
◎ Hero section renders as an animated az resource show output — typewriter command followed by streaming JSON lines simulating real Azure CLI behaviour. A subtle matrix canvas animation runs behind the hero content.
◎ Cert progress indicator in the nav bar reflects current certification status in real time. Soft skills framed as Azure Policy definitions with scope, status, and effect — technically coherent, not just decorative.
◎ Hosted on Azure Static Web Apps with a custom domain (get-karsten.cloud) configured via Cloudflare DNS. GitHub Actions CI/CD pipeline deploys automatically on every commit — zero manual deployment steps.
// stack
HTML CSS Vanilla JS Azure Static Web Apps GitHub Actions Cloudflare DNS Custom domain