This chapter covers Azure Spring Apps, a fully managed service for deploying and scaling Spring Boot applications on Azure. For the AZ-305 exam, understanding Azure Spring Apps is critical for designing application platform solutions for Java workloads, which appears in the 'Design for application architecture' objective (4.1). Approximately 10-15% of exam questions relate to choosing the right compute service for containerized or microservices-based applications, and Azure Spring Apps is a key option for Java-centric solutions.
Jump to a section
Imagine you run a chain of restaurants serving Java-based menus. Each restaurant has its own kitchen with stoves, prep stations, and chefs (Spring Boot apps). Managing these kitchens individually is a nightmare: you need to maintain each stove, ensure consistent chef training, and handle customer surges. Azure Spring Apps is like a centralized kitchen management service. You provide the recipes (Java code) and the ingredients (configuration and dependencies). The service handles the rest: it provisions the right number of stoves (compute resources), orchestrates the chefs (manages app lifecycle), and automatically scales up when a lunch rush hits (autoscaling). It also monitors food quality (health checks) and routes orders to the right chef (load balancing). If a chef calls in sick (app failure), the service quickly assigns a replacement (restart or redeploy). You don't need to worry about the physical kitchen layout or stove maintenance – that's the platform's job. The key is that you control the recipe, but the service manages the kitchen operations. This abstraction lets you focus on creating great dishes (business logic) rather than kitchen logistics (infrastructure).
What is Azure Spring Apps and Why Does It Exist?
Azure Spring Apps (formerly Azure Spring Cloud) is a Platform-as-a-Service (PaaS) offering specifically designed for Spring Boot and Spring Cloud applications. It abstracts the underlying infrastructure, providing managed capabilities for service discovery, configuration management, API gateway, logging, monitoring, and scaling. The primary reason for its existence is to simplify the operational complexity of running Java microservices on Azure, especially those built with the Spring framework. Instead of manually managing virtual machines, Kubernetes clusters, or container orchestrators, developers deploy their JAR files or source code, and Azure Spring Apps handles the rest.
How It Works Internally
Internally, Azure Spring Apps runs on top of Azure Kubernetes Service (AKS). When you create an Azure Spring Apps service instance, a dedicated AKS cluster is provisioned in your subscription (though managed by the service). The cluster is pre-configured with a service mesh (Envoy-based), Spring Cloud Config Server, Spring Cloud Service Registry (Eureka), and other Spring Cloud components. Each deployed application runs as a set of pods within the cluster. The service mesh handles routing, load balancing, and traffic management. The Config Server provides externalized configuration, and the Service Registry manages service discovery.
Key Components, Values, Defaults, and Timers
Service Instance: The top-level resource. Each instance has a unique name and is tied to a region. Default SKUs: Basic (1 vCPU, 2 GB memory per app; limited to 5 apps), Standard (2 vCPU, 4 GB memory per app; up to 50 apps), Enterprise (customizable, includes VMware Tanzu components).
App: A logical deployment unit. Each app has a name, a number of replicas (default 1), and a resource allocation (CPU and memory).
Deployment: Represents a version of the app. You can have multiple deployments per app (e.g., staging and production).
Scale Settings: You can set autoscaling rules based on CPU or memory usage (default: manual scaling). Minimum and maximum replica counts can be configured (default min=1, max=10).
Health Probes: Azure Spring Apps uses liveness and readiness probes (HTTP GET on /actuator/health/path). Default interval: 10 seconds, timeout: 1 second, failure threshold: 3.
Config Server: Git-based configuration. Default pattern: {application}/{profile} from a Git repository.
Service Registry: Eureka-based. Heartbeat interval: 30 seconds, lease expiration: 90 seconds.
Configuration and Verification Commands
To deploy a Spring Boot app, you can use the Azure CLI:
# Create an Azure Spring Apps service instance
az spring create -n MySpringApp -g MyResourceGroup -l eastus --sku Standard
# Create an app
az spring app create -n my-app --service MySpringApp
# Deploy a JAR file
az spring app deploy -n my-app --service MySpringApp --artifact-path target/my-app.jar
# Scale an app
az spring app scale -n my-app --service MySpringApp --cpu 2 --memory 4 --instance-count 3To verify deployment, use:
az spring app list --service MySpringApp -o table
az spring app show -n my-app --service MySpringApp --query properties.provisioningStateHow It Interacts with Related Technologies
Azure DevOps / GitHub Actions: Continuous integration and deployment pipelines can deploy directly to Azure Spring Apps.
Azure Monitor: Application Insights integration provides distributed tracing, metrics, and logs.
Azure Key Vault: Store secrets and reference them via Spring Cloud Config.
Azure Database for MySQL/PostgreSQL: Common data stores for Spring apps.
Azure Service Bus: For messaging between microservices.
Exam-Relevant Details
Azure Spring Apps supports both Spring Boot 2.x and 3.x applications.
It can run on Azure Stack Hub for hybrid scenarios.
Managed identity (system-assigned or user-assigned) is supported for accessing Azure resources.
Enterprise tier includes Tanzu Build Service, Application Configuration Service, and more.
The service integrates with Azure Front Door or Azure Application Gateway for inbound traffic.
Provision Azure Spring Apps instance
Use Azure Portal, CLI, or ARM template to create a service instance. This triggers the creation of a managed AKS cluster and installs Spring Cloud components. The process takes 10-15 minutes. The instance is assigned a public endpoint (if enabled) and a VNet for private access.
Create and configure an app
Define an app within the instance. Specify the number of replicas, CPU/memory limits, and environment variables. The app is registered in the service registry (Eureka). Configuration can be pulled from Config Server. At this stage, no application code is running yet.
Deploy application code
Upload a JAR file or source code. Azure Spring Apps builds the application (if source) and creates a container image. The image is pushed to an Azure Container Registry (ACR) managed by the service. The deployment is then rolled out to the pods, with health checks starting immediately.
Configure autoscaling and health probes
Set autoscaling rules based on CPU or memory metrics. Define liveness and readiness probe paths. The probes are HTTP GET requests. If a probe fails three times consecutively, the pod is restarted (liveness) or removed from load balancing (readiness). Default probe interval is 10 seconds.
Enable monitoring and logging
Integrate with Azure Monitor and Application Insights. Distributed tracing is automatically collected via Spring Cloud Sleuth. Logs are sent to Log Analytics. You can set up alerts for metrics like request rate, error rate, and response time. This step is crucial for production observability.
Enterprise Scenario 1: Retail E-Commerce Platform
A large retailer migrated their monolithic Java application to microservices using Spring Boot. They chose Azure Spring Apps to manage the 15 microservices. The problem: they needed to handle Black Friday traffic spikes without over-provisioning. Solution: Deployed all services to a single Azure Spring Apps instance with autoscaling enabled. They configured CPU-based autoscaling with a target of 70% utilization. During peak, the system scaled from 2 to 20 replicas per service. They used Application Insights to trace requests across services. Common mistake: failing to set proper readiness probes, causing traffic to be sent to services still loading. They learned to set the probe path to /actuator/health and a delay of 30 seconds.
Enterprise Scenario 2: Financial Services API Gateway
A bank built an API gateway using Spring Cloud Gateway and deployed it on Azure Spring Apps. The challenge: strict security compliance requiring private network access and managed identities. They deployed the instance into an existing VNet with a service endpoint. They used system-assigned managed identity to access Azure Key Vault for certificates. They also enabled TLS termination at the gateway. The gateway handled 10,000 requests per second with less than 50ms latency. Misconfiguration: initially they forgot to enable the managed identity, causing the gateway to fail to retrieve secrets. They resolved by adding the identity in the Azure Spring Apps configuration.
Enterprise Scenario 3: Healthcare Patient Portal
A healthcare provider deployed a patient portal as a Spring Boot app. They needed HIPAA compliance. They used Azure Spring Apps Enterprise tier for its enhanced security features. They configured private endpoints for the service instance and disabled public access. They also enabled diagnostic logs and sent them to a Log Analytics workspace. They set up alerts for any failed health probes. Scale considerations: the app had 1000 concurrent users during peak hours. They set a fixed replica count of 5 with 2 vCPU each. The app ran smoothly with 99.9% uptime. A common pitfall: they initially used the Basic SKU, which limited them to 5 apps and 1 vCPU per app, causing performance issues. They upgraded to Standard.
What AZ-305 Tests on This Topic
AZ-305 objective 4.1: 'Design a compute solution' includes selecting the appropriate compute service for application workloads. Azure Spring Apps is a candidate for Java microservices. The exam tests your ability to differentiate Azure Spring Apps from other compute options like App Service, AKS, Container Instances, and Virtual Machines. Specific sub-objectives: - 4.1.1: Design for containerized applications (Azure Spring Apps is a container-based PaaS). - 4.1.2: Design for serverless applications (Azure Spring Apps is not serverless; it runs continuously). - 4.1.3: Design for microservices architecture (Azure Spring Apps is designed for microservices).
Common Wrong Answers and Why
Choosing App Service for Spring Boot apps: While App Service can run Java, it lacks built-in service discovery, config server, and distributed tracing. Azure Spring Apps is purpose-built for Spring. Wrong because candidates think App Service is simpler, but they miss the microservices features.
Selecting AKS directly: AKS is more flexible but requires Kubernetes expertise. Azure Spring Apps abstracts Kubernetes. Wrong because candidates overvalue control and undervalue operational overhead.
Picking Azure Functions: Functions are event-driven and stateless, not suitable for long-running Spring Boot apps. Wrong because candidates confuse serverless with microservices.
Specific Numbers and Terms on the Exam
SKU names: Basic, Standard, Enterprise.
Default health probe interval: 10 seconds.
Maximum apps per instance: Basic (5), Standard (50), Enterprise (unlimited with limits).
Service registry: Eureka.
Configuration management: Spring Cloud Config Server (Git-backed).
Edge Cases and Exceptions
The exam may ask about hybrid scenarios: Azure Spring Apps can run on Azure Stack Hub.
For high availability, deploy across multiple regions with Azure Front Door.
For private networks, use VNet injection (available in Standard and Enterprise tiers).
Managed identity: supports system-assigned and user-assigned.
How to Eliminate Wrong Answers
If the scenario mentions 'Spring Boot', 'microservices', 'service discovery', or 'distributed configuration', lean toward Azure Spring Apps.
If the scenario requires full Kubernetes control, choose AKS.
If the scenario is simple and doesn't need microservices features, App Service may be sufficient.
If the scenario is event-driven and stateless, consider Functions.
Azure Spring Apps is a managed PaaS for Spring Boot applications, built on AKS.
It includes service discovery (Eureka), config server (Git-backed), and distributed tracing (Sleuth).
Three SKUs: Basic (5 apps), Standard (50 apps), Enterprise (customizable).
Health probes default: HTTP GET on /actuator/health, interval 10s, timeout 1s, failure threshold 3.
Autoscaling can be configured based on CPU or memory metrics.
Supports VNet injection for private networks and managed identities for secure access.
Integrates with Azure DevOps, GitHub Actions, Azure Monitor, and Key Vault.
These come up on the exam all the time. Here's how to tell them apart.
Azure Spring Apps
Purpose-built for Spring Boot/Cloud microservices.
Includes service discovery (Eureka) and config server.
Built-in distributed tracing with Spring Cloud Sleuth.
Supports managed identity for Azure resources.
Enterprise tier offers Tanzu Build Service, etc.
Azure App Service
General purpose PaaS for web apps and APIs.
No built-in service discovery or config server.
Requires manual setup for distributed tracing.
Also supports managed identity.
Supports multiple languages (Java, .NET, Python, etc.).
Mistake
Azure Spring Apps is just a renamed Azure Spring Cloud with no changes.
Correct
Azure Spring Apps is the new name, but it includes additional features like Enterprise tier with VMware Tanzu components, and improved integration with Azure Monitor.
Mistake
Azure Spring Apps can only run Spring Boot applications.
Correct
While optimized for Spring Boot, it can also run any Java application packaged as a JAR, but the managed features (service discovery, config server) work best with Spring Cloud.
Mistake
Azure Spring Apps requires you to manage the underlying Kubernetes cluster.
Correct
The AKS cluster is fully managed by Azure Spring Apps; you do not have direct access to it.
Mistake
You can only deploy one app per Azure Spring Apps instance.
Correct
You can deploy multiple apps (up to the SKU limit) within a single instance, sharing the underlying cluster.
Mistake
Azure Spring Apps does not support autoscaling.
Correct
It does support autoscaling based on CPU or memory metrics, configurable via Azure CLI or portal.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Spring Apps is the new name for Azure Spring Cloud. The service has been rebranded but continues to evolve with additional features like the Enterprise tier. The core functionality remains the same.
Yes, you can deploy any Java application as a JAR file. However, you will not benefit from the managed Spring Cloud components (service discovery, config server) unless your application uses Spring Cloud libraries.
You can manually scale by setting the number of replicas, or configure autoscaling based on CPU or memory usage. Autoscaling rules can be set per app using the Azure CLI or portal.
Azure Spring Apps is available in many regions, but not all. Check the Azure products by region page for the latest list. It is generally available in major regions like East US, West Europe, and Southeast Asia.
You can use VNet injection to deploy the instance into your own virtual network, disable public access, and use private endpoints. Additionally, you can enable managed identities for accessing other Azure resources securely.
The Enterprise tier includes additional VMware Tanzu components such as Tanzu Build Service, Application Configuration Service, and Spring Cloud Gateway for Kubernetes. It also offers higher limits and enhanced support for production workloads.
Yes, Azure Spring Apps has built-in integration with Azure DevOps and GitHub Actions. You can set up CI/CD pipelines to automatically build and deploy your applications.
You've just covered Azure Spring Apps for Java Workloads — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?