Back to Azure Solutions Architect Expert (AZ-305)

Design infrastructure solutions

Design compute, application architecture, migrations, and network solutions.

Encompasses designing compute solutions (VMs, containers, serverless, batch), application architecture (messaging, events, APIs, caching, deployment), migrations (Cloud Adoption Framework, IaaS/PaaS, databases), and network solutions (connectivity, security, load balancing).
5 minutes 5 Questions

Design infrastructure solutions is a critical domain for Azure Solutions Architect Expert certification that focuses on creating robust, scalable, and secure cloud architectures on Microsoft Azure. This competency encompasses several key areas that architects must master. First, architects must un…

Concepts covered: Specify components of a compute solution based on workload requirements, Recommend a virtual machine-based solution, Recommend a container-based solution, Recommend a serverless-based solution, Recommend a compute solution for batch processing, Recommend a messaging architecture, Recommend an event-driven architecture, Recommend a solution for API integration, Recommend a caching solution for applications, Recommend an application configuration management solution, Recommend an automated deployment solution for applications, Evaluate a migration solution that leverages the Microsoft Cloud Adoption Framework for Azure, Evaluate on-premises servers, data, and applications for migration, Recommend a solution for migrating workloads to IaaS and PaaS, Recommend a solution for migrating databases, Recommend a solution for migrating unstructured data, Recommend a connectivity solution that connects Azure resources to the internet, Recommend a connectivity solution that connects Azure resources to on-premises networks, Recommend a solution to optimize network performance, Recommend a solution to optimize network security, Recommend a load-balancing and routing solution

Test mode:
Start practice test
AZ-305 - Design infrastructure solutions Example Questions

Test your knowledge of Design infrastructure solutions

Question 1

An insurance claims processing company is deploying a new fraud investigation platform on Azure that analyzes suspicious claims using containerized microservices. The platform consists of seven services: claims intake API, document scanning service, data enrichment service, ML-based fraud detection engine, case management service, evidence archival service, and reporting dashboard. The claims intake API receives 2,000-8,000 requests daily with unpredictable submission patterns. The document scanning service must process PDF and image files stored in Azure Blob Storage, with each scan taking 5-15 minutes and requiring 2 vCPUs with 8GB RAM. The data enrichment service calls external third-party APIs to validate claimant information and needs consistent outbound IP addresses for API provider whitelisting. The fraud detection engine runs TensorFlow models requiring GPU acceleration (NVIDIA T4 GPUs) and must scale from 2 to 12 instances based on the depth of the Azure Storage Queue containing pending analysis jobs. The case management service maintains long-running WebSocket connections for investigator dashboards and requires session persistence. The evidence archival service runs scheduled jobs every 6 hours to compress and transfer completed case files to cold storage. The company requires granular network segmentation between services using subnet-level isolation and custom NSG rules to meet SOC 2 Type II compliance. The operations team needs the ability to deploy specific services to dedicated node pools with different VM SKUs (CPU-optimized for APIs, GPU-enabled for ML, memory-optimized for case management). The platform must support Azure Policy integration for enforcing resource tags and deployment guardrails. The development team uses CI/CD pipelines with Helm charts and requires support for Init Containers to perform database schema migrations before service startup. The company wants managed control plane operations, automated Kubernetes version upgrades, and integration with Azure Monitor Container Insights for performance monitoring. Which Azure container platform should the solutions architect recommend for this fraud investigation system?

Correct Answer: Azure Kubernetes Service with multiple node pools configured for different workload types, Azure CNI networking for subnet-level isolation, KEDA for queue-based autoscaling of the fraud detection engine, and GPU-enabled node pools for TensorFlow model inference

The correct solution is Azure Kubernetes Service (AKS) with multiple node pools configured for different workload types, Azure CNI networking for subnet-level isolation, KEDA for queue-based autoscaling of the fraud detection engine, and GPU-enabled node pools for TensorFlow model inference.

This is the optimal choice because:

Multiple Node Pools: The requirement explicitly states the operations team needs the ability to deploy specific services to dedicated node pools with different VM SKUs (CPU-optimized for APIs, GPU-enabled for ML, memory-optimized for case management). AKS supports multiple node pools with heterogeneous VM types, allowing precise workload placement.

