A free AWS project for your resume: build a GenAI helpdesk on Bedrock

You have learned a few AWS services, but your resume still says only “familiar with cloud computing.” That leaves an interviewer guessing what you can actually build. A finished GenAI helpdesk gives you something concrete to discuss: a chat page, an API, a hosted model on Amazon Bedrock, retrieval-augmented answers, ticket tools, safety controls, automated deployment, and one CloudFormation stack that you can tear down when you finish.

The project can be taught through a free course, but running its AWS resources may still create charges. The sensible goal is not to claim that you built a production support platform. It is to build a small, complete system, understand each connection, control its cost, and explain your decisions honestly.

A complete request path turns separate AWS services into one project

The application is an IT helpdesk assistant. A user opens a private static chat page and enters a question such as, “How do I connect to the office VPN?” The page sends that message to an HTTP endpoint, which invokes an AWS Lambda function.

The Lambda function passes the conversation to a foundation model hosted through Amazon Bedrock. It uses the Bedrock Converse API, which provides a common message-based interface for supported models. The function then returns the model’s response to the chat page.

Think of the application as a reception desk. The page receives the visitor, the API carries the request inside, Lambda coordinates the work, and the Bedrock model drafts the answer.

This first working path already demonstrates several useful skills. You show that you can build a serverless function, call a managed AI service through an SDK, handle an HTTP request, return structured data, and connect a browser interface to a backend.

You also encounter real engineering details. The function needs permission to invoke the selected Bedrock model. The API must handle malformed input and backend failures. The browser must receive a response it can safely display. These details distinguish a connected project from a collection of screenshots.

The chat page is stored in a private Amazon S3 bucket and delivered through Amazon CloudFront. Keeping the bucket private means visitors retrieve the site through CloudFront instead of directly from S3. This gives the project a clearer hosting boundary and lets you discuss why public storage access is unnecessary.

The page does not need to be a large frontend application. A focused interface with a message box, a send button, a conversation area, and visible error states is enough. For example, if the backend cannot answer, the page should show a useful failure message instead of appearing frozen.

Infrastructure as code makes the application reproducible

Creating every resource manually can produce a working demonstration, but it is difficult to reproduce and easy to misconfigure. In this project, AWS CloudFormation describes the infrastructure as code: resources and their relationships are written in a template and deployed as a stack.

The stack can define the Lambda function, its execution role, the HTTP endpoint, the private S3 bucket, the CloudFront distribution, and related permissions. Later stages can add the resources needed for retrieval, guardrails, and agent behaviour.

Think of the template as the project’s assembly plan. A console-built resource shows that you found the right settings once. A reviewed template shows how the system is meant to be assembled again.

This part demonstrates infrastructure-as-code skills, dependency management, identity and access management, and repeatable deployment. It also gives you useful design questions to discuss. Which resources need public access? Which permissions belong to the function? Which values should be parameters rather than fixed in the template?

The template should grant only the access the project needs. For example, the Lambda role needs permission to call the chosen Bedrock capability, but that does not mean it needs broad control over every AWS service. Keeping permissions narrow is a practical security habit, even in a learning project.

CloudFormation also makes teardown clearer. Instead of trying to remember every resource created during several lessons, you can delete the stack and let AWS remove the resources it manages. You should still check whether any retained data or separately created resources remain.

Retrieval and tools turn a chatbot into a helpdesk workflow

A model can produce a fluent answer without having access to your organisation’s support material. Retrieval-augmented generation, usually shortened to RAG, addresses that gap by finding relevant content from a supplied knowledge base and making it available while an answer is generated.

For this project, the knowledge base can contain small, fictional IT support documents written for the demonstration. Suitable examples include password-reset instructions, VPN setup steps, or an equipment-request policy. They should not contain real credentials, private company material, or personal information.

RAG does not guarantee a correct answer. It gives the system relevant source material, while your application still needs to handle missing or weak matches. A sensible response may state that the available knowledge does not contain enough information instead of inventing a procedure.

Think of RAG as giving the assistant an open handbook before it responds. The assistant still has to interpret the relevant page, but it no longer has to rely only on general model knowledge.

Tool use adds a different capability. Instead of merely discussing a support ticket, the model can request a defined ticket operation. The application validates the request and invokes code that performs the allowed action.

For a portfolio demonstration, the ticket tool can operate on controlled sample data. Its input might include a short issue summary, a category, and a priority selected from an allowed set. The important lesson is that the model proposes a tool call; trusted application code decides whether and how to execute it.

A triage agent connects these paths. It examines the request and decides whether to answer from the knowledge base, request a ticket action, or report that it cannot safely complete the task. For example, “How do I reset my password?” may use retrieved instructions, while “The reset process failed and I am locked out” may need a ticket.

This stage demonstrates semantic retrieval, prompt design, tool schemas, input validation, orchestration, and separation between model output and application authority. It also gives you a strong interview topic: a model-generated tool request should not be treated as automatically trustworthy.

Guardrails and failure handling show responsible GenAI engineering

