Azure Engineer interview questions

I would centralize shared connectivity and inspection in a hub VNet and peer each workload VNet as a nontransitive spoke.

• Spoke route tables send approved prefixes or 0.0.0.0/0 to Azure Firewall in the hub, while NSGs still enforce subnet and workload boundaries.
• Gateway transit lets spokes use the hub VPN or ExpressRoute gateway, with Allow gateway transit on the hub peering and Use remote gateways on each spoke.
• Because VNet peering is not transitive, spoke-to-spoke traffic needs explicit peering or a routed path through the hub appliance.

Azure chooses the longest matching prefix first, then uses route source precedence when equally specific routes compete.

• A 10.20.4.0/24 route wins over 10.20.0.0/16 regardless of whether the next hop came from BGP or a route table.
• For equal prefixes, a user-defined route normally wins over a BGP route, and BGP normally wins over a system route.
• I inspect effective routes on the NIC and verify the return path because a stateful firewall still needs symmetric routing.

I would deploy Azure Firewall in its dedicated AzureFirewallSubnet and route inspected spoke traffic through its private IP.

• A Firewall Policy separates network, application, and DNAT rule collections, with explicit priorities and threat-intelligence mode managed centrally.
• Standard covers stateful L3 to L7 filtering, while Premium adds features such as TLS inspection and IDPS when their certificate and performance costs are justified.
• UDRs on every participating subnet preserve symmetric paths, and diagnostic logs go to Log Analytics for rule and flow evidence.

I use NAT Gateway when private workloads need scalable, predictable outbound internet addresses without accepting unsolicited inbound connections.

• Associating it with a subnet makes it the preferred internet egress path and provides 64,512 SNAT ports per attached public IP address.
• Up to 16 public IP addresses or a public IP prefix can expand port capacity and provide an allow-listable egress range.
• NAT Gateway does not inspect traffic or replace inbound load balancing, so NSGs and Azure Firewall remain separate controls.

I would create a private endpoint in a consumer VNet, approve the connection, and disable public network access where the service supports it.

• The endpoint receives a private IP from the selected subnet, while the service remains provider-managed and does not require broad VNet peering.
• A service-specific private DNS zone, such as privatelink.database.windows.net, is linked to the VNets that must resolve the normal service name privately.
• NSGs, endpoint approval, Azure RBAC on the PaaS resource, and data-plane authorization solve different layers and must all be designed.

I would deploy redundant inbound and outbound endpoints in dedicated subnets and connect them with a DNS forwarding ruleset.

• On-premises DNS forwards Azure private-zone queries to inbound endpoint IPs over ExpressRoute or VPN.
• Outbound rules conditionally forward corporate suffixes to on-premises DNS servers, and the ruleset is linked to every VNet that needs those rules.
• Private DNS zone links remain responsible for Azure records, so I avoid forwarding loops and test both UDP and TCP port 53 paths.

I choose by scope and protocol: global HTTP at the edge, DNS routing, regional HTTP, or regional layer-four traffic.

• Front Door is a global anycast L7 proxy with edge TLS, WAF, path routing, and origin health checks, while Traffic Manager returns DNS answers and never proxies traffic.
• Application Gateway is a regional L7 reverse proxy with WAF and private or public frontends for web workloads inside VNets.
• Azure Load Balancer distributes TCP or UDP flows at L4 and fits high-performance public or internal regional services.

I would use ExpressRoute as the primary private circuit and an active-active VPN gateway as an independently routed backup.

• ExpressRoute provides provider-backed private connectivity and BGP but does not encrypt traffic by default, while IPsec VPN encrypts traffic across the public internet.
• Route advertisements and BGP weights must make the intended primary path deterministic without creating asymmetric return traffic through stateful appliances.
• Regular failover tests must prove that the VPN has enough throughput and that DNS, firewalls, and on-premises routes still work on the backup path.

I prefer a managed identity for an Azure-hosted workload and use a service principal when the identity lifecycle must exist independently of an Azure resource.

• A system-assigned identity follows one resource, while a user-assigned managed identity can be shared by approved workloads and survives their replacement.
• Entra manages managed-identity credentials, eliminating client-secret storage and rotation in the application.
• A service principal still suits external automation or products that cannot use managed identity, but it should use a certificate or federation instead of a long-lived secret.

Workload Identity Federation exchanges a trusted external OIDC token for an Entra access token without storing an Azure client secret.

• The federated credential pins issuer, subject, and audience, such as one GitHub environment or one Kubernetes service account.
• CI requests an ID token at runtime, or AKS projects a service-account token, then Azure Identity performs the token exchange for the target application or managed identity.
• Azure RBAC still limits the resulting identity, and narrow subject claims prevent another branch, repository, or service account from reusing the trust.

