BYTE the Cloud

Chris 0:00
Welcome to the deep dive the show that well cuts through the noise and gets straight to what you really need to know. Today we're diving into something a lot of you listeners have actually asked about the common pitfalls, the tricky spots when you're taking the AWS Certified Solutions Architect Associate exam. That's the SAA-C03.

Kelly 0:19
That's right, yeah, for mid level cloud engineers, this CERT is, well, it's often a really crucial next step and understanding not just the services themselves, but where people typically stumble, that can make all the difference. So our mission today is basically to give you that shortcut you know, to help you get really well informed with some practical advice and maybe some surprising insights, we want to help you ace that sa co three Exactly.

Chris 0:40
We've pulled together some some great material to help you navigate the nuances here, because it really is about moving beyond just like memorising facts to genuinely understanding that architectural mindset that AWS expects. So what does this deep dive mean for you? Well, hopefully a clearer path to success, and, you know, a lot more confidence in your AWS knowledge. Let's unpack this. Okay, so before we get into the nitty gritty of specific services, let's maybe zoom out a bit. Think of the SAA-C03 like a maze, right? Lots of candidates seem to hit dead ends almost immediately, and it's not always about lacking knowledge, but maybe looking at the map wrong. What are some of those big, overarching traps people fall into.

Kelly 1:21
Yeah, that's a good way to put it. One of the most significant pitfalls is probably focusing too much on the literal stuff, like specific CLI commands or you know exactly which button to click in the console. Now, hands on, experience is incredibly valuable, don't get me wrong, but the SAA-C03 exam, it's designed to test your understanding of what the tech is, how it works, and crucially, how you apply it to solve actual business problems. So an engineer might think, right, how do I set up this load balancer? But an architect, they step back and ask, wait, is a load balancer even the right solution here, or is there like a more AWS native, fully managed service that simplifies things and scales better for the specific problem? That distinction, it's absolutely critical for the SAA-C03, you really have to put on that architect hat, not just the engineer

Chris 2:07
one. That makes a lot of sense. It's a real shift in perspective needed for the exam. So less about the how to clicks, and more of the design principles. What about common misunderstandings, things that kind of cut across different services,

Kelly 2:19
absolutely and if cost is one pillar of a well architected solution, security is definitely the other. And just like with cost, there are these subtle security nuances in AWS that consistently trip people up on the exam. But let's start with cost optimization. That's a huge one, candidates often struggle with picking out the most cost effective solution from the options given, and doing that well requires understanding pricing models for different compute options, like your EC, two purchasing options, different S3, storage classes and even networking costs, especially data transfer fees, those can bite you

Chris 2:51
right. Cost is always looming. Can you give us maybe a concrete example, like where might someone think they're being cost effective, but the exam expects a different answer.

Kelly 3:00
Oh, definitely. A classic one is just sizing resources incorrectly. You need to remember to provision for average use, generally, not just peak load all the time and always leverage Auto Scaling where it makes sense. Also decoupling your application, say, using SQS queues can significantly cut costs because it lets you right size your database or other components

Chris 3:18
independently. Okay, so decoupling helps right sizing

Kelly 3:21
Exactly. And think about Compute types using Spot Instances for batch jobs that can be interrupted, super cost effective, but for mission critical stuff you stick with on demand and reserved instances for those one or three year commitments, they offer big discounts if you have predictable workloads. What's really interesting, though, is serverless, while it can be cheaper, especially for bursty workloads, sometimes, believe it or not, a traditional monolith might actually be more cost effective. Amazon Prime, for instance, famously moved some components back from serverless microservices to a monolith, because for their specific high volume pattern, it got too expensive.

Chris 3:59
Wow. That is surprising about prime really shows it's not always a simple answer. Okay, cost is one major area. What's another big one.

Kelly 4:06
So the other big one is security and compliance. Now AWS has the shared responsibility model, right? They secure the cloud infrastructure. You secure what you put in the cloud. Exam questions often test your ability to implement the right AWS security services on your side of that line, and a place people frequently get mixed up is the scope and function of, say, security groups versus network ACLs and ACLs.

Chris 4:27
Ah, yes, the classic security group versus NaCl confusion. I know I've definitely had to double check those myself. Sometimes. Can you maybe give us an analogy to help nail the difference?

