Scenario-Based Microsoft Azure Interview Questions

Reservations give a big discount, up to about 72% versus pay-as-you-go, when you commit to a specific VM family, region and term of one or three years. Savings plans commit to a fixed hourly spend for one or three years and apply flexibly across VM sizes, regions, App Service and Functions Premium. Use reservations for very stable workloads and savings plans when your sizes or regions change.

Follow the Cloud Adoption Framework landing zone design. Create a management group hierarchy (platform, landing zones, sandbox, decommissioned), separate subscriptions for identity, management and connectivity, and a hub-spoke or Virtual WAN network. Apply Azure Policy for allowed regions, tagging and diagnostics, and assign RBAC through Entra groups. Deploy it all as code with Bicep or Terraform so new app subscriptions can be vended consistently.

First recover what is possible: soft delete or backups for storage, Key Vault, SQL and VMs. Then add CanNotDelete locks on production groups, remove Owner and Contributor rights from individual users, and grant access through Entra groups with Privileged Identity Management for just-in-time elevation. Deploy infrastructure through pipelines only, and set activity log alerts on delete operations so the team is notified instantly.

List every component, such as App Service plan, Azure SQL tier, storage, bandwidth and monitoring, and model them in the Azure Pricing Calculator for the right region, Central India for example. Include egress, log ingestion and backup storage, which teams often forget. Compare pay-as-you-go with reservations or savings plans, then set a budget with alerts in Cost Management once deployed.

Start with constraints. If the app needs OS-level access, custom drivers or legacy software, a lift-and-shift to VMs is fastest. If it is a standard .NET, Java or Node web app with SQL Server, App Service plus Azure SQL removes patching and gives built-in scaling. Many teams lift and shift first to meet a datacenter exit date, then modernise to PaaS in a later phase.

Use management groups that mirror governance needs rather than the org chart, for example Platform, Corp landing zones, Online landing zones and Sandbox. Give each application or business unit its own subscriptions per environment to isolate quotas, cost and blast radius. Automate subscription vending with pre-wired networking, policy and RBAC. Keep the hierarchy shallow, ideally three or four levels, to avoid policy confusion.

AKS gives full Kubernetes: custom operators, service meshes, node pool control and any Helm chart, but you own upgrades and cluster operations. Container Apps is serverless containers built on Kubernetes, KEDA and Envoy, with scale to zero, revisions, traffic splitting and Dapr, without exposing the Kubernetes API. Pick Container Apps for microservices and APIs with a small ops team, and AKS when you need deep platform control.

Check Application Insights for response times, failed requests and dependency calls around 9 AM, and App Service plan metrics for CPU, memory and instance count. A morning spike often means traffic surge with autoscale reacting too slowly, cold start after idle, or a slow SQL query under load. Fixes include scheduled scale-out before 9 AM, Always On, a higher tier, caching with Redis or query tuning.

That is cold start: the plan scaled to zero and must load a new instance. Options are moving to Flex Consumption with always-ready instances or the Premium plan with pre-warmed instances, reducing package size and dependencies, and choosing a faster-starting runtime. A timer ping is a hack that is not reliable. For strict latency APIs, a dedicated plan or Container Apps with minimum replicas is better.

Check the VM is running and passed boot diagnostics via the serial console or screenshot. Use Network Watcher IP flow verify and effective security rules to see if an NSG blocks port 3389. Check the route table, any firewall and whether the VM has a public IP or you should use Bastion. Inside the OS, use Run Command to check the RDP service and Windows firewall. Reset the configuration if needed.

Avoid the old Consumption plan because of its execution timeout. Good options are Azure Batch or a VM Scale Set using Spot VMs with checkpointing, Container Apps jobs that run on a schedule and stop afterwards, or Durable Functions breaking work into short activities. The key is paying only while the job runs and tolerating restarts. Store input and output in Blob Storage so any worker can resume.

Run the app on App Service Premium v3 or a VM Scale Set spread across three availability zones in Central India. Put Azure Front Door in front for global load balancing, WAF and caching of static content, with a secondary region on standby. Pre-scale before the sale using scheduled rules, add Redis for sessions and catalogue caching, and load test with Azure Load Testing beforehand.