I start from the smallest required control-plane and data-plane operations and create a custom role only when no built-in role fits.

• Actions and DataActions grant management and resource-data operations separately, while NotActions subtract from a wildcard grant but do not create an explicit deny.
• AssignableScopes controls where the role definition may be assigned, so I keep it to the required management group or subscriptions.
• I test the role with a representative identity and avoid Owner-like permissions such as roleAssignments/write unless delegation is an explicit requirement.

I would make high-impact Azure roles eligible and require time-bounded activation instead of leaving administrators permanently active.

• Activation can require MFA, justification, approval, and a short duration for roles such as Owner or User Access Administrator.
• Access reviews remove stale eligibility, while PIM alerts expose risky permanent assignments or activations outside the expected process.
• Emergency accounts remain tightly monitored and excluded only from controls that could block recovery, with their use tested and audited.

I use management groups to place Azure Policy and Azure RBAC controls above subscriptions, but I treat their inheritance and exceptions separately.

• A hierarchy can separate platform, production, sandbox, and regulated workloads beneath the tenant root without mirroring a frequently changing org chart.
• Azure RBAC role assignments inherit through child management groups, subscriptions, resource groups, and resources, and an Azure Policy exemption cannot remove or weaken that access.
• Azure Policy assignments also inherit downward, but a Policy exemption only waives evaluation for specified assignments or initiative references at its approved scope and does not affect RBAC.

I choose the least disruptive effect that reliably enforces the requirement and stage new policy from visibility to enforcement.

• Audit and AuditIfNotExists report noncompliance, while Deny blocks a matching create or update request before it reaches the resource provider.
• Modify can add or change supported properties, and DeployIfNotExists can deploy related resources such as diagnostic settings after evaluating existence conditions.
• Modify and DeployIfNotExists need a managed identity plus remediation tasks for existing resources, and an initiative groups related definitions with shared parameters.

I would use Key Vault RBAC, private network access, and identity-based retrieval, then automate rotation according to the secret owner.

• Data-plane roles are assigned to managed identities at the narrowest vault or secret scope, avoiding legacy access policies and broad Contributor grants.
• A private endpoint plus private DNS permits application access while public network access or firewall rules block unapproved paths.
• Key rotation policies handle supported keys, while generic secrets usually need an Event Grid expiry event and a Function that updates the source system before publishing the new version.

I choose Manual, Automatic, or Rolling upgrade mode according to how much control the release requires.

• Manual mode updates the model but leaves existing instances unchanged until automation upgrades them, which gives maximum control but can create version drift.
• Automatic mode can propagate model changes without application-aware batching, so it suits replaceable fleets with tolerance for broad updates.
• Rolling mode replaces batches while honoring health probes, pause time, and minimum healthy percentages, making it the normal choice for controlled application releases.

I use a VM Scale Set with Flexible orchestration because both Spot Priority Mix and multiple VM sizes through Instance Mix require it.

• I select supported availability zones for the scale set and keep application state external so regular capacity remains healthy when one datacenter zone fails.
• Spot Priority Mix defines a base count and percentage of regular instances, with Spot instances supplying only interruptible excess capacity and using the Delete eviction policy.
• Instance Mix ranks several compatible VM sizes to improve capacity access, while autoscale headroom, Scheduled Events, and short drain logic absorb Spot evictions.

I size the App Service plan as the shared compute boundary and use a staging slot to validate the exact build before a controlled swap.

• Apps and slots in one plan compete for its CPU and memory, so scale-out affects the plan rather than allocating isolated workers per app.
• Slot swap warms the destination and exchanges routing, while slot-sticky settings keep environment-specific secrets and endpoints in the intended slot.
• Database changes must remain backward compatible because a swap can be reversed but cannot undo an incompatible schema migration.

I choose Container Apps for containerized HTTP, event-driven, or job workloads that need managed scaling without direct Kubernetes cluster operations.

• Revisions support immutable releases, traffic splitting, and single-revision mode, while KEDA-based rules can scale workloads from HTTP or queue demand to zero where supported.
• A Container Apps environment supplies ingress, logging, networking, and optional workload profiles for dedicated compute or special sizing.
• I choose AKS instead when workloads require Kubernetes APIs, privileged host access, custom operators, or deeper network and scheduling control.

Azure manages the Kubernetes control plane, while I remain responsible for cluster access, workloads, add-ons, networking, and node capacity.

• The managed API server and etcd remove control-plane host operations, but version support, upgrade scheduling, RBAC, and API exposure still need deliberate configuration.
• A small system node pool runs critical add-ons, while user pools separate workloads by VM size, zones, taints, labels, autoscaling, or Spot priority.
• Pod disruption budgets, topology spread, and surge settings let node-image and Kubernetes upgrades preserve application capacity.