AWS · Your First S3 Lab
Use the AWS CLI environment for a safe storage lifecycle with explicit cleanup.
What you'll build
Before You Build
2 quick questions. This is diagnostic only — it does not block the lesson.
What must be confirmed before creating AWS resources?
Why use a unique resource name?
Mission
Use LocalStack and the isolated AWS CLI container to complete one local S3 lifecycle, watch it appear in the ENJYRA console, and prove cleanup.
LOCAL AWS SIMULATION · NO CLOUD ACCOUNT
This lab runs only in lesson-scoped Docker containers on your machine. The ENJYRA console is inspired by the S3 workflow but is not the AWS Management Console. No AWS account or billable resource is used.
Understand
LocalStack emulates the S3 API for this lesson, while the ENJYRA console reads the emulator’s real state. The target lifecycle remains: create bucket → upload → list → download → delete object → delete bucket. The concepts transfer to AWS, but this local lab does not reproduce every AWS feature.
Build
You will launch the AWS Local Lab, create a bucket through the same professional wizard a real AWS engineer’s console mirrors (Block Public Access, encryption, versioning, tags, a Security Review), upload and inspect an object, deliberately weaken a permission and fix it, then confirm the Activity Log agrees with what the CLI did.
Start LocalStack and the official ENJYRA AWS console for this lesson only.
Every later step in this lesson reads and writes the same LocalStack state the console shows you.
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws start./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws start.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws startBefore You Run
- Your terminal is open in enjyra-cloud-labs.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Starts LocalStack and the official ENJYRA AWS console container, both scoped to this lesson.
Command Breakdown
ENJYRA launcher · AWS · start- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its start action.
Expected Result
ENJYRA aws local lab is starting.
Console: http://localhost:8081What Changed
BeforeThe requested local service or lab containers are not yet confirmed running.
AfterThe local service or lab containers are running in the background and can be verified.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
Both the emulator and ENJYRA console should report healthy.
If It Fails
- Run the status command below. If the console is not healthy, check that Docker Desktop is running.
What this command does Starts LocalStack and the official ENJYRA AWS console container, both scoped to this lesson.
ENJYRA aws local lab is starting.
Console: http://localhost:8081If it fails
Run the status command below. If the console is not healthy, check that Docker Desktop is running.
Open http://localhost:8081 and confirm the header shows ✓ Official ENJYRA Lab and ● Running locally. This is the ENJYRA AWS Local Lab, not the real AWS Management Console — the badge and the “Local simulation” line under the title say so on every page.
What’s happening behind the scenes?
Official ENJYRA image: enjyra/aws-labs · Release: console-0.1.1 · Platforms: linux/amd64, linux/arm64. Docker Compose reads compose/aws.compose.yml, pulls this image plus the upstream LocalStack emulator, and starts both. To inspect the image yourself: docker images –digests enjyra/aws-labs.
The AWS Local Lab console becomes reachable at http://localhost:8081. Docker Compose pulls the official enjyra/aws-labs image automatically — you do not need to run docker pull yourself.
Confirm both containers are healthy before continuing.
Catching a startup problem here is easier than debugging it three steps later.
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws statusBefore You Run
- Your terminal is open in enjyra-cloud-labs.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Lists the two containers for this lab and their health.
Command Breakdown
ENJYRA launcher · AWS · status- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its status action.
Expected Result
enjyra-aws-b01 Up (healthy)
enjyra-aws-b01-console Up (healthy)What Changed
BeforeThe current state has not yet been checked.
AfterNo persistent state changed; the command printed evidence you can compare with the expected result.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
Run the command and compare its output with the Expected Result block.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
- Docker daemon not running → start Docker Desktop or Docker Engine, then retry.
What this command does Lists the two containers for this lab and their health.
enjyra-aws-b01 Up (healthy)
enjyra-aws-b01-console Up (healthy)Nothing — this only reads status.
Decide the bucket's name, region and purpose before creating anything.
Real S3 bucket names must be globally unique; planning a clear, environment-scoped name avoids collisions and confusion later.
Bucket name: enjyra-documents-dev
Region: us-east-1 (local)
Purpose: Development storage for this lesson’s demo file
Use S3 Buckets → Create Bucket and choose a Region, then review Block Public Access, Encryption, Versioning & Recovery, Tags, and Permissions before creating.
This is the same sequence an engineer follows in the real AWS console — plan, secure, then create — instead of a single unexplained button.
Console path: S3 Buckets → Create Bucket → step through the wizard, keeping every recommended default (all four Block Public Access boxes checked, encryption and versioning on) → Review + create.
On the Review step, ENJYRA shows a live Security Review (for example “5 PASS · 0 WARNING”) calculated from your actual choices, not a fixed number. If you uncheck a Block Public Access box during the wizard, you will see an inline ⚠ warning immediately — try it, then re-check it before creating.
LOCAL LAB NOTE
The AWS Region is educational configuration for practising a real-cloud decision. LocalStack and the bucket’s bytes still run on your machine; selecting London, Virginia, or another Region does not move local data there.
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws cli s3api create-bucket --bucket enjyra-documents-dev --region us-east-1./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws cli s3api create-bucket --bucket enjyra-documents-dev --region us-east-1.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws cli s3api create-bucket --bucket enjyra-documents-dev --region us-east-1Before You Run
- Your terminal is open in the current lesson workspace.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Creates the same bucket directly against LocalStack, bypassing the wizard's extra settings.
Command Breakdown
ENJYRA launcher · AWS · cli- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its cli action.
Expected Result
{
"Location": "/enjyra-documents-dev"
}What Changed
BeforeThe requested local resource or updated object state is not yet visible in the emulator.
AfterThe emulator now contains the requested resource or updated object state.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
Confirm the lab is healthy, then refresh the matching ENJYRA console to see the resource.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
- Docker daemon not running → start Docker Desktop or Docker Engine, then retry.
What this command does Creates the same bucket directly against LocalStack, bypassing the wizard's extra settings.
{
"Location": "/enjyra-documents-dev"
}A real LocalStack bucket is created with Block Public Access, SSE-S3 encryption, and versioning. The chosen Region and 7-day recovery period are clearly labelled learning metadata because all bytes remain local.
Click the bucket's name in S3 Buckets to open its own page.
A real console does not keep you on the list — each bucket has its own Objects, Properties, Permissions and Activity views.
Console path: S3 Buckets → enjyra-documents-dev → Properties tab.
Confirm Versioning reads Enabled and Encryption reads SSE-S3 enabled — both read live from LocalStack, not guessed by the console.
Nothing is created here; this reads the bucket's real state from LocalStack.
Create a small text file and upload it to the bucket, from the console.
Objects are what a bucket actually stores; uploading proves the bucket is usable, not just present.
mkdir -p compose/workspace/aws
printf "Hello ENJYRA\n" > compose/workspace/aws/enjyra-demo.txtmkdir -p compose/workspace/aws
printf "Hello ENJYRA\n" > compose/workspace/aws/enjyra-demo.txtNew-Item -ItemType Directory -Force -Path "compose\workspace\aws" | Out-Null
Set-Content -Path "compose\workspace\aws\enjyra-demo.txt" -Value "Hello ENJYRA"Before You Run
- Your terminal is open in enjyra-cloud-labs.
Why You're Running This
Creates the workspace folder if needed, then writes a one-line text file for this lesson.
Command Breakdown
mkdir -p / New-Item Directory- Creates the requested folder and any missing parent folders without failing when it already exists.
printf / Set-Content- Writes the specified text into the target file, replacing its previous contents when it already exists.
Expected Result
compose/workspace/aws/enjyra-demo.txt now exists in the lesson workspace and is ready for the next instruction.What Changed
Beforecompose/workspace/aws/enjyra-demo.txt may not exist yet, or may still contain its previous content.
Aftercompose/workspace/aws/enjyra-demo.txt now exists in the lesson workspace and is ready for the next instruction.
Verify It
macOSls -l compose/workspace/aws/enjyra-demo.txt
Linuxls -l compose/workspace/aws/enjyra-demo.txt
Windows PowerShellGet-Item "compose\workspace\aws\enjyra-demo.txt"
Confirm the file exists at the expected path.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
What this command does Creates the workspace folder if needed, then writes a one-line text file for this lesson.
Console path: Bucket detail → Objects tab → Upload object → choose enjyra-demo.txt.
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws cli s3 cp /workspace/files/enjyra-demo.txt s3://enjyra-documents-dev/./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws cli s3 cp /workspace/files/enjyra-demo.txt s3://enjyra-documents-dev/.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws cli s3 cp /workspace/files/enjyra-demo.txt s3://enjyra-documents-dev/Before You Run
- Your terminal is open in the current lesson workspace.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Uploads the same file directly through the AWS CLI.
Command Breakdown
ENJYRA launcher · AWS · cli- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its cli action.
Expected Result
upload: ... to s3://enjyra-documents-dev/enjyra-demo.txtWhat Changed
BeforeThe requested local resource or updated object state is not yet visible in the emulator.
AfterThe emulator now contains the requested resource or updated object state.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
Confirm the lab is healthy, then refresh the matching ENJYRA console to see the resource.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
- Docker daemon not running → start Docker Desktop or Docker Engine, then retry.
What this command does Uploads the same file directly through the AWS CLI.
upload: ... to s3://enjyra-documents-dev/enjyra-demo.txtWhichever path you use, refresh the other: the CLI and the console Objects tab both read the same LocalStack bucket.
enjyra-demo.txt now exists inside enjyra-documents-dev in LocalStack.
Upload the same object name again with different content, then open its version history from the Objects tab.
With versioning on, overwriting never destroys the old copy — S3 keeps every version. This is the recovery mechanism the rest of this lesson relies on.
printf "Hello ENJYRA v2\n" > compose/workspace/aws/enjyra-demo.txt
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws cli s3 cp /workspace/files/enjyra-demo.txt s3://enjyra-documents-dev/printf "Hello ENJYRA v2\n" > compose/workspace/aws/enjyra-demo.txt
./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws cli s3 cp /workspace/files/enjyra-demo.txt s3://enjyra-documents-dev/Set-Content -Path "compose\workspace\aws\enjyra-demo.txt" -Value "Hello ENJYRA v2"
.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws cli s3 cp /workspace/files/enjyra-demo.txt s3://enjyra-documents-dev/Before You Run
- Your terminal is open in the current lesson workspace.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Replaces the file's contents locally, then uploads it to the same key, creating a new version.
Command Breakdown
printf / Set-Content- Writes the specified text into the target file, replacing its previous contents when it already exists.
ENJYRA launcher · AWS · cli- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its cli action.
Expected Result
upload: ... to s3://enjyra-documents-dev/enjyra-demo.txtWhat Changed
Beforecompose/workspace/aws/enjyra-demo.txt may not exist yet, or may still contain its previous content.
Aftercompose/workspace/aws/enjyra-demo.txt now exists in the lesson workspace and is ready for the next instruction.
Verify It
macOSls -l compose/workspace/aws/enjyra-demo.txt
Linuxls -l compose/workspace/aws/enjyra-demo.txt
Windows PowerShellGet-Item "compose\workspace\aws\enjyra-demo.txt"
Confirm the file exists at the expected path.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
- Docker daemon not running → start Docker Desktop or Docker Engine, then retry.
What this command does Replaces the file's contents locally, then uploads it to the same key, creating a new version.
upload: ... to s3://enjyra-documents-dev/enjyra-demo.txtConsole path: Bucket detail → Versions tab. You can also use the Versions button beside enjyra-demo.txt in the Objects tab.
The Versions tab is empty until you upload an object. After this overwrite you will see two entries: the newest marked CURRENT, and the older one marked NON-CURRENT with a Restore button. Both are real LocalStack version IDs, timestamps, sizes, and checksums — read live with ListObjectVersions, not invented by the console.
A second, newer version of enjyra-demo.txt now exists. The first version is still stored, just no longer current.
Delete enjyra-demo.txt from the Objects tab, then find it again under Show deleted objects.
In a versioned bucket, deleting an object does not erase it — S3 adds a delete marker on top, which makes the object disappear from normal listings while every version stays recoverable underneath.
Console path: Objects tab → Delete next to enjyra-demo.txt → confirm.
The object is now gone from the list — this is expected, not a bug. Click Show deleted objects above the table: enjyra-demo.txt reappears there, tagged DELETED — recoverable.
A new delete marker becomes the current version of enjyra-demo.txt. The object vanishes from the Objects tab; its history does not.
From the deleted object's Versions panel, click Restore on the non-current version.
There is no 'undo delete' in S3 — restoring works by copying an older version back on top as the new current version, which is exactly what the Restore button does.
Console path: Versions tab → find enjyra-demo.txt → Restore on a NON-CURRENT entry that is not a delete marker. The older Show deleted objects → Versions route remains available too.
Refresh the Objects tab: enjyra-demo.txt is back. Open Versions again — the delete marker is still listed in the history, exactly as real S3 keeps it, it just isn’t the current version anymore.
LocalStack performs a real CopyObject; enjyra-demo.txt is live again in the Objects tab with its full version history intact, including the delete marker you just created.
On the Permissions tab, uncheck Block public ACLs, save, observe the warning, then re-check it and save again.
Seeing a real ⚠ SECURITY WARNING appear — and clear — for a bucket you configured teaches the consequence of the setting far better than reading about it.
Console path: Bucket detail → Permissions tab → uncheck Block public ACLs → Save changes.
Expect: ⚠ SECURITY WARNING — This bucket currently allows public exposure. This is the same evaluation the wizard used to give you 5 PASS · 0 WARNING earlier — now it will show a WARNING.
Now re-check Block public ACLs and Save changes again. The warning disappears, confirming the fix — not just the click — took effect in LocalStack.
The bucket's real Public Access Block configuration in LocalStack is changed, then changed back.
Explore the new access and lifecycle controls
The same Permissions page now includes a real LocalStack-backed Bucket Policy editor plus a clearly labelled learning evaluator. The Presigned URL tab generates a working temporary SigV4 URL, while the Lifecycle tab persists a real lifecycle configuration. LocalStack does not reliably prove private-object enforcement or wait out long retention periods, so those limits remain explicitly labelled as simulation or real-cloud-only behaviour.
Open Activity Log from the sidebar and find every event you just caused.
The Activity Log is derived from real before/after LocalStack state, not a separate record the console could get out of sync with.
Confirm the log contains: Bucket created, Region selected, Versioning enabled, Object uploaded, Object overwritten, Delete marker created, and Object restored. Permission changes appear too. If you also ran a CLI command, its state change appears the same way — the console cannot tell CLI actions and UI actions apart, which is the point.
Nothing — this only reads the log.
Cleanup removes versions too
Reset Lab (and the bucket-list Delete button) now purge every stored version and delete marker before removing the bucket itself — not just the current object. Earlier in this lesson’s development, a versioned bucket could survive Reset Lab because old versions were left behind; that gap is fixed, and Reset Lab always leaves this lesson’s LocalStack completely empty.
Break
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws cli s3 mb s3://INVALID_NAME./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws cli s3 mb s3://INVALID_NAME.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws cli s3 mb s3://INVALID_NAMEBefore You Run
- Your terminal is open in Current lesson workspace.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
This creates or updates the resource in the same local emulator displayed by the ENJYRA console.
Command Breakdown
ENJYRA launcher · AWS · cli- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its cli action.
Expected Result
InvalidBucketName
A deliberately invalid bucket name produces an understandable local S3 error.What Changed
BeforeThe requested local resource or updated object state is not yet visible in the emulator.
AfterThe emulator now contains the requested resource or updated object state.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
Confirm the lab is healthy, then refresh the matching ENJYRA console to see the resource.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
- Docker daemon not running → start Docker Desktop or Docker Engine, then retry.
InvalidBucketNameIf it fails
command not found → verify the required tool is installed and reopen the terminal.No such file or directory → check your current folder with pwd or Get-Location.Permission denied → confirm the lesson workspace is writable.Debug
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws logs./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws logs.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws logsBefore You Run
- Your terminal is open in the current lesson workspace.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Checks status, then prints logs for only the AWS local lab. It does not prune global Docker resources.
Command Breakdown
ENJYRA launcher · AWS · status- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its status action.
ENJYRA launcher · AWS · logs- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its logs action.
Expected Result
No persistent state changed; the command printed evidence you can compare with the expected result.What Changed
BeforeThe current state has not yet been checked.
AfterNo persistent state changed; the command printed evidence you can compare with the expected result.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws logs
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws logs
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws logs
Run the command and compare its output with the Expected Result block.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
- Docker daemon not running → start Docker Desktop or Docker Engine, then retry.
What this command does Checks status, then prints logs for only the AWS local lab. It does not prune global Docker resources.
Improve
Add a second object with its own tag context, entirely through the CLI this time, then confirm the console Objects tab agrees without a manual reload.
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws cli s3api put-object --bucket enjyra-documents-dev --key notes/readme.txt --body /workspace/files/enjyra-demo.txt./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws cli s3api put-object --bucket enjyra-documents-dev --key notes/readme.txt --body /workspace/files/enjyra-demo.txt.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws cli s3api put-object --bucket enjyra-documents-dev --key notes/readme.txt --body /workspace/files/enjyra-demo.txtBefore You Run
- Your terminal is open in Current lesson workspace.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
This creates or updates the resource in the same local emulator displayed by the ENJYRA console.
Command Breakdown
ENJYRA launcher · AWS · cli- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its cli action.
Expected Result
{
"ETag": "..."
}
notes/readme.txt appears in the console's Objects tab within a few seconds — the console polls LocalStack, it does not require a page reload.What Changed
BeforeThe requested local resource or updated object state is not yet visible in the emulator.
AfterThe emulator now contains the requested resource or updated object state.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
Confirm the lab is healthy, then refresh the matching ENJYRA console to see the resource.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
- Docker daemon not running → start Docker Desktop or Docker Engine, then retry.
{
"ETag": "..."
}If it fails
command not found → verify the required tool is installed and reopen the terminal.No such file or directory → check your current folder with pwd or Get-Location.Permission denied → confirm the lesson workspace is writable.Verify
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws cli s3 ls s3://enjyra-documents-dev/ --recursive./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws cli s3 ls s3://enjyra-documents-dev/ --recursive.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws cli s3 ls s3://enjyra-documents-dev/ --recursiveBefore You Run
- Your terminal is open in the current lesson workspace.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Lists both objects so you can compare the CLI output with the console's Objects tab and object count.
Command Breakdown
ENJYRA launcher · AWS · cli- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its cli action.
Expected Result
No persistent state changed; the command printed evidence you can compare with the expected result.What Changed
BeforeThe current state has not yet been checked.
AfterNo persistent state changed; the command printed evidence you can compare with the expected result.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws cli s3 ls s3://enjyra-documents-dev/ --recursive
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws cli s3 ls s3://enjyra-documents-dev/ --recursive
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws cli s3 ls s3://enjyra-documents-dev/ --recursive
Run the command and compare its output with the Expected Result block.
If It Fails
- No such file or directory → verify the current folder and the path spelling.
- Permission denied → work inside your own lesson folder and confirm it is writable.
- Docker daemon not running → start Docker Desktop or Docker Engine, then retry.
What this command does Lists both objects so you can compare the CLI output with the console's Objects tab and object count.
Challenge
Delete both objects, then delete the bucket, then refresh the console and confirm the resource count returns to zero. The Reset lab button performs the same lesson-scoped cleanup safely.
Ship
LOCAL_EMULATOR_PASS when LocalStack is healthy, the bucket and object appear in the console, the deliberate failure is clear, and cleanup is verified.
Next Step
Return to the bonus lab list. Each cloud lab is optional and independent of the 9 / 9 core completion.
Prepare Your Machine
Open only the setup step you need. Complete every verification before moving into Build.
This lesson needs
Install Docker Desktop / Engine (full walkthrough)
- Check your Mac's chip architecture (Apple Silicon vs Intel) before downloading.COMMAND
uname -mExpected output"arm64" (Apple Silicon) or "x86_64" (Intel)If error
If nothing prints, open Terminal from Applications → Utilities and try again.
- Download Docker Desktop for your chip from docs.docker.com/desktop/setup/install/mac-install and open the downloaded
.dmg, then drag Docker to Applications. - Launch Docker Desktop from Applications and wait for the whale icon in the menu bar to show "Docker Desktop is running".
- Verify the CLI is installed.COMMAND
docker --versionExpected outputDocker version 2x.x.x, build xxxxxxxIf error
If “command not found”, reopen Terminal after installing so your PATH refreshes, or reinstall Docker Desktop.
- Verify the engine is actually running (not just installed).COMMAND
docker infoExpected outputA block of server information, including Server Version and ContainersIf error
If it says “Cannot connect to the Docker daemon”, open Docker Desktop and wait for the whale icon to stop animating.
- Run a real test container end-to-end.COMMAND
docker run --rm hello-worldExpected output"Hello from Docker!" followed by an explanation of what happenedIf error
If the image can't be pulled, check your internet connection; this is the only step that needs it.
- Download Docker Desktop for Windows from docs.docker.com/desktop/setup/install/windows-install and run the installer. Docker Desktop will guide you through any compatible Windows backend requirement; this lesson does not require a WSL terminal.
- If the installer asks you to enable a Windows feature or restart, follow that prompt and finish the Docker Desktop setup before continuing.
- Start Docker Desktop from the Start menu and wait for the whale icon in the system tray to report "Docker Desktop is running".
- Verify the CLI, using PowerShell or the built-in VS Code terminal (not a Bash-syntax terminal).COMMAND
docker --versionExpected outputDocker version 2x.x.x, build xxxxxxxIf error
If “not recognized”, close and reopen your terminal so PATH changes take effect.
- Verify the engine is running.COMMAND
docker infoExpected outputA block of server information, including Server Version and ContainersIf error
If it can't connect to the daemon, open Docker Desktop, wait until it reports Running, and review Docker Desktop's own Troubleshoot panel.
- Run a real test container.COMMAND
docker run --rm hello-worldExpected output"Hello from Docker!" followed by an explanation of what happenedIf error
If the pull hangs, check your internet connection and that Docker Desktop shows as running, not starting.
- Prefer Docker Engine (not Docker Desktop) on Linux. Follow the official instructions for your distribution at docs.docker.com/engine/install — for Ubuntu specifically, use docs.docker.com/engine/install/ubuntu.
- Start and enable the Docker service.COMMAND
sudo systemctl enable --now dockerExpected outputNo output on successIf error
If systemctl isn't available, your distro may use a different init system — check its Docker Engine install page.
- Confirm the service is active.COMMAND
systemctl status dockerExpected outputActive: active (running)If error
If it shows “inactive” or “failed”, re-run the enable command above and check the install steps were completed.
- Verify the CLI.COMMAND
docker --versionExpected outputDocker version 2x.x.x, build xxxxxxxIf error
If “command not found”, the Engine install likely didn't finish — re-check the distro-specific install page.
- Verify the engine responds.COMMAND
docker infoExpected outputA block of server information, including Server Version and ContainersIf error
A permission-denied error here usually means your user isn't in the docker group yet — see the note below rather than running commands as root.
- Run a real test container.COMMAND
docker run --rm hello-worldExpected output"Hello from Docker!" followed by an explanation of what happenedIf error
If you see a permission error, add your user to the docker group yourself (sudo usermod -aG docker $USER, then log out and back in) — we won't do this for you automatically.
Note: running Docker commands as root or with a global chmod on the socket is not recommended. Add your user to the docker group instead, as shown above.
Before You Run
Install Docker Desktop on macOS or Windows, or Docker Engine/Desktop using the official instructions for your Linux distribution. Start Docker and open Terminal or native Windows PowerShell.
Why Do We Need Docker?
The ENJYRA AWS, Azure, and GCP labs run locally inside Docker containers. No real AWS, Azure, or GCP account is required.
Command Breakdown
docker --version- Confirms the Docker command-line client is installed.
docker info- Asks the Docker Engine for server information, proving it is running and reachable.
docker run --rm hello-world- Runs a small official test container end to end and removes it when finished.
Expected Result
Docker version 2x.x.x
docker info: server details
Hello from Docker!What Changed
BeforeDocker is not yet confirmed.
AfterDocker CLI and Docker Engine are available to launch the local lab.
Verify It
macOSdocker --version
docker info
Linuxdocker --version
docker info
Windows PowerShelldocker --version
docker info
If It Fails
- Open Docker Desktop or start Docker Engine, wait until it reports running, and retry.
- Open a new terminal after installation so PATH changes are loaded.
- On Linux, follow the official instructions for your distribution rather than assuming Ubuntu commands apply.
Install this once — later lessons that need Python will only ask you to verify it.
Official download: python.org/downloads
- Open python.org/downloads and download the current Python 3 installer for macOS, if Python 3 isn't already available.
- Run the installer, then open a new Terminal window (existing ones won't see the update).
- Verify.COMMAND
python3 --versionExpected outputPython 3.x.xIf error
If “command not found”, reopen Terminal, or check the installer actually completed.
- Open python.org/downloads and download Python 3 for Windows.
- Run the installer. When offered, enable "Add Python to PATH" — this step is easy to miss.
- Open a new PowerShell window and verify.COMMAND
py --versionExpected outputPython 3.x.xIf error
If py isn't found, try python --version instead — installers vary in which launcher they register.
- Many Linux distributions already include Python 3 — check first.COMMAND
python3 --versionExpected outputPython 3.x.xIf error
If not found, install Python 3 through your distribution's own package manager or documentation — this varies by distro, so there's no single command here.
- If it's missing, see python.org/downloads for the official source and platform-specific guidance.
Before You Run
Complete the installation instructions for your operating system, then open a new Terminal or native Windows PowerShell window.
Why You're Running This
Python is used by ENJYRA learning utilities, scripts, and exercises.
Command Breakdown
python3 --version / py --version- Asks the installed Python launcher to print its version without running a program.
Expected Result
Python 3.x.xWhat Changed
BeforePython 3 is not yet confirmed on this machine.
AfterA supported Python 3 launcher is available in Terminal or native Windows PowerShell.
Verify It
macOSpython3 --version
Linuxpython3 --version
Windows PowerShellpy --version (fallback: python --version)
If It Fails
Open a new terminal after installation. On Windows, confirm “Add Python to PATH” was selected, then try py or python.
Official download: git-scm.com/downloads
- Visit git-scm.com/downloads and follow the macOS installer, or check whether it's already installed.
- Verify.COMMAND
git --versionExpected outputgit version 2.x.xIf error
macOS may prompt to install Xcode Command Line Tools the first time you run git — accept that prompt, then try again.
- Download Git for Windows from git-scm.com/install/windows and run the installer, keeping the default options.
- Open a new PowerShell window and verify.COMMAND
git --versionExpected outputgit version 2.x.xIf error
Reopen PowerShell so it picks up the updated PATH.
- Git is often preinstalled; check first with the command below. If missing, see git-scm.com/downloads for your distribution's official install method — this is not the same command on every distro.
- Verify.COMMAND
git --versionExpected outputgit version 2.x.xIf error
If git is missing, install it using your distribution's official package manager instructions, then open a new terminal.
Before You Run
Complete the installation instructions for your operating system, then open a new Terminal or native Windows PowerShell window.
Why You're Running This
Git is needed to download the official ENJYRA Cloud Labs repository and work with version-controlled lesson files.
Command Breakdown
git --version- Asks Git to print its installed version without changing any files.
Expected Result
git version 2.x.xWhat Changed
BeforeGit is not yet confirmed on this machine.
AfterGit is available to clone https://github.com/gudshuis/enjyra-cloud-labs.
Verify It
macOSgit --version
Linuxgit --version
Windows PowerShellgit --version
If It Fails
Open a new terminal after installation so the updated PATH is loaded, then retry.
Official download: code.visualstudio.com/download
- Download from code.visualstudio.com/download, unzip, and drag VS Code to Applications.
- Open VS Code once to confirm it launches.
- Optional — verify the
codeshell command, if you want it (not required):COMMANDcode --versionExpected outputA version number, e.g. 1.9x.xIf error
The code command is often not installed by default. In VS Code, open the Command Palette and run “Shell Command: Install 'code' command in PATH” — or just confirm VS Code opens instead, below.
- Download from code.visualstudio.com/download and run the installer.
- Open VS Code once to confirm it launches.
- Optional — verify the
codeshell command:COMMANDcode --versionExpected outputA version number, e.g. 1.9x.xIf error
The Windows installer usually adds this automatically; if not, confirm VS Code opens instead, below.
- Download the package for your distribution from code.visualstudio.com/download and install it using your distribution's normal method.
- Open VS Code once to confirm it launches.
- Optional — verify the
codeshell command:COMMANDcode --versionExpected outputA version number, e.g. 1.9x.xIf error
The code command may not be linked automatically on Linux; confirming VS Code opens is enough for this lesson.
Before You Run
Complete the installation instructions for your operating system, then open a new Terminal or native Windows PowerShell window.
Why You're Running This
Visual Studio Code is used to inspect and edit learner files when a lesson requires it.
Command Breakdown
code --version (optional)- Checks the optional VS Code shell command. Readiness depends on the app opening, not on this command being installed.
Expected Result
VS Code opens successfully; code --version may also print a version number.What Changed
BeforeVisual Studio Code is not yet confirmed on this machine.
AfterVisual Studio Code opens and can be used for lesson files; the code command remains optional.
Verify It
macOSOpen Visual Studio Code
LinuxOpen Visual Studio Code
Windows PowerShellOpen Visual Studio Code
If It Fails
Launch VS Code from Applications or the Start menu. Do not block readiness only because code is missing from PATH.
Run each command in your own terminal. This page cannot run commands on your machine, so tick a box only after you see the expected result.
docker --versiondocker --versiondocker --versionBefore You Run
- Your terminal is open in Any terminal folder.
- Docker Desktop or Docker Engine is running.
Why You're Running This
Confirms the Docker command-line client is installed.
Command Breakdown
docker- Runs the docker tool with the shown arguments to complete this lesson step.
Expected Result
A Docker version is printedWhat Changed
BeforeThe action shown by this card has not yet been completed or verified.
AfterThe command has completed and the next lesson step has the state it needs.
Verify It
macOSInspect the command output shown above.
LinuxInspect the command output shown above.
Windows PowerShellInspect the command output shown above.
Continue only when the observed result matches the Expected Result block.
If It Fails
- Confirm Docker CLI is installed or running, then retry the command in a new terminal.
docker infodocker infodocker infoBefore You Run
- Your terminal is open in Any terminal folder.
- Docker Desktop or Docker Engine is running.
Why You're Running This
Confirms Docker is running before the local emulator starts.
Command Breakdown
docker- Runs the docker tool with the shown arguments to complete this lesson step.
Expected Result
Docker server information is returnedWhat Changed
BeforeThe action shown by this card has not yet been completed or verified.
AfterThe command has completed and the next lesson step has the state it needs.
Verify It
macOSInspect the command output shown above.
LinuxInspect the command output shown above.
Windows PowerShellInspect the command output shown above.
Continue only when the observed result matches the Expected Result block.
If It Fails
- Confirm Docker Engine is installed or running, then retry the command in a new terminal.
python3 --versionpython3 --versionpy --version
# If py is unavailable:
python --versionBefore You Run
- Your terminal is open in Any terminal folder.
- Python 3 is installed; activate .venv first when the lesson has already created it.
Why You're Running This
Confirms Python 3 is installed. Windows PowerShell uses py --version, with python --version as a fallback.
Command Breakdown
python- Runs the selected Python module or script with the supplied arguments.
py- Runs the py tool with the shown arguments to complete this lesson step.
#- Runs the # tool with the shown arguments to complete this lesson step.
Expected Result
A supported Python 3.x version is printedWhat Changed
BeforeThe saved program has not yet been executed for this verification step.
AfterThe program ran and produced output or started the local process described by the lesson.
Verify It
macOSInspect the command output shown above.
LinuxInspect the command output shown above.
Windows PowerShellInspect the command output shown above.
Continue only when the observed result matches the Expected Result block.
If It Fails
- Confirm Python is installed or running, then retry the command in a new terminal.
git --versiongit --versiongit --versionBefore You Run
- Your terminal is open in Any terminal folder.
- Git is installed; cloning also requires an internet connection.
Why You're Running This
Confirms Git is available to download the public ENJYRA Cloud Labs repository.
Command Breakdown
git- Runs the git tool with the shown arguments to complete this lesson step.
Expected Result
A Git version is printedWhat Changed
BeforeThe action shown by this card has not yet been completed or verified.
AfterThe command has completed and the next lesson step has the state it needs.
Verify It
macOSInspect the command output shown above.
LinuxInspect the command output shown above.
Windows PowerShellInspect the command output shown above.
Continue only when the observed result matches the Expected Result block.
If It Fails
- Confirm Git is installed or running, then retry the command in a new terminal.
Download the official public ENJYRA Cloud Labs repository. It contains the launchers, Compose files, and verification scripts used by B01, B02, and B03. Students do not manually create these files.
Already downloaded it? Reuse the same folder, open a terminal inside it, and continue to verification.
git clone https://github.com/gudshuis/enjyra-cloud-labs.git
cd enjyra-cloud-labsgit clone https://github.com/gudshuis/enjyra-cloud-labs.git
cd enjyra-cloud-labsgit clone https://github.com/gudshuis/enjyra-cloud-labs.git
Set-Location enjyra-cloud-labsBefore You Run
- Your terminal is open in the current lesson workspace.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
- Git is installed; cloning also requires an internet connection.
Why You're Running This
Downloads the official ENJYRA Cloud Labs repository and moves your terminal into its folder.
Command Breakdown
git clone- Downloads a complete working copy of the official public ENJYRA Cloud Labs repository.
https://github.com/gudshuis/enjyra-cloud-labs.git- Identifies the official public repository to download.
cd / Set-Location- Moves macOS/Linux Terminal or native Windows PowerShell into the downloaded lab folder.
Expected Result
enjyra-cloud-labs/
├── scripts/
├── compose/
├── verify/
└── VERSIONWhat Changed
BeforeThe repository folder is not present in this workspace.
AfterA local repository folder exists and the terminal has moved into it when the command includes cd / Set-Location.
Verify It
macOSgit -C enjyra-cloud-labs status --short
Linuxgit -C enjyra-cloud-labs status --short
Windows PowerShellgit -C enjyra-cloud-labs status --short
No output means the downloaded working tree is clean.
If It Fails
- If Git is not installed, complete the Git setup above. If cloning reports a network error, confirm your internet connection and retry.
What this command does Downloads the official ENJYRA Cloud Labs repository and moves your terminal into its folder.
enjyra-cloud-labs/
├── scripts/
├── compose/
├── verify/
└── VERSIONIf it fails
If Git is not installed, complete the Git setup above. If cloning reports a network error, confirm your internet connection and retry.
Run the verifier for your operating system before starting a local cloud lab. It checks required files, checksums and integrity, Docker, Docker Compose, Git, Python, and launcher availability.
./verify/verify-enjyra-lab-macos.sh./verify/verify-enjyra-lab-linux.sh.\verify\verify-enjyra-lab.ps1Before You Run
- Your terminal is open in enjyra-cloud-labs.
Why You're Running This
Reads the downloaded files and local tool state without starting AWS, Azure, or GCP.
Command Breakdown
./verify/verify-enjyra-lab-macos.sh- Runs the macOS integrity and prerequisite verifier from the repository.
./verify/verify-enjyra-lab-linux.sh- Runs the Linux integrity and prerequisite verifier from the repository.
.\verify\verify-enjyra-lab.ps1- Runs the native Windows PowerShell verifier; WSL is not required.
Expected Result
PASS: All files match checksums.txt
Integrity: VERIFIEDWhat Changed
BeforeThe action shown by this card has not yet been completed or verified.
AfterThe command has completed and the next lesson step has the state it needs.
Verify It
macOSInspect the command output shown above.
LinuxInspect the command output shown above.
Windows PowerShellInspect the command output shown above.
Continue only when the observed result matches the Expected Result block.
If It Fails
- Do not start the lab after a checksum failure. Replace only the incomplete enjyra-cloud-labs folder with a fresh clone, then run the verifier again. If Docker fails, start Docker Desktop or Docker Engine first.
What this command does Reads the downloaded files and local tool state without starting AWS, Azure, or GCP.
PASS: All files match checksums.txt
Integrity: VERIFIEDIf it fails
Do not start the lab after a checksum failure. Replace only the incomplete enjyra-cloud-labs folder with a fresh clone, then run the verifier again. If Docker fails, start Docker Desktop or Docker Engine first.
- Docker CLI verified
- Docker Engine running
- Python verified
- Git verified
- VS Code ready
- ENJYRA Cloud Labs downloaded
- ENJYRA Cloud Labs integrity verified
Need help with a prerequisite?
Docker is not running? Open Docker Desktop or start Docker Engine, then run docker info again.
The repository will not clone? Confirm Git is installed and your internet connection can reach github.com, then retry.
Integrity verification failed? Do not start the lab. Remove only the incomplete enjyra-cloud-labs folder, clone the official repository again, and rerun the verifier.
A lab port is already in use? Stop the process using the lesson port; do not prune unrelated Docker resources.
The console stays on STARTING? Run the lesson status command, then inspect only this lab with the lesson logs command.
Launch the ENJYRA Lab
Start only after the prerequisite checks above are complete.
One start command runs the lesson-scoped emulator and localhost console. The browser detects when it is ready.
ENJYRA Lab · b01-s3-v6.0.0
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws start./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws start.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws startBefore You Run
- Your terminal is open in ~/enjyra-cloud-labs.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Starts this lesson’s emulator and ENJYRA localhost console as a lesson-scoped Docker Compose project.
Command Breakdown
ENJYRA launcher · AWS · start- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its start action.
Expected Result
The emulator and ENJYRA console report healthy.What Changed
BeforeThe requested local service or lab containers are not yet confirmed running.
AfterThe local service or lab containers are running in the background and can be verified.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
Both the emulator and ENJYRA console should report healthy.
If It Fails
- Check the current folder, confirm Docker is running when required, and verify the image or script name before retrying.
What this command does Starts this lesson’s emulator and ENJYRA localhost console as a lesson-scoped Docker Compose project.
The emulator and ENJYRA console report healthy.If it fails
Check the current folder, confirm Docker is running when required, and verify the image or script name before retrying.
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws statusBefore You Run
- Your terminal is open in ~/enjyra-cloud-labs.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Checks that both the local emulator and ENJYRA console are healthy before you use the browser interface.
Command Breakdown
ENJYRA launcher · AWS · status- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its status action.
Expected Result
The lab reports READY and its services are healthy.What Changed
BeforeThe current state has not yet been checked.
AfterNo persistent state changed; the command printed evidence you can compare with the expected result.
Verify It
macOS./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws status
Linux./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws status
Windows PowerShell.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws status
Run the command and compare its output with the Expected Result block.
If It Fails
- Confirm the start command completed first, then compare the image, container, port, or script name exactly with this lesson.
What this command does Checks that both the local emulator and ENJYRA console are healthy before you use the browser interface.
The lab reports READY and its services are healthy.If it fails
Confirm the start command completed first, then compare the image, container, port, or script name exactly with this lesson.
Reset My Lab
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws reset./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws reset.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws resetBefore You Run
- Your terminal is open in ~/enjyra-cloud-labs.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Returns this lesson’s local runtime or resources to a known starting state without touching unrelated projects.
Command Breakdown
ENJYRA launcher · AWS · reset- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its reset action.
Expected Result
This lesson’s runtime state is reset or the named lesson container is removed.What Changed
BeforeThe lesson service or local lab may still be running.
AfterThe requested lesson service has been stopped or its lesson-scoped state reset.
Verify It
macOSInspect the command output shown above.
LinuxInspect the command output shown above.
Windows PowerShellInspect the command output shown above.
Continue only when the observed result matches the Expected Result block.
If It Fails
- Check Docker is running and make sure you are using this lesson’s exact container or launcher name.
What this command does Returns this lesson’s local runtime or resources to a known starting state without touching unrelated projects.
This lesson’s runtime state is reset or the named lesson container is removed.If it fails
Check Docker is running and make sure you are using this lesson’s exact container or launcher name.
Clean up the lab
./scripts/cloud-labs/enjyra-cloud-lab-macos.sh aws stop./scripts/cloud-labs/enjyra-cloud-lab-linux.sh aws stop.\scripts\cloud-labs\enjyra-cloud-lab.ps1 aws stopBefore You Run
- Your terminal is open in ~/enjyra-cloud-labs.
- Docker Desktop or Docker Engine is running.
- You have cloned enjyra-cloud-labs and are working inside that repository.
Why You're Running This
Stops or removes only this lesson’s local runtime so it does not keep using machine resources.
Command Breakdown
ENJYRA launcher · AWS · stop- Uses the operating-system-specific ENJYRA launcher, selects the AWS local lab, and performs its stop action.
Expected Result
The lesson-scoped service or container is no longer running.What Changed
BeforeThe lesson service or local lab may still be running.
AfterThe requested lesson service has been stopped or its lesson-scoped state reset.
Verify It
macOSInspect the command output shown above.
LinuxInspect the command output shown above.
Windows PowerShellInspect the command output shown above.
Continue only when the observed result matches the Expected Result block.
If It Fails
- Inspect this lesson’s status first, then retry with the exact launcher or container name shown here.
What this command does Stops or removes only this lesson’s local runtime so it does not keep using machine resources.
The lesson-scoped service or container is no longer running.If it fails
Inspect this lesson’s status first, then retry with the exact launcher or container name shown here.
Prove What You Learned
This lesson contains 4 focused questions. You answered 2 before the build; complete the remaining 2 now.