Scenario-Based Azure Interview Questions

“First I'd stop guessing and use Network Watcher. IP flow verify takes the VM, the port, and my source address, and tells me which rule allowed or denied it. I'd also open the effective security rules on the NIC, because there can be an NSG on the subnet and another on the NIC, and inbound traffic has to be allowed by both. Very often the tidy-up removed an allow rule in one of them, or added a deny with a lower priority number, which wins. If the fix needs a change approval, I'd reach the machine through Azure Bastion or the serial console in the meantime, rather than opening RDP to the whole internet. Once it's working, I'd get the NSG rules into Bicep so the next tidy-up goes through a review.”

“That error is a useful clue. It means our connection still reached SQL over the public path, so the app isn't using the private endpoint at all. I'd check two things. First, the App Service has to be integrated with the VNet, otherwise its outbound traffic never enters the VNet. Second, DNS. The app still connects to the normal server name, and that name only points to the private IP if the privatelink database zone exists and is linked to the VNet the app resolves from. If the company runs its own DNS servers, they need to forward that zone to Azure's resolver. To prove it, I'd open the app's console and resolve the server name. If I get a public address back, it's DNS. Once it returns the private IP, the connection works, and public access can stay off.”

“When outbound calls time out under load but the app looks healthy and the other side sees nothing, I suspect SNAT port exhaustion. Outbound connections from App Service to the internet share a limited pool of ports, and if the code opens a new connection for every request, for example creating a new HTTP client each time, those ports run out and new calls wait until they time out. The payment team sees nothing because the requests never reach them. To test it, I'd run the SNAT port exhaustion check under Diagnose and solve problems for the peak window, and read how the code creates its HTTP clients. The main fix is in code: reuse connections through a client factory. If we truly need more outbound connections, I'd add VNet integration with a NAT gateway, and use private endpoints for Azure services so that traffic doesn't use SNAT at all.”

“Since the hub works, the tunnel is fine, so I'd focus on what's different for the spoke. First, the peering. The hub side needs allow gateway transit and the spoke side needs use remote gateways, or the spoke never learns the routes to on-premises. I'd then open the effective routes on a spoke VM's network card to see where traffic for the on-premises range actually goes. If there's a route table sending everything to a firewall in the hub, the firewall needs a rule allowing it. Then the return path. On-premises has to know the spoke's address range: with BGP it's advertised once gateway transit is set, but a static VPN needs it added on the on-premises side. If traffic goes through the firewall one way but not back, it gets dropped, so the gateway subnet may need its own route table. Next hop in Network Watcher confirms each step.”

“The fact that the script works tells me the SAS token is fine. CORS is a browser rule: before the real upload, the browser sends a preflight request, and if the storage account doesn't say this origin is allowed, the browser blocks it. Scripts don't do that check. So I'd go to the storage account and add a CORS rule on the Blob service with our site's origin, the PUT and OPTIONS methods, and the headers the upload sends, like the blob type header. If the error were a 403 with an authentication message instead, I'd look at the SAS: expiry, permissions, or a start time slightly in the future because of clock differences. I'd keep the allowed origins to our own domains, not a star, and hand out short-lived SAS tokens that can only write to one container.”

“First I'd set expectations, because an archived blob can't be read at all until it's rehydrated to an online tier. I'd say I can start now, but I can't promise an hour. Standard rehydration can take many hours. High priority often finishes in under an hour for smaller files, and a contract is small, but it isn't guaranteed. So I'd kick off high priority right away, and I'd do it as a copy into a new blob in the Hot tier rather than changing the tier of the original. That leaves the archived copy where it is and avoids an early deletion charge if it hasn't been in Archive long enough. I'd watch the rehydration status and send the file as soon as it lands. Afterwards, I'd look at the lifecycle rule: documents people may need at short notice probably belong in Cold, not Archive.”

“A quota error like that means Azure isn't out of machines, our subscription is at its limit. There are two kinds: a total cores limit for the region and a limit per VM family, so first I'd open Usage and quotas and see which one we hit. Then I'd raise a quota increase request straight away; many go through quickly, but I can't count on it. Meanwhile I'd free cores. Deallocated VMs still count against the quota, so that means deleting idle test VMs in the same subscription and region, or scaling test scale sets to zero. Or I'd switch the scale set to a VM size from a family that still has room. I'd also ease the load with caching or by switching off heavy non-essential features. For the next launch, quota checks go on the readiness list weeks ahead, next to the load test.”

“Queue triggers deliver messages at least once, not exactly once. The function picks up a message, and only when the run finishes successfully is it deleted. If the run throws or times out after the email already went out, the message comes back and runs again, so the customer gets a second email. If a message keeps failing, after the maximum number of tries, five by default, the runtime moves it to the poison queue so it stops blocking everything else. So I'd look in Application Insights for failures and timeouts on those message IDs, since it's probably one step failing after the email. The real fix is to make the function safe to run twice: record that confirmation was sent for that order ID and check before sending. And I'd alert on anything landing in the poison queue.”