Azure CNI Networking: The company requires granular network segmentation between services using subnet-level isolation and custom NSG rules for SOC 2 Type II compliance. Azure CNI assigns IP addresses from the virtual network subnet directly to pods, enabling subnet-level isolation and NSG rule application - critical for compliance requirements.

KEDA Integration: The fraud detection engine must scale from 2 to 12 instances based on Azure Storage Queue depth. KEDA (Kubernetes Event-Driven Autoscaling) natively integrates with AKS and provides queue-based autoscaling triggers, perfectly matching this requirement.

GPU Node Pools: The fraud detection engine requires NVIDIA T4 GPUs for TensorFlow models. AKS supports GPU-enabled node pools with NC-series VMs that provide T4 GPUs, enabling ML workload acceleration.

Additional Requirements Met:
- Managed control plane with automated Kubernetes version upgrades
- Azure Policy integration for enforcing resource tags and deployment guardrails
- Helm chart support for CI/CD pipelines
- Init Containers support for database schema migrations
- Azure Monitor Container Insights integration
- Session affinity for WebSocket connections in case management service
- CronJob support for scheduled evidence archival tasks

Why Other Options Are Insufficient:

The Azure Container Apps solution lacks the granular network segmentation capabilities required for SOC 2 Type II compliance. Container Apps cannot provide subnet-level isolation with custom NSG rules per service, and doesn't support multiple dedicated node pools with different VM SKUs. GPU acceleration for TensorFlow workloads is not natively supported in Container Apps.

The Azure Container Instances approach is fundamentally inadequate for this complex microservices architecture. ACI doesn't provide orchestration capabilities needed for managing seven interconnected services, lacks native support for Helm charts and CI/CD pipelines, cannot maintain long-running WebSocket connections reliably, doesn't offer GPU acceleration, and lacks the sophisticated networking features required for compliance. Queue-based autoscaling through Azure Functions is an anti-pattern compared to proper Kubernetes-native scaling.

The AKS with virtual nodes solution introduces unnecessary complexity and limitations. Virtual nodes (Azure Container Instances under the hood) don't support GPU workloads, which are critical for the fraud detection engine. Virtual nodes also don't provide the same level of network control and NSG integration as standard node pools. While Application Gateway provides ingress capabilities, this solution doesn't explicitly address the multiple heterogeneous node pools requirement or the queue-based autoscaling pattern needed for the ML workload.

The first solution provides the complete, enterprise-grade container orchestration platform with all the specific capabilities required: heterogeneous compute resources, advanced networking, event-driven scaling, GPU acceleration, and full Azure integration for compliance and monitoring.

Question 2

A digital publishing company operates a content delivery platform on Azure that serves 12 million readers across 35 countries with personalized article recommendations. The application uses Azure SQL Database to store author profiles, article metadata, content categories, and editorial guidelines totaling 450GB. The recommendation engine runs on Azure Container Instances and generates personalized content feeds by querying reader preference data combined with editorial policy rules. Each recommendation request retrieves content filtering policies based on reader geographic location, subscription tier, and content maturity ratings by executing queries across 14 database tables that take 1,100-1,350ms to complete. The platform processes 480,000 recommendation requests hourly during morning reading peaks (6 AM - 10 AM across global time zones), with analytics revealing that 94% of requests involve identical filtering for 410 standard reader profile combinations (country-tier-rating permutations). Editorial policy rules are revised semi-annually during June and December editorial board meetings when content standards are reviewed, with mid-cycle policy adjustments occurring 7-9 times annually when regulatory requirements change in specific jurisdictions. Database performance metrics show that content filtering queries account for 76% of total database resource consumption during peak reading hours, creating resource contention with article publishing workflows that require transactional consistency for content versioning and audit trails. The editorial team accepts policy data reflecting changes within 60 days since content moderators verify current policies through the editorial management system before approving sensitive content. Reader experience standards mandate that personalized feeds must render within 320ms to prevent reader abandonment and maintain engagement metrics. The infrastructure team must achieve a 72% reduction in database resource utilization while supporting the globally distributed reader access patterns and ensuring cache consistency across container instance scale-out events. Which caching strategy should the Azure Solutions Architect implement for this content delivery platform?

Correct Answer: Deploy Azure Cache for Redis Premium tier with 26GB capacity configured for the cache-aside pattern, implementing a distributed caching layer that stores the 410 standard content filtering policy combinations as pre-computed objects with 60-day sliding expiration windows, using Redis hash data structures to organize policies by reader profile attributes and enabling cache warming through scheduled jobs that reload all policy combinations following the semi-annual editorial updates and mid-cycle regulatory adjustments

