Azure Engineer interview questions

An Azure region is a deployment location inside an Azure geography, while a paired region is a designated partner that supports platform recovery where pairing applies.

• A geography is the broader market boundary used to meet data-residency requirements, subject to the commitments of each Azure service.
• A region contains one or more datacenters connected by a low-latency network and is where I deploy resources.
• Traditional region pairs are usually within one geography and support sequenced platform updates and recovery priority, but I still configure workload replication, backups, and failover.

Availability zones are physically separate datacenter groups within one Azure region, used to survive a datacenter-level failure.

• Each zone has independent power, cooling, and networking, but zones in the region remain connected by low-latency links.
• A zonal resource is pinned to one zone, while a zone-redundant service spreads or replicates across zones for me.
• I would place redundant VM instances in different zones and verify that every required service and SKU supports zones in that region.

A resource belongs to one resource group, and that resource group belongs to one subscription.

• The subscription is a billing, quota, and access boundary associated with a Microsoft Entra tenant.
• A resource group is a lifecycle container for related resources, although its resources can run in different Azure regions.
• RBAC and Azure Policy can be assigned higher in the hierarchy and inherited downward, so deleting a resource group must be treated as deleting everything inside it.

The ARM control plane manages Azure resources, while a service's data plane works with the data inside a deployed resource.

• Creating a storage account or changing its network settings is a control-plane operation sent through Azure Resource Manager.
• Uploading a blob or querying an Azure SQL database is a data-plane operation handled by that service's endpoint.
• The permissions are separate, so Contributor can manage a storage account but does not automatically grant permission to read its blobs.

Microsoft secures the cloud platform, while the customer remains responsible for their data, identities, access, and workload configuration.

• Microsoft always owns physical datacenters, hardware, and the underlying host infrastructure.
• With an Azure VM, I still patch the guest OS and secure the application, while Azure SQL takes over more OS and database engine maintenance.
• I must configure RBAC, network exposure, encryption choices, backups, and monitoring rather than assuming Azure enables the right controls automatically.

A user represents a person, a group collects identities, and a service principal represents an application or automation in a tenant.

• Users sign in interactively and can be cloud-only or synchronized from an on-premises directory.
• Groups let me assign the same application access or Azure role to many members instead of managing each person separately.
• A service principal is the tenant-local identity of an application and should receive only the roles its workload needs.

A managed identity is a Microsoft Entra service principal whose credential lifecycle Azure manages for the workload.

• The workload requests a short-lived token from Azure and does not keep a password or client secret in code or configuration.
• A system-assigned identity is tied to one resource's lifecycle, while a user-assigned identity can be attached to multiple resources.
• I still grant the identity a specific data-plane or control-plane role on the target resource because creating it grants no useful access by itself.

An Azure RBAC role assignment grants a principal a role at a scope, and that access is inherited by child scopes.

• Common scopes run from management group to subscription, resource group, and individual resource.
• The assignment combines who receives access, which role defines allowed actions, and where those actions apply.
• I prefer the narrowest built-in role and scope, such as Storage Blob Data Reader on one account instead of Owner on the subscription.

Azure Key Vault centrally protects secrets, cryptographic keys, and certificates, and an application should access it with a managed identity.

• Secrets hold values such as connection strings, keys perform cryptographic operations, and certificates include certificate lifecycle material.
• Microsoft Entra authentication plus Azure RBAC should grant the application only operations such as reading a particular vault's secrets.
• I would also restrict network access where required and retain recovery controls such as soft delete and purge protection.

MFA adds another proof of identity, while Conditional Access decides when access is allowed and whether MFA or another control is required.

• A Conditional Access policy evaluates signals such as user, application, device state, location, and sign-in risk.
• Its grant controls can require MFA or a compliant device, or block the sign-in when the conditions match.
• I would test policies in report-only mode and exclude controlled emergency accounts to avoid locking every administrator out.

I choose a private, non-overlapping CIDR block large enough for current subnets and expected growth.

