Top 50 Azure Cloud Administrator Interview Questions and Answers
Covering networking, identity, storage, virtual machines, security, governance, monitoring, cost management, and automation — with the depth of answer that separates engineers who have run Azure in production from those who have only read the documentation.
A strong Azure Cloud Administrator interview is not just about reciting definitions. Interviewers at senior level want to understand how you think about trade-offs, what you do when something breaks at 2am, and whether you understand the difference between a configuration that works in a sandbox and one that holds in production under load. The questions below are organized by topic area — each with an answer that goes beyond the documentation summary and into the reasoning that experienced engineers apply in the field.
Whether you are preparing for your first Azure role or preparing to move from Associate to Senior level, work through each section systematically. Do not skip the governance and monitoring sections — these are the areas where most interview candidates underperform relative to the technical sections, and they are where senior roles invest the most of their day-to-day time.
Topics Covered
These three form the Azure resource hierarchy and each serves a different governance purpose. A Management Group is the highest level — it contains subscriptions and allows you to apply Azure Policy, RBAC, and blueprints across multiple subscriptions simultaneously. An organization with 20 subscriptions can apply a "no public IP" policy at the Management Group level and have it cascade down to every subscription automatically. You can nest Management Groups up to six levels deep below the root.
A Subscription is the billing and access boundary. It represents a contract with Microsoft for Azure services and is where cost is tracked. Subscriptions also act as a hard limit boundary — resources in different subscriptions cannot communicate directly without VNet peering or VPN. Large organizations use multiple subscriptions to separate environments (Production, Development, Staging) or business units.
A Resource Group is a logical container within a subscription. It holds related resources and is the primary unit of management, deployment, and access control for day-to-day operations. Resources in a resource group share a lifecycle — deleting a resource group deletes everything in it. Resources can only belong to one resource group, but can interact with resources in other resource groups within the same subscription.
Azure Resource Manager is the management layer that underpins every Azure interaction — whether through the portal, PowerShell, Azure CLI, REST API, or Terraform. When you deploy a resource, ARM receives the request, authenticates it via Entra ID, authorizes it against RBAC, and then routes it to the appropriate resource provider (Microsoft.Compute for VMs, Microsoft. Storage for storage accounts, and so on).
ARM matters for three reasons in production. First, it provides declarative deployment via ARM templates and Bicep — you declare the desired state and ARM determines what needs to be created, updated, or left alone. Second, ARM provides consistent management — every resource, regardless of type, goes through the same management plane and supports the same features (tags, locks, RBAC, policies). Third, ARM enables idempotent operations — deploying the same template twice produces the same result rather than creating duplicate resources.
An Azure Region is a geographic area containing one or more datacentres that are close together and connected by a low-latency network. Azure currently operates in over 60 regions globally. When you deploy a resource, you choose a region — this determines where the data physically resides, which affects latency, compliance, data sovereignty, and the availability of specific service SKUs.
Availability Zones are physically separate datacentres within a single region. Each zone has independent power, cooling, and networking. A region with Availability Zones typically has three zones. If a zone fails — due to a power outage, cooling failure, or network incident — the other zones continue operating. Resources deployed across multiple Availability Zones survive a full zone failure without data loss or manual intervention.
The key difference: a region failure (rare but possible) affects all zones in that region simultaneously. An Availability Zone failure (more realistic) affects only that zone. For regional disaster recovery, you use paired regions (Geo-Redundant Storage, Azure Site Recovery). For zone-level resilience within a region, you use Availability Zones (ZRS storage, zone-redundant VMs, zone-redundant load balancers).
Tags are key-value metadata pairs applied to Azure resources and resource groups. They serve four primary purposes in production environments. Cost allocation — tagged resources can be filtered in Azure Cost Management to show spend per business unit, application, or environment. Without tags, you cannot answer "how much did the Finance application cost last month?" Governance — Azure Policy can enforce required tags, preventing deployment of any resource that does not have required tags like Environment, Owner, or CostCentre. Automation — runbooks and scripts can target resources by tag (start all VMs tagged AutoShutdown=Yes at 19:00). Operations — filtering by tag in the portal or CLI is faster than browsing resource groups when managing hundreds of resources.
Tags are not inherited by default — a resource group tag does not automatically apply to the resources within it. Azure Policy with the Inherit tag from resource group if missing effect can enforce inheritance. Each resource can have up to 50 tags. Tags are not visible inside the resource itself — they are ARM metadata.
Resource Locks prevent accidental modification or deletion of resources, overriding RBAC permissions. Even a Global Administrator cannot delete a resource with a Delete lock without first removing the lock. There are two lock types: CanNotDelete — allows read and modify but prevents deletion; and ReadOnly — allows reads only, blocks all write and delete operations.
Locks are applied at the resource, resource group, or subscription level and are inherited downward. A Delete lock on a resource group prevents deletion of any resource within it. Use Delete locks on production networking resources (VNets, NSGs, Route Tables), storage accounts containing critical data, Key Vaults, and Recovery Services Vaults. Use ReadOnly locks on resources that should never be modified manually — resources entirely managed by Infrastructure as Code, for example.
The important nuance: ReadOnly locks on storage accounts prevent creating SAS tokens and listing storage keys — it is not just preventing writes to data, it blocks management plane operations too. Test ReadOnly locks in a staging environment before applying to production storage accounts.
An Azure SLA is Microsoft's commitment for a specific service — for example, Azure Virtual Machines deployed across two or more Availability Zones offer a 99.99% uptime SLA. Single-instance VMs with Premium SSD have a 99.9% SLA. Free tier services typically have no SLA.
A composite SLA is the overall uptime guarantee for an application that depends on multiple services. It is calculated by multiplying the individual service SLAs together. An application depending on a VM (99.99%) and a SQL Database (99.99%) has a composite SLA of 99.99% × 99.99% = 99.98%. As you add more dependent services, the composite SLA decreases — each dependency is a point of failure.
This matters in practice because meeting a business SLA requirement of 99.95% may require architecting the application across multiple services with high individual SLAs and using redundancy patterns (active-active, failover groups) to compensate for the composite SLA erosion from adding dependencies.
RBAC controls who can perform actions — it grants or restricts permissions to create, read, update, or delete resources. A user with the Contributor role can create any resource type in that scope.
Azure Policy controls what can be done — it defines and enforces rules about how resources must be configured, regardless of who is creating them. Even a user with Owner permissions cannot create a resource that violates an enforced Deny policy. Policy effects include: Deny (block non-compliant resource creation), Audit (allow but flag as non-compliant), Append (add required fields like tags), DeployIfNotExists (automatically deploy a related resource when a condition is met), and Modify (add, update, or remove resource properties).
In practice: RBAC is for access control, Policy is for governance and compliance enforcement. A well-governed Azure environment uses both — RBAC limits who can deploy, Policy ensures that whatever is deployed conforms to organisational standards. Policy initiatives (groups of related policies) are assigned at Management Group, Subscription, or Resource Group scope.
A Virtual Network (VNet) is an isolated, software-defined network in Azure that provides private communication between Azure resources. It is the fundamental building block of Azure networking. A VNet is defined by an address space — a CIDR block such as 10.0.0.0/16 — that determines the range of private IP addresses available within it.
Key components: Subnets divide the VNet address space into smaller ranges and act as network segments — resources in different subnets can communicate by default unless NSGs prevent it. Network Security Groups (NSGs) contain inbound and outbound security rules that filter traffic by source/destination IP, port, and protocol. Route Tables define custom routing — for example, routing all internet-bound traffic through a firewall. Service Endpoints extend the VNet identity to Azure services. Private Endpoints bring Azure services into the VNet as private IP addresses.
VNets are region-scoped — a VNet exists in a single Azure region. Cross-region communication requires VNet peering, VPN Gateway, or ExpressRoute. VNets in the same region can be peered — traffic between peered VNets travels over Azure's backbone network, not the public internet.
An NSG is a basic, stateful packet filter associated with a subnet or a network interface. It evaluates rules based on source/destination IP address (or ASG), port, and protocol. NSGs are free, operate at Layer 4 (TCP/UDP), and are the first line of network security for every Azure subnet. They cannot inspect the content of traffic — they only see the header.
Azure Firewall is a fully managed, stateful network firewall service deployed at VNet level (typically in a hub VNet in a hub-spoke topology). It operates at Layer 4 and Layer 7, supports FQDN-based rules (allow traffic to *.microsoft.com), TLS inspection, threat intelligence filtering, and centralised logging to Log Analytics. Azure Firewall Premium adds IDPS (Intrusion Detection and Prevention) and URL filtering.
In a production enterprise deployment, you use both: NSGs at the subnet level for baseline access control (principle of least privilege per workload), and Azure Firewall at the hub level for centralised egress control, east-west traffic inspection between VNets, and internet-bound traffic filtering. NSGs are not a substitute for a proper firewall — they cannot block traffic to known malicious IPs, cannot perform application-layer inspection, and cannot centralise security policy across hundreds of subnets.
VNet Peering connects two VNets so that resources in both can communicate using private IP addresses over Azure's backbone network — no internet, no VPN, low latency. Peering can be within the same region (regional peering) or across regions (global peering). Traffic between peered VNets is billed at the intra-region or cross-region peering rate — it is not free.
Key limitations: Non-transitive — if VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A and C cannot communicate through B. Each pair needs its own peering unless you use a hub VNet with a firewall configured to route and forward traffic. No overlapping address spaces — peered VNets cannot have overlapping CIDR blocks. Address space cannot be updated on a VNet that has active peerings — the peerings must be deleted first. Gateway transit — a VNet peer can use the gateway in the peered VNet (e.g., the hub ExpressRoute gateway) if gateway transit is explicitly enabled on both sides.
Both technologies allow VNet resources to access Azure PaaS services (Storage, SQL, Key Vault) without traversing the public internet — but they work very differently.
A Service Endpoint extends the VNet's identity to the Azure service's public endpoint. Traffic from the subnet to the service still goes to the service's public IP — but it travels over Azure's backbone (not the internet) and the service can restrict access to the specific subnet. The service's DNS name still resolves to its public IP address. Service Endpoints are free and easy to configure.
A Private Endpoint places the Azure service directly inside your VNet with its own private IP address. The service's DNS name resolves to the private IP. Traffic never leaves your VNet. Resources outside your VNet — including on-premises networks connected via ExpressRoute or VPN — can also reach the service through the private IP. Private Endpoints are the recommended approach for production because they provide true network isolation and are required for services that must not be accessible from the public internet. Private Endpoints have a per-hour cost and bandwidth charges.
Azure Load Balancer operates at Layer 4 (TCP/UDP). It distributes traffic based on IP and port — it has no visibility into the HTTP request content. It is appropriate for any TCP/UDP workload — VMs running any application, databases, non-HTTP traffic. It is fast, low-latency, and inexpensive. Basic SKU is free; Standard SKU costs by the hour and by data processed.
Azure Application Gateway operates at Layer 7 (HTTP/HTTPS). It can route traffic based on URL path (/api/* → backend pool A, /static/* → backend pool B), host header, SSL termination, cookie-based session affinity, and WebSocket support. Application Gateway WAF (Web Application Firewall) adds OWASP rule protection, bot protection, and custom rules. It is appropriate for web applications and APIs that need sophisticated routing or WAF protection.
In production, you often use both: Application Gateway at the public-facing edge for HTTP/HTTPS web traffic with WAF, and internal Load Balancers between tiers (web to application, application to database) for non-HTTP traffic distribution.
Azure DNS Private Zones provide DNS resolution for names that should only resolve within a VNet. When you create a Private Endpoint for a storage account, the storage account's public FQDN (mystorageaccount.file.core.windows.net) needs to resolve to the private endpoint's IP from within the VNet, but to the public IP from outside the VNet. This split-horizon DNS is achieved by creating a Private DNS Zone (privatelink.file.core.windows.net), linking it to the VNet, and adding an A record pointing to the private endpoint IP.
Without the Private DNS Zone, resources inside the VNet resolve the storage account to its public IP — bypassing the private endpoint and potentially violating network policy. On-premises networks connected via ExpressRoute or VPN also need DNS forwarder configuration (via Azure Private DNS Resolver) to resolve these private zones correctly.
In large organisations, a centralised DNS architecture using Azure Private DNS Resolver with inbound and outbound endpoints in a hub VNet is the recommended pattern — it avoids deploying DNS forwarder VMs and scales to hundreds of private zones across multiple spoke VNets.
ExpressRoute is a dedicated private connection between your on-premises network and Azure — provisioned through a connectivity provider and delivered over a private MPLS circuit or co-location facility. Traffic never touches the public internet. It provides consistent latency, bandwidth guarantees (from 50 Mbps to 100 Gbps), and higher availability SLAs than VPN.
VPN Gateway creates an encrypted IPsec tunnel over the public internet between your on-premises network and Azure. It is simpler to provision, significantly cheaper, and sufficient for many hybrid connectivity use cases. The tradeoff: latency is variable (depends on internet conditions), bandwidth is limited (maximum 10 Gbps on the highest SKU), and the public internet path may not meet compliance requirements.
Use ExpressRoute when: bandwidth requirements exceed 1 Gbps, latency consistency is critical (financial trading, real-time applications), regulatory requirements prohibit internet transmission of certain data, or the organisation has sufficient volume of on-premises to Azure traffic to justify the cost. Use VPN when: budget is constrained, bandwidth requirements are low, or as a failover/backup path for an existing ExpressRoute circuit (ExpressRoute + VPN coexistence is a supported pattern).
Active Directory Domain Services (AD DS) is a traditional on-premises directory service that manages computers, users, and resources in a domain using Kerberos and LDAP protocols. It handles domain joins, Group Policy, and on-premises resource access. It was designed for on-premises networks in the 1990s and is fundamentally a network-aware, LDAP-based identity store.
Microsoft Entra ID is a cloud-native identity and access management service. It manages identities for cloud applications, supports modern authentication protocols (OAuth 2.0, OpenID Connect, SAML), and provides single sign-on (SSO), Conditional Access, Multi-Factor Authentication, Privileged Identity Management, and Identity Protection — none of which exist in AD DS. It is not a cloud version of AD DS — it is a fundamentally different identity platform designed for the cloud and the web.
In hybrid environments, Entra Connect synchronises users from on-premises AD DS to Entra ID, creating hybrid identities. This allows users to authenticate to cloud apps (Microsoft 365, Azure) using their on-premises credentials. Entra ID does not support Kerberos authentication to on-premises resources — that still requires AD DS or Entra Domain Services.
Role-Based Access Control (RBAC) in Azure controls access to Azure resources by assigning roles to users, groups, service principals, or managed identities at a specific scope (Management Group, Subscription, Resource Group, or Resource). Each role assignment is the combination of: who (security principal) + what permissions (role definition) + where (scope).
Owner — full control over all resources including the ability to assign roles to others. Can delegate access. Should be assigned to a minimal number of individuals and only at the scope they genuinely need. Never assign Owner at Subscription scope as a default for administrators.
Contributor — can create and manage all resources but cannot grant access to others. This is the appropriate role for engineers who need to build and modify resources but should not control who else has access.
Reader — can view existing resources but cannot make any changes. Appropriate for auditors, monitoring staff, or stakeholders who need visibility without modification rights.
Azure has over 200 built-in roles for specific services (Storage Blob Data Contributor, Virtual Machine Contributor, Key Vault Secrets User, etc.). Always prefer a built-in role over Owner or Contributor where a specific role exists — it follows the principle of least privilege.
A Managed Identity is an automatically managed identity in Entra ID that Azure services can use to authenticate to other Azure services without storing credentials. Managed Identities come in two types: System-assigned — created and deleted with the resource (a VM, App Service, Function App, etc.); and User-assigned — created independently and can be assigned to multiple resources.
Managed Identities are preferred over service principals with secrets for three reasons. No secret management — the credentials are managed entirely by Azure. There is no client secret or certificate to rotate, store securely, or accidentally leak into source code. Automatic rotation — Azure rotates the underlying credentials automatically. No credential leakage risk — because there is no secret to store, there is nothing to leak into Git repositories, configuration files, or CI/CD pipeline environment variables — the leading cause of Azure credential compromises.
Example: A VM that needs to read secrets from Key Vault. Assign the VM a system-assigned managed identity, then grant that managed identity the Key Vault Secrets User role. The VM's code requests a token from the instance metadata service (no credentials needed) and uses it to authenticate to Key Vault. No secrets anywhere in the code or configuration.
Conditional Access is the policy engine in Entra ID that enforces access controls based on signals from the sign-in context. Instead of a binary allow/deny based solely on credentials, Conditional Access evaluates who is signing in, from where, from what device, to which application, and under what risk level — then decides what access controls to apply.
A Conditional Access policy has two parts: Conditions (when does this policy apply?) and Access controls (what must be satisfied or what is blocked?). Conditions include: users and groups, cloud applications, device platform, location (named IP ranges, countries), device compliance, and sign-in risk. Controls include: require MFA, require compliant device, require Hybrid Entra join, block access, or require app protection policy.
Common production policies: require MFA for all users from outside the corporate network; block access from high-risk sign-in locations; require a compliant device for accessing sensitive applications; require an approved client app for accessing Exchange Online from mobile devices. Always deploy new Conditional Access policies in Report-only mode first and monitor sign-in logs for 48–72 hours before enabling enforcement.
Privileged Identity Management (PIM) is an Entra ID P2 feature that provides just-in-time (JIT) privileged access to Azure resources and Entra ID roles. Instead of permanently assigning a user the Global Administrator or Owner role, PIM makes them eligible for the role. When they need elevated access, they activate the role through PIM — specifying a reason, duration, and optionally providing a ticket number. The activation may require MFA, manager approval, or both.
PIM matters for security for two reasons. Reducing standing privilege — most security incidents involving compromised admin accounts exploit persistent permissions that are active 24/7. JIT access means the privileged permission exists for minutes or hours, not permanently. Audit trail — every activation is logged with who requested it, why, for how long, and who approved it. This creates an immutable record for compliance and incident investigation.
PIM also provides access reviews — periodic campaigns where role owners must verify that each user still needs their assigned or eligible role. Stale privileged assignments are among the most common findings in Azure security audits.
MFA requires two or more verification factors to authenticate: something you know (password), something you have (phone/authenticator app), or something you are (biometric). Standard MFA in Entra ID adds the authenticator app push notification or a one-time password on top of the password. It significantly reduces the risk of password-only credential attacks but still starts with a password, which can be phished or leaked.
Passwordless Authentication eliminates the password entirely. Microsoft Authenticator's passwordless mode, Windows Hello for Business, and FIDO2 security keys all authenticate using a cryptographic key pair — no password is ever transmitted, typed, or stored in the cloud. Passwordless is phishing-resistant by design: even if an attacker tricks a user into visiting a fake login page, there is no password to capture.
Microsoft's recommendation as of 2026 is to move to passwordless for all users where feasible, using the combination of FIDO2 keys for highly privileged accounts and Microsoft Authenticator passwordless for standard users. Entra ID Conditional Access can be configured to require phishing-resistant credentials (FIDO2 or certificate-based authentication) for administrator sign-ins.
Azure Blob Storage — object storage for unstructured data: documents, images, videos, backups, log files, and any data accessed via REST API or HTTP. The most cost-effective option for large volumes of data. Supports Hot, Cool, Cold, and Archive access tiers. Use when: data needs to be stored at scale and accessed via URL or API rather than file system paths.
Azure Files — fully managed SMB and NFS file shares accessible via standard file protocols. Mountable from Windows, Linux, and macOS. Use when: applications or users need a shared network drive, migrating on-premises file servers to Azure, or needing a persistent volume for containers (AKS).
Azure Queue Storage — message queue service for decoupling application components. Messages up to 64 KB, unlimited queue size, at-least-once delivery. Use when: building async architectures, buffering work between producers and consumers, or triggering Azure Functions.
Azure Table Storage — NoSQL key-value store for structured, non-relational data. Extremely low cost. Use when: storing large volumes of structured data with simple key-value lookup patterns and cost is the primary constraint. Cosmos DB provides a more capable API-compatible upgrade path when advanced query capabilities are needed.
LRS (Locally Redundant Storage) — 3 copies in a single datacentre. 11 nines durability. Cheapest. Fails if the entire datacentre is lost. Use for dev/test and non-critical workloads.
ZRS (Zone-Redundant Storage) — 3 copies across 3 Availability Zones in a region. 12 nines durability. 99.99% availability SLA. Survives a full zone failure without data loss or manual failover. Use for production workloads in regions with Availability Zones — this should be the default for new production deployments.
GRS (Geo-Redundant Storage) — LRS in primary region + asynchronous replication to secondary region (LRS). 16 nines durability. Survives primary region failure. Secondary is read-only unless failover is initiated. Use when regional disaster recovery is required.
GZRS (Geo-Zone-Redundant Storage) — ZRS in primary + async replication to secondary (LRS). Highest durability and availability. Combines zone-level resilience with regional disaster recovery. Use for mission-critical workloads with strict DR requirements.
A Shared Access Signature (SAS) is a URI that grants time-limited, scoped access to Azure Storage resources without sharing the storage account key. A SAS token specifies: which resource it applies to (specific blob, container, or account), what operations are permitted (read, write, delete, list), the valid time window (start and expiry time), and optionally an IP range restriction.
The risks of SAS tokens are significant. No revocation without storing policy — a standard ad-hoc SAS token cannot be revoked once issued. If leaked, it remains valid until expiry. This is why Service SAS tokens with a Stored Access Policy are preferred — the policy can be deleted to invalidate all tokens associated with it. Over-permissioned tokens — developers frequently create SAS tokens with write or delete permissions when read-only is sufficient. Long expiry windows — tokens with 1-year or "no expiry" dates are common in practice and represent sustained exposure windows.
Best practice: use Managed Identities or Entra ID authentication instead of SAS wherever possible. When SAS is required (external partner access, short-lived download links), use the minimum permissions needed, the shortest practical expiry, and a Stored Access Policy so revocation is possible.
Azure Blob lifecycle management is a policy engine that automatically moves blobs between access tiers (Hot → Cool → Cold → Archive) or deletes them based on their age or last access date. Policies are applied at the storage account or container level and evaluated daily.
A typical lifecycle policy for backup data: keep blobs in Hot tier for 30 days (fast access, highest cost), move to Cool tier at day 30 (44% cheaper storage, higher access cost), move to Cold tier at day 90 (80% cheaper than Hot), move to Archive at day 180 (99% cheaper than Hot, 15-hour rehydration), and optionally delete at day 730 if retention requirements are met.
The financial impact is significant — a 50TB dataset entirely in Hot tier costs approximately £900/month. The same dataset with a lifecycle policy that moves most data to Cold after 90 days might cost £180/month. The lifecycle policy runs automatically after the initial configuration — there is no ongoing operational effort.
Soft delete retains deleted blobs, blob versions, containers, or file shares for a configurable retention period (1 to 365 days for blobs; 1 to 365 days for file shares) before permanent deletion. During the retention period, the deleted item can be restored from the Azure portal, PowerShell, or REST API — without opening a support ticket or restoring from backup.
Soft delete protects against accidental deletion by legitimate users — a developer running a script that deletes the wrong container, for example. It does not protect against ransomware that encrypts files in place (the encrypted files replace the originals — soft delete retains previous versions if blob versioning is also enabled). It does not protect against a malicious actor who disables soft delete before deleting data.
For comprehensive data protection: enable soft delete (protection against accidental deletion), enable blob versioning (protection against overwrites and encryption in place — previous versions are retained), and enable Azure Backup with vaulted snapshots (protection against ransomware that targets the storage account itself, because vaulted backups are stored in a separate Recovery Services Vault).
The fundamental difference is the access protocol and use case. Azure Files serves data over SMB (Server Message Block) and NFS protocols — the same protocols used by Windows and Linux file servers. It can be mounted as a network drive (Z:\), integrated with Active Directory authentication, and accessed by users and applications exactly as they would access an on-premises file server. Azure File Sync enables hybrid caching. Use Azure Files when users or applications need shared folder access, when you are migrating file servers to Azure, or when containers (AKS) need persistent volumes.
Azure Blob Storage serves data as objects via REST API and HTTP/HTTPS. It has no concept of a network drive or directory traversal in the traditional sense. It is accessed programmatically. It supports Hot/Cool/Cold/Archive tiering that Azure Files does not. It is significantly cheaper per GB than Azure Files. Use Blob Storage for backups, archives, media files, application data accessed via SDK, data processed by analytics services, and any large-scale object data that does not need SMB access.
A common mistake: migrating all file server data to Azure Files without considering whether archive data should go to Blob Storage instead. Azure Files Standard Hot at $0.06/GiB is 3× more expensive than Blob Hot at $0.018/GiB. For read-rarely archive data, the cost difference across large datasets is significant.
B-series — burstable, low-cost VMs with a CPU credit model. Accumulate credits at idle, spend credits during bursts. Appropriate for dev/test environments, web servers with variable load, and lightweight workloads where sustained CPU is not required.
D-series (Dv5, Dsv5, Dadsv5) — general-purpose VMs with balanced CPU and memory. The default choice for most web applications, application servers, and databases that do not have specific hardware requirements. DS-series suffix indicates Premium SSD support.
E-series — memory-optimised. Higher RAM-to-CPU ratio. Appropriate for in-memory databases (SQL Server, SAP HANA), caching workloads, and analytics that require large working sets in memory.
F-series — compute-optimised. Higher CPU-to-memory ratio. Appropriate for batch processing, gaming, ad serving, and applications that are CPU-bound rather than memory-bound.
L-series — storage-optimised. High local NVMe SSD throughput and IOPS. Appropriate for NoSQL databases, data warehousing, and workloads that require extreme local storage performance.
N-series — GPU-enabled. For machine learning, deep learning, rendering, and graphics-intensive workloads. NV-series for virtualisation/rendering, NC-series for compute GPU workloads.
Availability Sets are a legacy (but still supported) redundancy mechanism within a single datacentre. They spread VMs across update domains (sequential patching groups) and fault domains (separate physical racks with independent power and networking). An Availability Set protects against hardware failures within a datacentre and reduces downtime during planned maintenance. They do not protect against a full datacentre or zone failure.
Availability Zones spread VMs across physically separate datacentres within a region. A VM in Zone 1 continues running if Zone 2 fails completely. This is the current recommended approach for high-availability VM deployments. Zone-redundant deployments offer a 99.99% SLA.
Virtual Machine Scale Sets (VMSS) are a different concept — they enable auto-scaling of a group of identical VMs based on metrics (CPU, memory, custom metrics). VMSS can be deployed across Availability Zones for both high availability and auto-scaling. They are appropriate for stateless workloads where the number of instances needs to grow and shrink with demand — web front-ends, API layers, batch workers.
Pay-As-You-Go (PAYG) — pay the full hourly rate with no commitment. Maximum flexibility, highest unit cost. Appropriate for unpredictable or short-duration workloads.
Reserved Instances — commit to a 1-year or 3-year term for a specific VM family and region. Up to 72% discount versus PAYG. The commitment is to a compute capacity reservation, not a specific VM instance. Appropriate for predictable, long-running workloads. Reserved capacity can be exchanged or returned with a fee.
Azure Savings Plans — commit to a fixed hourly spend on compute (not a specific VM family or region) for 1 or 3 years. Up to 65% discount. More flexible than Reserved Instances — the savings apply to any compute that fits within the committed spend across VM families, regions, and even Azure Container Instances and Azure App Service. Appropriate when workloads span multiple VM types or regions.
Azure Spot Instances — use Azure's spare compute capacity at up to 90% discount. Can be evicted with 30 seconds notice when Azure needs the capacity back. Appropriate for fault-tolerant batch workloads, dev/test, and stateless workloads that can tolerate interruption.
Auto-shutdown and right-sizing — non-production VMs should be automatically shut down when not in use. A D4s_v5 VM (4 vCPU, 16 GB RAM) running 24/7 costs approximately £250/month — running it only during business hours (9am–6pm weekdays) costs approximately £70/month. Review VM performance metrics quarterly and downsize underutilised VMs.
Azure Bastion is a managed service that provides secure RDP and SSH access to Azure VMs directly through the Azure portal browser, without exposing VMs to the public internet via a public IP address or requiring a VPN connection. Bastion runs within your VNet in a dedicated subnet (AzureBastionSubnet, minimum /26) and proxies the RDP/SSH session from the browser to the VM's private IP over a TLS-encrypted HTTPS connection.
Bastion is preferred for three reasons. No public IP on VMs — VMs with no public IP cannot be directly attacked from the internet. Removing public IPs from VMs eliminates the entire class of internet-facing VM attacks (brute force, exploit scanning). No VPN required for individual access — instead of maintaining a VPN just for occasional VM access, Bastion allows browser-based access to any VM in the VNet (or peered VNets with Standard tier) without client software. Session auditing — Bastion sessions can be logged and recorded for compliance and incident investigation.
Managed Disks are Azure-managed block storage volumes attached to VMs. Unlike legacy unmanaged disks, managed disks are independent resources — they have their own lifecycle, can be snapshotted independently, can be resized without VM downtime (in most cases), and are replicated automatically (LRS or ZRS depending on the disk type). The resource model means a VM can be deleted while retaining its disks.
Standard HDD — lowest cost, highest latency (~10ms). Appropriate for dev/test, infrequently accessed workloads, and backup storage where IOPS are not critical.
Standard SSD — lower latency than HDD, moderate cost. Appropriate for web servers and lightly loaded application servers that need better performance than HDD but do not require premium IOPS.
Premium SSD (v1 and v2) — sub-millisecond latency, provisioned IOPS and throughput. v1 provisions performance in tiers by disk size. v2 allows independent provisioning of size, IOPS, and throughput. Appropriate for production databases, application servers, and any latency-sensitive workload. Requires a Premium-capable VM size (DS, ES, FS, GS, LS series).
Ultra Disk — highest IOPS and throughput (up to 160,000 IOPS per disk), sub-millisecond latency, dynamically adjustable performance without downtime. Appropriate for SAP HANA, top-tier databases, and extreme I/O workloads. Significant premium pricing.
Azure does not have a single factory reset button. The most effective approach depends on the reason for the reset and what you need to preserve.
OS Disk Swap (recommended) — create a new managed disk from a clean Windows Server or Linux marketplace image, stop and deallocate the VM, swap the OS disk to the new clean disk via PowerShell (Set-AzVMOSDisk + Update-AzVM), and restart. The VM retains its NICs, private and public IP addresses, data disks, resource group membership, and NSG associations. Only the OS disk changes. This is the fastest and most reversible approach — create a snapshot of the original OS disk before swapping for a rollback path.
Delete and Redeploy — delete the VM resource (keeping disks and NICs by unchecking the delete checkboxes), then deploy a new VM using the retained NIC and a new OS disk from a marketplace image. Reattach data disks after deployment. Use this when you also need to change the VM size or completely rebuild the VM configuration.
Mounted ISO Reinstall — attach a Windows Server installation media managed disk, connect via Bastion, launch setup.exe from the mounted disk, perform a clean install on the OS partition. Use when the OS disk must remain the same resource (compliance/audit requirements) but the operating system must be reinstalled.
Microsoft Defender for Cloud (formerly Azure Security Centre + Azure Defender) is a Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP) service. It continuously assesses the security configuration of Azure resources, generates recommendations to remediate misconfigurations, provides threat detection for VMs, containers, storage, databases, and other workloads, and generates alerts when suspicious activity is detected.
The Secure Score is a numeric measure (0–100%) of an Azure environment's overall security posture based on the recommendations Defender for Cloud has evaluated. Each recommendation has a point value — remediating high-priority recommendations improves the score more than low-priority ones. The score provides a single number to track improvement over time and compare environments. Microsoft recommends targeting a Secure Score above 75% for production environments — enterprise security teams typically set internal targets of 85%+.
Defender for Cloud has two tiers: foundational CSPM (free) provides asset inventory, Secure Score, and basic recommendations. Defender for Cloud paid plans add runtime threat detection per resource type (Defender for Servers, Defender for Storage, Defender for SQL, etc.). Enable at minimum the foundational CSPM tier on every subscription.
Azure Key Vault is a cloud service for securely storing and accessing secrets, cryptographic keys, and certificates. It provides centralised secret management with access control via RBAC and Entra ID, audit logging of every access operation, automatic rotation support, and Hardware Security Module (HSM) backing for premium tiers.
Key Vault stores three types of objects. Secrets — arbitrary values up to 25 KB: database connection strings, API keys, passwords, storage account keys. Secrets are versioned and can have expiry dates. Keys — cryptographic keys (RSA, EC) used for encryption/decryption or signing/verification. Azure services can use keys stored in Key Vault to wrap Data Encryption Keys (Customer-Managed Keys for storage, SQL, VMs). Certificates — X.509 certificates with lifecycle management: issuance from integrated CAs (DigiCert, GlobalSign, or an internal CA), auto-renewal, and export control.
Best practice: never store secrets in application configuration files, environment variables, or source code. All secrets should be fetched from Key Vault at runtime using Managed Identity — no credentials stored anywhere in the deployment pipeline or code. Enable soft delete and purge protection on every Key Vault. Enable diagnostic logging so every secret access is auditable.
Azure provides two tiers of DDoS protection. DDoS Network Protection Basic is automatically enabled for all Azure resources at no additional cost. It provides always-on monitoring, automatic mitigation for common Layer 3 and Layer 4 attacks, and global capacity to absorb volumetric attacks. Basic protection defends the Azure platform as a whole — individual customer resources may still be impacted during large attacks.
DDoS Network Protection Standard (per-VNet pricing, approximately £2,500/month for the first 100 public IPs) provides adaptive tuning to a specific environment's traffic patterns, real-time metrics and attack telemetry, rapid response support from Microsoft's DDoS Rapid Response team, and per-IP attack mitigation reports. It provides SLA-backed protection and cost guarantee — if a resource scales out during a DDoS attack (to handle the traffic), Microsoft reimburses the extra compute cost.
Use DDoS Standard for: public-facing applications where availability is critical (e-commerce, financial services), environments with compliance requirements that mandate DDoS protection, and any application where an extended outage has significant financial consequences. For small internal applications with no public IP exposure, Basic protection is sufficient.
Azure Disk Encryption (ADE) encrypts the OS and data disks of Azure VMs using BitLocker (Windows) or dm-crypt (Linux), with the encryption keys stored and managed in Azure Key Vault. This provides encryption at the volume level — inside the VM's operating system — in addition to the server-side encryption that Azure applies automatically to all managed disks at the storage layer.
ADE protects against physical theft of the underlying storage — if someone extracts the managed disk from Azure's infrastructure, the data is encrypted and unreadable without the key in Key Vault. It also satisfies compliance requirements that mandate guest-OS-level encryption (rather than just storage-level encryption). Server-Side Encryption (SSE) with Platform-Managed Keys is automatic and free on all managed disks — it protects against physical media theft from the datacentre. ADE adds encryption within the VM's own OS for defence in depth and specific compliance standards (PCI DSS, HIPAA) that require it.
Zero Trust is a security model based on three principles: Verify explicitly — always authenticate and authorise based on all available signals (identity, location, device, workload, data classification) rather than assuming trust based on network location. Use least privilege access — limit user access with just-in-time, just-enough-access and risk-based adaptive policies. Assume breach — design as if the network perimeter has already been breached; minimise blast radius, segment access, verify end-to-end encryption, use analytics to detect threats.
Azure's services align to Zero Trust: Verify explicitly — Conditional Access, MFA, PIM, Entra ID Identity Protection all evaluate risk signals at every authentication. Least privilege — RBAC, Managed Identities, Key Vault access policies, and Azure Policy enforce minimal permissions. Assume breach — Private Endpoints eliminate public exposure, NSGs segment the network, Defender for Cloud detects threats, Log Analytics provides audit trails.
The practical implication: do not trust the network perimeter. A resource inside your VNet is not automatically trusted — it must still authenticate with valid credentials, be authorised via RBAC, and access only what it explicitly needs. A compromised VM inside the VNet should not be able to reach a database it is not supposed to reach.
Microsoft Defender for Cloud is a CSPM and CWPP tool — it assesses configuration posture, generates security recommendations, and detects threats within Azure workloads (VMs, containers, storage). Its scope is primarily Azure resources.
Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation and Response (SOAR) platform. It ingests security signals from a vast range of sources — Azure services, Microsoft 365, Active Directory, third-party firewalls, endpoint detection tools, cloud providers (AWS, GCP), custom applications — correlates them using machine learning and built-in analytics rules, generates incidents, and enables automated response via playbooks (Logic Apps).
In production, Defender for Cloud generates alerts that are forwarded to Sentinel. Sentinel correlates these with signals from other sources (on-premises, Microsoft 365, other clouds) to detect complex, multi-stage attacks that span the entire estate — not just Azure. A Security Operations Centre (SOC) works primarily in Sentinel; infrastructure and cloud teams work primarily in Defender for Cloud. They are complementary, not competing tools.
Azure Monitor is the umbrella monitoring service that collects, analyses, and acts on telemetry from Azure resources, on-premises environments, and other clouds. Its key components:
Metrics — numeric time-series data automatically collected from Azure resources (CPU percentage, disk IOPS, network throughput). Retained for 93 days at no extra cost. Used for real-time dashboards and metric-based alerts.
Log Analytics Workspace — a log store that ingests structured and unstructured log data from Azure resources, VMs (via Azure Monitor Agent), applications, and custom sources. Queried using KQL (Kusto Query Language). The foundation for diagnostic logs, application insights, and security event logging. Data is retained for 30 days by default; longer retention costs extra.
Alerts — rules that trigger notifications or automated actions when a metric crosses a threshold or a log query returns results. Alert rules fire action groups — which can email, call a webhook, trigger a Logic App, or create a ServiceNow ticket. Alerts are the operational nervous system of an Azure environment.
Application Insights — APM (Application Performance Monitoring) for web applications. Tracks request rates, response times, failure rates, dependencies, and user behaviour. Built on top of Log Analytics.
Workbooks — interactive report templates that combine metrics, logs, and parameters into dashboards. Used for operational reporting, incident investigation, and compliance evidence.
Azure Cost Management + Billing provides visibility into cloud spend, tools to analyse it, and controls to manage it. In production environments, it is used for four purposes:
Cost analysis — view spend broken down by subscription, resource group, resource type, tag, or time period. Identify which services and workloads are driving cost. Filter by tag (Environment, Application, CostCentre) to allocate spend to business units accurately.
Budgets — set monthly spend limits at subscription, resource group, or management group level. Configure alerts when spend reaches 80% of budget, 100%, and 120% (forecast). Budgets can trigger action groups — for example, emailing the team lead and creating a ServiceNow ticket.
Cost recommendations — Azure Advisor provides cost optimisation recommendations: right-sizing underutilised VMs, deleting unused resources (unattached disks, empty public IPs), purchasing Reserved Instances for consistently running workloads, and identifying idle SQL databases.
Exports — schedule daily or monthly cost data exports to an Azure Storage account in CSV format for integration with internal finance systems, BI tools (Power BI), or custom reporting.
Azure Log Analytics is a centralised log store and query engine. Resources send diagnostic logs, metrics, and activity logs to a Log Analytics Workspace. The Azure Monitor Agent on VMs sends Windows Event Log, Syslog, performance counters, and custom log files. Applications send traces and exceptions via Application Insights. All data is queried using KQL (Kusto Query Language) — a read-only, SQL-like language optimised for time-series log analytics.
Essential KQL patterns for administrators:
- AzureActivity | where OperationNameValue contains "delete" | project TimeGenerated, Caller, ResourceGroup, ResourceId | order by TimeGenerated desc — who deleted what and when
- Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" | where CounterValue > 90 | summarize avg(CounterValue) by Computer, bin(TimeGenerated, 5m) — find VMs with high CPU
- SecurityEvent | where EventID == 4625 | summarize FailedLogins = count() by Account, Computer | sort by FailedLogins desc — failed login attempts per account
- AzureDiagnostics | where ResourceType == "STORAGEACCOUNTS" | where StatusCode == 403 — unauthorised storage access attempts
Azure Advisor is a personalised recommendation engine that analyses Azure resource configuration and usage telemetry to provide actionable guidance across five categories.
Cost — identifies underutilised resources (VMs running at less than 5% CPU, unused disks, idle public IPs), recommends Reserved Instances for consistently running VMs, and estimates potential monthly savings for each recommendation.
Security — surfaces recommendations from Defender for Cloud: enable MFA, restrict RDP access, enable disk encryption, enable monitoring agents. Directly linked to the Secure Score.
Reliability (High Availability) — recommends changes to improve resilience: deploy VMs across Availability Zones, enable geo-redundant storage, configure backup for VMs, set up Azure SQL failover groups.
Performance — identifies performance bottlenecks: VMs hitting premium storage throttling limits, App Services hitting connection limits, SQL queries triggering full table scans.
Operational Excellence — recommends governance improvements: apply tags, configure diagnostic settings, use deployment best practices, keep VM agents up to date.
Review Advisor weekly as part of operational hygiene. Configure Advisor Score — similar to Secure Score but across all five categories — as an operational health KPI for the Azure environment.
An effective alerting strategy starts with defining what needs to be monitored, at what threshold, and what action should follow. Alerts that fire too frequently become noise; alerts that do not fire for real problems are worse than no alerts.
Alert types: Metric alerts fire when a value crosses a threshold (CPU > 90% for 5 minutes). Log alerts fire when a KQL query returns results (count of 403 errors > 10 in 5 minutes). Activity Log alerts fire when specific management operations occur (VM deleted, NSG rule changed, storage account public access enabled). Service Health alerts notify of Azure service outages in regions you use.
Action Groups define what happens when an alert fires: email notification, SMS, voice call, push notification, webhook, Logic App (for automation), Azure Function, or ServiceNow/PagerDuty integration. Create role-specific action groups: infrastructure team for VM alerts, security team for Defender for Cloud alerts, database team for SQL alerts.
Severity levels: Sev 0 (critical, requires immediate response), Sev 1 (active security incident), Sev 2 (anomaly requiring investigation within 4 hours), Sev 3 (informational, review next business day). Configure alert rules with appropriate severity and ensure on-call procedures match each level.
Critical alerts every Azure administrator should have: VM CPU > 90% for 10 minutes, failed authentication attempts > 10 in 5 minutes, storage account public access enabled (Activity Log), Key Vault deleted, NSG rule allowing RDP/SSH from Internet added.
The Azure Activity Log records management plane operations — every create, update, or delete action performed on Azure resources through ARM, regardless of the method (portal, CLI, PowerShell, Terraform). It records who performed the action, when, from which IP, and whether it succeeded. The Activity Log is automatically enabled, retained for 90 days, and available at the subscription level. It is the primary tool for investigating "who changed what and when."
Azure Resource Logs (previously called Diagnostic Logs) record operations that happen inside a resource — data plane operations. A storage account's resource log shows which files were read, written, or deleted, by which identity, from which IP. A VM's resource log shows OS-level events. Resource logs are not enabled by default — you must configure Diagnostic Settings for each resource and choose a destination (Log Analytics Workspace, Storage Account, or Event Hub).
In practice: the Activity Log tells you about infrastructure changes (who deleted the NSG, who modified the firewall rule). Resource Logs tell you about data access and internal operations (who read the secret from Key Vault at 3am, what files were deleted from the storage account). Both are essential — enable Diagnostic Settings on all production resources as a baseline, sending logs to a central Log Analytics Workspace.
ARM Templates are JSON-based declarative templates that define Azure resources and their configurations. They are the native Azure IaC format — every resource in Azure has a corresponding ARM template representation. ARM templates are verbose and difficult to read at scale (a complex environment can be thousands of lines of JSON), but they are the most complete and authoritative way to represent Azure resources because they map directly to the ARM API.
Bicep is Microsoft's domain-specific language for Azure deployments that transpiles to ARM templates. It is significantly more readable and concise than ARM JSON, supports modules for reusability, provides better tooling (VS Code extension with IntelliSense), and is the recommended approach for new Azure-native IaC. Because it compiles to ARM, it has complete coverage of all Azure resource types immediately when they are released.
Terraform is HashiCorp's open-source IaC tool that supports multiple cloud providers (Azure, AWS, GCP, and hundreds of others) through providers. It maintains a state file that tracks the current deployed state and calculates diffs. Terraform is the dominant choice in multi-cloud organisations and is preferred where team expertise already exists. The AzureRM provider is well-maintained and covers most Azure services. New Azure features may lag ARM/Bicep by days to weeks while the provider is updated.
Azure DevOps is Microsoft's DevOps platform providing: Repos (Git repositories), Pipelines (CI/CD), Boards (Agile work tracking), Artifacts (package management), and Test Plans. For Azure infrastructure, Pipelines is the primary component — it automates the testing and deployment of Infrastructure as Code.
A typical Azure infrastructure pipeline: a developer commits Bicep or Terraform changes to a feature branch in Azure Repos → a Pull Request triggers a PR pipeline that runs linting (tflint, bicep build), security scanning (Checkov, tfsec), and a plan/what-if to show what changes would be made → the PR is reviewed and merged → the main branch pipeline runs Terraform apply or az deployment sub create → the deployment is logged in Azure Activity Log with the service principal identity of the pipeline.
Critical practice: pipelines should authenticate to Azure using a Service Principal or Managed Identity (for Azure DevOps-hosted agents), never with a user account or hardcoded credentials. Service Principal credentials should be stored in Azure Key Vault and fetched by the pipeline, not stored as Pipeline Variables in Azure DevOps.
Azure Automation is a cloud-based automation service for process automation, configuration management, and update management across Azure and on-premises environments. Its primary components:
Runbooks — PowerShell, Python, or graphical workflows that automate operational tasks. Common runbooks: start/stop VMs on a schedule (cost saving for dev/test), create weekly disk snapshots for VMs without Azure Backup, tag untagged resources, clean up orphaned resources (unattached disks, unused public IPs), send weekly cost reports.
Update Management — assess and deploy OS updates to Azure and on-premises Windows and Linux machines. Define maintenance windows, exclusion lists, and required update classifications. Track compliance across the entire fleet.
Desired State Configuration (DSC) — declarative configuration management for Windows machines. Define the desired state (IIS must be installed, specific registry keys must be set, certain services must be running), and DSC continuously enforces it. Machines that drift from the desired state are automatically corrected or flagged.
Hybrid Runbook Worker — extends Azure Automation runbooks to execute on on-premises machines or VMs in private VNets, enabling automation of resources that are not accessible from Azure's public automation infrastructure.
Azure Arc extends Azure management and governance capabilities to resources that run outside of Azure — on-premises servers, VMs in other clouds (AWS, GCP), Kubernetes clusters, and SQL Server instances. It does this by installing a lightweight agent on the resource, which registers it with Azure Resource Manager. Once registered, the resource appears in the Azure portal, can have Azure tags and RBAC applied, can be managed with Azure Policy, and can use Azure services like Defender for Cloud, Azure Monitor, and Update Manager.
The problems it solves: organisations with hybrid infrastructure (on-premises + Azure) previously needed separate tooling for on-premises management (SCCM, Ansible, Nagios) and Azure management (Azure Monitor, Defender, Policy). Azure Arc provides a single pane of glass and unified management plane for the entire estate. Policies that apply to Azure VMs can apply to on-premises servers. Defender for Cloud's security recommendations cover Arc-enabled servers. Update Management applies to Arc-enabled Windows and Linux machines.
Common use cases: applying Azure Policy to on-premises Windows Server to enforce configuration standards, using Defender for Servers on on-premises machines for threat detection, and providing a unified inventory across the entire hybrid estate for asset management and compliance reporting.
Azure Logic Apps is a low-code/no-code workflow automation service. It connects applications and services using a visual designer and a library of pre-built connectors (Office 365, Salesforce, ServiceNow, SQL Server, HTTP webhooks, and hundreds more). Workflows are triggered by events (a new file in SharePoint, a new row in SQL, an HTTP request from Azure Monitor) and execute a sequence of actions. Appropriate for integration scenarios, business process automation, and alerting workflows where the logic is relatively straightforward and the primary value is the connector ecosystem rather than custom code.
Azure Functions is a serverless compute service for running small, event-driven pieces of custom code. Functions support C#, Python, JavaScript, PowerShell, Java, and others. They execute code in response to triggers (HTTP request, timer, Queue message, Event Grid event) and scale automatically. Appropriate when the integration logic is complex, requires custom code, needs fine-grained performance control, or needs to interact with systems that do not have Logic Apps connectors.
In production Azure administration: Logic Apps are commonly used for alert automation workflows (Defender for Cloud alert → Logic App → ServiceNow ticket + Teams notification + auto-remediation call). Functions are used for more complex automation: custom scaling logic, data transformation pipelines, or operations that require significant code.
This is the capstone question. Interviewers want to see that you think in systems, not features. A structured answer demonstrates seniority.
1. Governance foundation first. Design the Management Group hierarchy (Root → Platforms → Landing Zones → Sandboxes). Define the subscription strategy (Production, Non-Production, Shared Services, Identity). Assign Azure Policy initiatives at Management Group scope: required tags, allowed regions, no public IPs without exception, required diagnostic settings, Defender for Cloud enabled.
2. Identity and access. Deploy Entra ID tenancy configuration: Conditional Access baseline policies (MFA for all users, block legacy auth), PIM for all privileged roles, break-glass accounts excluded from Conditional Access. Configure Entra Connect for hybrid identity if on-premises AD exists. Define RBAC role assignments: custom roles where built-in roles are over-permissioned.
3. Networking (hub-spoke topology). Deploy a hub VNet with Azure Firewall, VPN Gateway or ExpressRoute gateway, Bastion, and Private DNS Resolver. Deploy spoke VNets for each workload or environment. Peer spokes to the hub. Route internet-bound traffic through Azure Firewall. Configure Private DNS zones for all PaaS services. Deploy NSGs on all subnets with default-deny rules.
4. Security baseline. Enable Defender for Cloud with all workload plans on all subscriptions. Configure Log Analytics Workspace in Shared Services subscription. Enable Diagnostic Settings on all resources. Deploy Microsoft Sentinel. Configure key alert rules. Enable Azure Backup for all VMs with appropriate retention.
5. Cost management. Set budget alerts at subscription level. Enforce tagging via Policy. Identify Reserved Instance candidates for planned production workloads. Configure auto-shutdown for non-production environments.
6. Infrastructure as Code from day one. All resources deployed via Bicep or Terraform through Azure DevOps pipelines. No portal deployments in production. GitOps model — infrastructure changes go through Pull Request review and automated validation before deployment.
Related FAVRITE Articles
- How to Configure Conditional Access for Approved Client Apps in Microsoft Entra ID
- Designing a Secure File Storage Architecture in Azure
- Azure Files Deep Dive: Lessons from a 15TB Production Migration
- How to Reset an Azure Virtual Machine to Factory Settings Using a Managed Disk
- Key Considerations Before Migrating File Shares to Azure
- Understanding Azure File Shares for Enterprise Workloads
- Get link
- X
- Other Apps
Labels
Career & Education- Get link
- X
- Other Apps