Kelly 4:37
Sure, let's try this. Think of a security group like a smart bouncer at a specific club door, right for an instance, if they let you in, they automatically know you're okay to leave again. They're stateful. So if traffic is allowed inbound, the return traffic gets out automatically. No need for a separate outbound rule for that specific connection. And they only support allow rules. If it's not allowed,

Chris 4:58
it's denied, okay. Stateful balancer at the instant store got it right now,

Kelly 5:02
network ACLs are more like like strict border control for a whole neighbourhood the subnet, you need a specific permit or rule for entry and a separate one for exit. No assumptions. They act at the subnet level. They're stateless. You need explicit inbound, A and D outbound rules, and they support both allow and D, E and y rules, plus the order of their rules matters the process lowest number first,

Chris 5:25
that border control analogy helps stateless subnet level, explicit rules for both ways.

Kelly 5:29
Okay, exactly understanding those fine points is critical.

Chris 5:33
So these nuanced differences can really swing the answer beyond specific services. What about the questions themselves? Any common tricks or keywords to watch for?

Kelly 5:42
Yes, definitely pay really close attention to the keywords in the question stems words like real time versus near real time, that might point you towards Kinesis data streams for the former, and maybe Kinesis Firehose for the latter, accidental deletion prevention, that should make you think immediately about S3 features like versioning or MFA delete or maybe object lock.

Chris 6:04
Oh, okay, keywords as signals

Kelly 6:06
precisely and minimal operational overhead that almost always steers you towards fully managed services. Think Lambda or AWS Secrets Manager, or maybe SQS Fargate. These can sometimes be like relaxing questions if you spot the keyword and know the associated service pattern, you can answer quickly and bank that time for harder scenarios.

Chris 6:27
That's a great tip. Bank time on the keyword questions

Kelly 6:29
and always remember high availability if the question mentions it, your first thought should be deploying across multiple availability zones redundant resources like load balancers, VMs, databases, the works

Chris 6:40
right? Multi, AZ is usually the baseline for AJ, okay, let's zero in. Now. Let's tackle some of those core services where mistakes frequently happen. First up, IAM, identity and access management,

Kelly 6:53
right? IAM, it's absolutely foundational for AWS security and, yeah, misunderstandings here can be costly, both on the exam. And you know, in the real world, the core principle to hammer home is least privilege.

Chris 7:06
Least privilege. Everyone hears it, but how does it specifically become a common mistake on the exam? What's the trap?

Kelly 7:12
The trap is granting overly broad permissions. It's easy to do, maybe quicker in the short term, but it's dangerous. Imagine like a scenario question, where maybe an application instance only needs to read from an S3 bucket, but the proposed solution gives it full S3 access, including Delete. That's a red flag the exam tests if you spot that over permissioning, remember, IAM policies are implicit deny by default. If you don't explicitly allow it, it's denied. And if multiple policies apply, the most restrictive one usually wins. And you absolutely need to grasp the difference between IAM users groups and roles. Roles are particularly key. Why roles specifically because roles are how you delegate permissions temporarily and securely, either to AWS services like letting an EC2 instance access an S3 bucket without embedding credentials, or to external identities, they provide temporary security credentials via the AWS Security Token Service, STS.

Chris 8:04
STS, okay, that comes up a lot. What's the key takeaway for STS on the exam?

Kelly 8:07
Well, STS is primarily for things like cross account access, using roles integrating with external identity providers, Federation and getting those temporary credentials for mobile or web apps talking to AWS. Best practice, use very short lived, very granular credentials from STS, minimise that window of opportunity and just general IAM, hygiene, MFA, multi factor authentication on your root account and all users period, never share access keys, rotate credentials, regularly clean up unused ones. And for managing secrets like database passwords or API keys use AWS Secrets Manager, it handles rotation automatically and encrypts them. That's often preferred over Systems Manager, parameter store for CD as parameter store can store things unencrypted.

Chris 8:50
Good distinction there on Secrets Manager versus parameter store, Okay, moving on to VPC, virtual private cloud, the network foundation. What trips people up here?

Kelly 9:00
VPC is where you build your virtual data centre. Yeah. And networking can definitely be tricky. We already talked about security groups versus NaCl, but another huge area is VPC endpoints. A really common mistake is assuming you need a NAT gateway, network address translation gateway to let instances in private subnets talk to public AWS services like S3 or DynamoDB.

