AZ-305: Designing Compute Solutions

Table of Contents

1. Module 1: Virtual Machines
   • 1.1 Designing Virtual Machine Solutions
   • 1.2 Planning a Virtual Machine Deployment
   • 1.3 Securing Virtual Machine Management Traffic
   • 1.4 Virtual Machine Availability
   • 1.5 Azure Hybrid Backup and Recovery
   • 1.6 Virtual Machine Backup and Recovery
   • 1.7 Case Study: Virtual Machines
2. Module 2: Containers
   • 2.1 Container Technologies in Azure
   • 2.2 Choosing Container Technologies
   • 2.3 Container Availability and Scaling
3. Module 3: Serverless Compute
   • 3.1 Serverless Technologies in Azure
   • 3.2 Choosing Serverless Technologies
4. Module 4: Batch Compute
   • 4.1 Batch Compute Technologies in Azure
   • 4.2 Choosing Batch Compute Technologies
   • 4.3 Case Study: Containers, Serverless, and Batch Compute
5. Module 5: Application Architecture
   • 5.1 Messaging Architecture within Applications
   • 5.2 Messaging Technologies in Azure
   • 5.3 Event-Driven Applications
   • 5.4 Choosing an Event Solution
   • 5.5 Exposing APIs
   • 5.6 Application Caching
6. Module 6: Application Deployment, Configuration, and Security
   • 6.1 Automated Application Deployment
   • 6.2 Application Configuration
   • 6.3 Securely Storing Secrets
   • 6.4 Case Study: Application Architecture
7. Module 7: Exam Tips and Architect Mindset
   • 7.1 Exam Tips by Topic Area
   • 7.2 The Azure Compute Solution Decision Flowchart
   • 7.3 On Being a Solutions Architect

Module 1: Virtual Machines

1.1 Designing Virtual Machine Solutions

When designing compute solutions, a good starting point is to ask: how do you decide what compute solution to use? Microsoft provides an Azure Compute Solutions Decision Flowchart to help answer that question. Each compute solution falls into one of three categories:

• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Functions as a Service (FaaS)

Virtual machines fall squarely in the IaaS category. When assessing whether a stakeholder should consider a virtual machine for their compute needs, four key characteristics need to be examined:

1. Is the stakeholder wanting to perform a lift-and-shift migration to the cloud?
2. Will the applications be optimized for cloud architecture before the migration?
3. Does the environment contain commercial-off-the-shelf (COTS) applications that require a specific environment?
4. Does the stakeholder require full control over the entire application environment?

If one or more of these characteristics are true, a virtual machine needs to be seriously considered. The clearest recommendation comes when a stakeholder explicitly states they need full control over the entire application environment.

flowchart TD
    A[Start: Choose Compute Solution] --> B{Lift-and-shift\nor full OS control?}
    B -->|Yes| C[Virtual Machines - IaaS]
    B -->|No| D{Containerized\nworkload?}
    D -->|Yes| E{Orchestration\nneeded?}
    E -->|Complex multi-container| F[AKS - PaaS]
    E -->|Simple/burst| G[ACI - PaaS]
    E -->|Serverless containers| H[ACA - PaaS]
    D -->|No| I{Event-driven\nor short-lived?}
    I -->|Yes| J{Need custom code?}
    J -->|Yes| K[Azure Functions - FaaS]
    J -->|No-code workflow| L[Azure Logic Apps - FaaS]
    I -->|Large-scale parallel| M[Azure Batch - PaaS/IaaS]

1.2 Planning a Virtual Machine Deployment

Planning a virtual machine deployment requires evaluating multiple parameters that are universal to virtually all situations.

VM Size and Type

The size of a virtual machine is a delicate balance of cost and capability. The VM needs to handle whatever applications or services run on it, but not be so over-provisioned that it goes mostly underutilized.

Considerations for VM size and type:

• Workloads: Will the machine run memory-intensive, CPU-intensive, or storage-intensive tasks? Is there a machine learning component? Azure provides VMs tailored to each workload type.
• Development stage: Is this a proof-of-concept/testing environment, a mainstream development environment, or a production environment?
• Supporting technology requirements: Some network and storage options have minimum VM requirements before they are available. Specific network and storage requirements can eliminate certain VM sizes and types.

Azure VM families include:

• General purpose (balanced CPU-to-memory ratio)
• Compute optimized (high CPU-to-memory ratio)
• Memory optimized (high memory-to-CPU ratio)
• Storage optimized (high disk throughput and I/O)
• GPU (for ML and graphics-intensive workloads)
• High performance compute (for HPC workloads)

Location

Location impacts two key areas: performance and compliance.

• Performance: Distance matters — the closer your VM and applications are to the target audience, the better the experience.
• Compliance: Some agencies and/or governments require applications and/or services to be located inside specific sovereignties (data residency requirements).
• Service availability: Not all Azure services are available in every region; ensure required services are supported in the chosen region.
• Pricing: The same VM type in two different locations can sometimes have different costs.
• Business continuity: Consider deploying across multiple regions or availability zones to enhance resilience.

Storage

Azure offers various storage types for virtual machines, each with different performance characteristics and costs:

Key storage recommendations:

• For most production workloads, use managed disks — they simplify storage management and improve reliability.
• Unmanaged disks are typically for specific needs with customized installations.
• Consider disk caching options as they can significantly impact VM performance.
• If using unmanaged disks, consider storage account limitations and management overhead.

Operating System

Azure VMs support two primary OS options: Windows and Linux.

• You can use prebuilt images from the Azure Marketplace, or upload your own custom images.
• Azure supports various versions of Windows Server and many Linux distributions.
• For Windows Server VMs, consider the Azure Hybrid Benefit — it can provide significant cost savings by allowing you to use existing on-premises Windows Server licenses.
• Decide between generalized images (more flexible, require some setup) and specialized images (preconfigured for specific workloads).
• Plan for image management and maintenance strategies, including how you will update and retire images.

Updates

Keeping VMs updated is crucial for security and performance. Azure provides several tools:

• Azure Update Management: Set up patch orchestration to automate the update process.
• Update schedules and maintenance windows: Define these to minimize disruption to services.
• Consider both OS updates and application updates in your planning.
• For complex update scenarios, leverage Azure Automation.
• Balance update speed: update too slowly and you risk insecurity; update too quickly and you risk an update breaking your infrastructure.

Monitoring

Effective monitoring is key to maintaining healthy, performant VMs. Azure provides several tools:

• Azure Monitor for VMs and VM Insights: Collect detailed performance metrics, set up alerts, and gain insights into VM health and resource utilization.
• Azure Diagnostics extension: Provides even more detailed information about VM operations.
• Azure Security Center: Provides enhanced security monitoring.
• Monitor costs as well as technical metrics — you pay for what you store, and more aggressive monitoring on the VM itself must be assessed for performance impact.

1.3 Securing Virtual Machine Management Traffic

Virtual machine management traffic includes the traffic involved in managing VMs — RDP (Remote Desktop Protocol), SSH (Secure Shell), and other management protocols. This traffic is necessary for management and operation, but also makes VMs susceptible to attack. Common threats include:

• Brute force attacks
• Man-in-the-middle attacks
• Unauthorized access attempts

Azure provides three key tools to secure this traffic, and a layered approach using all three is strongly recommended.

Azure Bastion

Azure Bastion is a fully managed service that provides secure and seamless RDP and SSH access to virtual machines directly through the Azure portal.

Key characteristics:

• VM management traffic never traverses the public internet — eliminating exposure to potential threats.
• No need to expose public IP addresses on VMs.
• Access is provided through the Azure portal using TLS encryption.
• Integrates with Azure Private Link to further secure management traffic by keeping it within the Azure backbone network.