The optimal solution deploys Azure Cache for Redis Premium tier with 26GB capacity configured for the cache-aside pattern with 60-day sliding expiration windows.

This approach is correct because:

Cache-Aside Pattern Alignment: This pattern is ideal for read-heavy workloads where 94% of requests involve identical filtering for 410 standard reader profile combinations. The application checks the cache first, and only queries the database on cache misses, directly addressing the 76% database resource consumption problem.

Appropriate Capacity: 26GB Premium tier provides sufficient capacity for 410 pre-computed policy combinations plus overhead, with Premium tier offering necessary features like data persistence and higher throughput for 480,000 hourly requests.

60-Day Sliding Expiration: Aligns perfectly with the editorial team's acceptance of policy data reflecting changes within 60 days. Sliding expiration ensures frequently accessed policies remain cached while automatically refreshing on access, supporting the semi-annual updates and 7-9 mid-cycle adjustments.

Redis Hash Data Structures: Efficiently organize policies by reader profile attributes (country-tier-rating permutations), enabling fast lookups and optimal memory usage for the 410 combinations.

72% Resource Reduction Target: By caching 94% of identical queries, this solution can achieve the required 72% reduction in database resource utilization while maintaining transactional consistency for article publishing workflows.

320ms Rendering Requirement: Cache-aside with in-memory Redis can reduce query time from 1,100-1,350ms to sub-millisecond cache hits, easily meeting the 320ms feed rendering requirement.

Why other approaches fall short:

The write-behind pattern with cross-region synchronization adds unnecessary complexity for data that changes infrequently (semi-annually plus 7-9 times yearly). The 45-day absolute expiration doesn't align with the 60-day acceptance window, and eventual consistency introduces unnecessary risk for policy enforcement.

The read-through pattern with Basic tier (6GB) lacks sufficient capacity for global scale and doesn't leverage the opportunity to pre-compute the 410 standard combinations. Basic tier also lacks clustering capabilities and high availability features needed for 12 million readers across 35 countries. The 30-day TTL is too conservative given the 60-day acceptance window.

The refresh-ahead pattern with 53GB capacity and 90-day retention is over-engineered for this scenario. The capacity is excessive for 410 policy combinations, and proactive reloading before expiration wastes resources when policies change only 8-10 times yearly. Active geo-replication across four regions adds cost and complexity beyond requirements, and maintaining version histories for 90 days exceeds the stated 60-day acceptance window.

Question 3

A multinational pharmaceutical company operates a clinical trial data management platform that processes patient data from 150 hospitals across 8 countries. The architecture includes Azure Container Apps for data processing microservices (12 services), Azure API Management for hospital integrations, Azure Database for PostgreSQL Flexible Server for clinical data, and Azure Front Door for global traffic distribution. The engineering team uses GitLab with 7 repositories: microservices code, API policies, database migration scripts, infrastructure templates, monitoring configurations, security policies, and compliance documentation. Microservices deploy 6-8 times weekly, API policies update bi-weekly, database migrations execute monthly, and infrastructure changes occur quarterly. The regulatory team requires 21 CFR Part 11 and GDPR compliance with complete deployment lineage tracking retained for 25 years. Database schema migrations must execute in a maintenance window (Sunday 1 AM - 3 AM UTC) and complete before microservice deployments. The clinical operations team mandates that deployments affecting patient data processing must include validation gates checking data processing accuracy against 1,000 test cases (requiring 90 minutes) and referential integrity checks across 45 database tables. If validation fails, the deployment must pause and require approval from both the data quality manager and the clinical informatics lead before proceeding or rolling back. Each country operates isolated PostgreSQL instances, Container Apps environments, and API Management instances due to data sovereignty regulations. The platform must support deploying emergency security patches to individual countries during business hours while scheduled feature releases deploy globally during off-peak hours. The security team requires workload identity federation with Azure AD, Key Vault integration with customer-managed keys per country, and deployment audit logs forwarded to country-specific Log Analytics workspaces with 25-year retention. The solution must handle repository-specific schedules since infrastructure updates should not trigger microservice recompilation, and database migrations must occur before application deployments. Which automated deployment solution architecture should you design?

