CCHQ ARTICLE GUIDE / HANDS-ON LABS
Practical learning, clear decisions, real-world context
An easy-to-navigate field guide with key takeaways, applied checks, FAQs, and official references. Approximately 7 minutes of reading.
Hands-on AWS labs are most valuable when they build a skill you can explain, validate, and safely repeat. A low-cost learning plan does not need a sprawling three-tier production clone.
It needs a controlled account, scoped permissions, small workloads, meaningful security checks, documented costs, and a reliable teardown process.
This roadmap progresses from account safety and IAM through private networking, infrastructure as code, application deployment, observability, and incident-style troubleshooting. Each lab includes an outcome and an objective test.
Real AWS charges may occur even in a small experiment, and AWS Budgets alerts are notifications rather than hard spending caps. Review current prices, regions, and service eligibility before starting.
The examples are lab designs for your own execution, not claims that an AWS environment has already been deployed or tested.
At a glance
The main topics you’ll work through:
- Before lab one: prepare the learning account
- Lab one: an IAM role with a denied action
- Lab two: a private S3 object workflow
- Lab three: VPC network boundaries on paper and in AWS
In this guide
01 / KEY CONCEPT
Before lab one: prepare the learning account
KEY TAKEAWAY
Begin with an AWS account or designated sandbox that you are authorized to administer.
Protect the root user with current AWS account security guidance, configure federation or an appropriately scoped administrative path, and enable multifactor authentication. Choose a region and record it in your notes.
Set an AWS Budget with notification thresholds suited to your spending limit and confirm that alerts reach you.
Understand that delayed usage reporting can mean a notification arrives after charges have accrued, so budget alerts are not an absolute financial stop.
Make an inventory sheet with the lab name, intended resources, region, start date, expected costs, and cleanup checklist. Learn how to review Cost Explorer or the account billing interface where available.
Avoid service demonstrations that require NAT gateways, always-on managed databases, large clusters, or expensive data transfer unless you deliberately budget for them.
Apply a consistent resource tag when supported and never publish account identifiers or access credentials in a public README.
02 / PRACTICAL APPLICATION
Lab one: an IAM role with a denied action
KEY TAKEAWAY
The first useful security lab is to understand who is making a request.
Use AWS STS identity inspection to identify the active principal. Create a narrowly scoped role according to an approved trust relationship and grant permission to a harmless test resource.
Use an isolated S3 bucket or another low-risk target and verify one allowed action. Then try a harmless unauthorized action that should fail. The exercise is about reading policy behavior, not exploiting anything.
Document the principal ARN, trust path, policy action, resource scope, and expected outcomes. Compare the allowed and denied requests and inspect relevant audit information where configured.
If both requests succeed, tighten the policy; if both fail, investigate the assumed identity, conditions, and resource permissions. Do not attach AdministratorAccess to ‘solve’ the lab.
Destroy the temporary identities and objects when finished, while retaining sanitized notes describing what you learned.
03 / KEY CONCEPT
Lab two: a private S3 object workflow
KEY TAKEAWAY
Create a general purpose bucket for non-sensitive test objects and verify Block Public Access and expected ownership settings.
Upload a test document and configure the exact role needed to read it. Review encryption defaults and decide whether versioning is useful for the learning objective. If you enable versioning, change the object once and practice retrieving an earlier version.
Be mindful that old versions consume storage until removed or expired.
Run three validations: the expected role can read the approved key, a different identity cannot read it, and no anonymous public access has accidentally been introduced. Record how the bucket and identity policies interact.
If you configure logging, identify whether the events you need are management or data events and whether there may be charges. Tear down object versions and the bucket only after confirming they are no longer needed.
This exercise builds data protection, permissions, and lifecycle knowledge in one manageable environment.
04 / PRACTICAL APPLICATION
Lab three: VPC network boundaries on paper and in AWS
KEY TAKEAWAY
Draw a VPC with a public entry path and a private application or database tier.
Label route tables, subnets, security groups, DNS resolution, and any gateways or endpoints. Before deploying, explain how an external client reaches the public service and why it cannot connect directly to the private dependency.
In AWS, implement only the components required for one narrow connectivity test. A full NAT setup may be unnecessary and can create continuing charges.
Validate the allowed path and the blocked path with authorized, non-destructive tests. Trace an unexpected timeout through DNS, routes, security-group rules, and service health.
Keep traffic logs if they serve a clear learning outcome, but remove or expire unnecessary logs after the exercise.
Write an architecture decision about private access to AWS APIs through VPC endpoints versus other paths, including cost and service compatibility.
Teardown includes gateways, endpoints, load balancers, instances, and network resources in the correct dependency order.
05 / KEY CONCEPT
Lab four: Terraform without unsafe state handling
KEY TAKEAWAY
Translate a small portion of a lab into Terraform and commit the configuration to Git.
Use formatting, validation, a reviewed plan, and a deliberate apply. Start with resources that are inexpensive and safe to remove. Keep provider credentials outside source control.
Understand that local state can include sensitive values even if the example itself is harmless. When moving to a team-ready workflow, use a protected backend and locking, and follow the current HashiCorp S3 backend documentation.
Practice reading a plan and identifying create, update, and destroy actions. Modify a safe attribute, run a new plan, and verify the change in AWS. Avoid modifying production or intentionally corrupting important state just to demonstrate recovery.
For a disposable backend, rehearse saving and restoring an object version and carefully inspect the resulting plan before applying.
Finish with a reviewed destroy operation and check the cloud console or API for resources left behind by dependencies outside Terraform’s ownership.
06 / PRACTICAL APPLICATION
Lab five: deploy a small application
KEY TAKEAWAY
Choose a tiny HTTP application or static site whose requests you can understand.
A function, virtual machine, or managed container can work depending on the skill you want to practice. Use an application identity rather than long-lived access keys and collect logs that demonstrate both success and failure.
Set basic health checks and a budget alert before deployment. Avoid placing a database on the public internet for convenience.
Validate the application from the intended client, inspect the active version, and confirm a deliberately invalid request is handled without leaking secrets. Check network rules and IAM permissions rather than trusting a ‘running’ state alone.
If you use a container, document the image and task identity. If you use a managed database, inspect ongoing instance and backup costs carefully. Destroy compute, load balancers, images, logs, and storage according to the project’s retention plan.
Reproducibility matters more than the number of services deployed.
07 / KEY CONCEPT
Lab six: a CI/CD deployment with OIDC
KEY TAKEAWAY
Add a simple GitHub Actions workflow that runs format or build checks on a proposed change and obtains AWS credentials through a narrow OIDC trust relationship for an approved deployment job.
Start with a nonproduction role and protected branch or environment settings. Do not grant production access to pull-request code from unknown sources.
The workflow should demonstrate review, identity federation, and auditable deployment rather than merely pushing files quickly.
Run one approved deployment and verify the resulting resource. Try a harmless action outside the role’s permitted scope and confirm the expected denial. Inspect the assumed identity in the job without printing secret tokens.
Record which repository context is trusted and why. Remove any obsolete access keys only after the new role-based approach is validated. Include a manual approval or equivalent appropriate gate for higher-risk infrastructure changes.
Review GitHub and AWS documentation when implementing trust conditions because token subject behavior depends on branch and environment configuration.
08 / PRACTICAL APPLICATION
Lab seven: monitoring and incident investigation
KEY TAKEAWAY
Design one deliberate, authorized failure.
For example, change a nonproduction app setting so the health endpoint fails, or use a restricted role to generate an expected access denial. Observe logs and metrics and explain how an operator would identify the symptom.
Then restore the desired configuration and record the observed recovery. If using threat detection, verify the feature’s pricing and supported tests before enabling it.
Write a one-page incident note containing the scenario, expected signal, observed evidence, diagnosis, corrective action, and proposed prevention. Include exactly which service logs were enabled; absent logs cannot be treated as proof an event did not occur.
Avoid collecting real credentials or confidential data in the exercise. Connect a clear alert to an owner where possible. This lab illustrates the operational loop: deploy, observe, detect, investigate, and improve.
It also produces material you can discuss confidently in a technical interview.
Before you finish: practical checklist
Turn the main lessons into a short review of your own environment:
- Protect the root user with current AWS account security guidance, configure federation or an appropriately scoped administrative path, and enable multifactor authentication.
- Set an AWS Budget with notification thresholds suited to your spending limit and confirm that alerts reach you.
- Make an inventory sheet with the lab name, intended resources, region, start date, expected costs, and cleanup checklist.
- Avoid service demonstrations that require NAT gateways, always-on managed databases, large clusters, or expensive data transfer unless you deliberately budget for them.
- Use AWS STS identity inspection to identify the active principal.
Frequently asked questions
Can these AWS labs really be free?
Not necessarily. Costs depend on services, account eligibility, region, time, and traffic. Always review current pricing and set alerts before provisioning.
How many services should a beginner use?
Start with a few and learn each dependency deeply. Add a service only when it supports a specific learning outcome.
What is the best evidence of completion?
Accurate diagrams, code, approved configuration, observed allowed and denied tests, a cost review, troubleshooting notes, and a verified teardown.
Official references and next step
AWS IAM best practices · AWS Budgets pricing · Terraform backend guide · GitHub OIDC to AWS
Choose lab one, complete it in an authorized sandbox, and save only sanitized evidence. Then progress to the next lab after the previous architecture, cost, and security boundaries make sense.
Explore Hands-On Labs for focused project guides, and continue updating the runbooks when cloud-service behavior changes.