Chris 9:21
Okay, so if a NAT gateway isn't the best way for S3 or DynamoDB access from private subnets, what should you

Kelly 9:29
use for S3 and DynamoDB? Specifically, you should almost always go for a gateway endpoint. Key things, they're free. They add a route directly into your subnets route table, and crucially, the traffic stays entirely within the AWS network, backbone, better security, better performance, no data transfer charges for that

Chris 9:44
traffic free and keeps traffic internal. Got it gateway endpoints for S3 DynamoDB,

Kelly 9:49
right now, for most other AWS services, like talking to the EC2 API, or SNS, Kinesis, et cetera, you'd use an interface endpoint. These work differently. They actually provision an eni. An elastic network interface with a private IP address right inside your subnet. Traffic still stays private, but there is an hourly cost plus data processing charges for interface endpoints.

Chris 10:10
Okay, so gateway for S3 DynamoDB interface for most others and NAT Gateways.

Kelly 10:15
NAT Gateways are primarily for allowing instances in private subnets to initiate outbound connections to the general internet, like for patching or pulling external dependencies while still preventing inbound connections from the internet. And remember, high availability for NAT gateways too. A single NAT gateway lives in one availability zone. For real fault tolerance across AZs, you need to deploy a NAT gateway in each AZ you're using and configure routing accordingly,

Chris 10:39
right? MultIAZ for NAT gateways, too, if you need that resilience. Okay. Next up, S3 simple storage service seems simple on the surface, but where are the layers people miss, especially on cost.

Kelly 10:50
Yeah, S3 is incredibly powerful and durable, but cost optimization and data protection common pain points on the exam, a frequent mistake is just defaulting to S3 standard without thinking or not picking the most cost effective storage class based on how the data is actually accessed.

Chris 11:07
So it's not just dump it in S3 standard, yeah. How do you navigate those storage classes effectively for the exam, you

Kelly 11:13
really need to know the main ones and their use cases. S3 standard for frequently accessed data. Your go to default standard IA, infrequently accessed, cheaper storage, but you pay a retrieval fee, still fast retrieval, though one zone. IA, like standard IA, but even cheaper because it only stores data in a single AZ, so less resilient. Good for data you can easily recreate. Then you have the Glacier family for archival Glacier instant retrieval for archive data you need back in milliseconds. Glacier, flexible. Retrieval, minutes to hours. Retrieval and Glacier deep archive, the absolute cheapest, but retrieval takes hours. Okay, that's quite a spectrum. It is, and the key one to remember for unpredictable or changing access patterns is S3 intelligent tiering. It automatically moves your data between frequent and infrequent access tiers based on usage. Optimising costs for you, it's often the best answer when access patterns aren't clear.

Chris 12:06
Intelligent tiering for the unknowns, that's a good one. What about protecting data? Accidental deletion seems like a huge risk, huge

Kelly 12:12
risk, and definitely an exam topic. First line of defence enable versioning. This keeps multiple versions of an object, so if you delete or overwrite something, you can recover the previous version. Versioning, okay? What else for an extra layer of safety, especially against accidental deletion, enable MFA Delete. This requires multi factor authentication, your Password Plus a code from an MFA device to change the versioning state of a bucket or permanently delete an object

Chris 12:38
version like a two factor auth for deletion

Kelly 12:41
exactly, and then for compliance scenarios where you need immutable storage, data that cannot be changed or deleted. For a set period, you use S3 object lock. It has two modes, governance mode, where users with special permissions can override the lock settings, and compliance mode, which is stricter even the root account can't override the lock or delete the object until the retention period expires, crucial for regulatory requirements,

Chris 13:05
object log for compliance. Got it okay. Finally, let's talk Lambda, the core of serverless. What common misconceptions or mistakes pop up here?

Kelly 13:15
Lambda is fantastic, but yeah, the serverless name can sometimes mislead. A common mistake is assuming Lambda runs without any servers at all, it absolutely still runs on servers managed by AWS. The key difference is you don't manage them, no patching, no OS updates, none of that, but servers are there.

Chris 13:31
That's a critical clarification. You don't manage them, but they exist. What other key Lambda concepts are important for the exam?

Kelly 13:38
Okay, first, Lambda functions are inherently stateless. This means each invocation starts fresh, it doesn't remember anything from previous invocations. So if your application needs to maintain state across multiple steps or calls, you need to handle that externally, maybe using AWS Step Functions to orchestrate multiple Lambdas or storing state in a database like DynamoDB,