Just-in-Time (JIT) VM Access

Just-in-Time (JIT) VM Access reduces the attack surface of virtual machines by allowing access only when it is needed.

How JIT works:

• Ports like RDP (3389) or SSH (22) remain closed by default.
• When a legitimate user requests access, the port is opened temporarily for a specific duration.
• Access is limited to authorized users and specific ports only.
• Ports automatically close after the set time — minimizing the risk of unauthorized access.
• All access requests are logged, providing detailed insights into who accessed the VM and when.

Network Security Groups (NSGs)

Network Security Groups (NSGs) appear repeatedly in security discussions and are a bare minimum for VM management security. Three principles apply when using NSGs for management traffic:

1. Create rulesets specific to management tools — rarely does a single ruleset apply to all management scenarios.
2. Scope your tools to their managed assets — just because a tool can manage a range of technology does not mean it should have access to everything.
3. Embrace granularity, but focus on simplicity — granularity in pursuit of zero trust must be intentional to avoid configuration sprawl.

Layered Security Approach

Configuring VM management traffic security is not an either/or consideration — it almost always requires an also/and approach.

NSGs (bare minimum)
    +
Just-in-Time VM Access (recommended)
    +
Azure Bastion (highly recommended)
    =
Layered VM Management Security

When considering additional technologies that incur cost (JIT, Bastion), it is important to make stakeholders aware of how much money these technologies save in preventing data breach incidents.

1.4 Virtual Machine Availability

Virtual machine availability refers to ensuring that VMs are operational and accessible whenever needed, minimizing downtime and disruptions. For business-critical applications, even brief outages can lead to significant revenue loss or operational delays.

Availability Sets

Availability Sets protect against hardware failures and planned maintenance within a single datacenter. They have two core components:

• Fault Domains: Physically separate groups of hardware (power, networking, servers) within a datacenter. VMs in different fault domains are isolated from hardware failures — if one rack of servers loses power, VMs on a different fault domain continue running.
• Update Domains: Logical groups of VMs that are updated sequentially during planned maintenance. VMs in separate update domains are never updated simultaneously, ensuring at least one VM is always available to handle incoming load.

graph TD
    subgraph AS[Availability Set]
        subgraph FD1[Fault Domain 1]
            VM1[VM 1\nUpdate Domain 1]
            VM3[VM 3\nUpdate Domain 2]
        end
        subgraph FD2[Fault Domain 2]
            VM2[VM 2\nUpdate Domain 2]
            VM4[VM 4\nUpdate Domain 1]
        end
    end

Availability Zones

Availability Zones take VM availability a step further by physically separating resources across different datacenters within the same Azure region. Each zone has its own:

• Independent power supply
• Independent cooling infrastructure
• Independent network infrastructure

A failure in one zone does not affect the others. By placing VMs in different zones, applications remain highly available even in the event of a datacenter-wide failure. This is ideal for applications requiring higher levels of redundancy and resilience.

Important: Have a deployment strategy to ensure VMs are explicitly placed into different availability zones at deployment time.

graph LR
    subgraph Region[Azure Region]
        subgraph Z1[Zone 1 - Datacenter A]
            VM_A[VM Instance A]
        end
        subgraph Z2[Zone 2 - Datacenter B]
            VM_B[VM Instance B]
        end
        subgraph Z3[Zone 3 - Datacenter C]
            VM_C[VM Instance C]
        end
        LB[Load Balancer] --> VM_A
        LB --> VM_B
        LB --> VM_C
    end

Availability Sets vs. Availability Zones

Load Balancing

Load balancing is the process of distributing incoming network traffic across multiple servers to ensure no single server bears too much load. Benefits include:

• Improved availability and responsiveness
• Increased reliability by mitigating the possibility of failure

Two types of load balancing:

Load balancers can be configured to distribute traffic based on:

• Geographic location
• Session persistence
• Health probes — ensuring traffic is only sent to healthy VMs and providing failover when a VM goes down

VM Scale Sets (VMSS)

Virtual Machine Scale Sets (VMSS) allow for automatic scaling of VMs based on demand. This is particularly useful for:

• Applications with variable workloads
• Cost optimization — scale down during periods of low traffic
• Scale up automatically during high demand periods

VMSS is both a scaling solution and a cost optimization tool.

1.5 Azure Hybrid Backup and Recovery

Azure provides two complementary services for hybrid backup and recovery: Azure Backup and Azure Site Recovery. These two services are designed to work in tandem.

Azure Backup

Azure Backup is ideal for scenarios where data protection and long-term retention are required. It supports hybrid environments by providing backup capabilities for both on-premises and Azure workloads.

Best suited for:

• File shares
• On-premises workloads
• Databases (SQL Server, SAP HANA)
• VMs where compliance or data archiving is a priority

Components for hybrid backup:

Azure Site Recovery (ASR)

Azure Site Recovery (ASR) is best for scenarios requiring disaster recovery. It replicates on-premises workloads to Azure, ensuring business continuity and minimal downtime during outages.

Best suited for:

• Failover capabilities for VMs or physical servers during a disaster (to Azure or another on-premises site)
• Scenarios where minimal RTO (Recovery Time Objective) is critical

Key ASR components:

• Recovery Services Vault: Stores replication data
• Recovery plans: Define what to configure as far as triggering and what actions to perform
• Failover and failback procedures: Configured to respond to disaster triggers
• Azure Automation integration: Enables automatic recovery

Complementary Approach

The best practice is to use Azure Backup and Azure Site Recovery together, each serving a distinct role:

Azure Backup
├── Purpose: Data protection and long-term retention
├── What it backs up: Files, databases, individual VMs
└── When used: Daily/scheduled backups, compliance retention

Azure Site Recovery (ASR)
├── Purpose: Disaster recovery and business continuity
├── What it replicates: Entire VMs and physical servers
└── When used: During disasters — automatic failover to Azure

Using these two in tandem helps to optimize costs while protecting critical data and services in different ways, depending on the business requirement.

1.6 Virtual Machine Backup and Recovery

Azure VM Backup is a native Azure service designed to provide comprehensive backup and recovery solutions for virtual machines, protecting against data loss and corruption.

Purpose: Back up and ensure that data and VMs can be restored to a previous state in the event of:

• Accidental deletion
• Data corruption
• Hardware failure

Backup Considerations

Data consistency levels:

The Backup Process

• Snapshot-based backups: Azure Backup uses incremental snapshots, capturing only the changes since the last backup to optimize storage and reduce backup time.
• Backup Vaults: Backups are stored in Recovery Services Vaults, which securely house backup data.
• Automation: The backup process is automation-capable and enforceable through Azure Policy to enforce backup policies across resources, ensuring compliance and consistency.

The Recovery Process

Three recovery options are available:

1. Full VM Recovery: The entire virtual machine, including OS and data, is restored to a previous point in time.
2. Granular File Recovery: Individual files or directories are restored from a VM backup (file-level recovery).
3. Recovery options:
   • Replace the existing VM: Recover the VM by overwriting the existing one.
   • Create a new VM: Recover a copy of the VM in a different region or as a separate instance.

flowchart TD
    A[Disaster / Data Loss Event] --> B{What needs recovery?}
    B -->|Entire VM| C[Full VM Recovery]
    B -->|Individual files| D[Granular File Recovery]
    C --> E{Recovery destination?}
    E -->|Same location| F[Replace Existing VM]
    E -->|Different region/new instance| G[Create New VM]
    D --> H[File-Level Restore]

Best Practices for VM Backup and Recovery