Check the release notes and API deprecations, then upgrade a non-prod cluster first. Set Pod Disruption Budgets and multiple replicas so draining is safe. Upgrade the control plane, then node pools one at a time using max surge so new nodes join before old ones drain. Use planned maintenance windows and auto-upgrade channels for patches. For major risk, run a blue-green cluster and switch traffic.

Queue Storage is cheap and simple, holds millions of messages up to 64 KB each, and suits basic background work. Service Bus is an enterprise broker with queues and topics, FIFO through sessions, duplicate detection, dead-lettering, transactions and messages up to 100 MB on Premium. Choose Service Bus for ordered or business-critical messaging like orders and payments, and Storage queues for simple, high-volume job queues.

If versioning was on, promote the previous version; if soft delete was on, undelete within the retention period. Point-in-time restore can roll back a whole container if enabled. If none were enabled, recovery may only be from backups. Going forward, enable versioning, soft delete and Azure Backup for blobs, give developers read-only roles in production and route writes only through the application identity.

Use Storage insights and Cost Analysis to find which containers and tiers drive cost. Enable last access tracking and apply lifecycle rules that move logs to Cool, then Cold or Archive, and delete after the retention period required by policy. Check for unnecessary GRS replication on non-critical data and leftover snapshots. Compress logs before upload and stop verbose logging at the source.

Enable a system-assigned or user-assigned managed identity on the VM. Assign the identity the least role needed, such as Storage Blob Data Reader on the specific container. In code, use DefaultAzureCredential or ManagedIdentityCredential from the Azure SDK. Then disable shared key access on the account. The token is fetched from the local metadata endpoint and rotated automatically by Azure.

Combine prevention and recovery. Use private endpoints, disable shared keys and public access, and restrict RBAC with PIM. Enable soft delete, versioning, change feed and point-in-time restore. For critical data, use immutable storage policies or vaulted Azure Backup with immutability and multi-user authorization so attackers cannot delete backups. Turn on Defender for Storage to detect malware uploads and unusual access.

Calculate transfer time first: 200 TB over a 1 Gbps link at 70% efficiency takes almost a month. Use Azure Data Box devices shipped to your site, copy data locally and send them back for upload into the storage account. Then run AzCopy or Azure File Sync to sync the changes made after shipping. For ongoing large flows, consider ExpressRoute.

Use a storage account in Central India with ZRS, or GZRS paired with South India which keeps data inside India. Apply time-based immutability for seven years on the archive container and lifecycle rules to move older files to Cool and Archive tiers. Encrypt with customer-managed keys in Key Vault if compliance asks, use private endpoints, and log access to Log Analytics for audits.

Confirm the app has regional VNet integration into a subnet that can reach the private endpoint subnet. Check DNS first: from the Kudu console, nslookup the SQL server name; it must resolve to the private IP through privatelink.database.windows.net linked to the VNet. Then check NSGs, UDRs sending traffic to a firewall that blocks port 1433, and whether SQL public access is disabled as expected.

Propose ExpressRoute through a provider at the Pune or Mumbai peering location with private peering into a hub VNet in Central India, sized for current and forecast bandwidth. Add a site-to-site VPN as a failover path, or a second ExpressRoute circuit at another peering location for higher resilience. Use BGP for route exchange, and encrypt traffic with MACsec or IPsec if compliance requires.

Put Azure Front Door Premium or Application Gateway with WAF in front of the app, using the managed Default Rule Set based on OWASP plus bot protection and rate limits. Enable Azure DDoS Network Protection on the VNet for layer 3 and 4 attacks on public IPs. Lock the app so it accepts traffic only from Front Door, using access restrictions with the service tag and the Front Door ID header.

Peering is not transitive, so spoke to spoke traffic needs a route through the hub. Check that both spokes have UDRs pointing the other spoke's range to the hub firewall, that peerings allow forwarded traffic, and that firewall network rules allow the flow. Then check NSGs on both subnets and NICs and the guest OS firewall. Use Network Watcher next hop and IP flow verify to confirm.