“First I'd open boot diagnostics, which shows a screenshot of the console or the serial log, so I can see if it's stuck on a failed update, a disk check, or a kernel panic. If the service is down, I'd get it running elsewhere in parallel: fail over to the other instance, or restore last night's backup. Next I'd try the serial console, which works even when networking is broken. From there I can often roll back the update or fix a bad config file. If that doesn't work, I'd use the VM repair commands: they make a copy of the OS disk, attach it to a rescue VM, and I fix it there, for example removing the bad package or fixing the boot config. Then I swap the fixed disk back. Afterwards, I'd patch one machine first and wait before patching the rest.”

“When it breaks only after scaling out, I think state first. With one instance, keeping session data or carts in memory works. With three, the load balancer can send a user's next request to a different instance that has never heard of them, so they look logged out. I'd check how the app stores sessions and whether ARR affinity, the setting that pins a user to one instance with a cookie, has been switched off. Turning it back on would reduce the problem quickly, but it's only a patch: any restart, deploy or scale-in still wipes that memory, and load spreads unevenly. The proper fix is to make the instances stateless, keeping sessions and carts in Azure Cache for Redis or the database, so any instance can serve any request. After that change I'd test by restarting one instance mid-session.”

“I'd start with the job itself: how long it really runs, how much memory it needs, what it installs, and what happens if it dies halfway. That rules things out quickly. Functions on the Consumption plan stop a run at ten minutes, so an hour-long job doesn't fit unless we split it into smaller steps. If the job can be packaged in a container, a scheduled Container Apps job is a good fit: it starts on a cron schedule, runs to completion, and we pay nothing between runs. If it's heavy work that splits into many parallel pieces, Azure Batch makes more sense. If it depends on software that's hard to containerise, the quickest win is keeping the VM but having automation start it before the job and deallocate it after. Whatever we pick, I'd add retries, an alert when it fails, and a log of each run.”

“I'd invite the contractor into Entra ID as a guest, so they sign in with their own company account and I never create or share a password for them. Then I'd ask what the work actually is. If they're building and changing resources, Contributor on that one resource group is usually enough; if it's only an App Service, there's often a narrower built-in role. I'd never give them anything at the subscription level. For the two weeks, I'd make the assignment time-bound, ideally through Privileged Identity Management with an end date, so it expires even if everyone forgets. I'd make sure a Conditional Access rule asks guests for MFA. At the end I'd confirm the access is gone, look over the activity log for what they changed, and make sure their work is in our code, not only in the portal.”

“First I'd check which permission model the vault uses. A vault uses either access policies or Azure RBAC, and if you add an RBAC role to a vault that runs on access policies, or the other way round, nothing changes. If it's RBAC, I'd check the role. Reader on the vault only covers management, so it can see the vault but not read secrets. The app needs something like Key Vault Secrets User. Then I'd check it's the right identity. If the app uses a user-assigned identity, the code has to be told its client ID, or it picks up nothing or the wrong one. I'd also look at the vault's firewall, because a blocked network also gives a 403, and the error text says which it is. And a role assigned a minute ago can take a few minutes to kick in.”

“First I'd get deployments working again. I'd find the app registration behind the pipeline's service connection, add a new client secret with a short expiry, update the service connection, and rerun one pipeline to confirm. Anything urgent can deploy tonight. While I'm there, I'd check what that service principal can access, because old ones often have Owner on far more than they need, and I'd trim it. Then the real fix: move the pipelines to workload identity federation. The pipeline gets a short-lived token from Entra ID that trusts our pipeline directly, so there's no secret to expire, rotate or leak. Once that works, I'd delete the old secret. Finally, every app registration gets at least two owners who still work here, and a scheduled check that warns us weeks before any remaining credential expires.”

“The gap is that we were only watching the inside of the system, if anything. First, I'd add availability tests in Application Insights that request the home page and one key page every few minutes from several regions, and alert when more than one location fails, so one bad probe doesn't page anyone. Second, alerts on symptoms users feel: a spike in 5xx responses from the App Service and response time going up. CPU alerts alone miss most outages. Third, the alerts have to reach a person, so I'd set up an action group that pages whoever is on call, not a shared inbox nobody reads at night, and then trigger a test alert to prove the whole chain works. I'd also run a short blameless review of last night: what broke, and why nothing noticed.”