1. Backup testing: Regularly test backups to ensure they can be restored successfully in case of a disaster.
2. Backup redundancy: Store backups in geo-redundant storage (GRS) for high availability across regions.
3. Cost management: Optimize backup frequency and retention policies to manage storage costs efficiently.

1.7 Case Study: Virtual Machines

Scenario: A financial services company is expanding its infrastructure by integrating Azure virtual machines to support new applications while maintaining critical systems on-premises.

Primary Goals:

• Ensure high availability for critical applications
• Provide robust backup and disaster recovery
• Securely manage the hybrid environment
• Optimize costs using scalable, flexible solutions

Requirement 1: High Availability

Solution: Availability Zones + Availability Sets + Load Balancers

• Availability Zones: Distribute critical VMs across multiple availability zones to ensure redundancy in case of a datacenter failure.
• Availability Sets: For non-critical workloads, availability sets with fault domains and update domains minimize downtime during planned maintenance and unexpected hardware failures.
• Load Balancers: Distribute incoming traffic across VMs in different zones and availability sets to enhance overall reliability.

Why this works: Availability zones and availability sets work together to protect against both datacenter-level and hardware-level failures, ensuring applications remain available during planned maintenance or regional outages. Load balancers assist in the implementation of both technologies.

Requirement 2: Backup and Disaster Recovery

Solution: Azure Backup + Azure Site Recovery

• Azure Backup: Daily incremental backups for Azure VMs, plus use of Azure Backup Server to back up on-premises file shares, SQL databases, and VMs to Azure Recovery Services Vaults.
• Azure Site Recovery: Replicate on-premises VMs to Azure. In the event of a disaster, ASR can fail over VMs to Azure with minimal downtime.

Requirement 3: Security

Solution: Azure Bastion + NSGs + Azure Private Link

• Azure Bastion: Manage VMs securely via SSH and RDP without exposing them to the public internet.
• Network Security Groups (NSGs): Restrict traffic to only necessary ports and IP addresses, minimizing the attack surface.
• Azure Private Link with Azure Bastion: Further secures management traffic by keeping it within the Azure backbone network rather than exposing it to the public internet.

These three technologies provide a layered security model that ensures management traffic remains private and VMs are protected from unauthorized access.

Requirement 4: Cost Optimization

Solution: Virtual Machine Scale Sets (VMSS)

• VMSS allows scaling of VMs based on demand, minimizing costs by scaling down during periods of low traffic and scaling up automatically during peak demand.

Summary Architecture

Financial Services Hybrid Cloud
├── On-Premises
│   ├── MABS (Microsoft Azure Backup Server)
│   ├── MARS Agent on all servers
│   └── Physical/Virtual servers replicated via ASR
│
└── Azure Cloud
    ├── Availability Zone 1: Critical VM replicas
    ├── Availability Zone 2: Critical VM replicas
    ├── Azure Bastion (secure management)
    ├── NSGs (traffic control)
    ├── Load Balancer (traffic distribution)
    ├── VMSS (scalable workloads)
    └── Recovery Services Vault (backup storage)

Module 2: Containers

2.1 Container Technologies in Azure

Containers have become a key technology in cloud computing because they allow for portable, lightweight, and scalable environments for running applications. They provide a consistent way to package applications and their dependencies.

Container technologies in Azure fall into the Platform as a Service (PaaS) category.

Containers vs. Virtual Machines

When to choose containers: Better suited for modern microservices architectures where quick deployments, scalability, and portability are essential.

When to choose VMs: Still the right choice when you need full OS control or when working with monolithic or legacy applications.

Azure Container Instances (ACI)

Azure Container Instances (ACI) is a lightweight, serverless container service that allows users to run containers directly in Azure without managing the underlying infrastructure.

Key characteristics:

• Best for: Short-lived workloads, quick deployments, and scenarios where full Kubernetes orchestration is not needed.
• Cost model: Pay only for what you use — no need to manage VM infrastructure.
• Speed: Can quickly launch containers on demand.
• No orchestration: ACI does not provide container orchestration; it simply runs individual containers.

Use cases:

• Burst workloads requiring fast deployment
• Development and testing — spin up containers rapidly
• Short-lived batch jobs

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is a fully managed Kubernetes service in Azure that simplifies deploying, managing, and operating Kubernetes clusters.

Key features:

• Automated scaling and updates
• CI/CD pipeline integration (supports DevOps workflows)
• Full control over container networking, storage, and governance
• Self-healing capabilities — automatically replaces failed nodes and restarts unhealthy pods

Best suited for: Complex multi-container applications that require orchestration, such as microservices architectures or large-scale applications.

Azure Container Apps (ACA)

Azure Container Apps (ACA) is Azure’s serverless container service — fully managed, serverless, and great for microservice, API, and background-type implementations.

Key characteristics:

• Automatically scales based on HTTP traffic, events, or background processes.
• Fully managed: No need to manage underlying infrastructure — Azure handles scaling, networking, and load balancing.
• Serverless scaling: Perfect for applications that need to scale on demand but do not require the complexity of AKS.

Best suited for: Event-driven or lightweight applications that need serverless scaling, microservices, and APIs.

Container Technology Comparison

2.2 Choosing Container Technologies

When to Use ACI

Azure Container Instances are best for:

• Short-lived burst workloads: Tasks that require fast deployment with no complex orchestration.
• Development and testing: Spin up containers rapidly; pay-as-you-go cost efficiency for short-lived workloads.
• Simple deployments: No orchestration capability means it is not suitable for complex multi-container apps.

When to Use AKS

Azure Kubernetes Service is the best choice for:

• Complex, large-scale applications requiring container orchestration and high availability.
• Production-grade microservices — AKS provides full control over networking, storage, and security configurations.
• CI/CD pipeline integration — automated scaling, self-healing capabilities, and integrated DevOps workflows.
• Teams needing granular control over infrastructure, advanced networking, and security tools.

When to Use ACA

Azure Container Apps offers a middle ground between simplicity and scalability. Best for:

• Microservices and APIs: Event-driven applications without needing to manage infrastructure.
• Lightweight web APIs: Fully managed service lets you focus on code while Azure handles scaling.
• Serverless scaling: Automatically adjusts to demand based on HTTP requests, events, or background jobs.

Decision Guide

Need to run containers...
├── Quick, simple, short-lived task? → ACI
├── Complex multi-container orchestration, production-grade? → AKS
└── Event-driven, microservices, serverless scaling? → ACA

2.3 Container Availability and Scaling

High availability and scaling are crucial for ensuring containerized workloads perform optimally and remain resilient to failures.

High Availability in AKS

AKS provides several features to ensure high availability:

• Multiple node pools: Different pools of nodes can be configured for different workload types.
• Availability Zones: AKS supports deploying nodes across availability zones — if one zone fails, others take over, maintaining uptime.
• Self-healing capabilities: Kubernetes automatically replaces failed nodes and restarts unhealthy pods.
• Cross-region replication and failover: Set up region replication for disaster recovery, ensuring applications can recover from large-scale outages.

Scaling Options in AKS

AKS offers three flexible scaling options:

graph TD
    subgraph AKS Cluster
        CP[Control Plane - Managed by Azure]
        subgraph NP[Node Pool]
            N1[Node 1 - AZ1]
            N2[Node 2 - AZ2]
            N3[Node 3 - AZ3]
        end
        CA[Cluster Autoscaler] -->|Adds/removes nodes| NP
        HPA[Horizontal Pod Autoscaler] -->|Adds/removes pods| NP
    end
    VN[Virtual Nodes - ACI] -->|Burst scaling| NP
    ALB[Azure Load Balancer] --> NP

Scaling and Availability Considerations

Several factors influence scaling and availability decisions:

1. Traffic patterns: Applications with predictable spikes might benefit from predefined scaling rules; unpredictable traffic requires dynamic scaling.
2. Resource utilization: Monitor CPU, memory, and storage to ensure resources are not over- or underutilized.
3. Cost balance: Overprovisioning for high availability can be expensive; underscaling leads to performance bottlenecks.
4. RTO and RPO: Keep Recovery Time Objectives and Recovery Point Objectives in mind when planning disaster recovery strategies.

Best Practices

• Proactive monitoring: Use Azure Monitor and Azure Log Analytics to track performance and resource usage in real time.
• Failover testing: Regularly test failover strategies to ensure AKS clusters recover quickly in case of failure.
• Optimized scaling settings: Strike a balance between performance and cost by adjusting thresholds to prevent both overprovisioning and underprovisioning.

Module 3: Serverless Compute

3.1 Serverless Technologies in Azure

Serverless computing in Azure lets you build and run applications without managing the underlying infrastructure. Azure provisions, scales, and manages the resources your applications need automatically.

Serverless is ideal when:

• Workloads are event-driven and do not require constant long-running processes
• Tasks are short-lived
• Minimal operational overhead is preferred
• Automatic scaling is needed

Cost model: Pay only for what you use — if the code does not execute, there is no charge.

Azure provides two primary serverless services: Azure Functions and Azure Logic Apps.

Azure Functions

Azure Functions are serverless pieces of code that require no infrastructure management.

Key features:

• Language support: Supports many languages including C#, JavaScript, Python, Java, PowerShell, and TypeScript.
• Pay-per-execution: Only charged when code executes — no charge for idle time.
• Event-driven: Triggered by HTTP requests, timers, queues, blobs, events, and more.
• Automatic scaling: Scales based on the number of executions.
• Code-first approach: Developers write and deploy custom code.

Azure Logic Apps

Azure Logic Apps is a cloud-based service that enables you to automate workflows and integrate systems without writing extensive code.

Key features:

• 400+ pre-built connectors: Links to various services including Office 365, Salesforce, Dynamics 365, databases, and more.
• Visual designer: Build workflows using a drag-and-drop interface — no deep coding required.
• Workflow-first approach: Focus is on orchestrating processes across multiple systems.
• Event-triggered workflows: Respond to events and trigger chains of actions automatically.

Azure Functions vs. Azure Logic Apps

Both Azure Functions and Azure Logic Apps are serverless and allow you to focus on business logic rather than infrastructure management. Together, they provide powerful serverless options for different kinds of tasks.

3.2 Choosing Serverless Technologies

When to Use Azure Functions

Azure Functions is best suited for:

• Event-driven applications: Respond quickly to HTTP requests, process messages in a queue, or handle real-time events.
• Lightweight APIs: Write custom code and scale automatically based on the number of executions.
• Background processes: Scheduled or event-triggered tasks.
• Microservices: Custom logic that needs to scale automatically.

Real-world examples:

• Processing orders in an e-commerce system as they come in
• Sending notifications based on an event trigger
• Running background data processing on a schedule

Advantages of Azure Functions:

• Flexible coding — full control over custom logic
• Event-driven and highly scalable
• Pay-per-execution cost model

Disadvantages of Azure Functions:

• Development overhead — requires coding skills
• Limited pre-built integrations compared to Logic Apps

When to Use Azure Logic Apps

Azure Logic Apps is ideal for:

• Automating workflows: Orchestrating business processes across multiple systems.
• Integration across services: Cloud services, on-premises systems, and external APIs using built-in connectors.
• Data synchronization: Automating data movement between systems.
• Non-developer scenarios: Users who want a no-code solution.

Real-world examples:

• Automated approval processes where an email trigger initiates actions across multiple systems
• Syncing customer information between CRM and ERP systems
• Automated file transfers between storage systems

Advantages of Azure Logic Apps:

• No-code/low-code visual drag-and-drop interface
• 400+ pre-built connectors for rapid integration
• Easy to orchestrate complex multi-step workflows

Disadvantages of Azure Logic Apps:

• Performance overhead compared to custom code
• May be more costly at high throughput
• Not optimal for real-time, high-throughput applications

Decision Guide

Serverless compute decision:
├── Need custom code with full logic control? → Azure Functions
├── Need real-time, high-performance event processing? → Azure Functions
├── Need to automate workflows without much coding? → Azure Logic Apps
├── Need to integrate many services with pre-built connectors? → Azure Logic Apps
└── Need both? → Use both together (Functions for code, Logic Apps for orchestration)

Module 4: Batch Compute

4.1 Batch Compute Technologies in Azure

Batch computing is essential for running large-scale, parallel workloads that can be broken down into smaller tasks and processed independently. By dividing jobs into smaller tasks, batch computing allows for efficient processing of massive datasets or repetitive tasks.

Primary areas where batch compute is used:

• High-performance computing (HPC)
• Media and entertainment rendering jobs
• Large-scale scientific simulations

What is Batch Compute?

Batch compute involves:

• Large-scale, parallel jobs that are split into smaller tasks
• Tasks are processed in bulk independently
• Jobs are typically long-running (not real-time or short-lived)

Azure Batch

Azure Batch is a cloud-based service designed specifically for large-scale, parallel, and batch jobs.

Key capabilities:

• Job scheduling: Automatically handles the scheduling of tasks across a pool of compute nodes.
• Automatic scaling: Scales across thousands of VMs based on workload demand.
• Custom images: Supports custom VM images for specific execution environments.
• Containerized workloads: Supports Docker containers for flexible workload execution.
• Integration: Works with familiar tools and languages including Python, .NET, and Docker.

How Azure Batch Works:

flowchart LR
    A[Define Job] --> B[Break into Tasks]
    B --> C[Pool of Compute Nodes]
    subgraph Pool[Azure Batch Pool - Dynamic Scaling]
        C --> N1[Node 1]
        C --> N2[Node 2]
        C --> N3[Node 3]
        C --> N4[Node N...]
    end
    N1 --> D[Aggregate Results]
    N2 --> D
    N3 --> D
    N4 --> D
    D --> E[Job Complete]

Key advantages of Azure Batch:

4.2 Choosing Batch Compute Technologies

When to Use Azure Batch

Azure Batch is ideal for:

• High-performance computing (HPC): Scientific research with extensive modeling.
• Media rendering: Large-scale rendering across multiple nodes (e.g., movie productions with special effects) — the rendering job is broken into multiple parts, distributed across nodes, and reassembled.
• Parallel task processing: Any workload that can be split into independent parallel tasks.
• Data processing and transformation: Large-scale ETL (Extract, Transform, Load) jobs processing massive datasets in parallel.
• Financial services: Complex financial modeling, risk analysis, and large-scale data transformation.

When NOT to Use Azure Batch

Azure Batch is not suitable for:

How Azure Batch Works — Step by Step

1. Define the job: Specify what needs to be done.
2. Break into tasks: The job is decomposed into individual tasks that can be executed in parallel.
3. Pool of compute nodes: Tasks run on a pool of compute nodes (VMs) that can be dynamically scaled up or down based on demand.
4. Automatic scheduling: Azure Batch automatically handles scheduling and execution — no manual infrastructure management.
5. Custom environments: Azure Batch supports custom VM images and containerized workloads, allowing you to define the exact environment needed.
6. Scale down: After jobs complete, the pool scales back down.

Azure Batch Integration

Azure Batch integrates with:

• Python and .NET SDKs for job submission and management
• Docker for containerized workloads
• Azure Storage for input/output data
• Azure Monitor for job monitoring and diagnostics

4.3 Case Study: Containers, Serverless, and Batch Compute