Configure the cluster's outbound type as a managed or user-assigned NAT Gateway with a static public IP, or route egress through Azure Firewall using userDefinedRouting so all traffic leaves from the firewall's public IP. Share that IP with partners. NAT Gateway is simpler and gives many SNAT ports, while Azure Firewall adds FQDN filtering and logging for compliance.

Treat it as compromised. Immediately delete the secret on the app registration and create a new one only if needed, then update the pipeline. Check Entra sign-in logs for service principal sign-ins and the activity log for changes made with it, and remove anything suspicious. Purge it from Git history. Long term, move pipelines to workload identity federation so no secret exists to leak.

Invite the auditor as a B2B guest user in Entra ID, add them to a group, and assign the Reader role, plus Security Reader if they review Defender findings, at the required scope through PIM with a two-week expiry. Require MFA through Conditional Access for guests. Avoid sharing accounts. After the audit, an access review or expiry removes access automatically, with all activity logged.

Sort recommendations by the score increase and effort. Typical quick wins are enabling MFA for all privileged accounts, restricting management ports with just-in-time access, enabling endpoint protection and vulnerability assessment on VMs, and turning on diagnostic logs. Use Azure Policy to enforce fixes so new resources stay compliant. Assign owners and due dates through governance rules and track progress weekly.

Use Entra ID groups mapped to roles per team and environment, with no direct user assignments. Make production access eligible-only through PIM with approval and MFA, and require phishing-resistant MFA and compliant devices via Conditional Access. Use managed identities and workload federation for apps and pipelines. Keep break-glass accounts excluded from policies but monitored. Run quarterly access reviews and stream logs to Sentinel.

Use Entra ID integration with Kubernetes RBAC and disable local accounts. Make the API server private or restrict authorized IP ranges. Run workloads with Workload ID instead of secrets, keep secrets in Key Vault through the CSI driver, and apply Azure Policy for Kubernetes to block privileged pods. Enable Defender for Containers, use network policies, scan images in ACR and route egress through Azure Firewall.

Azure SQL Database is a fully managed single database or elastic pool, best for new cloud apps. SQL Managed Instance offers near 100% SQL Server compatibility including SQL Agent, cross-database queries and CLR, in a VNet, ideal for lift-and-shift. SQL Server on a VM gives full OS and instance control for unsupported features but you handle patching, HA and backups yourself, although the SQL IaaS extension helps.

An elastic pool shares a set of resources, in eDTUs or vCores, among many Azure SQL databases on one logical server. It suits SaaS apps with a database per tenant, where individual usage peaks at different times. Instead of sizing each database for its peak, you size the pool for combined usage and set per-database min and max limits. Too many busy databases at once will contend for resources.

429 means requests exceeded provisioned RU/s. Check Insights for normalized RU consumption per partition. If one partition is hot, the partition key is the problem. If usage is even, enable autoscale or raise RU/s. Reduce RU cost by using point reads instead of queries, excluding unused paths from indexing and smaller documents. SDKs retry 429s automatically, so tune retry options too.

Use Azure SQL Database Business Critical or General Purpose with zone redundancy in Central India, plus a failover group to South India. Geo-replication is asynchronous with typical lag under a few seconds, meeting the RPO. Point the app to the failover group listener, deploy the app tier in both regions behind Front Door, and test failover drills quarterly. Document RTO for the automatic policy grace period.

Stop further writes if possible and note the exact time of the mistake. Use point-in-time restore to create a new copy of the database from a minute before the delete. Then copy the missing rows back into production with INSERT SELECT across databases or a data export, rather than replacing the whole database, which would lose later legitimate changes. Afterwards restrict direct write access in production.

Use Azure SQL for orders, payments and inventory, which need joins, transactions and strong consistency. Use Cosmos DB for high-volume, flexible-schema data such as product catalogue, shopping carts, user activity or session data needing global low latency. Many systems combine both. If the team knows SQL well and scale is moderate, starting with Azure SQL alone is simpler and cheaper.

