Give database readers their own lane — Aurora and Cluster settings

Your goal

Create an Aurora cluster configuration and inspect its reader and writer information.

Why this matters

Aurora describes writer and reader endpoints at the cluster level. You will inspect that cluster record and change its backup retention. Reading an endpoint field is different from testing SQL traffic through it.

Words you will use

An Aurora cluster groups database instances around shared storage. A writer handles changes and readers handle suitable reads. An endpoint is a connection address. Retention is the number of days backup history is kept.

How to proceed

Start a fresh emulator, read each numbered step, and enter the practice settings shown. Run the action, inspect its API receipt, then continue. Finish lab checks the emulator state again before saving your progress.

1. Create an Aurora cluster

Create an Aurora PostgreSQL cluster configuration. Inspect the identifiers and endpoints returned by the emulator. An endpoint record here does not run a database connection.

2. Set cluster retention

Choose and save the cluster’s backup retention period. This gives you a concrete setting to compare when reading the cluster record back.

Cluster retention days: Choose 1–35 days. This is an emulated cluster setting. Suggested practice value: 7.

3. Read the cluster record

Describe the cluster, inspect its reader and writer endpoint fields, and verify the retention value. This lab does not send SQL traffic or measure how connections are balanced.

Practice, then check your understanding

Perform the actions yourself and inspect the returned state. Errors keep your settings so you can retry. Starting another lab clears the previous live environment. Earned XP is kept, and signed-in achievements sync to your account. Replay does not award duplicate XP.

Read the official AWS documentation for service behavior and production details.