Scenario: A retail company wants to modernize its analytics platform to handle increasing data volumes and performance demands.

Key Requirements:

1. Real-time data ingestion: Handle real-time analytics for customer behavior and product tracking.
2. Data processing and transformation: Process large datasets to perform batch transformations.
3. Automated workflows: Integrate multiple systems and automate the process of data ingestion, analysis, and reporting.

Solution Architecture

flowchart TB
    subgraph Sources[Data Sources]
        IoT[IoT Devices]
        Store[In-Store Systems]
        Ecom[E-commerce Platform]
    end

    subgraph Ingestion[Real-Time Ingestion - AKS]
        EH[Azure Event Hubs]
        AKS[AKS Microservices\nData Collection Pipeline]
    end

    subgraph Processing[Batch Processing - Azure Batch]
        AB[Azure Batch\nParallel Processing]
        Storage[Azure Storage\nHistorical Data]
    end

    subgraph Automation[Workflow Automation - Serverless]
        LA[Azure Logic Apps\nSystem Integration]
        AF[Azure Functions\nNotifications / Triggers]
    end

    subgraph Output[Output]
        Reports[Analytics Reports]
        Alerts[Customer Alerts]
    end

    IoT --> EH
    Store --> EH
    Ecom --> EH
    EH --> AKS
    AKS --> Storage
    Storage --> AB
    AB --> Reports
    AB --> LA
    LA --> AF
    AF --> Alerts

Requirement 1: Real-Time Data Ingestion — AKS

Recommended Solution: Azure Kubernetes Service (AKS)

• AKS processes data coming from IoT devices, in-store systems, and e-commerce platforms in real time.
• Offers scalability and flexibility — the ingestion pipeline scales as data flows increase.
• Microservices architecture lets the company break data collection and processing into smaller, manageable services.
• Integrates seamlessly with Event Hubs or messaging systems for real-time data capture.

Requirement 2: Processing and Transformation — Azure Batch

Recommended Solution: Azure Batch

• Designed to handle large-scale, parallel processing tasks.
• Performs trend analysis on historical data — Azure Batch’s ability to schedule jobs and scale across thousands of VMs ensures even the largest datasets are processed quickly and efficiently.
• Ideal for data-heavy industries looking to optimize analytics and reporting processes.

Requirement 3: Automated Workflows — Azure Functions + Azure Logic Apps

Recommended Solution: Azure Logic Apps + Azure Functions

• Azure Logic Apps: Integrates data from different systems using pre-built connectors and provides custom connectors for additional speed of integration.
• Azure Functions: Handles notifications on customer shopping patterns to indicate high product demand.

Summary

By combining AKS for real-time data ingestion, Azure Batch for large-scale processing, and serverless technologies (Logic Apps and Functions) for automation, the company achieves:

• A powerful, scalable analytics platform
• Handles large volumes of data efficiently
• Automates workflows
• Cost efficiency through dynamic resource scaling
• A modern, flexible platform ready to scale with growing needs

Module 5: Application Architecture

5.1 Messaging Architecture within Applications

Messaging is one of the core components of modern application architecture. Understanding what a message is — and what it is not — is foundational for designing effective application architectures.

What is a Message?

A message is a structured packet of data that is sent between services to communicate or trigger actions. It contains:

• Payload: The actual data being sent
• Metadata: Headers and other properties (routing information, content type, etc.)

Key characteristics of messages:

What a Message is NOT

• Not a direct API call: Unlike direct API calls, messages do not expect an immediate response. API calls expect real-time communication with immediate feedback; messages are processed asynchronously.
• Not a persistent database record: While a message may be stored temporarily for processing, it is not designed for long-term data storage. Messages are ephemeral — consumed, acted upon, then discarded or archived.
• Not an event: Events and messages serve different purposes (covered in Section 5.3).

The Publish/Subscribe (Pub/Sub) Model

The Pub/Sub model allows for asynchronous communication between services by decoupling message producers (publishers) from message consumers (subscribers).

How it works:

1. Publisher sends a message to a topic or queue — without knowing who will consume it.
2. Subscriber receives messages from the queue or topic and processes them.
3. Message Broker is the intermediary that handles message routing from the publisher to the appropriate subscriber(s).

graph LR
    P1[Publisher 1] --> Broker[Message Broker\nTopic / Queue]
    P2[Publisher 2] --> Broker
    Broker --> S1[Subscriber 1]
    Broker --> S2[Subscriber 2]
    Broker --> S3[Subscriber 3]

Benefits of Pub/Sub architecture:

5.2 Messaging Technologies in Azure

Azure provides several messaging technologies to meet different needs. Choosing the right one depends on the complexity of the messaging requirements.

Azure Queue Storage

Azure Queue Storage is a simple, cost-effective service for managing large volumes of messages.

Key features:

• Highly scalable: Capable of handling millions of messages.
• Durable: Messages remain in the queue until they are processed.
• Cost-effective: Simple solution for applications that do not require complex messaging features.
• Best for: Simple, scalable messaging solutions where enterprise-level features are not required.

Azure Service Bus

Azure Service Bus is a fully managed enterprise message broker that provides reliable messaging between applications and services.

Key features:

• Transactional messaging: Messages are delivered in a secure and reliable manner.
• Deferred messaging: Messages can be deferred for later processing.
• Message sessions: Group related messages together for ordered processing.
• Advanced patterns: Supports both point-to-point and publish/subscribe messaging models.
• Best for: Enterprise-level scenarios requiring reliable, ordered messaging with advanced features.

Service Bus Queues vs. Service Bus Topics

graph LR
    subgraph Queues[Service Bus Queue - Point-to-Point]
        PQ[Publisher] --> Q[Queue]
        Q --> R[Single Receiver]
    end

    subgraph Topics[Service Bus Topic - Pub/Sub]
        PT[Publisher] --> T[Topic]
        T --> S1[Subscriber 1\nFilter A]
        T --> S2[Subscriber 2\nFilter B]
        T --> S3[Subscriber 3\nAll messages]
    end

Choosing the Right Messaging Technology

5.3 Event-Driven Applications

Event-driven architecture is an essential part of most modern application infrastructures. Events are distinctly different from messages and serve a different purpose.

What is an Event?

An event is a significant occurrence or change in state in a system. Events are:

• Produced by the system and consumed by other components interested in reacting to those changes.
• Could be anything from a new customer signing up on a website to a temperature sensor detecting a change.
• In event-driven architecture, events are published and consumed by components that react to them.

Events vs. Messages

Azure Event Hub

Azure Event Hub is a scalable event processing service designed to handle large volumes of data streams from multiple sources in real time.

Key features:

• High throughput: Can handle millions of events per second.
• Partitioning: Allows for parallel consumption of events by multiple consumers.
• Integration: Integrates with Azure Stream Analytics, Azure Data Lake, and other analytics services.
• Best for: Telemetry ingestion from IoT devices, mobile apps, or web applications; stream processing.

Azure Event Grid

Azure Event Grid is an event routing service designed to manage the distribution of events from various sources to different consumers.

Key features:

• Event routing: Manages routing of events from sources (Azure resources, custom apps) to handlers.
• Built-in integrations: Native integration with Azure Functions, Logic Apps, webhooks, and more.
• Event filtering: Consumers only receive events they are interested in.
• Serverless architecture: Minimizes management overhead.
• Best for: Automating workflows based on events — responding to resource creation/deletion, triggering functions on storage changes.

Azure Stream Analytics

Azure Stream Analytics is a real-time analytics service for processing fast-moving streams of data.

Key features:

