Azure for an AWS-shaped brain

You will not be asked to be an Azure expert in a Python backend interview. You will be asked “we’re on Azure, is that a problem?” — and the answer is a confident mapping plus the two or three places the mental model actually differs.

Service mapping

Where the model genuinely differs

Resource groups. Every resource lives in exactly one resource group — a lifecycle boundary you can delete as a unit. AWS has no direct equivalent; tags plus CloudFormation stacks are the closest thing. This makes per-environment teardown cleaner than in AWS.

Entra ID is the identity plane for everything, not just cloud resources — the same directory backs Microsoft 365. So “SSO” in an Azure shop usually means Entra ID, and app registrations / service principals are the OAuth clients. Managed Identity is the Azure answer to an EC2 instance profile: the platform injects a credential, your code never holds a secret.

# The idiomatic Azure auth pattern - works locally (az login) and in
# production (managed identity) with no code change.
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
)

DefaultAzureCredential walks a chain (environment vars, managed identity, Azure CLI, …). It’s the single most useful thing to know about Azure SDKs.

Cosmos DB is not DynamoDB. It offers five tunable consistency levels (strong, bounded staleness, session, consistent prefix, eventual) rather than DynamoDB’s two read modes, and it bills in Request Units (RU/s) — a normalized cost unit across reads, writes and queries. Under-provisioning RUs gets you throttled (429) with a x-ms-retry-after-ms header; the SDK retries, but a badly-partitioned container will still hot-spot.

Subscriptions and management groups are the billing/isolation hierarchy, roughly where AWS accounts and Organizations sit.

The AI angle

For an AI-focused role this is the part that matters. Azure OpenAI Service gives you OpenAI models inside your Azure tenant, with your network boundary, your Entra identity and your data-residency guarantees — which is the entire reason regulated enterprises pick it. Microsoft Foundry (renamed from Azure AI Studio, and marketed as plain “Foundry” by 2026) is the surrounding platform: model catalog, agent tooling, evaluation, and deployment.

The interview-relevant contrast: Bedrock leads on breadth of model catalog, Foundry leads on OpenAI-model access plus deep Microsoft-estate integration, Vertex leads on Gemini plus Google’s data stack. As of 2026 all three also host Claude.

Interview angle

• “We’re on Azure — how quickly could you be productive?” — lead with the mapping above, then name the three real differences: resource groups as a lifecycle unit, Entra ID + managed identity instead of IAM roles, and RU-based billing in Cosmos DB. That’s a better answer than claiming Azure experience you don’t have.
• “How does a Python app on Azure authenticate to a database or storage account?” — DefaultAzureCredential with a managed identity. Same code path locally via az login. No connection string with an embedded key.
• “Cosmos DB vs DynamoDB?” — Cosmos has five consistency levels and multi-model APIs (SQL, Mongo, Cassandra, Gremlin); DynamoDB has a simpler model and two read consistencies. Cosmos bills RU/s; DynamoDB bills RCU/WCU or on-demand. Both punish a poor partition key the same way.
• “Why would a company pick Azure OpenAI over the OpenAI API directly?” — data residency, private networking, Entra-based access control, enterprise agreements and compliance coverage. Rarely about the model itself.