• A CIDR such as 10.20.0.0/16 defines the VNet address space, and smaller ranges from it are allocated to subnets.
• I account for Azure reserving five IP addresses in every subnet, so a /29 does not provide all eight addresses to resources.
• I check planned peering, VPN, and ExpressRoute networks first because overlapping address spaces prevent straightforward routing between them.

A subnet is a non-overlapping slice of a VNet address space used to place and control groups of resources.

• A VNet can contain multiple subnets, but each subnet range must stay inside the VNet and cannot overlap another subnet.
• I can associate an NSG and a route table with the subnet to apply common traffic controls and routes.
• Some services require dedicated or delegated subnets, so I check service requirements before mixing workloads in one range.

An NSG filters inbound and outbound traffic with stateful allow or deny rules, and service tags represent maintained groups of Azure IP ranges.

• Rules match source, destination, protocol, port, and direction, with lower priority numbers evaluated before higher ones.
• Because NSGs are stateful, response traffic for an allowed connection does not need a separate reverse rule.
• A tag such as Storage is safer to maintain than hardcoded service IP lists, but I still scope ports and direction narrowly.

A user-defined route overrides or supplements Azure's system routes to send matching traffic to a chosen next hop.

• A route table matches address prefixes and supports next-hop types such as `Virtual appliance`, `Virtual network gateway`, and `None`.
• The `Virtual appliance` type uses a private IP and can steer traffic to managed Azure Firewall or a third-party Network Virtual Appliance, but Azure Firewall itself is not an appliance.
• I associate the route table with a subnet and verify IP forwarding and return routes for traffic sent through the network function.

An Azure public IP is a separately managed address resource that exposes a supported Azure frontend to the internet.

• It can be associated with resources such as a load balancer frontend, NAT Gateway, application gateway, or VM network interface.
• A static allocation keeps the address assigned to the resource, which is important for DNS records and external allowlists.
• A public IP provides reachability, not protection, so NSGs, firewalls, and application authentication still control access.

Azure NAT Gateway gives a subnet scalable, predictable outbound internet connectivity through one or more static public IP addresses.

• Private resources use source NAT through the gateway without each VM needing its own public IP.
• It is attached at subnet level and takes precedence for new outbound connections from supported resources in that subnet.
• It does not accept unsolicited inbound connections, so I use a load balancer, application gateway, or Bastion for inbound needs.

Azure Bastion provides managed RDP and SSH access to VMs over their private IP addresses without public IPs on the VMs.

• An administrator connects through the Azure portal or supported native client while Bastion reaches the target inside the VNet.
• The VM avoids exposing RDP port 3389 or SSH port 22 directly to the internet.
• I still restrict who can connect with Azure RBAC, VM credentials or Entra login, and appropriate network rules.

Azure Private Link is the private connectivity technology, and a private endpoint is a network interface with a private VNet address that connects to a supported service through it.

• Clients send traffic to the private IP across the Microsoft network instead of reaching the service's public endpoint.
• The endpoint is created in a subnet and targets a specific service subresource, such as Blob on a storage account.
• I also review the service's public network access because adding a private endpoint alone may not disable its public endpoint.

Private DNS makes the service's normal hostname resolve to the private endpoint address for clients in the connected VNet.

• Azure services use private DNS zones such as privatelink.blob.core.windows.net for private endpoint records.
• Linking the zone to the VNet lets workloads keep using the standard service hostname while DNS returns the private IP.
• For on-premises or custom DNS clients, I configure forwarding or Azure DNS Private Resolver so they receive the same private answer.

VNet peering gives two virtual networks private, low-latency connectivity over the Azure backbone, but the connectivity is not transitive by default.

• Peered VNets can communicate using private addresses when their address spaces do not overlap and security rules allow the traffic.
• If VNet A peers with B and B peers with C, A does not automatically gain a route to C.
• A hub-and-spoke design needs explicit peerings or routing through a gateway, firewall, or network virtual appliance for spoke-to-spoke traffic.