“No deploy doesn't mean nothing changed: data grows, statistics update, and the optimiser can pick a new plan. First I'd check resource use for the database. If CPU or IO is pinned at the limit, the query is waiting for resources, not slow on its own. I'd also check for blocking. If resources look fine, I'd open Query Store, find the query, and look at its plans over time. Very often there's a new plan from a few days ago, maybe a scan where it used to seek, compiled for a parameter value that suited a different caller. The quick fix is to force the old plan from Query Store, or let automatic tuning do it. Then I'd fix the real cause, like a missing index or a query that behaves badly with skewed data, so we're not relying on a forced plan forever.”

“A failover group moves the data, not everything around it. First I'd check the connection string. If the app points at the primary server's own name, it's still talking to the old server. It should use the failover group's listener name, which always points at whichever side is primary. Next, logins. If the app uses a SQL login created on the server, that login lives in the primary's master database, and it has to exist on the second server with the same SID, or the database users end up orphaned. Contained users or Entra authentication avoid that. Then networking: firewall rules and private endpoints belong to each server, so the second one needs its own, plus DNS that works in that region. I'd write down every gap, fix it in code, and run the test again.”

“The total can look fine while one partition is overloaded. Cosmos DB spreads the container's throughput evenly across its physical partitions, so if most of the evening traffic lands on one key, that partition runs out of its share and returns 429s while the others sit idle. I'd check the normalized RU consumption metric split by partition key range. If one range is near the top and the rest are low, that's the hot partition. The diagnostic logs then show which key values are doing it. I'd also look for queries without the partition key in the filter, which fan out across partitions, and an indexing policy indexing fields nobody queries, which makes writes more expensive. The lasting fix is usually a better partition key, which means a new container and moving the data. Raising throughput alone mostly pays for idle partitions.”

“That's almost certainly a deployment in Complete mode. The default, Incremental, only adds or updates what's in the template. Complete makes the resource group match the template exactly, so anything not listed gets deleted, including a storage account someone created by hand. First I'd pause the pipeline so it doesn't run again, check whether the account can be recovered, which is possible for a short time if the name hasn't been reused, and tell whoever owned it. Then I'd check the deployment history to confirm the mode. To prevent it, I'd switch to Incremental unless there's a strong reason, add a what-if step that shows every change before apply, and put delete locks on production resource groups. And the stray account needs an owner: either it goes into our template, or it moves to its own group.”

“A jump right after a release points at what the app is sending, not new resources. First I'd query the Usage table in the workspace to see billable volume by data type per day, which usually shows one table jumping on release day, often traces or dependencies from Application Insights. Then I'd find why: a log level left on debug, a new retry loop writing an error on every attempt, or a diagnostic setting someone switched to send every category. The fix is at the source: log level back to warning in production, sampling turned on for high-volume telemetry, and only the diagnostic categories we actually query. For bulky logs we keep but rarely search, a cheaper table plan helps. I'd add a budget alert on the workspace and add a volume check to the release checklist. A daily cap is a last resort, because it stops collecting right when you might need the logs.”

“RDP open to the internet gets hammered by password guessing all day, so I'd treat it as urgent but not panic. First I'd check the security logs on those machines for successful sign-ins from strange places, and if I find any, that VM becomes an incident. Then I'd give the owners a better way in before taking the old one away: Azure Bastion, so they connect through the portal over HTTPS without any public IP on the VM, or just-in-time access that opens the port to their own address for a few hours. With that ready, I'd remove the public IPs and the open rules subscription by subscription, with a date agreed with each owner. To stop it coming back, I'd assign a policy at the management group that denies public IPs on VM network cards, with a reviewed exemption process for real exceptions.”

“Older pods working often just means their image was already cached on those nodes, so I wouldn't read too much into it. First I'd describe one of the stuck pods and read the event message, because it tells me which of three problems I have. If it says not found, it's the tag or the registry name, often a pipeline that pushed a tag nobody deployed. If it says unauthorized, the cluster's kubelet identity probably doesn't have AcrPull on the registry, maybe because the registry was recreated or the role assignment was removed. Attaching the registry to the cluster puts that role back, and the check command confirms the nodes can pull. If it's a timeout, I'd look at networking: the registry may now only allow private access, and the nodes can't reach its private endpoint or resolve its name.”

“I'd start with a pending pod and read its events, because the scheduler says why: insufficient CPU or memory, or no node matching a selector or taint. If it's insufficient resources, the question becomes why the autoscaler didn't add nodes. I'd check its status and events. Common reasons: the node pool is already at its maximum count, or the pods request more than any single node of that size can offer, so a new node wouldn't help. Then the Azure-side limits. The subscription may have hit its vCPU quota for that VM family in the region, which shows up as failed scale operations in the activity log. And with classic Azure CNI, every node reserves IPs for its pods up front, so a small subnet runs out and new nodes can't join. Short term I'd raise whichever limit is hit; long term, headroom and overlay networking.”