Identity and Access Architecture
Identity architecture at AZ-305 level means designing for the enterprise, not just a single application. Hybrid identity: Azure AD Connect synchronises on-premises Active Directory to Entra ID — synchronisation modes (Password Hash Sync recommended for simplicity and phishing-resistant MFA, Pass-through Authentication for on-prem validation without hash sync, ADFS for full on-prem control with higher complexity). Azure AD DS (Domain Services): managed domain services (LDAP, Kerberos, NTLM) without running DCs — lift legacy apps to Azure without re-architecting. B2C (Business-to-Consumer): customer identity management — support social logins (Google, Facebook, Apple), custom user journeys, branded login pages. External Identities / B2B: invite partner users as guests — they authenticate with their own identity provider. Design principle: one Entra ID tenant per organisation, external collaboration via B2B guests, not separate tenants. Landing Zone architecture: subscription design (by environment: prod/dev/test, or by business unit), Management Group hierarchy, Azure Policy assignments at MG level for governance at scale.
Business Continuity and Disaster Recovery Design
AZ-305 BC/DR design requires selecting the right Azure services for each RTO/RPO combination. VM BC/DR: Azure Site Recovery (ASR) replicates VMs to a secondary region — RPO in minutes, RTO in hours. ASR recovery plans automate failover sequencing with custom scripts. Database BC/DR: Azure SQL Database active geo-replication (up to four readable secondaries in different regions, manual failover), auto-failover groups (automatic failover with a listener endpoint that updates DNS — application does not need to know the new endpoint). Cosmos DB: 99.999% SLA with multi-region writes — automatic failover, no data loss. Blob Storage: GRS (Geo-Redundant Storage — Microsoft manages failover), GZRS (Geo-Zone-Redundant — zone-redundant in primary, geo-replicated to secondary), RA-GRS (read access to secondary region always, failover manual or Microsoft-managed). AZ-305 asks you to choose the right BC/DR approach given RTO, RPO, and cost constraints — there is always a trade-off.
Data Architecture: SQL, NoSQL, and Analytics
Data architecture decisions for AZ-305: relational vs non-relational (structured transactional data with complex queries and strong consistency = SQL; high-volume, flexible schema, horizontal scale = NoSQL), Azure SQL vs SQL Managed Instance (SQL Database is fully managed with some limitations; SQL MI is near 100% SQL Server compatible — lift-and-shift for complex on-prem SQL workloads), Azure Cosmos DB API choice (NoSQL API for JSON documents, MongoDB API for MongoDB compatibility, Apache Cassandra API for wide-column data, Gremlin API for graph data, Table API for Azure Table Storage migration). Synapse Analytics: unified analytics platform — Dedicated SQL Pools (former SQL DW, provisioned Massively Parallel Processing for predictable high performance), Serverless SQL Pool (ad-hoc queries over data lake files — pay per query), Apache Spark pools (data engineering and ML). Data Lake Storage Gen2: ADLS Gen2 combines object storage (Blob) with hierarchical namespace and POSIX ACLs — prerequisite for Synapse Analytics integration.
Application Architecture Patterns
AZ-305 application architecture goes beyond 'use App Service' to 'which service, which tier, why'. Compute decision framework: VM (full control, legacy apps, custom OS), App Service (managed PaaS for web apps — scale in/out, deployment slots, built-in auth), Container Apps (serverless containers with Kubernetes-based orchestration, KEDA event-driven scaling), AKS (managed Kubernetes for complex microservices needing full control), Functions (event-driven serverless — consumption plan scales to zero, Premium plan for VNet integration and pre-warmed instances). Microservices patterns: API Gateway pattern (Azure API Management as the single entry point — versioning, rate limiting, auth, transformation), Event-Driven (Event Grid for discrete events, Service Bus for complex message routing with dead-lettering, Event Hubs for high-throughput streaming data ingestion). CQRS (Command Query Responsibility Segregation): separate read and write models — reads from a materialised read-optimised view (Cosmos DB or Redis cache), writes to a transaction-optimised store (SQL). Cache-aside pattern: check cache first, load from database on miss, write to cache for future reads — Azure Cache for Redis.
Network Architecture and Security Design
Network architecture for AZ-305 requires Hub-Spoke topology design. Hub VNet: shared services (Azure Firewall, VPN Gateway, ExpressRoute Gateway, DNS resolver, Bastion). Spoke VNets: workload-specific VNets peered to hub — only have direct internet access through the hub firewall. Azure Virtual WAN: Microsoft-managed hub-and-spoke at scale — automated peering, routing, and SD-WAN integration for branch offices. Service Endpoints: enable Azure PaaS services to be accessible from VNet without public IP traversal — traffic stays on Azure backbone. Private Endpoints: gives a PaaS service a private IP in your VNet — DNS resolves to private IP, no public internet exposure. Private Link: the technology behind Private Endpoints — also used to expose your own services privately across VNet boundaries. ExpressRoute circuits: dedicated private connectivity from on-premises to Azure — Global Reach connects ExpressRoute circuits in different locations without traffic touching the public internet.