Update Gardener GCP learning path content

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/gardener-gcp/_index.md

@@ -1,18 +1,14 @@
 ---
 title: Deploy Gardener on Google Cloud C4A (Arm-based Axion VMs)
 
-draft: true
-cascade:
-    draft: true
-
 minutes_to_complete: 50
 
-who_is_this_for: This learning path is intended for software developers deploying and optimizing Gardener workloads on Linux/Arm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.
+who_is_this_for: This is an introductory topic for software developers deploying and optimizing Gardener workloads on Linux Arm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.
 
 learning_objectives:
-  - Provision an Arm-based SUSE SLES virtual machine on Google Cloud (C4A with Axion processors)
+  - Provision an Arm-based SUSE Linux Enterprise Server (SLES) virtual machine on Google Cloud (C4A with Axion processors)
   - Install and configure Gardener on a SUSE Arm64 (C4A) instance
-  - Deploy Garden, Seed, and Shoot clusters locally using KinD
+  - Deploy Garden, Seed, and Shoot clusters locally using Kubernetes in Docker (KinD)
   - Validate Gardener functionality by deploying workloads into a Shoot cluster
   - Perform baseline security benchmarking of Gardener-managed Kubernetes clusters using kube-bench on Arm64
 
@@ -62,7 +58,7 @@ further_reading:
       type: documentation
 
   - resource:
-      title: kube-bench documentation
+      title: kube-bench security benchmarking tool
       link: https://github.com/aquasecurity/kube-bench
       type: documentation
 

content/learning-paths/servers-and-cloud-computing/gardener-gcp/background.md

@@ -1,25 +1,35 @@
 ---
-title: Getting started with Gardener on Google Axion C4A (Arm Neoverse-V2)
+title: Get started with Gardener on Google Axion C4A (Arm Neoverse-V2)
 
 weight: 2
 
 layout: "learningpathall"
 ---
 
-## Google Axion C4A Arm instances in Google Cloud
+## Explore Google Axion C4A Arm instances
 
-Google Axion C4A is a family of Arm-based virtual machines built on Google’s custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machines offer strong performance for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.
+Google Axion C4A is a family of Arm-based virtual machines built on Google's custom Axion CPU, which uses Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machines deliver strong performance for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.
 
 The C4A series provides a cost-effective alternative to x86 virtual machines while leveraging the scalability and performance benefits of the Arm architecture in Google Cloud.
 
-To learn more about Google Axion, refer to the [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) blog.
+To learn more about Google Axion, see the Google blog [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu).
 
-## Gardener
+## Explore Gardener
 
-Gardener is an open-source, Kubernetes-native system for managing and operating Kubernetes clusters at scale. It enables automated creation, update, healing, and deletion of clusters across multiple cloud and on-prem providers.  
+Gardener is an open-source, Kubernetes-native system for managing and operating Kubernetes clusters at scale. It enables automated creation, updates, healing, and deletion of clusters across multiple cloud providers and on-premises environments.
 
-Gardener uses Kubernetes APIs and CRDs to declaratively manage clusters in a cloud-agnostic way. It follows a **Garden–Seed–Shoot** architecture to separate control planes from workload clusters.  
+Gardener uses Kubernetes APIs and Custom Resource Definitions (CRDs) to declaratively manage clusters in a cloud-agnostic way. It follows a Garden–Seed–Shoot architecture to separate control planes from workload clusters:
 
-Gardener is widely used to build reliable internal developer platforms and operate thousands of Kubernetes clusters.
+- Garden is the central management cluster that runs Gardener components.
+- Seed clusters are intermediary clusters that host Shoot control planes.
+- Shoot clusters are the workload clusters managed by Gardener for end users.
 