Move them to serverless General Purpose with auto-pause, or into an elastic pool if they are always on but lightly used. Use Azure Hybrid Benefit if you own SQL licences, use the Azure Dev/Test pricing offer for non-production subscriptions, delete databases nobody has connected to in months, and use smaller backup retention and LRS backup storage for non-production.

Bicep is Azure-only, needs no state file, supports new resource features immediately and has native what-if previews. Terraform works across many clouds and SaaS providers, has a huge module ecosystem, and keeps a state file that must be stored securely, for example in a Blob Storage backend with locking. Choose Bicep for Azure-only teams and Terraform for multi-cloud or existing Terraform skills.

Detect drift by running Bicep what-if or terraform plan on a schedule and failing the run on unexpected differences, and by alerting on activity log write events from users rather than pipeline identities. Decide whether the manual change was a valid hotfix; if so, add it to code, otherwise redeploy to restore. Then reduce write access in production to the pipeline identity plus PIM break-glass.

Keep non-secret settings in parameter files or Azure App Configuration per environment. Keep secrets in Key Vault per environment and let apps read them via managed identity or Key Vault references, so pipelines rarely handle them. When pipelines need secrets, link variable groups to Key Vault and use environment approvals. Never echo secrets in logs and prefer federated identities over stored credentials.

Make deployments idempotent so rerunning the same template converges to the right state. Use slot swaps or blue-green so the old version keeps serving until the new one passes health checks, and roll back by swapping back. Keep database migrations backward compatible, using expand and contract, so the old code still works. Add smoke tests and automatic rollback, and alert the team with logs.

Separate a platform repo for landing zone, networking and policies from shared versioned modules published to a Bicep registry in ACR or a Terraform module registry. App teams consume modules in their own repos with pinned versions. Use pull request checks: linting, what-if or plan, policy tests and security scanning with tools like Checkov or PSRule. Document module contracts and use semantic versioning for breaking changes.

Profile which stages are slow. Cache dependencies like NuGet or npm packages, run unit tests and linting in parallel jobs, and split slow integration tests to run only on main or nightly. Use self-hosted or Managed DevOps Pools agents with warm caches for big builds, build container images with layer caching, and deploy only changed services in a monorepo using path filters.

Enable Container Insights and Managed Prometheus with Managed Grafana for cluster and pod metrics. Instrument services with OpenTelemetry sending to Application Insights for distributed tracing. Send logs to a central Log Analytics workspace using cheaper table plans for verbose logs. Define SLOs for latency and error rate, alert on them through action groups and build dashboards and runbooks for common failures.

Run the usage query on the Usage table to see which tables and resources ingest most. Remove debug or duplicate logs at the source, use data collection rules with transformations to drop columns or filter rows, and move verbose tables to Basic or Auxiliary plans. Set a daily cap for non-production workspaces, shorten interactive retention and use commitment tiers if ingestion is steady above 100 GB per day.

Agree RPO and RTO with the business. Replicate VMs to South India with Azure Site Recovery, configure recovery plans that start the database first, then app and web tiers, and pre-create the network. Use Traffic Manager or Front Door for DNS failover. Back up data separately with Azure Backup in case of corruption. Run test failovers into an isolated VNet every quarter.

Make tags like costcenter and team mandatory through Azure Policy with deny for new resources and modify to inherit from resource groups. Prefer separate subscriptions per team where possible, since subscription boundaries are the cleanest cost split. Use Cost Management views and scheduled exports grouped by tag and subscription into Power BI. Share untaggable costs like shared networking with an agreed split.

Check whether alerts measured the right signal: CPU alerts miss application errors. Add alerts on user-facing SLIs, such as failed request rate, p95 latency and availability tests from multiple locations in Application Insights. Make sure the action group has correct recipients and that alert processing rules are not suppressing it. Review the incident timeline and add the missing signals to the on-call runbook.

Organise subscriptions under management groups and assign initiatives at the top: allowed regions, required tags, diagnostics, no public IPs in corp zones, Defender plans on. Use deny for critical rules and audit for the rest, with exemptions tracked. Deploy policy as code from a repo. Report compliance and secure score monthly, and use Resource Graph for inventory and cost dashboards across all subscriptions.