Skip to main content
AS
~4 min read|2026|Azure Administration & Cloud Operations
Azure Administration & Cloud OperationsCompleted Azure lab project2026

Azure Administration Lab Platform

Azure administration lab covering RBAC, Policy, Bicep, networking, storage, compute, backup, and monitoring.

Azure ARM TemplatesAzure BicepRBACAzure PolicyAzure Virtual NetworksAzure Load BalancerApplication GatewayAzure StorageAzure Virtual MachinesAzure MonitorRecovery Services Vault

I used one Azure lab to tie together governance, networking, compute, storage, backup, and monitoring across both portal and IaC workflows.

Built

Azure governance, networking, compute, storage, backup, and monitoring lab platform.

My Role

Planned the layout, ran the lab tasks, and turned them into one project page.

Visuals

1 diagram + 11 supporting visuals

Portal screenshots and lab notes

Portal screenshots and lab notes

The page shows the main lab work with selected screenshots and a summary diagram. Raw practice material is not included.

Project Scope

Coverage Scope

Governance, RBAC, Azure Policy, template-based deployment, virtual networking, traffic management, storage, VMs, backup, and monitoring.

Execution Model

Portal, Azure PowerShell, Azure CLI, ARM templates, and Bicep used together instead of relying on one administration path only.

Network Focus

Multi-VNet planning, subnet segmentation, ASG and NSG logic, DNS, peering, Load Balancer, and Application Gateway.

Operations Focus

Storage protection, VM and VMSS administration, Recovery Services Vault, alerting, and query-backed monitoring validation.

Project Overview

This project brings a broad Azure lab into one clear administration project. Instead of showing isolated tasks, it shows how governance, deployment, networking, storage, compute, backup, and monitoring fit together.

The material was reorganized into one project page with consistent terminology, visuals, and structure.

Why This Project Exists

Certification labs often contain useful technical depth but weak portfolio structure. They usually end up as fragmented steps and screenshots rather than one clear project.

This page turns that material into one Azure administration project. It is not meant to present a production migration; it shows broad Azure coverage explored in a structured way.

Platform Coverage

The project spans multiple Azure administration areas and intentionally connects them into one platform view.

Governance and Access

  • Management groups used to think about hierarchy and inherited scope.
  • RBAC review covering built-in roles and custom permission boundaries for operational access.
  • Tags, Azure Policy, remediation, and resource locks used as governance controls rather than optional metadata.

Automation and Provisioning

  • Resource creation in the portal followed by template export and JSON review.
  • ARM template editing and parameterization to avoid hardcoding environment-specific values.
  • Deployment through both Azure PowerShell and Azure CLI, plus Bicep exposure for cleaner declarative authoring.

Networking and Services

  • CoreServicesVnet and ManufacturingVnet planning with subnet sizing for present needs and projected growth.
  • ASG and NSG usage, DNS zones, virtual network peering, and custom route logic.
  • Azure Load Balancer and Application Gateway as the public traffic-management layer.

Data, Compute, and Operations

  • Storage account configuration, lifecycle movement, secure blob handling, and Azure file shares.
  • Virtual machine deployment, resizing, VM Scale Set autoscaling, and workload review.
  • Recovery Services Vault, backup policy understanding, Azure Monitor, alerts, action groups, and query-backed monitoring validation.

What I Implemented

  • Reviewed Azure tenant hierarchy and role assignment patterns, including management groups and constrained operational permissions.
  • Worked through policy-backed tagging and resource protection so the project reflects governance thinking instead of resource creation only.
  • Used exported ARM templates, edited JSON, parameter files, and deployment commands to move from portal actions to repeatable infrastructure execution.
  • Planned and documented virtual networks, subnets, DNS, ASG and NSG usage, VNet peering, and traffic-management components.
  • Configured storage-oriented controls such as redundancy choice, restricted access, lifecycle rules, blob immutability awareness, and file share handling.
  • Covered compute operations through VM deployment, resize actions, VM Scale Set concepts, and scale rules.
  • Included recovery and observability work through Recovery Services Vault, backup posture review, Azure Monitor alerting, and query-based validation.
  • Reworked the raw lab material into one clear project page with custom visuals and concise technical notes.

Reliability and Administrative Quality

A strong Azure administration project should show more than successful resource creation. It should show that access scope, naming, cleanup, service boundaries, lifecycle behavior, and recovery posture were considered deliberately.

This project reflects that mindset by pairing governance controls with automation, by separating networking and public-entry concerns, and by treating monitoring and backup as baseline responsibilities rather than nice-to-have additions.

The public page leaves out secrets, temporary credentials, and training material.

