Home labs & practical projects

Contain an over-permissioned workload identity

A project to do with your own tools, with guidance on what to create and capture.

Cloud sandbox Suggested time: 2–3 hoursYour own authorised environment

What you could create

A test application role can read more objects than its job requires. You must reduce access while preserving a working audit trail.

Example evidence format

Project evidence map (example)

Permission diff and access test matrixScope and inputs

Audit walkthrough and containment noteDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Permission diff and access test matrix	Show the inputs, scope and decisions behind this record. The required read succeeds and the unrelated read fails.
Audit walkthrough and containment note	Include the evidence supporting your conclusion. The audit record identifies the test identity and attempted operation.

What you'll need

Cloud sandbox

Create synthetic objects in two separate storage locations and a test role. Record the application’s one legitimate read operation before changing permissions.

Project record

Keep the working files for permission diff and access test matrix and record assumptions as you go.

Current reference material

Use the linked provider resources to verify the features, access terms and version relevant to your project.

Access & cost

A cloud account may incur charges. Check current service prices and quotas before creating resources; a budget alert is not a spending cap.

Use a separate learning account or subscription and synthetic data. Keep credentials and administrative endpoints private.

Suggested milestones

1
Plan and investigate
Map the role’s effective permissions and trust relationships.
2
Develop your approach
Replace broad permissions with a scoped policy and capture audit events.
3
Verify and explain
Test the permitted read, a denied read and a response plan for suspected credential exposure.

Evidence worth keeping

Keep clear, organised evidence of your design and any testing you carry out.

1
Permission diff and access test matrix
Show the inputs, scope and decisions behind this record. The required read succeeds and the unrelated read fails.
2
Audit walkthrough and containment note
Include the evidence supporting your conclusion. The audit record identifies the test identity and attempted operation.

Label design proposals and observed results clearly.

Explain your work

Use these prompts to reflect on your decisions and what you learned.

Which part of your permission diff and access test matrix needed the most judgement?
What observation or assumption changed your approach?
What would you improve, and what have you not verified?

Describe this as a personal project in your portfolio.

Useful resources

Use these resources to deepen your understanding and check key details.

Official certification objectives

Review the current provider requirements and relevant subject areas.

AWS Official Practice Question Set (SCS-C02)

Check relevance, platform versions and current access terms.

Explore external learning resources

Find relevant providers and check features, access requirements and costs.

A useful starting point

Create synthetic objects in two separate storage locations and a test role. Record the application’s one legitimate read operation before changing permissions.

What a good result looks like

The required read succeeds and the unrelated read fails.
The audit record identifies the test identity and attempted operation.
The containment plan distinguishes permission repair from credential response.

Finish the project

Remove the exercise resources, including retained storage, snapshots and public IPs. Check the billing view for anything still running.

Independent home-project guidance, not an official vendor lab or a claim of complete exam coverage. Use your own tools and label the work accurately.