Correct Answer: Establish Azure Pipelines with multi-stage YAML templates for each repository, implementing stage dependencies to enforce database-first deployment sequencing with approval gates between migration and application stages. Configure scheduled triggers for database migrations (Sunday maintenance windows) and continuous triggers for microservices, using variable groups per country for environment configurations. Implement validation tasks using Azure CLI scripts that execute test case verification and database integrity checks, with manual intervention tasks requiring data quality manager and clinical informatics lead approval on validation failures. Create separate pipelines for each country-isolated deployment using service connections with workload identity federation and Key Vault variable groups scoped per country. Configure deployment jobs that retrieve secrets from country-specific Key Vaults and publish deployment metadata to country-specific Log Analytics workspaces. Use release gates with Azure Monitor queries to validate deployment health metrics before proceeding to subsequent countries, and implement artifact retention policies maintaining build artifacts and deployment logs for 25 years in archive storage tiers.

The correct solution uses Azure Pipelines with multi-stage YAML templates, which provides the comprehensive capabilities required for this complex regulatory environment.

Why this is the optimal solution:

Repository-Specific Deployment Orchestration: YAML pipelines support different trigger types per repository (scheduled for database migrations during Sunday maintenance windows, continuous for microservices). This prevents infrastructure changes from unnecessarily triggering microservice recompilation while maintaining proper deployment sequencing.

Deployment Sequencing with Stage Dependencies: Multi-stage YAML templates with stage dependencies enforce the critical requirement that database migrations complete before microservice deployments. This is essential for maintaining data integrity across the 45 database tables and ensuring schema changes are in place before application code that depends on them.

Validation Gates with Manual Intervention: The solution implements validation tasks that execute the 1,000 test cases (90-minute requirement) and referential integrity checks. Manual intervention tasks pause deployments on validation failures, requiring approval from both the data quality manager and clinical informatics lead before proceeding—exactly as specified.

Country-Specific Isolation: Separate pipelines per country with service connections using workload identity federation provide the required data sovereignty compliance. Variable groups scoped per country manage environment-specific configurations for isolated PostgreSQL instances, Container Apps environments, and API Management instances.

Security and Compliance Requirements: Workload identity federation with Azure AD eliminates credential management risks. Country-specific Key Vault variable groups support customer-managed keys per jurisdiction. Deployment metadata published to country-specific Log Analytics workspaces with artifact retention policies in archive storage tiers satisfies the 21 CFR Part 11 and GDPR requirements for 25-year deployment lineage tracking.

Flexibility for Emergency vs. Scheduled Deployments: Azure Pipelines supports both scheduled triggers for global feature releases during off-peak hours and manual/continuous triggers for emergency security patches to individual countries during business hours.

Why the other approaches fall short:

Classic Release Pipelines Approach: Classic editor pipelines are being deprecated by Microsoft and lack the infrastructure-as-code benefits of YAML pipelines. They require more manual configuration for multi-repository scenarios and don't provide the same level of version control for pipeline definitions. Managing 7 repositories with different schedules would be significantly more complex. The pre-deployment conditions are less flexible than YAML stage dependencies for enforcing database-first sequencing.

GitHub Actions Approach: While GitHub Actions is powerful, the organization uses GitLab (stated in the scenario). Migrating to GitHub would be disruptive and unnecessary. Even if migration were considered, GitHub Actions has limitations for complex approval workflows spanning multiple teams and doesn't integrate as natively with Azure-specific features like deployment history retention and compliance logging compared to Azure Pipelines. The workflow dispatch approach for maintenance windows is less robust than Azure Pipelines' scheduled triggers with time zone support.

Azure Deployment Stacks with Automation Runbooks: Deployment Stacks are infrastructure-focused and not designed for application deployment orchestration. Using PowerShell orchestration scripts and Automation runbooks adds significant custom code complexity for workflow logic that Azure Pipelines provides natively. This approach lacks built-in support for approval gates with specific approvers, test case validation integration, and deployment lineage tracking. The webhook-based triggering for on-demand deployments is less sophisticated than pipeline triggers. Managing deployment sequencing across 8 countries with 7 repositories through custom scripts would be error-prone and difficult to maintain. Sending approval requests through Logic Apps is an overly complex solution compared to native pipeline approval gates.

More Design infrastructure solutions questions
761 questions (total)
Start 100 question test