A helpdesk can receive sensitive, abusive, irrelevant, or manipulative input. Amazon Bedrock Guardrails can be added to apply configured controls to model interactions. Guardrails are one layer of the design, not a replacement for authentication, authorization, validation, or careful handling of data.

The application should also set boundaries in ordinary code. Reject an empty message. Limit the input accepted by the endpoint. Validate every ticket field. Avoid placing secrets in prompts or browser code. Return controlled errors rather than raw internal details.

For example, a user might ask the assistant to ignore its helpdesk role and perform an unrelated task. The application should keep its scope narrow and avoid calling a ticket tool unless the request satisfies the tool’s expected structure and purpose.

This part shows that you understand a central GenAI boundary: generated text is not trusted application logic. Your code remains responsible for permissions, input checks, tool execution, error handling, and the final response returned to the user.

It is also worth testing failure cases, not only the happy path. Try a blank request, invalid JSON, an unavailable model call, a question absent from the knowledge base, and a malformed tool request. Record what the user sees and what the backend logs without exposing sensitive content.

Automated deployment proves the repository can rebuild the system

Once local and manual deployments work, a GitHub Actions workflow can automate validation and deployment. The workflow can run when changes are pushed to the chosen branch, package the application, check the infrastructure template, and deploy the CloudFormation stack.

The deployment workflow should use scoped credentials and avoid storing long-lived secrets in the repository. Treat deployment permissions with the same care as runtime permissions: grant the workflow what it needs to update the project, not unrestricted access by default.

Think of continuous deployment as a repeatable checklist executed by a machine. It does not make a weak template safe, but it reduces the chance that a required packaging or deployment step exists only in your memory.

A useful repository keeps the chat page, Lambda code, infrastructure template, workflow, sample knowledge documents, and setup instructions together. The documentation should explain the architecture, deployment process, test cases, expected costs, and teardown steps.

This stage demonstrates version control, deployment automation, environment configuration, and operational documentation. A successful workflow run also provides evidence that the repository and infrastructure definition agree.

Cost controls belong in the project from the first deployment

“Free course” does not mean unlimited AWS usage is free. Bedrock model calls, Lambda execution, storage, content delivery, logging, retrieval resources, and other deployed components can have usage-based costs. Exact charges depend on the services, model, region, configuration, and traffic.

Create an AWS budget alert before experimenting. An alert helps you notice estimated spending, but it is not the same as an automatic hard spending limit. You remain responsible for monitoring the account and removing resources you no longer need.

Keep the demonstration small. Use short sample documents, avoid unnecessary traffic, do not run repeated model calls without a reason, and inspect the resources created by the stack. If a component is not needed for the current stage, do not leave it running merely because it may be useful later.

When you finish, delete the CloudFormation stack and verify the result. Check for resources that may have been created separately, retained deliberately, or left with stored data. Also review the billing and cost-management views rather than assuming that closing the browser stopped the services.

Cost awareness is itself an AWS skill. It shows that you understand cloud resources continue to matter after the feature works and that teardown is part of the application lifecycle.

An honest resume entry describes what you built and verified

Your resume should describe the scope of the project without presenting a learning deployment as production experience. Use “built,” “implemented,” or “deployed” when those statements are true. Avoid claims about scale, uptime, users, savings, or business impact unless you have measured evidence.

A defensible project entry could say:

Built and deployed a serverless GenAI IT helpdesk on AWS using a private S3 and CloudFront chat interface, an HTTP API, AWS Lambda, and Amazon Bedrock’s Converse API. Added retrieval-augmented answers from sample support documents, validated ticket tool use, triage logic, guardrail controls, CloudFormation infrastructure, and automated deployments with GitHub Actions. Documented test cases, cost monitoring, and stack teardown.

Adjust that wording to match what you actually completed. If your ticket tool writes only to a sample store, say so. If deployment still requires a manual approval, do not call it fully automatic. If you tested only with synthetic documents, describe them as sample data.

In an interview, be ready to draw the request path and explain one decision from each layer. You might explain why the S3 bucket is private, how Lambda calls Bedrock, what RAG contributes, why tool input is validated, how the workflow deploys CloudFormation, and how you removed the resources afterward.

The strongest demonstration is not a long list of AWS names. It is a coherent explanation of how a request moves through the system, where trust changes, what can fail, and how the deployment can be reproduced.

Key takeaways

A finished portfolio project connects a chat page, HTTP endpoint, Lambda function, Bedrock model, and CloudFormation stack.
RAG supplies relevant support material, while validated tool use lets the application perform a controlled ticket action.
A triage agent, guardrails, narrow permissions, and application-level checks demonstrate responsible GenAI design.
GitHub Actions and infrastructure as code make the project reproducible instead of dependent on undocumented console steps.
A budget alert, small test data, cost monitoring, stack deletion, and resource verification help keep experimentation controlled.
Resume wording should state exactly what you built and tested without implying production scale or business results.

This project can demonstrate a broad set of beginner AWS skills in one understandable system. It does not prove production readiness, security under every threat, reliable operation at scale, or professional experience; those require deeper testing, monitoring, governance, and real operating conditions.

Build this project step by step in the free AWS in Action: AI edition course. To go further with mentoring, see the Cloud and AI Solutions Architect program.