• SQL-like query language: Simple to define rules for analyzing incoming data streams.
• Real-time insights: Detects patterns and trends in data as it flows.
• Integration: Works with Event Hubs, IoT Hub, Blob Storage for seamless data ingestion and output.
• Best for: Analyzing telemetry data from IoT devices or logs from applications in real time; detecting patterns or anomalies.

Azure IoT Hub

Azure IoT Hub is a managed service that allows for secure communication between IoT devices and the cloud.

Key features:

• Device management: Manages millions of IoT devices including provisioning, authentication, and bidirectional communication.
• Security: Strong focus on security and scalability to ensure data moving between IoT devices and Azure is secure.
• Telemetry collection: Collects telemetry data from devices.
• Integration: Integrates with Event Hubs and Stream Analytics.
• Best for: Device management, secure telemetry ingestion, managing large fleets of IoT devices.

5.4 Choosing an Event Solution

Each Azure event solution has specific use cases. The table below provides a quick comparison:

When to Use Azure Event Hub

• High-throughput event ingestion is needed.
• Scenarios: Telemetry ingestion and stream processing.
• Strength: Scalability and integration with analytics tools.

When to Use Azure Event Grid

• Event routing and automation between services is needed.
• Scenarios: Triggering functions when new Azure resources are created, orchestrating events between services.
• Strength: Built-in integrations with Azure Functions and Logic Apps; event broadcasting to multiple services.

When to Use Azure Stream Analytics

• Real-time data processing is needed.
• Scenarios: Processing streams of data from IoT devices, logs, or applications to generate real-time insights.
• Strength: Real-time data processing and pattern detection using SQL-like queries.

When to Use Azure IoT Hub

• Secure IoT device management is needed.
• Scenarios: Managing device provisioning, authentication, and software updates at scale.
• Strength: Secure, scalable management of large fleets of IoT devices with bidirectional communication.

flowchart TD
    A[Event Solution Decision] --> B{High-volume event ingestion?}
    B -->|Yes, millions/sec| C[Azure Event Hub]
    B -->|No| D{Real-time analytics\non streaming data?}
    D -->|Yes| E[Azure Stream Analytics]
    D -->|No| F{IoT device management?}
    F -->|Yes| G[Azure IoT Hub]
    F -->|No| H{Event routing and\nworkflow automation?}
    H -->|Yes| I[Azure Event Grid]

5.5 Exposing APIs

APIs (Application Programming Interfaces) are an essential component of application architecture. The decision of when and how to expose APIs has important security implications.

Why Expose APIs?

• Integration point: APIs create an integration point for internal systems, mobile applications, and external services.
• Interoperability: APIs allow different platforms to exchange data and functionality.
• Business agility: Exposing APIs enables new partnerships and revenue streams through external access to services.

Azure API Management

Azure API Management is a fully managed service that helps organizations publish, secure, monitor, and scale their APIs, enabling internal teams and external partners to access and use APIs efficiently.

Key features:

graph LR
    subgraph Consumers
        App1[Mobile App]
        App2[Web App]
        App3[External Partner]
        Dev[Developer Portal]
    end
    
    subgraph APIM[Azure API Management]
        GW[API Gateway]
        SEC[Security\nOAuth / JWT / IP]
        RL[Rate Limiting\nThrottling]
        MON[Analytics\nMonitoring]
    end
    
    subgraph Backend[Backend APIs]
        API1[API Service 1]
        API2[API Service 2]
        API3[API Service 3]
    end
    
    App1 --> GW
    App2 --> GW
    App3 --> GW
    Dev --> GW
    GW --> SEC
    SEC --> RL
    RL --> MON
    MON --> API1
    MON --> API2
    MON --> API3

When to Use Azure API Management

• Managing both internal and external APIs: Ensures APIs are secure and scalable.
• Strong security requirements: Authentication, rate limiting, and IP filtering.
• API monetization: Offer tiered access or subscription-based APIs.
• Engaging external developers: Provide a developer portal for discovery and testing.
• Monitoring and optimization: Gain insights on API usage and performance.

5.6 Application Caching

Caching improves application performance by storing frequently accessed data in memory, reducing the time needed to retrieve it.

Why Use Caching?

• Faster response times: Reduces the time to retrieve data by serving it from memory rather than databases.
• Reduces database load: Allows databases to focus on processing other tasks.
• Scalability: Minimizes bottlenecks and helps handle higher volumes of users efficiently.

Azure Cache for Redis

Azure Cache for Redis is a fully managed in-memory caching system designed to provide fast data access for applications.

Key characteristics:

• High throughput and low latency: Ideal for real-time applications.
• Flexible data structures: Supports strings, lists, sets, sorted sets, and hashes.
• Persistence options: Cached data can survive restarts.
• Built-in failover and replication: High availability and resilience.

Common use cases:

• Session storage
• Real-time analytics
• Leaderboards and counters
• Product catalogs and user profiles
• E-commerce, gaming, and content delivery scenarios where speed is crucial

Caching Patterns

Three primary caching patterns for Azure Cache for Redis:

Cache-Aside Pattern:

Application checks cache → Data found? → Return data
                        → Data NOT found? → Fetch from DB → Store in cache → Return data

• The application is responsible for checking the cache first and populating it on a miss.
• Most flexible pattern — application controls what and when to cache.

Write-Through Pattern:

Application writes data → Data written to BOTH cache AND database simultaneously
                       → Cache is always in sync with the database

• Ensures cache and database are always consistent.
• Slightly higher write latency but reads are always fast.

Read-Through Pattern:

Application requests data → Cache checks itself → Found? → Return data
                                                → Not found? → Cache fetches from DB → Return data

• The cache itself handles fetching from the database (not the application).
• Reduces application complexity.

Eviction Policies

Five Key Benefits of Azure Cache for Redis

1. Sub-millisecond data retrieval: Significantly improves performance for applications requiring real-time responses.
2. Scalability: Highly scalable — capable of handling growing data and traffic volumes.
3. Cost efficiency: Reduces load on databases, avoiding the need for expensive database scaling.
4. Data flexibility: Supports a wide variety of data structures (strings, lists, sets, etc.).
5. High availability and resilience: Built-in failover and replication ensure reliability.

Module 6: Application Deployment, Configuration, and Security

6.1 Automated Application Deployment

Automated deployment enables teams to deploy applications quickly, consistently, and reliably without manual intervention. The benefits include:

• Consistent and repeatable deployments
• Reduced errors compared to manual processes
• Faster time to deployment

Two categories of tools are used for automated deployment:

1. Infrastructure as Code (IaC) — for provisioning infrastructure
2. CI/CD pipelines — for automating build, test, and deployment workflows

Infrastructure as Code (IaC)

IaC tools allow you to automate the provisioning and management of infrastructure using code rather than manual processes.

ARM Templates

Azure Resource Manager (ARM) Templates are native to Azure and provide a powerful way to define Azure resources using JSON.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2021-03-01",
      "name": "[parameters('vmName')]",
      "location": "[parameters('location')]",
      "properties": {
        "hardwareProfile": {
          "vmSize": "[parameters('vmSize')]"
        }
      }
    }
  ]
}

Characteristics:

• Native to Azure — deep integration with all Azure services.
• JSON-based — can be verbose and complex.
• Declarative — define the desired state; Azure handles the deployment.
• Best for: Azure-only deployments needing full Azure resource support.

Bicep Language

Bicep is a domain-specific language (DSL) that abstracts much of the complexity of ARM templates while offering full Azure resource support.

param vmName string
param location string = resourceGroup().location
param vmSize string = 'Standard_D2s_v3'

resource vm 'Microsoft.Compute/virtualMachines@2021-03-01' = {
  name: vmName
  location: location
  properties: {
    hardwareProfile: {
      vmSize: vmSize
    }
  }
}