Testing and Validation

  • Checked that governance controls, scope decisions, and metadata requirements were understood before treating the environment as a free-form sandbox.
  • Validated template-based workflows by moving from exported portal resources to edited ARM and Bicep-style deployment patterns.
  • Reviewed networking logic across subnet planning, DNS, NSG and ASG behavior, peering, and public traffic-management placement.
  • Confirmed that storage, compute, backup, and monitoring areas are represented as connected service layers, not as isolated screenshots with no operational meaning.
  • Checked that the published page reflects the actual lab work and not just isolated screenshots.

Key Learnings

  • Broad cloud-administration work becomes much more convincing when governance, deployment, networking, operations, and validation are presented as one system.
  • ARM and Bicep matter most when they reduce manual drift and make changes reproducible, not when they exist only as exported files.
  • Networking is easier to explain and defend when address planning, segmentation, peering, DNS, and frontend service entry are mapped together visually.
  • Backup and monitoring deserve first-class treatment in portfolio work because they signal operational maturity, not just service familiarity.
  • Certification lab work becomes much stronger portfolio material when it is organized as one clear project with defined scope and validation.

Lab Platform Architecture

Overview of governance, networking, compute, storage, backup, monitoring, and validation in the Azure lab.

The diagram turns separate Azure administration exercises into one structured platform view: governance controls, deployment paths, segmented networking, data services, compute, recovery, and monitoring. It makes the project easier to read as one repeatable baseline instead of a list of disconnected labs.

Governance Layer

Management groups, RBAC, tagging, policy enforcement, and resource locks establish administrative guardrails before resource deployment begins.

Automation Layer

ARM exports, parameter files, PowerShell, CLI, and Bicep cover the repeatable-deployment side of Azure administration rather than leaving the project portal-only.

Network Fabric

Virtual networks, subnets, ASGs, NSGs, DNS zones, peering, and custom route thinking define the internal communication and isolation model.

Traffic Management

Azure Load Balancer and Application Gateway extend the project from internal segmentation to public-facing service entry and distribution.

Storage and Compute

Storage redundancy, lifecycle controls, secure containers and file shares, virtual machines, and VM scale sets are treated as an operational platform, not as isolated resources.

Operations Baseline

Recovery Services Vault, Azure Monitor, alert rules, action groups, processing rules, and validation queries define the resilience and observability layer.

Visuals

Includes one overview diagram and eleven Azure Portal screenshots covering governance, RBAC, policy, networking, storage, compute, backup, and monitoring.

Step 01

Azure Portal screenshot showing custom role creation under Access control (IAM) and RBAC scope design.

Step 02

Azure Portal screenshot from the policy workflow showing the tag-related policy definitions reviewed while building the governance layer.

Step 03

Azure Portal screenshot showing remediation-task configuration for inherited resource tagging.

Step 04

Azure Portal screenshot showing VNet peering between CoreServicesVnet and ManufacturingVnet.

Step 05

Azure Portal screenshot showing Application Gateway creation, subnet selection, SKU choice, and frontend planning.

Step 06

Azure Portal screenshot showing secure blob container creation with private access enforced.

Step 07

Azure Portal screenshot showing the VM size selection interface during compute scaling work.

Step 08

Azure Portal screenshot showing Virtual Machine Scale Set creation during the compute-scaling part of the lab.

Step 09

Azure Portal screenshot showing Recovery Services Vault creation for the backup and recovery part of the lab.

Step 10

Azure Portal screenshot showing alert processing rule scheduling in Azure Monitor.

Step 11

Azure Portal screenshot showing backup policy configuration with scheduling and retention settings.

Code Example

bicep

Example Bicep subnet definition

param location string = resourceGroup().location
param vnetName string = 'coreservices-vnet'

resource vnet 'Microsoft.Network/virtualNetworks@2023-06-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.20.0.0/16']
    }
    subnets: [
      {
        name: 'SharedServicesSubnet'
        properties: {
          addressPrefix: '10.20.10.0/24'
        }
      }
      {
        name: 'DatabaseSubnet'
        properties: {
          addressPrefix: '10.20.20.0/24'
        }
      }
    ]
  }
}

Example Bicep snippet showing how subnet structure was defined in code instead of only in the portal.

More Projects

View all

Infrastructure Implementation

Virtual Machine Infrastructure Project

2023 · Dell PowerEdge T330, VMware ESXi 7, VMware vCenter

View project

Networking & Infrastructure

Juniper vSRX Network Services Lab

2021-2022 · Juniper vSRX, Junos OS, VMware Workstation

View project
Back to Projects