AZ-305: Designing Microsoft Azure Infrastructure Solutions

Single Sign-On (SSO) lets users access multiple applications by signing in once with a single set of credentials. This removes the need to remember and manage multiple passwords, and it reduces the administrative work of managing user access across different applications. SSO works especially well with SaaS applications like Microsoft 365 and Salesforce, where it creates a seamless integration and boosts user productivity.

Operational excellence in logging aims to minimize manual maintenance while maximizing system visibility. A core architecture strategy is deploying the fewest number of Log Analytics workspaces necessary to satisfy compliance and business requirements. This centralized approach simplifies access control and makes it easier to manage workspace resources using Infrastructure as Code (IaC) tools such as ARM, Bicep, or Terraform. To verify the health of the logging pipeline itself, operators use Log Analytics Workspace Insights to track ingestion rates and configure proactive alerts for any system degradation.

To design governance in Azure, you first map your organization's structure into a logical hierarchy. You analyze departments, projects, and environments (like production or development) to decide how they fit into management groups and subscriptions. Management groups act as containers above subscriptions, allowing you to apply policies and permissions across many subscriptions at once. Subscriptions are the fundamental units for billing and resource limits. Inside subscriptions, you use resource groups to isolate specific workloads and provide a scope for applying policies.

Azure SQL Database is a fully managed relational database service that runs in the cloud without you needing to manage servers or apply patches. It offers several deployment options that fit different application needs: a single database works well for independent applications that need predictable performance, while an elastic pool lets multiple databases share the same compute resources, which saves money when some databases sit idle while others handle heavy traffic. The hyperscale tier separates compute from storage, allowing databases to grow to 100 TB or more and to add read replicas quickly for heavy read workloads. The service maintains transactional consistency through ACID properties, meaning every transaction either completes fully or rolls back completely, so your data stays accurate. For high availability, Azure SQL Database spreads replicas across multiple availability zones and can replicate data to a paired region for disaster recovery; if the primary database fails, traffic automatically moves to a replica. Automated scaling adjusts resources based on demand, and built-in backups let you restore data to any point within your retention window.

Azure Cosmos DB is a globally distributed, multi-model database service built for handling semi-structured data such as JSON documents. It provides automatic indexing, rich query capabilities, and tunable performance, all while scaling across regions. The service is designed to meet requirements for throughput, latency, consistency, and query flexibility, making it a central choice for storing semi-structured data in Azure.

When you design a data integration solution on Azure, you choose among three primary services: Azure Data Factory (ADF) , Azure Synapse Analytics Pipelines, and Azure Logic Apps. Each service handles different data movement and transformation patterns—batch, streaming, and change-data-capture (CDC)—and each has distinct authentication methods, network connectivity options, throughput limits, and cost models. The decision depends on whether the workload is enterprise-scale ETL, tightly coupled analytics, or event-driven workflow automation.

Designing for high availability in Azure compute involves choosing between different levels of isolation. Availability Zones are physically separate datacenters within a single region, each with its own power and network. Availability Sets provide logical isolation by spreading virtual machines (VMs) across different hardware racks within a single datacenter. Use Availability Zones to protect against a full datacenter outage, and use Availability Sets to guard against a single rack failure.

When planning recovery for SQL Server databases in Azure, several built-in technologies help keep data available during failures. Failover clustering automatically switches operations to a backup server when hardware or software fails, while Always On availability groups maintain multiple synchronized copies of a database across different servers. Database mirroring provides high-performance asynchronous replication, and log shipping periodically moves transaction logs to a secondary system for recovery. For geographic protection, active geo-replication copies databases across regions asynchronously, enabling near real-time failover when a whole data center experiences an outage. Auto-failover groups simplify the failover process by automating the switch between primary and secondary databases, reducing manual steps during an emergency.

Decoupling application workloads requires matching specific messaging patterns to the appropriate Azure service. For high-volume telemetry, Azure Event Hubs serves as the primary engine for real-time streaming pipelines. When an architecture demands reliable enterprise messaging with ordered transactional delivery, Azure Service Bus provides the necessary integration. Azure Event Grid manages publish-subscribe event distribution with low-latency notifications, while Azure Storage Queues offers a cost-effective buffering solution for simple queue-based decoupling.

The Microsoft Cloud Adoption Framework (CAF) provides five core migration patterns to move workloads to Azure, each matching different business and technical needs. These patterns are rehost (lift-and-shift), refactor (optimize), rearchitect (rebuild), replace (repurchase), and retire (decommission). Choosing the correct pattern requires evaluating the workload's specific dependencies, its required performance and uptime (SLAs), and any legal or security compliance constraints.

When designing a compute solution, you first evaluate the available offerings against your workload’s performance, scalability, and cost needs. Azure Virtual Machines (VMs) give you the most control over the operating system and fit applications that require specific configurations or continuous runtime. VM families include general purpose (balanced CPU-to-memory ratio, like the Dv2-Dsv2 series), compute optimized (high CPU-to-memory ratio for intensive applications, like the FSv2 series), and GPU VMs (for enhanced graphic processing, including NC, NCv2, NCv3 series). For workloads that need rapid scaling without managing individual VMs, VM Scale Sets automatically add or remove instances based on a signal such as average CPU, moving each VM through a predictable lifecycle from provisioning to running to terminating.

When Azure resources need to send traffic to the internet, they have two main paths. Azure NAT Gateway acts as a managed service that gives each virtual machine its own public IP for outbound connections, providing up to 64,512 SNAT ports per public IP and supporting up to 16 IPs total, which makes it perfect for workloads that need to make many outbound connections at once. Azure Firewall can also handle outbound traffic through source NAT, but it offers only 2,496 SNAT ports per IP, which limits how many simultaneous outbound connections it can support. Both services work well in a hub-and-spoke network design where all outbound traffic flows through a central hub, making it easier to manage and monitor what is leaving the network.