AWS SAA Wasn't the Exit From IT Support—This Was
The Solutions Architect Associate opens a door, but only if you pair it with evidence, ownership, and a cloud-native project trail. Here’s what actually moved support engineers into cloud roles.
The AWS Solutions Architect Associate (SAA) is often sold as the cleanest exit from IT support. You study, pass, update LinkedIn, and wait. For most people, nothing changes.
The engineers who actually make the jump treat the exam as a milestone, not the destination. They combine the credential with a public project trail, cloud-adjacent work in their current support role, and a story that makes a hiring manager feel safe taking a chance on them.
The SAA gets you past filters, not interviews
Passing the SAA proves you can think inside the AWS Well-Architected lens. It helps with recruiters and automated résumé screens. But every hiring manager has seen the pattern: certifications, no live infrastructure, no operational scars.
AWS-sponsored employer research from Enterprise Strategy Group has repeatedly found that certified teams report faster troubleshooting and improved security confidence. That matters once you are in the room. To get into the room, you need to show you have applied the vocabulary.
Build an evidence trail in a real AWS account
Do not stop at practice exams. Open a personal AWS account, keep billing alerts on, and ship something small.
A useful first portfolio project is not a résumé grid. Build a static site behind CloudFront with S3 origin, add WAF, then extend it with a serverless contact form using API Gateway, Lambda, and DynamoDB. Write the infrastructure as code with Terraform or AWS CDK.
Push the repository to GitHub and write a README that covers:
Architecture diagram or description
Cost controls and budget alarm
Security choices, such as least-privilege IAM roles
Failure modes and what you would improve
This is what turns a certification into a body of evidence. You can now answer an interview question about VPC endpoints or retry behavior because you have built something that used them.
Mine your current IT support role for cloud-adjacent work
You may not have AWS access at work. You still have incidents, vendors, SSO, DNS, email delivery, and cloud-hosted SaaS tools. That is operational cloud context.
Start writing internal runbooks for anything that touches a hosted service. Shadow the team that manages infrastructure. Ask to own the ticket queue triage for cloud-related issues. If you have AWS access, automate the obvious: use Cost Explorer APIs to build a weekly cost report, tag resources, or create a Lambda that flags unused EBS volumes.
These projects become interview answers. A support engineer who says “I wrote an automation that reduced repetitive cloud tickets by 20%” is far more compelling than one who only says “I passed the SAA.”
Rewrite your résumé around outcomes
Remove the line that simply lists the certification under education. Keep the credential, but connect it to work.
Weak bullet:
Passed AWS Solutions Architect Associate
Strong bullet:
Designed and deployed a serverless web app on AWS with CloudFront, API Gateway, Lambda, and DynamoDB; kept monthly costs under $5 and documented security controls in Terraform
Use the same pattern for your current role. Focus on incidents resolved, costs saved, automations shipped, or documentation used by teammates.
Target cloud support engineering roles first
The most common mistake is applying only to Solutions Architect roles. The easier bridge from IT support is into cloud support engineering, cloud operations, or managed services engineering. Those roles value your ticket discipline, customer communication, and SLAs. The SAA supplies the cloud layer.
Once you are inside a cloud team, the next jump to architecture, DevOps, or platform engineering becomes a conversation instead of a cold application.
What not to do
Do not wait for permission at work to build.
Do not list five certifications and zero live projects.
Do not memorize services you have never opened.
Do not call yourself an architect until you have operated something in production.
The SAA can absolutely help you move beyond IT support, but only if you treat it as part of a body of work. The people who make the jump build, automate, document, and then apply. The certification opens the door; the evidence gets you hired.
At Sapior, we see this same pattern in the developers we build for: the best career changes come from shipping visible work, not waiting for a title.