Merge pull request #53945 from davidsmatlak/ds-updates-deploy-manage-app

freshness and content edits for Deploy and manage a stateful application Learn module

Author: JillGrant615

learn-pr/azure/aks-manage-application-state/1-introduction.yml

@@ -3,7 +3,7 @@ uid: learn.aks-manage-application-state.1-introduction
 metadata:
   title: Introduction
   description: Introduction
-  ms.date: 01/04/2024
+  ms.date: 03/23/2026
   author: davidsmatlak
   ms.author: davidsmatlak
   ms.topic: unit
@@ -15,4 +15,3 @@ title: Introduction
 durationInMinutes: 2
 content: |
   [!include[](includes/1-introduction.md)]
-

learn-pr/azure/aks-manage-application-state/2-understand-state-management.yml

@@ -3,7 +3,7 @@ uid: learn.aks-manage-application-state.2-understand-state-management
 metadata:
   title: Understand state management in Kubernetes
   description: Understand state management in Kubernetes
-  ms.date: 01/04/2024
+  ms.date: 03/23/2026
   author: davidsmatlak
   ms.author: davidsmatlak
   ms.topic: unit
@@ -20,12 +20,12 @@ quiz:
   questions:
     - content: "What's the persistent state of an application?"
       choices:
-        - content: "It's the type of state that continues to exist even after the application has been closed."
+        - content: "It's the type of state that continues to exist even after the application was closed."
           isCorrect: true
           explanation: "Although state itself involves all the contents of an application stored in memory, the persistent state is the one that needs to be stored persistently across the lifecycle of the application."
-        - content: "It's the state that's stored in memory or locally on the container."
+        - content: "It's the state stored in memory or locally on the container."
           isCorrect: false
-          explanation: "This is the ephemeral state. It's stored only in local memory or in the local container's file system and destroyed after the application or container is closed."
+          explanation: "This state is the ephemeral state. It's stored only in local memory or in the local container's file system and destroyed after the application or container is closed."
         - content: "It's all the disks and volumes that compose the application."
           isCorrect: false
           explanation: "Disks and volumes make a state persistent, but they store only the state."
@@ -47,8 +47,7 @@ quiz:
           explanation: "Although it's possible to store state in Kubernetes, the complexity of maintaining that for a highly available and scalable application doesn't pay off."
         - content: "Remove any possible state and use only ephemeral storage."
           isCorrect: false
-          explanation: "Although this is the easiest solution, it's nearly impossible to hold a large system together without any state management."
+          explanation: "Although this state is the easiest solution, it's nearly impossible to hold a large system together without any state management."
         - content: "Delegate the state management to external specialized solutions."
           isCorrect: true
           explanation: "To efficiently solve all scalability and availability problems, the best option is to externalize the state to specialized applications such as Azure Cosmos DB."
-

learn-pr/azure/aks-manage-application-state/3-exercise-create-resources.yml

@@ -3,7 +3,7 @@ uid: learn.aks-manage-application-state.3-exercise-create-resources
 metadata:
   title: Exercise - Host a new database by using Azure Cosmos DB
   description: Host a new database using Azure Cosmos DB and create a new AKS cluster to save your API changes to the database.
-  ms.date: 01/04/2024
+  ms.date: 03/23/2026
   author: davidsmatlak
   ms.author: davidsmatlak
   ms.topic: unit
@@ -12,7 +12,7 @@ metadata:
     - devx-track-azurecli
     - build-2023-dataai
     - build-2023
-title: Host a new database using Azure Cosmos DB
+title: Exercise - Host a new database using Azure Cosmos DB
 sandbox: false
 # sandbox: true
 # interactive: bash
@@ -40,4 +40,3 @@ content: |
 #           addonProfiles:
 #             httpApplicationRouting:
 #               enabled: true
-

learn-pr/azure/aks-manage-application-state/4-summary.yml

@@ -3,7 +3,7 @@ uid: learn.aks-manage-application-state.4-summary
 metadata:
   title: Summary
   description: Summary
-  ms.date: 01/04/2024
+  ms.date: 03/23/2026
   author: davidsmatlak
   ms.author: davidsmatlak
   ms.topic: unit
@@ -15,4 +15,3 @@ title: Summary
 durationInMinutes: 2
 content: |
   [!include[](includes/4-summary.md)]
-

learn-pr/azure/aks-manage-application-state/includes/1-introduction.md

@@ -1,6 +1,6 @@
-Imagine you work for a freight company that uses ships to transport goods across the world. The operations department uses a small system that tracks where all the company's ships are docked. Due to staff increases, your company has decided to move this system to Kubernetes.
+Imagine you work for a freight company that uses ships to transport goods across the world. The operations department uses a small system that tracks where each ship is docked. Due to staff increases, your company decided to move this system to Kubernetes.
 
-The system's application uses Azure Cosmos DB as a database, and it's built through a separated back end. You've been tasked with determining how to manage your database access in this distributed environment and how to deploy a new database to support this critical application.
+The system's application uses Azure Cosmos DB as a database built through a separate back end. You were assigned to determine how to manage your database access in this distributed environment and how to deploy a new database to support this critical application.
 
 ## Learning objectives
 

learn-pr/azure/aks-manage-application-state/includes/2-understand-state-management.md

@@ -1,22 +1,22 @@
-When talking about applications in general, you might often hear about the *application state*. In this unit, we review the definition of state and the different types of states so you can better prepare your application for handling them.
+When talking about applications in general, you might often hear about the _application state_. In this unit, we review the definition of state and the different types of states so you can better prepare your application to handle various states.
 
 ## State
 
