INFOTICS Skill Labs — Microsoft Azure interview questions

Enable a system-assigned managed identity on the VM, grant that identity get/list permission on the Key Vault secret (RBAC or access policy), then from the VM request a token from the instance metadata endpoint and call Key Vault. No secret or key is stored on the VM — Azure manages the identity.

Use Infrastructure as Code: Bicep or ARM templates (or Terraform) describe the resources, and you deploy with az deployment group create. It is versioned, reviewable and repeatable, prevents drift, and lets you recreate whole environments. Parameters separate config (names, sizes) from the template.

Ensure their address spaces do not overlap, then create a VNet peering between them (it is bidirectional to configure). Resources then communicate over the Azure backbone with low latency. Check NSGs allow the traffic, and if one VNet has a gateway, enable gateway transit so the other can use it.

Lead with the impact in their terms (cost, risk, time, customers affected), not the technical cause. Use a simple analogy, avoid jargon, and offer a clear recommendation with options and trade-offs. Confirm they have understood and tell them what you need from them. The goal is a confident decision, not to show how much you know.

Set a cadence and a single source of truth: short, regular updates in plain language with status, impact, next step and ETA — even when the news is "no change yet". Tailor the detail to the audience and never let people find out bad news late. Reliable, proactive communication builds the trust that lets you do the technical work.

Create the VM (portal, CLI az vm create, or ARM/Bicep), choosing a size, image, VNet/subnet and an SSH public key (not a password). Open only port 22 in the NSG, ideally from your IP or via Azure Bastion so no public IP/open port is needed. Connect with ssh azureuser@<ip> or through Bastion in the portal.

Connect your answer to the actual job and company: what about the work, the stack or the mission fits your strengths and goals. For the three-year question, show healthy ambition and direction (deeper expertise, more ownership, perhaps leading) that the company could realistically support, so it reads as commitment, not a stepping stone.

Give a concrete example: how you set clear expectations, paired on real work, let them struggle productively before stepping in, gave specific feedback, and gradually handed over ownership. Mention a result — they shipped something, passed a certification, became independent. Leadership is about multiplying others, not doing it all yourself.

Protect the business first: a production outage affecting users usually wins. State your rule — impact and urgency over who is shouting loudest — communicate quickly to set expectations, delegate or ask for help, and park or renegotiate the lower-impact items with their owners. Show calm, a clear framework, and that you keep people informed.

Enable Application Insights for request/dependency/exception telemetry, and send the app’s diagnostic logs to a Log Analytics workspace. Use the portal’s Diagnose and solve problems, the Log stream, and Metrics (HTTP 5xx, response time). Query logs with KQL to find the failing requests and their exceptions.

ACI runs a single container quickly with no orchestration — good for a short task, a build step or a simple always-on container. AKS is a managed Kubernetes cluster for multiple containers that need orchestration, scaling, rolling updates and service discovery. Start with ACI for simple workloads; move to AKS when you need orchestration.

Explain how you gathered the facts you could quickly, identified the biggest risk, made a reversible decision where possible, and set a point to re-evaluate. Note how you communicated the uncertainty and your assumptions. Show judgement and bias for action — making a sound call and adjusting beats waiting for perfect information.

Be specific and show it is a habit: hands-on labs and home projects, following release notes and a few trusted sources, a certification roadmap, reading other people’s code or post-mortems, and teaching others to cement what you learn. Tie it to this role’s stack. Enthusiasm plus a concrete routine beats a vague "I love learning".

Deallocate (stop) the VM when idle — a stopped-deallocated VM stops compute charges (you still pay for the disk). Automate it with an auto-shutdown schedule on the VM, or an Automation runbook/Logic App to start and stop it on a schedule. For throwaway labs, delete the resource group when done.

Use the STAR method: briefly set the Situation and Task, then spend most of your answer on the Action — how you broke the problem down, what you tried, how you tested — and finish with the Result and what you learned. Pick a real example with a measurable outcome (time saved, outage resolved) and show your reasoning, not just the fix.

Create the database, then restrict access: use a private endpoint or the SQL firewall to allow only required networks, and authenticate with Microsoft Entra ID (or a managed identity) rather than a SQL login where possible. Store any connection secret in Key Vault. Enforce encryption in transit (it is on by default).

Pick a real failure and own it without blaming others. Describe how you contained the impact, communicated honestly, fixed the root cause (not just the symptom), and added a safeguard — a test, a monitor, a checklist, a runbook — so it cannot recur. Interviewers want accountability and a blameless, learning mindset, not a claim that you never fail.

Use an Azure Storage account with the static website feature enabled (serves from the $web container), or put files in Blob storage and front them with Azure CDN/Front Door for caching and HTTPS. Set the correct content types and use lifecycle rules/tiers to control cost. No VM is required.

Remove the single point of failure: run two or more instances across Availability Zones (or a scale set) behind a load balancer, move the database to a managed, zone-redundant service (Azure SQL/Cosmos DB), keep the app stateless, and back it up with Azure Backup. Define the RTO/RPO and test recovery.

Show that you separated the person from the problem. Explain how you listened to their reasoning, brought data or a small proof of concept instead of opinions, looked for the shared goal (reliability, deadline, cost), and either reached agreement or disagreed-and-committed to the team’s decision. Avoid blaming; emphasise the outcome and the relationship staying intact.