Chris 13:59
stateless. Need external state management. Right? Cost is another one. While Lambda is often cost effective, especially for event driven or bursty workloads, because you pay per request and duration, a very heavily used Lambda function can become expensive. It's pay per use. So high usage means higher cost. It's not always automatically cheaper than, say, an EC2 instance running constantly. Good point paper use cuts both ways, exactly. And you need to know the common integration points. What can trigger a Lambda function? Big ones are API Gateway for handling HTTP requests as three events, like object uploads, DynamoDB streams for reacting to table changes, SNS notifications, CloudWatch events for scheduled execution. The list is long,

Kelly 14:41
so understanding triggers is key, very key. Oh, and one more thing, Lambda provides encryption for environment variables using KMS. That's important for storing sensitive configuration data securely within the function settings.

Chris 14:53
Okay, great. We've covered a lot of technical ground, hitting IAM, VPC, S3 Lambda pitfalls. So. Let's switch gears slightly. What about strategies for the exam itself? Studying test day? How should people

Kelly 15:07
approach it? Right strategy? First off, practice questions are absolutely essential, but don't just memorise answers. Use them to really dig into the explanations. Understand why the correct answer is right, and, just as importantly, why the other options, the distractors are wrong. That's where the real learning happens and where you solidify those concepts.

Chris 15:26
So focus on the why behind the answers, and practice tests

Kelly 15:29
exactly, and look for those keywords we talked about, cost effective, real time, fault tolerant, minimal operational overhead. They are often direct pointers to the type of AWS solution. The question is looking for

Chris 15:41
makes sense. It's about deep understanding, not just surface level memorization. What about the mindset needed when you actually sit down for the

Kelly 15:48
exam? Yeah, mindset is huge. You need to really embrace that architectural thinking we mentioned earlier. The exam wants to see if you can design solutions. Can you take a business problem described in this scenario and map it to the appropriate AWS services, considering trade offs like cost, performance, security and reliability. That means knowing the features, the benefits, but also the limitations of services and how they fit together.

Chris 16:12
And sometimes the best exam answer might lean towards AWS native services.

Kelly 16:17
Often Yes, the exam frequently favours the most AWS native, fully managed solution, even if, in the real world, you could build something more custom or complex. For example, if a question describes a relational database needing to handle heavy read traffic, knowing about Aurora read replicas and how Aurora Auto Scaling can manage them automatically, that's likely the kind of AWS native, optimised answer

Chris 16:40
they're looking for, okay, lean towards managed services where appropriate. Any final practical tips, especially on managing time during the test

Kelly 16:46
time, management is super crucial. Those questions that are more direct, maybe asking about MFA delete or a specific S3 storage class for a well defined access pattern, if you've done the conceptual groundwork, you should be able to answer those relatively quickly, those relaxing questions you mentioned Exactly. Nail those quickly, and it frees up precious minutes for the more complex scenario questions that require you to really analyse the situation and weigh different options. Oh, and don't forget the basics like CloudWatch monitoring for EC2. Remember that standard EC2 metrics don't include things like memory usage or disk space utilisation by

Chris 17:22
default, right? You need the CloudWatch agent for that level of detail you

Kelly 17:25
do. You have to instal the agent on the instance to get those custom metrics. That's a detail that catches people out surprisingly often.

Chris 17:32
That's a great specific tip to end on. Okay, that wraps up our deep dive into the common SAA-C03 exam mistakes. This has been well, incredibly insightful, really, highlights where knowing the details and thinking like an architect pays off

Kelly 17:48
Absolutely. And remember, the real goal here isn't just ticking a box on an exam, it's about becoming a genuinely well informed cloud professional, someone who can actually leverage AWS effectively to solve real problems. So focusing on these common pitfalls, it's not just exam prep. You're building a much stronger foundation for your cloud career.

Chris 18:09
Well said. So think about it. What's one area from today's deep dive that maybe you'll focus on a bit more in your next study session? How can you apply some of this thinking, maybe even to projects you're working on right now, keep exploring, keep learning, keep building.

Kelly 18:22
Yeah, thank you for joining us on The Deep Dive. We really hope this has given you the clarity and the insights you need to go tackle that. Saa 03 with more confidence until

Chris 18:31
next time, stay curious and keep diving deep.