Learn which AWS certification to take first, how to build a portfolio hiring managers trust, how cloud engineering career levels differ, and how to research compensation before negotiating.
You pass the SAA-C03 exam. You update LinkedIn. You wait for recruiters to call. Three weeks later, nothing has changed. Meanwhile a candidate with no certification but a GitHub repo showing a real three-tier deployment, a working CI/CD pipeline, and a recorded demo gets three interview calls in a week. This is not because certifications are worthless. It is because a certification proves you can pass an exam. A portfolio proves you can build. Companies hire for the second thing and use the first thing as a filter, not a decision. This module gives you both pieces: which certification to take and in what order, and how to build the portfolio evidence that actually gets you through the door. ### Why order matters more than which certifications you collect A cloud engineer with just SAA-C03 and one strong capstone project will out-interview someone with four certifications and no hands-on evidence. Certifications compound only when paired with something you built. Treat the certification path as a study structure, not the finish line. ### The career path in one picture Learn fundamentals | v Build real projects | v Earn a relevant certification | v Document your decisions (ADRs) | v Publish portfolio evidence | v Practice interviews | v Get an offer | v Evaluate level + total compensation | v Negotiate before accepting Certification is one step in this loop, not the centre of it. Skipping straight from "earn certification" to "wait for recruiters" is why the opening scenario in this module happens so often. ---
Do not collect Cloud Practitioner automatically just to have a certificate. Take it if you genuinely need foundational cloud knowledge; otherwise, consider progressing directly toward an Associate-level certification, since for most experienced technical candidates it carries less hiring weight than an Associate credential. ### CLF-C02 — Cloud Practitioner, the on-ramp **Cloud Practitioner** validates that you understand cloud concepts, AWS service categories, security basics, and pricing models at a conceptual level. There are no hands-on scenario questions. Take this first only if you cannot yet explain the difference between IaaS and PaaS, or you have never touched the AWS console. If you can already pass SAA-C03 practice exams at 70%+, skip straight to SAA-C03. Taking CLF-C02 as a stepping stone when you are already ready for the Associate exam wastes 4-6 weeks you could spend going deeper. > 📌 **Remember:** Cloud Practitioner tests what you know. Associate-level exams test what you can decide. Employers care about the second one. ### SAA-C03 — Solutions Architect Associate, the one that matters most For most aspiring cloud engineers, **Solutions Architect Associate (SAA-C03)** is the strongest general-purpose starting certification, because it develops architecture and service-selection judgment rather than memorisation. Its exact value still depends on your target role, geography, and existing experience — a developer-heavy role may value DVA-C02 just as highly. It tests whether you can choose the right service and the right architecture for a scenario, not whether you can recite definitions. The exam domains and their approximate weight: | Domain | Weight | What it actually tests | |:---|:---|:---| | Design resilient architectures | 26% | Multi-AZ vs Multi-Region, RDS failover, decoupling with SQS/SNS | | Design high-performing architectures | 24% | Caching, storage class choice, database selection, auto scaling | | Design secure architectures | 30% | IAM, Security Groups vs NACLs, encryption, least privilege | | Design cost-optimised architectures | 20% | Purchasing options, storage lifecycle, rightsizing | Notice security is the largest single domain. Most candidates under-study IAM and over-study EC2 instance types. Do not make that mistake. ### The exam question patterns that trip people up every time * **NAT Gateway vs Internet Gateway vs VPC Endpoint** — if private resources need general outbound internet access while remaining unreachable from unsolicited inbound traffic, a NAT Gateway is the common managed answer. But check what the traffic is actually going to first: if it only needs to reach supported AWS services like S3 or DynamoDB, a VPC Endpoint can remove the need for internet or NAT access entirely, and is usually the cheaper, more secure choice. If the scenario says the resource must be reachable from outside, it wants an Internet Gateway plus a public subnet. * **Multi-AZ vs Read Replica** — Multi-AZ is for **availability** (synchronous standby, automatic failover, same region). Read Replica is for **scaling reads** (asynchronous, can be cross-region, requires manual promotion to become writable). A question mentioning "read-heavy workload" wants a Read Replica. A question mentioning "must survive an AZ outage with zero data loss" wants Multi-AZ. * **SQS vs SNS vs EventBridge** — think in terms of the need, not a fixed hierarchy: | Need | Common choice | |:---|:---| | Buffer work for asynchronous processing | SQS | | Fan out the same notification to multiple subscribers | SNS | | Route events based on content and rules, including SaaS sources | EventBridge | | Give each of several consumers its own independent queue | SNS or EventBridge publishing into separate SQS queues per consumer | SQS, SNS, and EventBridge are frequently combined rather than mutually exclusive — a fan-out architecture typically uses SNS or EventBridge upstream with SQS queues downstream of each subscriber. > 🔴 **Common Mistake:** Memorising service names instead of the decision logic behind them. The exam rarely asks "what does S3 stand for." It asks "given this constraint, which service satisfies it." Study the trade-off, not the trivia. ### After SAA-C03 — picking your next certification by role focus * **DVA-C02 (Developer Associate)** — choose this if your daily work leans toward Lambda, API Gateway, DynamoDB, and CI/CD pipelines rather than infrastructure design. Good fit for developers moving into cloud engineering. * **SOA-C02 (SysOps Administrator Associate)** — choose this if your work is closer to operations: CloudWatch, Systems Manager, patching, and automation at scale. Good fit for engineers coming from a sysadmin background. * **SAP-C02 (Solutions Architect Professional)** — the hardest AWS exam. Covers multi-account architectures, complex migrations, and advanced networking. Attempt this only after 1-2 years of hands-on production experience following SAA-C03 — the scenarios assume real-world judgment, not just textbook knowledge. * **DOP-C02 (DevOps Engineer Professional)** — for engineers who own CI/CD pipelines, infrastructure as code, and incident response at scale. *Specialty certifications* go even deeper on one domain: **SCS-C02** (Security Specialty) tests the fine distinctions between GuardDuty, Inspector, and Macie, plus KMS key policy debugging. **DBS-C01** (Database Specialty) and **MLS-C01** (Machine Learning Specialty) exist for engineers specialising in those tracks covered in the Specialization Tracks module. ---
### Take a practice exam before you study, not after Most people study a topic for two weeks, then take a practice exam to check readiness. Reverse this. Take a full practice exam on day one, before opening a single study guide. Your score tells you where to prioritise. If you already score 85% on the security domain, spending another week re-reading IAM basics is time better spent on the domain where you scored 45%. Prioritising weak domains does not mean skipping the strong ones entirely, though — do a final pass across the complete exam blueprint before your exam date so no hidden gaps remain in a domain you assumed was solid. ### Where to study * **AWS Skill Builder** — the official platform. Free digital courses, official practice question sets, and the Cloud Practitioner Essentials course. Start here for structure. * **Tutorials Dojo** — widely regarded as the closest match to real exam question style for Associate and Professional level exams. Use this for final readiness checks before booking the exam. * **Hands-on over video** — for every service you read about, create it in the console or CLI and delete it the same day. A person who has actually launched an ASG behind an ALB will never forget how target group health checks work. A person who only watched a video will. ### Realistic time budgets * **SAA-C03**, starting from zero cloud knowledge: 3 months at 1-2 hours daily, combining study with hands-on labs * **SAA-C03**, with 6+ months of hands-on AWS experience already: 4-6 weeks of focused practice exam review * **SAP-C02**: 5-6 months after passing an Associate exam, because the scenarios require production judgment that only comes from experience or extensive lab time > 💡 **Tip:** Book the exam date before you feel ready. A concrete deadline forces consistent daily study far more effectively than an open-ended "I'll take it when I'm ready" plan, which quietly becomes never. ---
A certification is a claim. A portfolio is evidence. Here is what separates a portfolio a senior engineer respects from one they skim past in ten seconds. ### The GitHub README is the first and sometimes only thing they read A hiring manager spends 30-60 seconds on your repo before deciding whether to keep reading. That README needs: * An architecture diagram, even a simple one, showing the actual services and how traffic flows * Deployment instructions that genuinely work if someone clones the repo and follows them * A short section explaining **why** you made key decisions, not just what you built A repo with only a working `main.tf` and no explanation reads as "I followed a tutorial." A repo with the same code plus a paragraph explaining why you chose ECS Fargate over Lambda for this workload reads as "this person thinks like an engineer." ### Terraform structure signals experience level Compare these two structures: ```text Junior signal Senior signal -------------- -------------- main.tf (everything) modules/vpc/ variables.tf modules/ecs-service/ outputs.tf environments/dev/ environments/prod/ (remote state, S3 + DynamoDB lock) ``` A single flat `main.tf` with hardcoded values tells a reviewer you followed a getting-started guide. Modules, separate environments, and remote state tell them you have managed infrastructure that had to survive a second developer touching it. > 🔴 **Common Mistake:** Splitting a small, genuinely simple project into modules purely to look senior. A five-resource demo project does not need a `modules/` directory, and a reviewer can tell the difference between structure that serves a real purpose and structure added for appearance. Introduce modules when components are actually reused or when complexity justifies the separation, not by default. ### CI/CD pipeline evidence, not a claim about CI/CD "I set up CI/CD" in a README is a sentence anyone can write. A `.github/workflows/deploy.yml` file in the repo that a reviewer can actually open and read is proof. Include the real workflow file, not a screenshot. ### Monitoring proof and the ADR A CloudWatch dashboard screenshot with an SLO stated in the README ("p99 latency under 300ms, alerting above 500ms") shows you think about production behaviour, not just deployment. An **Architecture Decision Record (ADR)** is a short document explaining a single technical choice: the context, the decision, the alternatives you considered, the trade-offs, and the outcome. One page. A well-written ADR can be a very high-signal portfolio artifact, because it demonstrates how you evaluate alternatives and defend a trade-off, which is exactly what senior engineers do daily and almost no junior candidate includes. An excellent architecture diagram, a genuinely clean Terraform setup, or strong troubleshooting documentation can be just as high-signal — the common thread across all of them is that they show your reasoning, not just your output. > **Note:** An ADR is not a design document. It documents one decision, not the whole system. "Why Aurora instead of standard RDS for this project" is a good ADR topic. "How the entire system works" is not. ### The working demo beats the deck every time Record a 10-minute walkthrough: 1 minute stating the problem, 2 minutes on the architecture, 5 minutes of the system actually running, 2 minutes on what you would improve with more time. A live, working demo is worth more than ten slides describing a system that may or may not run. ---
The year ranges below are typical, not a requirement. Someone can reach senior scope in three years in a fast-moving environment and remain mid-level for eight years elsewhere. Scope, ownership, and technical judgment matter more than tenure alone — treat the years column as a rough signpost, not a checklist to complete. | Level | Typical experience range | Typical scope | |:---|:---|:---| | Junior Cloud Engineer | 1-3 years | Deploys on existing infrastructure, follows runbooks, AWS Associate certified | | Cloud Engineer | 3-5 years | Designs architectures for new features, writes Terraform, owns CI/CD, on-call | | Senior Cloud Engineer | 5-8 years | Sets platform direction, multi-account strategy, mentors team, Professional certified | | Cloud Architect | 8+ years | Org-wide cloud strategy, large migrations, stakeholder presentations | The jump from Cloud Engineer to Senior is rarely about knowing more services. It is about scope: a Junior implements what they are told to build. A Senior is trusted to decide what should be built and can defend that decision to a room of stakeholders who disagree with them. Actual compensation for each level varies by company, city, and market conditions, and changes faster than the technical content in this roadmap. Rather than list numbers that go stale, the hands-on lab below has you build your own current benchmark using live salary data sources. ---
### System design questions always start with requirements The most common mistake in a cloud system design interview is drawing a diagram before asking a single clarifying question. Always start by establishing RTO, RPO, expected scale, and budget constraints. An architecture that is correct for "10,000 users, cost-sensitive startup" is often wrong for "10 million users, enterprise compliance requirements" — and the interviewer is testing whether you know to ask first. ### Practical infrastructure exercises Be prepared for practical exercises such as designing a VPC, explaining Terraform code you have written, debugging a broken piece of infrastructure, or writing a small infrastructure component live on a shared screen. The exact format varies a lot between companies, but a VPC with public and private subnets is a common enough prompt that you should be able to talk through the route table and NAT Gateway placement without hesitating. ### Architecture trade-off questions "Why not just use Lambda for everything?" is a classic trade-off question. A strong answer covers: cost at sustained high volume (EC2/Fargate can be cheaper than Lambda at scale), the 15-minute execution limit, cold start latency for user-facing low-latency needs, and that Lambda is stateless by design so long-running stateful workloads do not fit. ### Cost estimation questions "How much would this architecture cost at 1 million requests per day?" is not asking for an exact dollar figure. It is testing whether you understand the AWS pricing model — what scales with request count, what is a fixed monthly cost, and where the biggest cost driver in the architecture actually sits (often data transfer or NAT Gateway processing, not compute). ### Security walkthrough structure When asked "how would you secure this architecture," work outward to inward in a consistent order: IAM (who can do what) → network (Security Groups, NACLs, subnet placement) → encryption (in transit and at rest) → monitoring (GuardDuty, CloudTrail, alerting). Interviewers are listening for structure as much as content. ---
You pass the SAA-C03 exam. You update LinkedIn. You wait for recruiters to call. Three weeks later, nothing has changed....
Do not collect Cloud Practitioner automatically just to have a certificate. Take it if you genuinely need foundational c...
Take a practice exam before you study, not after Most people study a topic for two weeks, then take a practice exam to c...
A certification is a claim. A portfolio is evidence. Here is what separates a portfolio a senior engineer respects from ...
The year ranges below are typical, not a requirement. Someone can reach senior scope in three years in a fast-moving env...
System design questions always start with requirements The most common mistake in a cloud system design interview is dra...
Competing offers are the single most effective lever available. Even being mid-process in another interview loop changes...
Take a full SAA-C03 practice exam on AWS Skill Builder before doing any dedicated study. Score your results by domain an...
Topic Key decision rule First certification SAA-C03 for most technical candidates, CLF-C02 first only if genuinely new t...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.