diff --git a/content/learning-paths/servers-and-cloud-computing/redis-data-searching/_index.md b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/_index.md
new file mode 100644
index 0000000000..1faf259d98
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/_index.md
@@ -0,0 +1,57 @@
+---
+title: Deploy Redis for data searching on Google Cloud C4A (Arm-based Axion VMs)
+
+minutes_to_complete: 30
+
+who_is_this_for: This learning path is intended for software developers deploying and optimizing Redis-based data searching 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)
+  - Install Redis on a SUSE Arm64 (C4A) instance
+  - Verify Redis functionality by running the server and performing baseline data insertion and retrieval tests on the Arm64 VM  
+  - Measure Redis SET (write) and GET (read) performance using the official redis-benchmark tool to evaluate throughput and latency on Arm64 (Aarch64)
+
+prerequisites:
+  - A [Google Cloud Platform (GCP)](https://cloud.google.com/free) account with billing enabled
+  - Basic familiarity with [Redis](https://redis.io/) 
+
+author: Pareena Verma
+
+##### Tags
+skilllevels: Introductory
+subjects: Databases
+cloud_service_providers: Google Cloud
+
+armips:
+  - Neoverse
+
+tools_software_languages:
+  - Redis
+  - redis-benchmark
+
+operatingsystems:
+  - Linux
+
+# ================================================================================
+#       FIXED, DO NOT MODIFY
+# ================================================================================
+further_reading:
+  - resource:
+      title: Google Cloud documentation
+      link: https://cloud.google.com/docs
+      type: documentation
+
+  - resource:
+      title: Redis documentation
+      link: https://redis.io/docs/
+      type: documentation
+
+  - resource:
+      title: Redis benchmark documentation
+      link: https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/benchmarks/
+      type: documentation
+
+weight: 1
+layout: "learningpathall"
+learning_path_main_page: "yes"
+---
diff --git a/content/learning-paths/servers-and-cloud-computing/redis-data-searching/_next-steps.md b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/_next-steps.md
new file mode 100644
index 0000000000..c3db0de5a2
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/_next-steps.md
@@ -0,0 +1,8 @@
+---
+# ================================================================================
+#       FIXED, DO NOT MODIFY THIS FILE
+# ================================================================================
+weight: 21                  # Set to always be larger than the content in this path to be at the end of the navigation.
+title: "Next Steps"         # Always the same, html page title.
+layout: "learningpathall"   # All files under learning paths have this same wrapper for Hugo processing.
+---
diff --git a/content/learning-paths/servers-and-cloud-computing/redis-data-searching/background.md b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/background.md
new file mode 100644
index 0000000000..e32b5d281a
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/background.md
@@ -0,0 +1,25 @@
+---
+title: Getting started with Redis on Google Axion C4A (Arm Neoverse-V2)
+
+weight: 2
+
+layout: "learningpathall"
+---
+
+## Google Axion C4A Arm instances in Google Cloud
+
+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.
+
+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.
+
+## Redis
+
+[Redis](https://redis.io/) is an open-source, **in-memory data structure store** developed under the [Redis project](https://redis.io/). It is used as a **database**, **cache**, and **message broker**, supporting a variety of data structures such as **strings**, **hashes**, **lists**, **sets**, and **sorted sets**.
+
+Redis is designed for **high performance**, **low latency**, and **high throughput**, making it ideal for real-time applications. It supports **persistence**, **replication**, **Lua scripting**, **transactions**, and **high availability** through Redis Sentinel and **automatic partitioning** with Redis Cluster.
+
+Redis is widely adopted for **caching**, **session management**, **real-time analytics**, **pub/sub messaging**, and **leaderboards** in gaming and web applications. It integrates seamlessly with programming languages like **Python**, **Java**, **Go**, and **Node.js**.
+
+To learn more, visit the [Redis official website](https://redis.io/) and explore the [documentation](https://redis.io/docs/latest/).
diff --git a/content/learning-paths/servers-and-cloud-computing/redis-data-searching/baseline.md b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/baseline.md
new file mode 100644
index 0000000000..21a2d88575
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/baseline.md
@@ -0,0 +1,164 @@
+---
+title: Redis Baseline Testing on Google Axion C4A Arm Virtual Machine
+weight: 5
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Redis Baseline Testing on GCP SUSE VMs
+This section performs baseline testing for Redis running on a GCP SUSE Arm64 VM, focusing on data insertion, retrieval, and search performance.
+
+### Prerequisites
+This command launches the Redis server process in the background. It allows you to run subsequent commands in the same terminal session while Redis continues running.
+Start the Redis service in the background:
+
+```console
+redis-server &
+```
+
+**Check if Redis is active and responding to commands:**
+
+The redis-cli ping command sends a simple health check request to the Redis server. A PONG response confirms that the server is running correctly and the client can communicate with it.
+```console
+redis-cli ping
+```
+
+output:
+
+```output
+PONG
+```
+
+### Insert Sample Data
+These steps populate the Redis database with a sample dataset to validate insertion performance and data persistence. You will create 10,000 key-value pairs using a simple shell loop and verify that the data has been successfully stored.
+
+Use `redis-cli` to insert **10,000 sample key-value pairs**:
+```console
+for i in $(seq 1 10000); do
+  redis-cli SET key:$i "value-$i" > /dev/null
+done
+```
+- This command iterates through numbers **1 to 10,000**, setting each as a Redis key in the format `key:<number>` with the corresponding value `"value-<number>"`.
+- The `> /dev/null` part suppresses command output to make the insertion process cleaner and faster.
+
+**Verify Data Storage Count:**
+
+The `DBSIZE` command returns the total number of keys currently stored in the Redis database.
+
+```console
+redis-cli DBSIZE
+```
+
+```output
+(integer) 10000
+```
+Seeing `(integer) 10000` confirms that all key-value pairs were inserted successfully.
+
+**Verify Sample Data Retrieval**
+
+Fetch one of the inserted keys to confirm data correctness:
+
+```console
+redis-cli GET key:5000
+```
+- The `GET` command retrieves the value of a given key.  
+- If Redis returns `"value-5000"`, it confirms that data insertion worked properly and the database is responding as expected.
+
+You should see an output similar to:
+
+```output
+"value-5000"
+```
+
+### Perform Basic Data Search Tests
+This step verifies Redis’s ability to retrieve specific data efficiently using unique keys. The `GET` command fetches the value associated with a given key from Redis.
+
+You can test this by retrieving a known key-value pair:
+
+```console
+redis-cli GET key:1234
+```
+
+You should see an output similar to:
+
+```output
+"value-1234"
+```
+This confirms that Redis is storing and retrieving data correctly from memory.
+
+### Search for Multiple Keys Using Pattern Matching
+This test demonstrates how Redis can locate multiple keys that match a pattern, useful for exploratory queries or debugging.
+
+Use the `KEYS` command to search for keys matching a pattern:
+
+```console
+redis-cli KEYS "key:1*"
+```
+`KEYS` is fast but **blocks the server** when handling large datasets, so it’s not recommended in production.
+
+You should see an output similar to:
+
+```output
+   1) "key:1392"
+   2) "key:1076"
+   3) "key:1683"
+   4) "key:1490"
+   5) "key:117"
+   6) "key:1293"
+   7) "key:1791"
+   8) "key:1891"
+   9) "key:1543"
+..........
+```
+
+### Production-Safe Searching with SCAN
+This step introduces a production-friendly method for iterating through keys without blocking Redis operations.
+
+Use the `SCAN` command for larger datasets — it is non-blocking and iterates safely.
+
+```console
+redis-cli SCAN 0 MATCH "key:1*" COUNT 100
+```
+
+You should see an output similar to:
+
+```output
+1) "9792"
+2) 1) "key:151"
+   2) "key:1845"
+   3) "key:1397"
+   4) "key:1501"
+   5) "key:1994"
+   6) "key:1475"
+   7) "key:1522"
+   8) "key:1884"
+```
+Redis will return a cursor value (for example, `9792`).  
+Continue scanning by reusing the cursor until it returns `0`, meaning the iteration is complete.
+
+### Measure Data Retrieval Performance
+This step measures how quickly Redis can retrieve a single key from memory, helping to establish a baseline for data access latency on the Arm-based VM.
+
+**Time Single Key Lookup**: Redis operations are extremely fast since data is stored in-memory. To quantify this, the Unix `time` command is used to measure the latency of retrieving a single key using `redis-cli`.
+
+```console
+(time redis-cli GET key:9000) 2>&1
+```
+
+This command measures three time metrics:
+
+- **real** – Total elapsed time (wall-clock time)  
+- **user** – Time spent in user mode  
+- **sys** – Time spent in kernel mode
+
+You should see an output similar to:
+
+```output
+"value-9000"
+
+real    0m0.002s
+user    0m0.002s
+sys     0m0.000s
+```
+These results show that Redis retrieves data almost instantly (in milliseconds or microseconds), confirming that the instance is performing efficiently under baseline conditions.
diff --git a/content/learning-paths/servers-and-cloud-computing/redis-data-searching/benchmarking.md b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/benchmarking.md
new file mode 100644
index 0000000000..54d7aa0c5f
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/benchmarking.md
@@ -0,0 +1,171 @@
+---
+title: Redis Benchmarking
+weight: 6
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+
+## Redis Benchmarking by redis-benchmark
+The `redis-benchmark` tool is an official performance testing utility for Redis. It helps measure to throughput (requests per second) and latency (response delay) across different workloads.
+
+### Prerequisites
+Ensure Redis server is running and accessible:
+
+```console
+redis-server &
+redis-cli ping
+```
+### Benchmark SET (Write Performance)
+The `SET` benchmark helps validate Redis’s ability to handle high insertion rates efficiently on Arm-based servers.
+
+The following command benchmarks data insertion performance:
+
+```console
+redis-benchmark -t set -n 100000 -c 50
+```
+**Explanation:**
+
+- `-t set`: Runs the benchmark only for **SET** operations.  
+- `-n 100000`: Performs **100,000 total requests**.  
+- `-c 50`: Simulates **50 concurrent clients**.
+
+You should see an output similar to:
+
+```output
+====== SET ======
+  100000 requests completed in 0.67 seconds
+  50 parallel clients
+  3 bytes payload
+  keep alive: 1
+  host configuration "save": 3600 1 300 100 60 10000
+  host configuration "appendonly": no
+  multi-thread: no
+
+Latency by percentile distribution:
+0.000% <= 0.063 milliseconds (cumulative count 1)
+50.000% <= 0.167 milliseconds (cumulative count 54147)
+75.000% <= 0.175 milliseconds (cumulative count 94619)
+96.875% <= 0.183 milliseconds (cumulative count 98788)
+99.219% <= 0.231 milliseconds (cumulative count 99222)
+99.609% <= 0.415 milliseconds (cumulative count 99617)
+99.805% <= 0.543 milliseconds (cumulative count 99817)
+99.902% <= 0.671 milliseconds (cumulative count 99909)
+99.951% <= 0.775 milliseconds (cumulative count 99965)
+99.976% <= 0.983 milliseconds (cumulative count 99978)
+99.988% <= 1.087 milliseconds (cumulative count 99993)
+99.994% <= 1.095 milliseconds (cumulative count 100000)
+100.000% <= 1.095 milliseconds (cumulative count 100000)
+
+Cumulative distribution of latencies:
+0.035% <= 0.103 milliseconds (cumulative count 35)
+99.166% <= 0.207 milliseconds (cumulative count 99166)
+99.465% <= 0.303 milliseconds (cumulative count 99465)
+99.577% <= 0.407 milliseconds (cumulative count 99577)
+99.743% <= 0.503 milliseconds (cumulative count 99743)
+99.869% <= 0.607 milliseconds (cumulative count 99869)
+99.932% <= 0.703 milliseconds (cumulative count 99932)
+99.968% <= 0.807 milliseconds (cumulative count 99968)
+99.975% <= 0.903 milliseconds (cumulative count 99975)
+99.983% <= 1.007 milliseconds (cumulative count 99983)
+100.000% <= 1.103 milliseconds (cumulative count 100000)
+
+Summary:
+  throughput summary: 149700.61 requests per second
+  latency summary (msec):
+          avg       min       p50       p95       p99       max
+        0.170     0.056     0.167     0.183     0.191     1.095
+```
+
+### Benchmark GET (Read/Search Performance)
+Now test data retrieval performance separately.
+
+```console
+redis-benchmark -t get -n 100000 -c 50
+```
+**Explanation:**
+
+- `-t get`: Runs the benchmark only for **GET** operations.  
+- `-n 100000`: Executes **100,000 total requests**.  
+- `-c 50`: Simulates **50 concurrent clients** performing reads.
+
+You should see an output similar to:
+
+```output
+====== GET ======
+  100000 requests completed in 0.67 seconds
+  50 parallel clients
+  3 bytes payload
+  keep alive: 1
+  host configuration "save": 3600 1 300 100 60 10000
+  host configuration "appendonly": no
+  multi-thread: no
+
+Latency by percentile distribution:
+0.000% <= 0.055 milliseconds (cumulative count 2)
+50.000% <= 0.167 milliseconds (cumulative count 55781)
+75.000% <= 0.175 milliseconds (cumulative count 94250)
+96.875% <= 0.183 milliseconds (cumulative count 98794)
+99.219% <= 0.239 milliseconds (cumulative count 99222)
+99.609% <= 0.431 milliseconds (cumulative count 99618)
+99.805% <= 0.575 milliseconds (cumulative count 99822)
+99.902% <= 0.663 milliseconds (cumulative count 99906)
+99.951% <= 0.759 milliseconds (cumulative count 99953)
+99.976% <= 0.783 milliseconds (cumulative count 99976)
+99.988% <= 0.799 milliseconds (cumulative count 99995)
+99.997% <= 0.807 milliseconds (cumulative count 100000)
+100.000% <= 0.807 milliseconds (cumulative count 100000)
+
+Cumulative distribution of latencies:
+0.034% <= 0.103 milliseconds (cumulative count 34)
+99.141% <= 0.207 milliseconds (cumulative count 99141)
+99.478% <= 0.303 milliseconds (cumulative count 99478)
+99.558% <= 0.407 milliseconds (cumulative count 99558)
+99.718% <= 0.503 milliseconds (cumulative count 99718)
+99.866% <= 0.607 milliseconds (cumulative count 99866)
+99.951% <= 0.703 milliseconds (cumulative count 99951)
+100.000% <= 0.807 milliseconds (cumulative count 100000)
+
+Summary:
+  throughput summary: 150375.94 requests per second
+  latency summary (msec):
+          avg       min       p50       p95       p99       max
+        0.169     0.048     0.167     0.183     0.191     0.807
+```
+
+### Benchmark Metrics Explanation
+
+- **Throughput:** Number of operations (requests) Redis can process per second.
+- **Latency:** Latency reflects the time it takes for Redis to complete a single request, measured in milliseconds (ms).  
+- **avg:** Average time taken to process a request across the entire test.
+- **min:** Fastest observed response time (best case).
+- **p50:** Median latency — 50% of requests completed faster than this value.
+- **p95:** 95th percentile — 95% of requests completed faster than this value.
+- **p99:** 99th percentile — shows near worst-case latency, key for reliability analysis.
+- **max:** Slowest observed response time (worst case).
+
+### Benchmark summary on x86_64
+To compare the benchmark results, the following results were collected by running the same benchmark on a `x86 - c4-standard-4` (4 vCPUs, 15 GB Memory) x86_64 VM in GCP, running SUSE:
+
+| Operation | Total Requests | Concurrent Clients | Avg Latency (ms) | Min (ms) | P50 (ms) | P95 (ms) | P99 (ms) | Max (ms) | Throughput (req/sec) | Description |
+|------------|----------------|--------------------|------------------|-----------|-----------|-----------|-----------|-----------|-----------------------|--------------|
+| SET        | 100,000        | 50                 | 0.176            | 0.048     | 0.175     | 0.191     | 0.327     | 0.679     | 146,842.88            | Measures Redis write performance using SET command |
+| GET        | 100,000        | 50                 | 0.184            | 0.056     | 0.183     | 0.207     | 0.311     | 1.127     | 139,860.14            | Measures Redis read performance using GET command |
+
+
+### Benchmark summary on Arm64
+Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):
+
+| Operation | Total Requests | Concurrent Clients | Avg Latency (ms) | Min (ms) | P50 (ms) | P95 (ms) | P99 (ms) | Max (ms) | Throughput (req/sec) | Description |
+|------------|----------------|--------------------|------------------|-----------|-----------|-----------|-----------|-----------|-----------------------|--------------|
+| SET        | 100,000        | 50                 | 0.170            | 0.056     | 0.167     | 0.183     | 0.191     | 1.095     | 149,700.61            | Measures Redis write performance using SET command |
+| GET        | 100,000        | 50                 | 0.169            | 0.048     | 0.167     | 0.183     | 0.191     | 0.807     | 150,375.94            | Measures Redis read performance using GET command |
+
+
+ ### Redis benchmarking comparison on Arm64 and x86_64
+
+ - **High Efficiency:** Redis achieved over **150K ops/sec** on both read and write workloads, showcasing strong throughput on **Arm64 (C4A)** architecture.
+- **Low Latency:** Average latency remained around **0.17 ms**, demonstrating consistent response times under concurrency.
+- **Balanced Performance:** Both **SET** and **GET** operations showed nearly identical performance, indicating excellent CPU and memory optimization on **Arm64**.
+- **Energy-Efficient Compute:** The **Arm-based C4A VM** delivers competitive performance-per-watt efficiency, ideal for scalable, sustainable Redis deployments.
diff --git a/content/learning-paths/servers-and-cloud-computing/redis-data-searching/images/gcp-vm.png b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/images/gcp-vm.png
new file mode 100644
index 0000000000..0d1072e20d
Binary files /dev/null and b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/images/gcp-vm.png differ
diff --git a/content/learning-paths/servers-and-cloud-computing/redis-data-searching/installation.md b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/installation.md
new file mode 100644
index 0000000000..30958df36d
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/installation.md
@@ -0,0 +1,107 @@
+---
+title: Install Redis
+weight: 4
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Install Redis on GCP VM
+This section provides a complete guide to installing Redis on a **GCP SUSE virtual machine**. Redis will be built from source to ensure compatibility with the Arm architecture and to enable TLS support for secure connections.
+
+### Prerequisites
+Before building Redis, update your package repositories and install essential build tools and libraries.
+
+```console
+sudo zypper refresh
+sudo zypper install -y gcc gcc-c++ make tcl openssl-devel wget
+```
+### Download and Extract Redis Source Code
+This step downloads the Redis 8.2.2 source archive directly from the official GitHub repository, extracts the contents, and navigates into the extracted directory for compilation.
+
+```console
+wget https://github.com/redis/redis/archive/refs/tags/8.2.2.tar.gz
+tar -xvf 8.2.2.tar.gz
+cd redis-8.2.2
+```
+{{% notice Note %}}
+In [this](https://developer.arm.com/community/arm-community-blogs/b/servers-and-cloud-computing-blog/posts/improve-redis-performance-by-deploying-on-alibaba-cloud-yitian-710-instances) blog, Redis version 6.0.9 is recommended for deployment on Arm-based Alibaba Yitian 710 instances, which deliver up to 36% higher throughput and 20% lower cost compared to equivalent x86-based ECS instances, making it a more efficient and cost-effective choice for Redis workloads.
+
+The [Arm Ecosystem Dashboard](https://developer.arm.com/ecosystem-dashboard/) recommends Redis version 6.0.9, the minimum recommended on the Arm platforms.
+{{% /notice %}}
+
+### Build Redis with TLS Support
+**Clean any previous build artifacts (if any):**
+
+```console
+make distclean
+```
+This removes any residual files from a previous build, ensuring a clean build environment.
+
+**Now build Redis dependencies and compile Redis:**
+
+Redis relies on several third-party libraries (such as hiredis, jemalloc, and lua) to optimize performance and functionality. After building dependencies, the Redis source is compiled with BUILD_TLS=yes, enabling support for encrypted TLS connections.
+
+```console
+cd deps
+sudo make hiredis jemalloc linenoise lua fast_float
+cd ..
+sudo make BUILD_TLS=yes
+```
+Note: The BUILD_TLS=yes flag enables TLS (SSL) support for secure Redis connections.
+
+### Verify Redis Binary
+After a successful build, check that the redis-server binary exists:
+
+```
+cd src
+ls -l redis-server
+```
+
+You should see a file similar to:
+
+```output
+-rwxr-xr-x 1 root root 17869216 Oct 23 11:48 redis-server
+```
+This confirms that Redis compiled successfully and that the `redis-server` binary is present in the `/src` directory. The file’s permissions indicate it is executable.
+
+### Install Redis System-Wide
+This command installs Redis binaries (`redis-server` and `redis-cli`) into system-wide directories (typically `/usr/local/bin`), allowing you to run Redis commands from any location.
+To make redis-server and redis-cli accessible globally:
+
+```console
+sudo make install
+```
+
+Verify installation paths:
+
+```console
+which redis-server
+which redis-cli
+```
+
+Expected:
+
+```output
+/usr/local/bin/redis-server
+/usr/local/bin/redis-cli
+```
+This confirms that Redis binaries are available in your system path, verifying a successful installation.
+
+### Verify Installation
+Check Redis versions:
+
+```console
+redis-server --version
+redis-cli --version
+```
+
+Output:
+
+```output
+redis-server --version
+Redis server v=8.2.2 sha=00000000:1 malloc=jemalloc-5.3.0 bits=64 build=72ba144d8c96c783
+$ redis-cli --version
+$ redis-cli 8.2.2
+```
+This confirms that Redis has been installed and is ready for use.
diff --git a/content/learning-paths/servers-and-cloud-computing/redis-data-searching/instance.md b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/instance.md
new file mode 100644
index 0000000000..2b93bc950d
--- /dev/null
+++ b/content/learning-paths/servers-and-cloud-computing/redis-data-searching/instance.md
@@ -0,0 +1,31 @@
+---
+title: Create a Google Axion C4A Arm virtual machine on GCP 
+weight: 3
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Overview
+
+In this section, you will learn how to provision a Google Axion C4A Arm virtual machine on Google Cloud Platform (GCP) using the `c4a-standard-4` (4 vCPUs, 16 GB memory) machine type in the Google Cloud Console.  
+
+{{% notice Note %}}
+For support on GCP setup, see the Learning Path [Getting started with Google Cloud Platform](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/google/).
+{{% /notice %}}
+
+## Provision a Google Axion C4A Arm VM in Google Cloud Console
+
+To create a virtual machine based on the C4A instance type:
+- Navigate to the [Google Cloud Console](https://console.cloud.google.com/).
+- Go to **Compute Engine > VM Instances** and select **Create Instance**. 
+- Under **Machine configuration**:
+   - Populate fields such as **Instance name**, **Region**, and **Zone**.
+   - Set **Series** to `C4A`.
+   - Select `c4a-standard-4` for machine type.
+
+   ![Create a Google Axion C4A Arm virtual machine in the Google Cloud Console with c4a-standard-4 selected alt-text#center](images/gcp-vm.png "Creating a Google Axion C4A Arm virtual machine in Google Cloud Console")
+
+- Under **OS and Storage**, select **Change**, then choose an Arm64-based OS image. For this Learning Path, use **SUSE Linux Enterprise Server**. Pick the preferred version for your Operating System. Ensure you select the **Arm image** variant. Click **Select**.
+- Under **Networking**, enable **Allow HTTP traffic**.
+- Click **Create** to launch the instance.