Characteristics:

• Simpler and more readable than ARM JSON templates.
• Compiles to ARM templates — full Azure resource support.
• Better tooling and IntelliSense support.
• Best for: Teams working exclusively in Azure who want a simpler authoring experience.

Terraform

Terraform is a multi-cloud IaC tool that supports a variety of cloud providers.

resource "azurerm_virtual_machine" "example" {
  name                = var.vm_name
  location            = var.location
  resource_group_name = azurerm_resource_group.example.name
  vm_size             = "Standard_D2s_v3"
}

Characteristics:

• Multi-cloud support: Works with Azure, AWS, GCP, and others.
• HCL (HashiCorp Configuration Language): Readable and expressive.
• Manages infrastructure consistently across different platforms.
• Best for: Multi-cloud or hybrid cloud environments needing a single IaC tool.

IaC Tool Comparison

CI/CD Pipelines

CI/CD (Continuous Integration / Continuous Deployment) pipelines automate the build, test, and deployment of application code.

Azure DevOps

Azure DevOps is a comprehensive suite of tools for managing the entire software development lifecycle.

Components:

• Azure Pipelines: Build and release pipelines for CI/CD
• Azure Boards: Work item tracking and agile project management
• Azure Repos: Git repositories for source control
• Azure Artifacts: Package management

Characteristics:

• Deep integration with Azure services.
• Supports complex, advanced workflows.
• Ideal for larger enterprise projects with deep Azure integrations.
• Favored for complex workflows requiring advanced release management.

GitHub Actions

GitHub Actions is a lightweight, flexible CI/CD tool integrated directly into GitHub.

name: Deploy to Azure
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Login to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
      - name: Deploy ARM Template
        uses: azure/arm-deploy@v1
        with:
          resourceGroupName: my-rg
          template: ./template.json

Characteristics:

• Seamless GitHub integration.
• Large marketplace with pre-built actions.
• Excellent for smaller teams or open-source projects.
• Community-driven workflows.

Jenkins

Jenkins is a highly popular open-source automation server used in CI/CD pipelines.

Characteristics:

• Extensive plugin ecosystem: Integrates with Azure, AWS, Docker, and more.
• Custom workflows: Highly adaptable to various environments.
• Scalable: Can handle large-scale builds and deployments across multiple machines.
• Best for: Teams that need to build custom workflows or deploy applications across multi-cloud infrastructures.

CI/CD Tool Comparison

6.2 Application Configuration

Application configuration refers to managing the settings that control how an application behaves in different environments (development, staging, production).

Why Centralize Configuration?

• Consistency across environments: Ensures all environments are configured consistently.
• Separation of concerns: Separating configuration from code allows changes to be made without redeploying the application.
• Environment-specific settings: Easily manage settings like database connection strings or API endpoints per environment.

Azure App Configuration

Azure App Configuration is a managed service that enables the central management of application settings and feature flags.

Key benefits:

Feature Flags

Feature flags are a powerful tool for managing application features without the need to redeploy or modify the codebase. A feature flag acts as a switch that can enable or disable specific features dynamically.

Use cases:

graph LR
    subgraph Config[Azure App Configuration]
        FF[Feature Flag:\nNew Checkout Feature]
    end
    App[Application] -->|Check flag| Config
    Config -->|Flag = ON| UA[Group A Users\nSee new checkout]
    Config -->|Flag = OFF| UB[Group B Users\nSee old checkout]

Securing Application Configuration

• RBAC: Specify who can access or modify certain settings using Entra ID and role-based access control.
• Encryption: All configuration data is encrypted in transit and at rest.
• Audit logs: Track changes made to configuration settings for compliance and security auditing.

6.3 Securely Storing Secrets

Secrets are sensitive data such as API keys, passwords, and encryption keys that allow applications to access other systems and resources. Improperly secured secrets can lead to:

• Unauthorized access
• Data breaches
• Compliance violations (GDPR, HIPAA, etc.)

Types of Secrets

Each type of secret plays a critical role in keeping applications secure and must be handled carefully to prevent exposure.

Azure Key Vault

Azure Key Vault is a cloud service for securely storing and managing secrets, certificates, and encryption keys.

Key capabilities:

• Centralized secrets management: All secrets, certificates, and encryption keys in one secure location.
• Access control: Uses Entra ID and role-based access control to restrict access.
• Audit logs: Tracks who has accessed or modified secrets, ensuring compliance.
• Certificate management: Automates certificate renewal, reducing the risk of expired certificates.
• Integration: Integrates with Azure services for seamless secret retrieval.

Typical use cases:

• Securely storing API keys
• Managing SSL/TLS certificates
• Controlling access to encryption keys
• Storing database connection strings

Protecting Azure Key Vault

Because secrets are centralized in Key Vault, protecting Key Vault itself becomes critically important. A multi-layer protection approach:

graph TD
    subgraph Layers[Azure Key Vault Protection Layers]
        L1[Layer 1: Access Control\nEntra ID + RBAC]
        L2[Layer 2: Network Security\nFirewalls + VNets + Private Endpoints]
        L3[Layer 3: Encryption\nSecrets encrypted at rest\nCustomer-managed keys available]
        L4[Layer 4: Audit and Monitoring\nAudit logs + Alerts]
    end
    L1 --> L2
    L2 --> L3
    L3 --> L4

Key Benefits of Azure Key Vault

1. Centralized platform: All secrets, certificates, and encryption keys in one place.
2. Simplified management: Consolidates all sensitive assets with robust access control.
3. Automated certificate management: Auto-renewal reduces risk of expired certificates.
4. Compliance support: Detailed audit logs for tracking secret access and changes.
5. Azure integration: Easy, secure storage and retrieval of secrets across Azure applications.

6.4 Case Study: Application Architecture

Scenario: A retail company is expanding its online presence and needs a scalable, secure, and resilient e-commerce platform to handle increasing traffic and ensure data security.

Requirements:

1. Automated deployment: Streamline deployments across development, staging, and production environments.
2. Configuration management: Dynamic configuration management for environment-specific settings.
3. Secret management: Secure storage for API keys, database connection strings, and encryption keys.

Solution Architecture

flowchart TB
    subgraph Dev[Development Environment]
        D1[Dev Config\nApp Configuration]
        D2[Dev Secrets\nKey Vault - Dev]
    end

    subgraph Staging[Staging Environment]
        S1[Staging Config\nApp Configuration]
        S2[Staging Secrets\nKey Vault - Staging]
    end

    subgraph Prod[Production Environment]
        P1[Prod Config\nApp Configuration]
        P2[Prod Secrets\nKey Vault - Prod]
    end

    subgraph Deploy[Deployment Pipeline]
        ARM[ARM Templates\nInfrastructure as Code]
        ADO[Azure DevOps\nCI/CD Pipeline]
    end

    ADO -->|Deploy to| Dev
    ADO -->|Deploy to| Staging
    ADO -->|Deploy to| Prod
    ARM --> ADO

Deployment Solution: ARM Templates + Azure DevOps

• ARM Templates: Define and deploy infrastructure components (VMs, storage accounts, networking resources). Allows for consistent and repeatable deployments across different environments.
• Azure DevOps: Automates deployment of both infrastructure and application code. Integrates seamlessly with ARM templates and offers advanced release management features for managing deployments across all three environments.

Configuration Management Solution: Azure App Configuration

• Centralized management of all configuration settings including environment-specific configurations (database connection strings, API endpoints).
• Real-time updates: Modify settings without redeploying the application.
• Feature flags: Manage feature rollouts — release new features gradually or quickly as needed.
• Ensures consistency across all three development environments.

Secret Management Solution: Azure Key Vault

