Building an AWS Challenge Environment Around the People Using It
How I designed a shared AWS environment for a beginner-friendly student challenge, balanced usability with practical guardrails, and learned that good cloud infrastructure starts with the participant experience.
Building an AWS Challenge Environment Around the People Using It
How I tried to make AWS feel approachable for students who were there to build—not spend the entire challenge fighting setup.
When I started planning the AWS Builder Challenge at Sarvajanik College of Engineering and Technology (SCET), I knew I wanted participants to do more than follow a tutorial. I wanted them to receive a problem, enter an AWS environment, and figure out their own way to build a solution.
That idea sounded simple. Making the environment work for a room full of beginners was a different story.
The challenge was designed for a two-hour session, with teams of two or three students. Participants didn't need previous AWS experience, an existing AWS account, or a preconfigured laptop. We wanted them to focus on solving the problem—not lose half the event creating accounts, configuring permissions, or trying to understand why a service wouldn't let them proceed.
That made the environment itself a major part of the event.
The real requirement wasn't just “make AWS work”
There were several things the environment needed to support:
- A low-friction start: participants should be able to sign in and begin building.
- Room to experiment: teams should be able to choose their own implementation instead of following a prescribed architecture.
- Useful building blocks: the environment needed to support common application workflows.
- Practical guardrails: participants shouldn't be able to change account-level settings or manage IAM identities and policies.
- A manageable event-day experience: the setup had to be understandable, documented, and supportable by a small organizing team.
Those goals sometimes pulled in different directions. More restrictions can improve isolation, but they can also make a beginner's workflow frustrating. More freedom can help participants build, but it increases the importance of clear rules and sensible boundaries.
I had to decide which trade-offs made sense for this particular event.
Choosing a setup participants could actually use
There were plenty of possible ways to approach the environment. The question wasn't simply which architecture looked the most sophisticated on paper. It was which approach would let students get started quickly and spend most of the two hours building.
I chose to give participants individual IAM user credentials, place those users in a shared IAM group, and attach a participant policy defining what they could do. That gave each participant a familiar sign-in path while allowing the permissions to be managed centrally.
The username format was consistent:
Converse-AWS-XXThat naming convention made it easier to map credentials to teams, communicate instructions, and recognize which resources belonged to which participants.
We did not email AWS credentials to everyone who registered. Instead, we planned to distribute them individually at event check-in after confirming attendance. That was a practical event-management decision as much as a security one: registrations don't always turn into attendance, and credentials should go to the people who actually need them.
Building useful permissions without handing over the account
The participant policy was the heart of the setup.
Participants needed enough permissions to build, but they did not need permission to administer the entire AWS account. We allowed the supported workflows for services such as Lambda, S3, DynamoDB, SNS, and EventBridge Scheduler, along with read access to CloudWatch Logs for troubleshooting.
At the same time, we explicitly denied high-risk account and identity-management actions. Participants couldn't create or modify IAM users, roles, or policies, and account-level areas such as billing, budgets, and Organizations were off-limits.
This was not intended to be a universal least-privilege template for every production workload. It was a policy designed around a time-limited student challenge, a known set of services, and the need to keep the environment usable for beginners.
That distinction matters. A policy appropriate for a supervised workshop is not automatically appropriate for a production application or an environment containing sensitive data.
Shared execution roles: fewer setup steps for participants
Lambda and EventBridge Scheduler need execution roles to perform actions on behalf of their services. Asking every beginner team to create and configure its own roles would have added complexity and required IAM permissions we deliberately did not want to grant.
Instead, I prepared two shared roles:
AWS-Competition-Lambda-ExecutionRoleAWS-Competition-Scheduler-ExecutionRole
Participants could select the appropriate existing role when configuring their functions or schedules. The participant policy allowed passing each role only to its intended AWS service.
The Lambda execution role also needed permissions for the runtime operations our test workflows required. During testing, we discovered that a Lambda function could be created successfully but still fail when it tried to write to DynamoDB. The function's creator permissions and the function's runtime permissions were separate things. We updated the shared execution role with the necessary runtime permissions for the supported workflows.
That was a useful reminder: a successful deployment doesn't prove that an application can actually do its job. The code must be tested using the identity it will run as.
A shared S3 bucket, with participant-specific prefixes
For file storage, we used one shared bucket:
sbg-scet-builder-163918294993Participants worked under prefixes following their own team or participant identifier, such as:
Converse-AWS-01/The policy limited object operations to the participant's own prefix, while allowing the bucket-level listing and location checks needed by the console workflow. We also gave participants a clear naming convention and documented a 10 MB per-file guideline.
This was a practical way to avoid creating a separate bucket for every participant. It also kept the instructions consistent.
There was an important limitation, though: S3 prefixes are key-name conventions, not separate buckets. They are useful for organizing objects and applying scoped permissions, but they should not be mistaken for a complete isolation boundary across every AWS service.
Testing the workflows—not just the policy JSON
One of the biggest lessons was that writing a policy is only the beginning. The AWS console may make additional API calls as it loads a page, and an application may need permissions that aren't obvious from the first successful click.
So I tested the environment using participant accounts and real service workflows.
Lambda
I created a test function, selected the shared execution role, configured a Function URL, and verified that the function could be invoked. We also encountered a console inspection error because the participant policy lacked some read-only permissions for inspecting the shared role. I added the required role-inspection permissions scoped to that role.
DynamoDB
I created a test table, added an item, and checked that basic data operations worked. Later, a participant test exposed a different issue: the Lambda function itself couldn't perform
dynamodb:PutItem. That was a runtime-role permission problem, not a participant's table-creation permission problem. Updating the Lambda execution role fixed it.SNS
I tested topic creation, subscriptions, and publishing. This uncovered missing console permissions for subscription attributes and tag listing, as well as a
kms:DescribeKey permission needed during the console workflow. We also investigated signature errors that turned out to be related to a participant computer's clock being out of sync—not an IAM policy failure.That distinction was important. Not every AWS error is an IAM problem, even when it first looks like one.
EventBridge Scheduler
The legacy scheduling experience wasn't the clearest path for the workshop, so I used EventBridge Scheduler. After adding the required schedule permissions and creating its shared execution role, I successfully created a test schedule that invoked a Lambda function.
A service we chose not to depend on
We also explored document-processing options. Amazon Textract was not accessible in the account environment available to us, so I decided not to make it a required dependency. The lesson was straightforward: don't build a student challenge around a service until you've verified that the actual participant environment can use it.
The trade-off: practical usability over perfect isolation
This was one of the most deliberate decisions in the design.
Some AWS console experiences and list operations could expose the names or existence of resources belonging to other teams. Permissions also weren't a perfect, independent sandbox for every resource across every service. I chose not to turn the challenge into a much more complicated multi-account or fully isolated architecture, because the priority was a manageable environment that beginners could use during a short event.
That did not mean cross-team access was allowed.
The rules clearly prohibited participants from accessing, invoking, modifying, deleting, or interfering with another team's resources—even if the permissions technically made an action possible. Participants were expected to use their own resources, and violations could lead to disqualification.
This was a conscious compromise for a supervised student challenge, not a claim that rules alone provide strong security isolation. In a production or untrusted multi-tenant environment, stronger technical isolation would be necessary. For a future version, separate accounts or more tightly scoped resource-level permissions would be worth evaluating if the added setup and operational overhead were manageable.
Documentation was part of the infrastructure
I didn't want participants to have to ask an organizer every time they encountered a normal setup question. I prepared two documents:
- Rules & Guidelines, covering account use, naming, permitted activities, security boundaries, cross-team conduct, and judging.
- Participant Technical Guide, explaining the available capabilities, how to use the supported services, the shared roles, common errors, and basic troubleshooting.
The aim wasn't to tell teams which AWS service to use for each problem. It was to give them enough information to understand their environment and make their own design decisions.
That matched the philosophy of the challenge: define the problem and the boundaries, then let participants choose how to solve it.
The result: the environment supported the challenge we wanted
We had 60 team registrations, and 13 teams attended on the day. The attendance was lower than we had hoped, but the teams who came were actively building and experimenting. Two teams personally told me they really enjoyed the format.
I also saw teams approach the work in different ways: some used AI tools, some searched documentation, and some were learning basic AWS concepts as they went. That was exactly the kind of independent problem-solving the format was meant to encourage.
The environment wasn't perfect, and the setup wasn't a universal blueprint. But it gave the attending teams a way to get hands-on with AWS without requiring every participant to arrive with a pre-existing account and a preconfigured environment.
For me, that was the important outcome: the infrastructure helped the event happen instead of becoming the event.
What I'd tell someone planning a similar challenge
If you're setting up an AWS environment for a student event, here's what I would take away from this experience:
- Design for the time available. A two-hour challenge can't afford a long account setup or a complicated onboarding process.
- Test as a participant. Admin access can hide problems that participants will hit immediately.
- Test complete workflows. Creating a resource is not the same as proving that the application can use it.
- Separate deployment permissions from runtime permissions. Lambda needs its own execution-role permissions when it accesses other services.
- Treat console errors as clues, not conclusions. Missing IAM actions, unsupported services, and a computer clock out of sync can look deceptively similar.
- Document the boundaries. Participants should know which account, names, prefixes, and resources they are allowed to use.
- Be honest about isolation. If the environment is not strongly isolated, say so internally and design the rules and supervision accordingly. Don't present a workshop policy as production security.
- Make the participant experience a technical requirement. A theoretically elegant setup isn't a success if beginners can't use it.
Final thought
While preparing the AWS Builder Challenge, I received suggestions about how the environment could be designed. I considered different approaches, but in the end I chose the one I believed participants would find easiest to use within the time available.
That decision wasn't about finding the most elaborate architecture. It was about reducing setup friction, keeping the rules understandable, testing the actual workflows, and leaving students enough room to build in their own way.
The event reinforced something I want to carry into future SBG activities: cloud infrastructure should be designed around the people who have to use it—not just the person who configures it.
For this challenge, that meant giving students a usable environment, clear boundaries, and the freedom to figure things out.
And seeing them actually build made the effort worth it.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article