Intermediate Questions
Infrastructure management, deployment strategies, and delivery flows.
How does Azure Service Bus differ from Azure Event Grid?
Azure Service Bus is a message broker for point-to-point or pub/sub messaging with guaranteed delivery, FIFO ordering, transactions, and dead-letter queues ideal for enterprise messaging. Azure Event Grid is an event routing service for reactive programming with high-throughput delivery.
What are Azure Managed Identities?
Azure Managed Identities provide Azure resources with automatically managed identity in Azure AD for authenticating without storing credentials.
Real Production Scenarios
Real-world architecture, system migration, and design challenges.
What is Azure Resource Manager (ARM) and how does it differ from classic deployment?
Azure Resource Manager (ARM) is the deployment and management service for Azure, introduced to replace the classic (ASM) model. ARM uses a declarative JSON template approach, supports resource groups for logical grouping, provides role-based access control (RBAC) at the resource level, enables parallel deployment of resources, and supports tagging and dependency management. Classic deployment used separate APIs per service with no unified management layer. ARM templates are idempotent — re-running them produces the same state, making them ideal for Infrastructure as Code workflows.
What are the different Azure storage services and when should you use each?
Azure provides multiple storage services optimized for different data types and access patterns.
Azure Blob Storage: Object storage for unstructured data like images, videos, backups, and logs. Three access tiers: Hot (frequent access), Cool (infrequent, 30-day minimum), and Archive (rare access, 180-day minimum). Supports lifecycle management to auto-tier data. Equivalent to Amazon S3 or GCS.
Azure File Storage: Fully managed file shares via SMB and NFS protocols. Can be mounted on Windows, Linux, and macOS. Use for lifting on-premises file servers, shared config files, or Azure Files Sync for hybrid scenarios.
Azure Table Storage: NoSQL key-value store for semi-structured data. Serverless, auto-scaling. Good for large amounts of structured non-relational data at lower cost than Cosmos DB.
Azure Queue Storage: Message queue service for decoupling components. Messages up to 64KB. Use for async task processing and reliable messaging between services.
Azure Disk Storage: Persistent block storage for Azure VMs. Options include Premium SSD, Standard SSD, Standard HDD, and Ultra Disk. Managed disks are recommended as Azure handles availability and replication.
Azure Data Lake Storage Gen2: Hierarchical filesystem built on Blob Storage, optimized for analytics with Hadoop-compatible access. Used with Azure Databricks, HDInsight, and Synapse Analytics.
What is Azure DevOps and how does it support CI/CD pipelines?
Azure DevOps is a suite of developer services for planning, developing, testing, and delivering software. It provides integrated DevOps toolchain capabilities for Azure and third-party platforms.
Azure DevOps Services
Azure Boards: Agile project management with Kanban boards, backlogs, sprints, and work item tracking supporting Scrum and CMMI methodologies.
Azure Repos: Git repositories with branch policies, pull request workflows, and code review. Supports both Git and TFVC.
Azure Pipelines: CI/CD platform that builds, tests, and deploys code to any language, platform, and cloud. Runs on Microsoft-hosted or self-hosted agents.
Azure Test Plans: Manual and automated test management.
Azure Artifacts: Package management supporting NuGet, npm, Maven, Python, and Universal Packages.
CI/CD with Azure Pipelines
Pipelines are defined in YAML (azure-pipelines.yml) and consist of triggers, stages, jobs, and steps.
A typical pipeline structure:
- trigger: branches to watch (e.g., main)
- pool: agent image (ubuntu-latest, windows-latest)
- stages: Build stage builds and pushes Docker image; Deploy stage deploys to AKS using kubectl or Helm
Key Features
Environments with deployment gates and approval workflows protect production. Variable groups and Azure Key Vault integration manage secrets securely. Service connections connect to Azure, AWS, GCP, and other external services. Matrix builds enable parallel testing across multiple OS/runtime combinations. Integration with GitHub, Jira, Slack, and Microsoft Teams for notifications and collaboration.
What is Azure Active Directory (Azure AD) and how does it differ from on-premises Active Directory?
Azure Active Directory (Azure AD, now rebranded as Microsoft Entra ID) is Microsoft’s cloud-based identity and access management service. It handles authentication and authorization for Azure resources, Microsoft 365, and thousands of third-party SaaS applications.
Azure AD vs On-Premises Active Directory
On-premises AD DS uses Kerberos and NTLM protocols, is structured around OUs, domains, and forests, and uses LDAP for querying and Group Policy for management. It is designed for traditional Windows environments.
Azure AD uses OAuth2, OpenID Connect, and SAML. There are no OUs, forests, or Kerberos by default. It provides SSO across cloud apps and supports modern identity scenarios like MFA, Conditional Access, and Identity Protection.
Key Azure AD Concepts
Tenants: An isolated instance of Azure AD representing an organization. Each Azure subscription is associated with one tenant.
App Registrations: Applications register with Azure AD to get credentials for OAuth2 authentication flows.
Service Principals: Identities for applications and automation to authenticate with Azure resources.
Managed Identities: Azure-managed identities for Azure resources like VMs, App Service, and AKS that eliminate the need for storing credentials in code. System-assigned identities follow resource lifecycle; user-assigned identities have independent lifecycle.
Conditional Access: Policy-based access controls evaluating sign-in risk, device compliance, location, and other signals to grant or block access.
Azure AD Connect: Synchronizes on-premises AD DS identities to Azure AD for hybrid identity scenarios.
What is Azure Kubernetes Service (AKS) and how do you deploy and manage a cluster?
Azure Kubernetes Service (AKS) is a managed Kubernetes service that simplifies deploying, managing, and scaling containerized applications on Azure. Microsoft manages the control plane (API server, etcd, scheduler) while you manage the worker nodes.
Key AKS Concepts
Node Pools: Groups of VMs with the same configuration. AKS supports system node pools for system pods like CoreDNS and user node pools for application workloads. Multiple node pools can have different VM sizes and scaling settings.
Virtual Nodes: AKS integrates with Azure Container Instances via virtual nodes, enabling burst scaling to serverless containers without managing additional VMs.
Networking: AKS supports Kubenet (simple, assigns IPs from separate address space) and Azure CNI (assigns IPs directly from VNet for better performance and Azure service integration).
Deploying an AKS Cluster
az aks create –resource-group myRG –name myAKS –node-count 3 –enable-addons monitoring –generate-ssh-keys
az aks get-credentials –resource-group myRG –name myAKS
kubectl get nodes
Key AKS Features
Managed control plane with automatic upgrades and patching. Azure AD integration for RBAC authentication. Azure Monitor and Container Insights for observability. Azure Policy for compliance. Cluster autoscaler for automatic node scaling. Azure Disk and Azure Files for persistent volumes. Private cluster option restricts API server access to VNet. Integration with Azure DevOps and GitHub Actions for CI/CD pipelines.
What is Azure Resource Manager (ARM) and how does it differ from the classic deployment model?
Azure Resource Manager (ARM) is the deployment and management service for Azure. It provides a consistent management layer that enables you to create, update, and delete resources in your Azure subscription using infrastructure as code.
ARM vs Classic Deployment Model
The Classic deployment model (also called Azure Service Manager or ASM) was the original Azure deployment system. It treated resources individually and lacked the ability to manage them as a group. ARM replaced it with a resource-group-based approach.
Key differences: In ARM, resources are organized into Resource Groups – logical containers for resources that share the same lifecycle. Classic had no resource grouping. ARM enables declarative templates (ARM templates or Bicep) to define infrastructure. Classic required scripting each resource individually. ARM supports role-based access control (RBAC) at the resource, resource group, or subscription level. Classic had limited access controls. ARM tracks dependencies between resources and deploys them in the correct order. ARM supports tags on resources for cost tracking and organization.
ARM Templates
ARM templates are JSON files that define the infrastructure and configuration for your project. They follow an idempotent deployment model where you define the desired state and ARM ensures the environment matches. Bicep is a domain-specific language (DSL) that compiles to ARM templates and provides cleaner syntax.
Resource Groups
A resource group is a logical container where Azure resources are deployed and managed. All resources in a group share the same lifecycle – you can deploy, update, or delete them together. Resources in the same group can be in different regions. Resource groups enable cost management and access control at a group level.