-To learn more, visit the Gardener [official website](https://gardener.cloud/) and explore the [documentation](https://gardener.cloud/docs/).
+Organizations use Gardener to build and operate Kubernetes clusters at scale, creating reliable internal developer platforms that serve thousands of teams.
+
+To learn more, visit the [Gardener website](https://gardener.cloud/) and explore the [Gardener documentation](https://gardener.cloud/docs/).
+
+## Summary and what's next
+
+You now understand Google Axion C4A's capabilities as a cost-effective Arm-based platform and how Gardener automates Kubernetes cluster management at scale. Together, these technologies provide a powerful foundation for running enterprise Kubernetes workloads on Arm infrastructure.
+
+In the next sections, you'll provision your Arm-based VM on Google Cloud, install Gardener, and deploy your first clusters. You're ready to get started!

content/learning-paths/servers-and-cloud-computing/gardener-gcp/baseline.md

@@ -10,7 +10,7 @@ layout: learningpathall
 
 This section confirms that your Gardener Local setup is functioning correctly on an Arm-based Google Cloud C4A VM before running production workloads. You'll check cluster health, deploy test workloads, and validate networking.
 
-### Set the kubeconfig environment variable
+## Set the kubeconfig environment variable
 
 Configure kubectl to communicate with your Gardener cluster by setting the `KUBECONFIG` variable:
 
@@ -20,7 +20,7 @@ export KUBECONFIG=$PWD/example/gardener-local/kind/local/kubeconfig
 
 This tells kubectl where to find your cluster's authentication credentials.
 
-### Check cluster health
+## Check cluster health
 
 Verify that your Gardener Local Kubernetes cluster is healthy by checking node and pod status:
 
@@ -31,14 +31,13 @@ kubectl get pods -A
 
 The output is similar to:
 
-```output
-NAME                           STATUS   ROLES           AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE
+```outputNAME                           STATUS   ROLES           AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE
 gardener-local-control-plane   Ready    control-plane   148m   v1.32.5   172.18.0.2    <none>        Debian GNU/Linux 12 (bookworm)
 ```
 
 A `Ready` status indicates the control plane is healthy. You should also see numerous pods running across the `garden`, `kube-system`, `istio-system`, and `shoot--local--local` namespaces, confirming that all Gardener components are operational.
 
-### Deploy a test nginx pod
+## Deploy a test nginx pod
 
 Deploy a simple nginx pod to verify that workload deployment works correctly:
 
@@ -62,7 +61,7 @@ test-nginx   1/1     Running             0          4s
 
 When the pod reaches `Running` status, workload deployment is functioning. Press **Ctrl + C** to stop watching the pod.
 
-### Create a service for the pod
+## Create a service for the pod
 
 Kubernetes services provide stable network endpoints for pods. Create a ClusterIP service to expose your nginx pod:
 
@@ -81,23 +80,20 @@ The output is similar to:
 NAME             TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
 test-nginx-svc   ClusterIP   10.2.194.17   <none>        80/TCP    9s
 ```
-A ClusterIP is assigned (example: 10.2.194.17). This confirms that Kubernetes services are functioning.
 
-### Test Service-to-Pod Connectivity
-Now we verify that one pod can talk to another pod through a service.
+The assigned ClusterIP (such as `10.2.194.17`) confirms that Kubernetes service networking is functioning correctly.
 
-- Start a temporary curl pod
-- Send an HTTP request to the nginx service
+## Test pod-to-service connectivity
 
-**Start a curl pod:** Create a temporary curl pod.
+Verify that one pod can communicate with another pod through a service by running curl inside a temporary pod:
 
-``` console
+```console
 kubectl run curl --image=curlimages/curl -i --tty -- sh
 ```
 
-Inside pod shell:
+Inside the pod shell, send an HTTP request to the nginx service:
 
-``` console
+```console
 curl http://test-nginx-svc
 ```
 Exit shell:
@@ -106,7 +102,7 @@ Exit shell:
 exit
 ```
 
-You should see an output similar to:
+The output is similar to:
 
 ```output
 All commands and output from this session will be recorded in container logs, including credentials and sensitive information passed through the command prompt.
@@ -140,21 +136,19 @@ Session ended, resume using 'kubectl attach curl -c curl -i -t' command when the
 ```
 This confirms pod-to-service networking.
 
-- Creates a curl container with an interactive shell.
-- Uses curl to send an HTTP request to the nginx service.
+Successful curl output confirms that pod-to-service networking is working correctly.
 
-### Verify DNS resolution
+## Verify DNS resolution
 
-- `nslookup test-nginx-svc` checks if DNS can resolve the service name
-- `CoreDNS` is responsible for this
+Test DNS service discovery by running `nslookup` inside the curl pod:
 
 If DNS resolves correctly, service discovery is healthy.
 
 ``` console
 kubectl exec curl -- nslookup test-nginx-svc.default.svc.cluster.local
 ```
 
-You should see an output similar to:
+The output is similar to:
 
 ```output
 Server:         10.2.0.10
@@ -163,23 +157,21 @@ Address:        10.2.0.10:53
 Name:   test-nginx-svc.default.svc.cluster.local
 Address: 10.2.194.17
 ```
-If DNS fails, networking or CoreDNS is broken.
 
-### Test Logs and Exec
-This confirms two important Kubernetes features:
-- Logs – you can debug applications
-- Exec – you can run commands inside containers
+Successful DNS resolution confirms that CoreDNS is functioning and service discovery is healthy.
 
-If logs show nginx startup and exec returns version info, pod access works.
+## Check pod logs and command execution
 
-``` console
+Verify that you can access pod logs and execute commands inside containers:
+
+```console
 kubectl logs test-nginx | head
 kubectl exec test-nginx -- nginx -v
 ```
 - `kubectl logs` → Shows nginx pod logs.
 - `kubectl exec` → Runs nginx -v inside the pod.
 
-You should see an output similar to:
+The output is similar to:
 
 ```output
 /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
@@ -196,26 +188,26 @@ You should see an output similar to:
 > kubectl exec test-nginx -- nginx -v
 nginx version: nginx/1.29.3
 ```
-- Logs show nginx starting.
-- Exec shows nginx version (e.g., `nginx version: nginx/1.25.3`).
 
-### Delete Test Resources
-Once testing is complete, temporary resources should be removed.
-- Deletes nginx and curl pods
-- Deletes the service
- 
-``` console
+Pod logs and command execution working confirms that you can debug and troubleshoot workloads effectively.
+
+## Clean up test resources
+
+Remove the test pods and service to keep your cluster clean:
+
+```console
 kubectl delete pod test-nginx curl
 kubectl delete svc test-nginx-svc
 ```
-Confirms cleanup works and keeps the cluster clean.
 
-You should see an output similar to:
+The output is similar to:
 
 ```output
 pod "test-nginx" deleted from default namespace
 pod "curl" deleted from default namespace
 > kubectl delete svc test-nginx-svc
 service "test-nginx-svc" deleted from default namespace
 ```
+## Summary and what's next
+
 After completing these steps, you have confirmed that the Kubernetes cluster and Gardener setup are healthy, core components are functioning correctly, pods start successfully, networking and services operate as expected, DNS resolution works, and the cluster is ready to run real workloads.