-The state of the application is everything that's stored in memory by the time the application is running. The state can involve various things, but we mostly focus on the user data.
+The state of the application is everything stored in memory by the time the application is running. The state can involve various things, but we mostly focus on the user data.
 
-To give an example of application state, imagine you have a music player opened. This application has a state. It knows who you are, what you like to hear, and what music you've downloaded. All this information is part of the application state.
+To give an example of application state, imagine you have a music player opened. This application has a state. It knows who you are, what you like to hear, and which music you downloaded. All this information is part of the application state.
 
 The in-memory state is the information that the application doesn't need to look for anywhere else. The disk state contains the information that the application doesn't have at hand, so it needs to retrieve that from another data source.
 
 ### Types of states
 
-There are two types of application states. The first type is the *ephemeral state*, which isn't persistent and vanishes as soon as the application is closed.
+There are two types of application states. The first type is the _ephemeral state_, which isn't persistent and vanishes as soon as the application is closed.
 
-Containers have an ephemeral state. All of the data stored within them is instantly lost when the container is deleted. Some applications can work with that alone, because they can regenerate the state from other sources and don't need the state to be stored locally. Those applications are called *:::no-loc text="stateless"::: applications*.
+Containers have an ephemeral state. All of the data stored within them is instantly lost when the container is deleted. Some applications can work with that alone, because they can regenerate the state from other sources and don't need the state to be stored locally. Those applications are called _:::no-loc text="stateless"::: applications_.
 
-All the remaining state that isn't ephemeral is called *persistent state*. Persistent state continues to exist after the lifecycle of a container. Most container technologies that we use have the concept of *volume*, an in-disk location where the state exists. Even if you remove the container and turn it back on, the state remains stored in a safe location and can be used again.
+The remaining state that isn't ephemeral is called _persistent state_. Persistent state continues to exist after the lifecycle of a container. Most container technologies that we use have the concept of _volume_, an in-disk location where the state exists. If you remove the container and turn it back on, the state remains stored in a safe location and can be used again.
 
-Applications that rely on an external state to be retrieved are called *:::no-loc text="stateful"::: applications*.
+Applications that rely on an external state to be retrieved are called _:::no-loc text="stateful"::: applications_.
 
 ## States and Kubernetes
 
@@ -26,14 +26,14 @@ For most stateless applications, a simple deployment workload with a pod would b
 
 Dealing with stateful applications is the opposite. In these cases, you need to consider the application and its state, where the state is stored, and how you can store the state securely and reliably.
 
-This is why Kubernetes also has the concept of *:::no-loc text="PersistentVolumes":::* (PVs) and *:::no-loc text="PersistentVolumeClaims":::* (PVCs).
+This is why Kubernetes also has the concept of _:::no-loc text="PersistentVolumes":::_ (PV) and _:::no-loc text="PersistentVolumeClaims":::_ (PVC).
 
 > [!TIP]
 > This module doesn't discuss storage concepts further, but you can refer to the Azure Kubernetes Service resources in the summary to learn more.
 
-`PersistentVolumes` are disks that are allocated in nodes to store states from a pod's container. Because Kubernetes is best for distributed apps, all created volumes lie in a pool of *available volumes*. Containers then claim that space for themselves. You can use `PersistentVolumeClaims` to bind a `PersistentVolume` with a pod and use its space to store the needed data.
+`PersistentVolumes` are disks that are allocated in nodes to store states from a pod's container. Because Kubernetes is best for distributed apps, all created volumes lie in a pool of _available volumes_. Containers then claim that space for themselves. You can use `PersistentVolumeClaims` to bind a `PersistentVolume` with a pod and use its space to store the needed data.
 
-All database providers are stateful applications. If you're deploying a database provider in your cluster, you need a PV and a PVC to store the database data in a safe spot and allow the provider to retrieve that data even if its containers were deleted.
+All database providers are stateful applications. If you're deploying a database provider in your cluster, you need a PV and a PVC to store the database data and allow the provider to retrieve that data even if its containers were deleted.
 
 ## Best practices for state handling
 
@@ -43,15 +43,15 @@ You design any efficient application with the goal of making it highly available
 
 ### Highly available state
 
-To be highly available, an application must be online at all times. This is done through zone and region replication. Kubernetes is zone aware in most of its workloads. That means you can have several instances of an application that are deployed in different zones. However, disks aren't zone aware.
+To be highly available, an application must always be online. This is done through zone and region replication. Kubernetes is zone aware in most of its workloads. That means you can have several instances of an application that are deployed in different zones. However, disks aren't zone aware.
 
-When you deploy a new `PersistentVolume` object on Kubernetes, it's bound to a disk on a node. That disk is also bound to a particular zone in a particular region. Using zone or region replication with PVs is complex and requires a lot of maintenance, both to replicate and to synchronize data.
+When you deploy a new `PersistentVolume` object on Kubernetes, it's bound to a disk on a node. That disk is also bound to a particular zone in a particular region. Using zone or region replication with PVs is complex and requires much maintenance, both to replicate and to synchronize data.
 
 ### Highly scalable state
 
 To be highly scalable, an application should grow its throughput together with the number of users who are connected to it. This is complicated in state management because any external state is essentially a disk, and a disk has a limited input and output rate. Throughput management helps solve this problem.
 
-Database solutions came up with the idea of *:::no-loc text="ReplicaSets":::*, which replicate the whole database into multiple instances. The replication increases the number of disks *and* the I/O for the state.
+Database solutions came up with the idea of _:::no-loc text="ReplicaSets":::_ which replicate the whole database into multiple instances. The replication increases the number of disks _and_ the I/O for the state.
 
 On every database change, the state needs to be synchronized so that all disks contain the same data. This synchronization is also complex.