• Secure, centralized location for all secrets (API keys, database connection strings, encryption keys).
• Managed through Entra ID and RBAC for access control.
• Auto-renewal policies for certificates, reducing ongoing maintenance burden.

Business Benefits

• Scalability: Platform scales efficiently with automated provisioning.
• Security: Strong secret management and access control.
• Flexibility: Real-time configuration changes without redeployment.
• Cost efficiency: Three-stage development cycle reduces production defects.
• Consistency: Automated deployments ensure reproducible environments.

Module 7: Exam Tips and Architect Mindset

7.1 Exam Tips by Topic Area

Virtual Machines

Key exam concepts:

• VMs are the go-to solution for lift-and-shift migrations from on-premises data centers to the cloud.
• Know the four key characteristics that indicate a VM should be considered (lift-and-shift, COTS apps, full OS control, pre-cloud optimization).
• Virtual Machine Scale Sets (VMSS): Available in cloud environments for fantastic scalability when using VM infrastructure.
• Know the availability tools: Availability Sets (Fault Domains + Update Domains) vs. Availability Zones.
• Know Azure Bastion, JIT VM Access, and NSGs for securing management traffic.

Containers

Key exam concepts:

• Know the three Azure container services: ACI, AKS, and ACA — each solves a specific problem.
• Focus on the unique problem each service solves — this is usually the first indicator of which solution an exam question is looking for.
• ACI = simple, burst, short-lived; AKS = complex orchestration, production; ACA = serverless, event-driven microservices.
• Know the strengths of each service as these are typically what exam scenarios test.

Serverless

Key exam concepts:

• Azure Functions: Code-based serverless solutions — high customization, event-driven execution.
• Azure Logic Apps: Automated workflows — responses to events with subsequent actions, 400+ connectors, no-code.
• The key differentiator: Functions = custom code; Logic Apps = visual workflow automation.

Batch Compute

Key exam concepts:

• Azure Batch: Know what it is — large-scale, parallel, batch jobs.
• Know when to use it (HPC, rendering, parallel data processing) vs. when NOT to use it (real-time, short-lived, non-parallelizable workloads).
• Know what a message is vs. what an event is — and understand Pub/Sub patterns.

Applications (Module 5 + 6)

Key exam concepts:

• Know the difference between messages and events and the appropriate Azure service for each scenario.
• Azure Queue Storage vs. Service Bus: Know when to use each (simple vs. enterprise).
• Service Bus Queues vs. Topics: Point-to-point vs. Pub/Sub.
• Event Hub vs. Event Grid vs. Stream Analytics vs. IoT Hub: Know each service’s strength and primary use case.
• Azure API Management: Know when it’s appropriate (security, monetization, developer portals).
• Azure Cache for Redis: Know the caching patterns (cache-aside, write-through, read-through).
• IaC tools: ARM Templates (Azure, JSON), Bicep (Azure, simpler), Terraform (multi-cloud).
• CI/CD: Azure DevOps (enterprise, complex) vs. GitHub Actions (simple, GitHub-integrated) vs. Jenkins (open-source, custom).
• Azure App Configuration: Feature flags = gradual rollouts, A/B testing, instant rollbacks.
• Azure Key Vault: Centralized secrets management, Entra ID + RBAC, audit logs.

7.2 The Azure Compute Solution Decision Flowchart

The Azure Compute Solution Decision Flowchart is one of the most important tools for the AZ-305 exam. Start with this flowchart when approaching any compute-related exam question or scenario.

Most Azure compute services fall into one of three categories:

flowchart TD
    Start([Start]) --> Q1{Lift-and-shift\nmigration?}
    Q1 -->|Yes| VM[Virtual Machines\nIaaS]
    Q1 -->|No| Q2{Need full OS\ncontrol?}
    Q2 -->|Yes| VM
    Q2 -->|No| Q3{COTS application\nrequiring specific env?}
    Q3 -->|Yes| VM
    Q3 -->|No| Q4{Container\nworkload?}
    Q4 -->|Yes| Q5{Orchestration\ncomplexity?}
    Q5 -->|None, short-lived burst| ACI[Azure Container Instances\nPaaS]
    Q5 -->|Complex, production-grade| AKS[Azure Kubernetes Service\nPaaS]
    Q5 -->|Serverless, event-driven| ACA[Azure Container Apps\nPaaS]
    Q4 -->|No| Q6{Large-scale parallel\nbatch processing?}
    Q6 -->|Yes| Batch[Azure Batch\nPaaS/IaaS]
    Q6 -->|No| Q7{Event-driven\nor short-lived?}
    Q7 -->|Custom code| AF[Azure Functions\nFaaS]
    Q7 -->|Workflow automation| ALA[Azure Logic Apps\nFaaS]

    style VM fill:#f9d5e5
    style ACI fill:#d5e8f9
    style AKS fill:#d5e8f9
    style ACA fill:#d5e8f9
    style Batch fill:#d5e8f9
    style AF fill:#d9f9d5
    style ALA fill:#d9f9d5

Using the Flowchart for Exam Questions

1. The easiest path is the migration path: Particularly lift-and-shift that cannot be containerized → Virtual Machines.
2. Container questions: Identify whether it needs orchestration, how complex the workload is, whether it needs to be serverless.
3. Serverless: Look for keywords like “event-driven,” “no infrastructure management,” “pay-per-execution,” “automated workflow.”
4. Batch: Look for keywords like “parallel processing,” “large-scale jobs,” “HPC,” “rendering.”
5. The flowchart provides a basic filter — use it to narrow down options, not as the final answer in all cases.

7.3 On Being a Solutions Architect

A Solutions Architect’s role is not just to know Azure services — it is to bring the right knowledge to stakeholders so they can make informed decisions.

The Solutions Architect Mindset

1. Seek solutions to requirements or problems.

The job is fundamentally about solving problems for stakeholders. Start with the requirement, then identify the best available solution. The Azure Compute Solution Decision Flowchart is a starting point, not the complete answer.

2. Every solution has tradeoffs.

There is rarely — if ever — a perfect solution for any stakeholder, even in the moment. Every architectural decision involves tradeoffs:

Acknowledge these tradeoffs openly with stakeholders. Do not hide the downsides of a recommendation.

3. Stakeholder requirements are dynamic.

Stakeholder requirements change over time — what is the best solution today may not be the best solution tomorrow. This means:

• Architect for adaptability where possible.
• Plan for evolution — today’s proof-of-concept may need to become tomorrow’s production system.
• Continuously reassess solutions as business needs change.

4. Bring knowledge to stakeholders for informed decisions.

The goal is not to make decisions for stakeholders — it is to equip them with the knowledge to make informed decisions about how to create solutions for their requirements. A good Solutions Architect:

• Presents options clearly with their respective tradeoffs.
• Translates technical concepts into business value.
• Helps stakeholders understand the financial and operational implications of each choice.

Recommended Next Steps

• Complete the full AZ-305 learning path: This course covers compute solutions, but the full AZ-305 covers identity, governance, monitoring, storage, networking, and more.
• Complete hands-on labs: Getting hands-on with these technologies solidifies understanding of what they do and how they can provide solutions to requirements.
• Take practice exams: After going through all content and getting hands-on experience, practice exams help train your brain to work through solutions, requirements, and problems in an exam format.

Quick Reference: Azure Compute Services Summary

Quick Reference: Azure Messaging and Events Summary

Quick Reference: Application Deployment and Security Summary

Search Terms

az-305 · designing · compute · azure · architect · microsoft · batch · virtual · application · availability · backup · requirement · technologies · architecture · configuration · container · event · recovery · aks · apps · choosing · deployment · machine · management