Episode 17: Exam Q&A - 30 Multi-Choice Questions - Lambda, Messaging, CloudFront, Monitoring & DR | SAA-C03

Hey everyone, Balu here, welcome to a special supplement episode of Tech Top with Balu. This is our third exam Q&A supplement and this time we're doing something very different. In the previous supplements we used simple question and answer format but this time I'm switching to a more realistic exam style format that's multiple choice questions with four options just like you will see on the actual SAAC03 exam. So here is how all of this will work. For each question, I'm going to read you a scenario, then give you four options, A, B, C, and D. You will have seven seconds to pick your answer, then I will tell you the correct answer with a detailed explanation of why it's right and just as importantly why the wrong answers are wrong. This is actually how you learn understanding the reasoning, not just memorizing answers. Today we're covering episodes 12 through 16, that's covering topics like AWS Lambda and serverless, messaging and event architecture, content delivery and global apps, monitoring and observability and finally disaster recovery architectures. I'm going to give you 30 questions total, six questions per episode so you track your score and at the end I'll tell you what your score means for exam greatness. A few tips before we start, listen to each option carefully, the exam loves to include options that are almost right, they sound plausible but have one wrong detail in it. So look for the keyword triggers, words like static IP, real time, prevent, audit, these all point to specific services and when in doubt, eliminate obviously wrong answers first, then choose between the remaining options. So are you ready? Grab a pen and paper to track your score and let's go. So let's look first at Lambda and serverless topic, question number one, Lambda maximum execution. A company needs to process large video files, each video takes approximately 25 minutes to process, they want to use AWS Lambda for cost efficiency. What is the best approach? Option A, increase Lambda timeout to 25 minutes. Option B, use Lambda with provisioned concurrency. Option C, use AWS batch or step functions to chain multiple Lambda functions. Option D, use Lambda at edge for parallel processing. Think about it. The correct answer is option C, use AWS batch or step functions to chain multiple Lambda functions and here's why, Lambda has a hard limit of 15 minutes maximum execution time, you cannot increase it beyond 15 minutes, so option A is impossible. So 25 minute tasks, you have two options. You can use AWS batch or ECS for long running workloads or use step functions to orchestrate multiple Lambda functions where each one handles a portion of the work. Now why are the other answers wrong? Option A, to increase the Lambda timeout to 25 minutes, is impossible because it's got a 15 minute hard limit. Option B, to use Lambda with provisioned concurrency, doesn't help because provisioned concurrency only eliminates call starts. It doesn't extend execution time, remember that. And option D, that is to use Lambda at edge for parallel processing, is for content delivery customization at edge locations, not for heavy compute options. So for an exam tip, the 15 minute Lambda limit is one of the most tested serverless facts. So memorize it. If a question describes long running workloads, Lambda alone is wrong. Okay, onto question number two, Cognito versus I am. A mobile application needs to authenticate 50,000 users. Users should be able to sign in with Facebook or Google, which AWS service should use. Option A is I am users. Option B is Amazon Cognito user pools. Option C is I am roles with web identity federation. And option D is AWS directory service. Think about it. The correct answer is option B, Amazon Cognito user pools. And here's the reasoning. The keywords are mobile users, 50,000 users, and signing with Facebook or Google. These all point to Cognito. I am is not designed for managing thousands of end users. It's for AWS services and small numbers of internal users. Cognito user pools is specifically built for mobile and web app users with sign up, sign in social federation and JWT tokens. And why are the other answers wrong? Option A to use I am users is wrong because I am doesn't scale to 50,000 users and has no native social federation. Option C to use I am roles with web identity federation is partially right. You might use I am dT pools for AWS credentials, but user pools is the primary authentication mechanism. Option D to use AWS directory service is wrong because it's used for active directory integration, not for consumer facing applications. So an exam tip here, if you see mobile users, thousands of users or social login in a question, the answer is almost always Cognito and not I am. Question number three, API gateway timeout. The rest API built with API gateway and Lambda needs to process complex computations that take two minutes. Users complain they're getting timeout errors. What is the problem? Option A, Lambda has a 60 second timeout limit. And B, API gateway has a 29 second timeout limit. Option C, the VPC needs to be configured. And option D, Cognito is rejecting the request. Think about it. The correct answer is B, API gateway has a 29 second timeout limit. Here's the explanation, API gateway has a hard 29 second timeout, even though Lambda can run up to 15 minutes, API gateway will terminate the connection after 29 seconds. So even though your Lambda function can process for two minutes, the API call will fail. The solution is to use an asynchronous pattern here, API gateway invokes Lambda asynchronously, returns immediately and the client polls for the results. Option A, Lambda has a 60 second timeout is wrong because Lambda's timeout can be up to 15 minutes, you set it basically. Option C, the VPC needs to be configured, is not the issue, because VPC configuration doesn't cost the specific timeout. And option D, that Cognito is rejecting the request, would normally give you a 401 or 403 error and not a timeout error. For an exam tip, remember these two critical limits together. Lambda maximum is 15 minutes, API gateway max is 29 seconds, they're often confused. Now on to question four, Lambda VPC access. A Lambda function needs to access an RDS database in a private subnet. After configuring it, users report increased latency on the first request. What is causing this? Option A, the Lambda function is not in the correct VPC. Option B, Lambda functions in VPC experience slower call starts due to ENI creation. And here's why, when Lambda runs inside a VPC, AWS must create an elastic network interface that's ENI, in your subnet. This takes time for a few minutes, and you'll be able to get a lot of time out of here. You'll be able to get a lot of time out of here to get a lot of time out of here. And you'll be able to get a lot of time out of here, and you'll be able to get a lot of time out of here, and you'll be able to get a lot of time out of here, and you'll be able to get a lot of time out of here. This takes time on call starts. AWS has significantly improved this, but it's still slower than non-VPC Lambda. The solution for consistent low latency is provisioned concurrency, which keeps Lambda environments warm and ENI's pre-created. Now why the other answer's wrong? Option A, that's the Lambda function is not in the correct VPC. Would have prevented connection entirely, not just add latency. Where RDS requires Lambda to have a public IP is wrong, because Lambda doesn't need public IPs to access RDS in a VPC. An option D, the security group is misconfigured, would be the wrong option, because that would cause connection failures, again, not latency, on the first request specifically. Now for an example, the phrase first request slow, subsequent request fast is the classic call start signal. On to question number five, step functions use case. A company has five Lambda functions that need to run in sequence with error handling, retries and the ability to track progress visually. What's the best AWS service to use here? Option A, Lambda calling other Lambda functions in sequence. Option B, AWS step functions, option C, Amazon SQS for queuing, and finally option D, event bridge for orchestration. Think about it. The correct answer is B, that's AWS step functions, and here's why. Step functions are specifically designed for orchestrating multiple Lambda functions into workflows. You get visual state machines, automatic retries, error handling, parallel execution, conditional logic, and the ability to track progress visually. Trying to chain Lambda's manually, that's option A, gets messy fast. You have complex code, manual error handling, and it's hard to visualize. And why there are other options wrong? Option A, Lambda calling other Lambda functions in sequence, like you said works, but it's hard to manage at scale. Option C, that's Amazon SQS for queuing, is for decoupling normally, not for orchestration. And option D, which was event bridge for orchestration, triggers event. but doesn't orchestrate complex workflows with retries and error handling. For an example, when you see orchestrate multiple lambdas, workflow, error handling or track progress, the answer is always step functions. Question number six, Lambda Concurrency. A Lambda function is suddenly being throttled during traffic spikes, what's the most likely cost? Option A? Lambda hit the 15-minute execution limit. Option B? The function exceeded the thousand concurrent execution limit. Option C? The Lambda deployment package is too large, and finally option D? The function ran out of memory. Think about it. The correct answer is option B. Now here's the reasoning. Lambda has a default concurrency limit of thousand simultaneous executions per region, or account. When you hit this limit, additional invocations get throttled. The solution here is to request a limit increase from AWS support. You can also use a reserved concurrency to guarantee capacity for critical functions. Option A, which is Lambda hit the 15-minute execution limit, is wrong because that would have caused execution failures, that's function timeouts, not throttling. Option C, that's Lambda deployment package is too large, is wrong because that would have prevented deployment and again not caused throttling. Option D, the function ran out of memory is wrong because that would have caused memory errors in individual invocations and not throttling. For an exam tip, throttling plus traffic spike remember equals to concurrency limit. The default is thousand, so plan ahead for high traffic scenarios. Let's go into the next section now, messaging and event architecture. Question number seven, SQS versus SNS selection. Any commas application needs to send a single order event to multiple downstream services, inventory, shipping, billing and notification systems. What's the best architecture? Option A, send the message to multiple SQS cues directly. Option B, use SNS topic with SQS cues subscribe, that's a fan out pattern. Option C, use a single SQS cue with multiple consumers. And option D, use event bridge with rules for each service. Think about it. The correct answer here is option B, that is to use SNS topic with SQS cues subscribe, that is the fan out pattern we discussed in detail. Here's why this is classic fan out pattern. The publisher sends one message to an SNS topic. SNS automatically delivers a copy to every subscribed SQS cue. Each downstream service has its own cue with persistence, retries and independent processing. Adding new services later is easy so it's just a subscribe a new cue kind of model. Why the others are wrong? As for the other options, option A that is to send message to multiple SQS cues directly is wrong because that is fragile because if sending to one cue fails after another succeeded, you have an inconsistent state. C, use a single SQS cue with multiple consumers is also wrong because that delivers each message to only one consumer, not multiple services. And option D, that is to use event bridge with rules for each service, could work but it's more complex than fan out for this particular use case. Event bridge remember is better for AWS service events and SaaS integrations. For an exam tip, fan out pattern equals to SNS to multiple SQS cues. This critical SQS cues access policy must allow SNS to write, this trips many people up. On to question number 8, SQS visibility timeout. An SQS consumer reports the same message being processed multiple times. The processing takes about 45 seconds. What is the most likely cause here? Option A, the SQS cue is a fee for cue. Option B, the visibility timeout is too short, that's the default of 30 seconds. If you see multiple consumers are running, option D, the cue has duplicate messages. Think about it. The correct answer is B here, the visibility timeout is too short. Here's the reasoning, default visibility timeout is 30 seconds. If processing takes 45 seconds, the message becomes visible again before the consumer finishes processing. Another consumer picks it up causing duplicate processing. So solution is to increase visibility timeout to at least the maximum processing time or use change message visibility to extend it dynamically. Now why are the other options wrong? Option A, the SQS cue is a fee for cue is wrong because fee for cue is provide exactly one processing that would prevent this issue. Option C, which was multiple consumers are running, alone wouldn't cost this issue. SQS handles multiple consumers correctly. And finally option D, the cue has duplicate message is unlikely with standard cues if producers aren't sending duplicates. For an example, if the question asks about same message processing twice plus long processing time, then always understand that the visibility timeout is too short. Always make timeout larger than your processing time. Question number nine, fee for was a standard cue. A financial application needs to process transaction in exact order that they were submitted in with no duplicates. Trooper requirements are 200 transactions per second. What should you use? Option A is SQS standard cue with D duplication. Option B is SQS fee for cue. Option C is SNS topic with ordering. And option D is kinases data streams. Think about it. The correct answer is option B is SQS fee for cue. And here's why. The requirements are exact order and node duplicates. SQS fee for provides both first and first out ordering and exactly once processing via D duplication ID. The throughput of 200 transactions per second is within fee for limits that's 300 without batching and 3000 with batching. Option A, SQS standard cue with D duplication is wrong because standard cues have best effort ordering and possible duplicates at least once delivery. Option C that is SNS topic with ordering is wrong because SNS standard doesn't guarantee ordering. You need SNS fee for plus SQS fee for and option D which is kinases data streams is wrong. It could work but it's an overkill for 200 TPS. Kinases is for generally high volume streaming. So for an example tip, when you see exact order plus node duplicates plus transactions, the answer is almost always fee for that standard cue equals to high throughput but possible duplicates. On to question number 10, even bridge versus SNS. A security team wants to be alerted whenever an EC2 instance state changes in any AWS account. They need to filter by specific criteria like instance type. What service should they use? Option A, Amazon, SNS with subscribers, Option B, Amazon, SQS with multiple consumers, Option C, Amazon, Event Bridge with Event Patterns, and Option D cloud watch logs with alarms. Think about it. The correct answer here is Option C, Amazon, Event Bridge with Event Patterns and here's why. Event bridge is specifically designed to react to AWS service events like EC2 state changes. It provides rich event patterns matching for filtering by criteria like instance type. You can also aggregate events by the way across multiple AWS accounts using resource-based policies. SNS is for Pub/Sub messaging, not native AWS event detection. Now why the others are wrong? Option A, Amazon, SNS with subscribers, remember SNS doesn't natively detect EC2 state changes. It's a messaging service. Option B, Amazon, SQS with multiple consumers, is wrong because SQS is for queuing. It doesn't react to AWS events. When Option D, cloud watch logs with alarms is also wrong because cloud watch logs is for log data not state change events. So for an example, when you see react to AWS service events coupled with filter with patterns and across accounts, then think event bridge. SNS is just a Pub/Sub broadcasting. On to question number 11 now, SQS maximum message size. An application needs to send five MPJs and payloads through SQS. What's the correct approach to use? Option A, send directly through SQS because it supports up to 10 MP messages. Option B, store the payload in S3 and send a reference through SQS. That's the claim check pattern. Option C, compress the message before sending and finally option D split the payload across multiple messages. I'll give you five seconds. The correct answer here is option B that is to store the payload in S3 and send a reference through SQS. And here's why SQS has a 256 KB maximum message size. For larger payloads, the standard pattern is the claim check pattern that is store the actual data in S3 and send a message containing just the S3 reference as the bucket name and key information. The consumer then reads the message and then fetches the data from S3. Why the other options wrong? Option A that is sending directly through SQS is wrong because SQS max is 256 KB only not 10 MP. Option C which is compressed the message before sending might help but it's also wrong because 5 MP compressed file often exceed still 256kb. Option D, which is split the payload across multiple messages, just adds complexity and ordering issues. So if any messages lost, the whole payload is corrupted. On for an exam tip here, SQL's message size limit is 256kb. For larger payloads, you want to use s3+ reference, that's the claim check button. This is a classic exam scenario. Let's now move on to question number 12, even bridge multi-account. A company has 50 AWS accounts and wants to aggregate security related events from all accounts into a central security account for monitoring what's the best approach to user. Option A, setup CloudWatch logs from all accounts to a central log group. Option B, configure SNS topics in each account with cross-account subscriptions. Option C, use AWS config aggregator for all the accounts. And finally option D, use even bridge for resource-based policies on a central even bus. You can think about it. The correct answer here is option D, that is to use even bridge with resource-based policies on a central even bus. Even bridge even buses can be accessed by other AWS accounts using resource-based policies. You create a central even bus in your security account, configure resource-based policies allowing other accounts to send events and all 50 accounts route their security events to the central bus. This is the recommended pattern for cross-account event aggregation. The other options are wrong. Option A, setup CloudWatch logs from all the accounts to a central log group. Could work for logs but doesn't capture API events the same way. Option B, that's to configure SNS topics in each account with cross-account subscription, would be complex to manage 50 accounts. And option C, which is use AWS config aggregator for all accounts. That's for only configuration data and not for security events. So quick example here is if you hear aggregate event across accounts, then think even bridge even buses with resource-based policies. This is the standard enterprise pattern. Now we go on to the next section, content delivery and cloud front. Question number 13, cloud front versus global accelerator. Question is, an online gaming company needs to provide low latency connections for players worldwide. The game uses UDP protocol. Players devices need to connect to fixed IPs for firewall listing. Option A is AWS global accelerator. Option B is Amazon cloud front. Option C is Amazon Route 53 with latency routing. And option D is Amazon API gateway. Think about that. The correct answer here is option A, AWS global accelerator. And here's why. This question has multiple keyword triggers all pointing to global accelerator. You have the UDP protocol. Cloud front only supports HTTP and HTTPS. Then there's the fixed and static IPs for firewall listing. Global accelerator provides two static any cast IPs. And then there is this gaming that's classic global accelerator use case. All three signals confirm global accelerator here. Now why the other option is wrong? Option B is wrong because cloud front only handles HTTP and HTTPS not UDP. And option C, that's Amazon Route 53 with latency routing. Well, Route 53 manages DNS, but doesn't solve UDP or static IP issues. And finally option D, which was Amazon API gateway. That is normally for HTTP APIs. So for an exam tip here, the mental shortcut is gaming UDP static IP regional failover always think global accelerator. HTTPS caching web content, on the other hand, think cloud front. On to question number 14, cloud front origin security. A company hosts a static website in S3 served through cloud front. They want to ensure users cannot access the S3 bucket directly only through cloud front. What's the most secure approach? Option A is make the S3 bucket public. Option B is use signed URLs for all access. Option C is use origin access control OAC for short with restrictive S3 bucket policy. And option D is use AWSW AF on the S3 bucket. The correct answer here is option C. Use origin access control with restrictive S3 bucket policy. And here's why. OAC is the modern recommended pattern here. You create an origin access control in cloud front, then configure the S3 bucket policy to only allow access from your specific cloud front distribution. The bucket stays completely private to the public internet. Users can only hear access content through cloud front. The other options are wrong here making the S3 bucket public allows direct access. So it defeats the purpose. Option B which was use signed URLs for access. Well, that's for protecting individual files with expiring URLs, not a bucket wide security. And option D was use AWSW AF on S3 bucket. Waf doesn't apply to S3 directly. It applies to cloud front ALB or API gateway. For an exam tip here, for S3 plus cloud front secure architecture, always use OAC with a restrictive bucket policy. This is the standard pattern. Question number 15, signed URLs versus signed cookies. Question S, a premium video streaming service needs to give paying subscribers access to multiple video files in their library. The access should expire after their subscription ends. What's the best approach? Option A, generate a signed URL for each video file. Option B, use signed cookies to authorize access to all videos. Option C, make all videos public. And option D, use IM users for each subscriber. Think about that. The correct answer here is option B, that is to use signed cookies to authorize access to all videos. And here's why. Signed cookies are designed for authorizing access to many files with one credential. The cookie is set to once when the user signs in and their browser automatically includes it with every request. Signed URLs would require generating individual URLs for each video. So that's cumbersome and complex. Option A, that's to generate a signed URL for each video would work, but it's in practical like we said for many videos. You would generate hundreds of URLs here. Option C is wrong, make all videos public because that eliminates the security entirely there. And option D, that is to use IM users for each subscriber. Doesn't really scale to thousands of subscribers. IM is in for end users. You want to use cognitive for that. For an exam tip here, use signed URLs for one file, that's specific file with expiration. And you want to use signed cookies if you want to do that for many files. That's to access the whole subscription area. Question number 16, Claude Front Cash Invalidation. A company frequently updates their website. They invalid Claude Front Cash after each deployment costing thousands of dollars per month. What's a better approach here? Option A is to use versions file names like style-v2.css instead of invaltations. Option B is to increase the TTL to reduce invaltations. Option C is to disable caching entirely. And option D is to use lambda at edge for cash control. Think about it. The correct answer here is option A. That's to use versioned file names instead of invaltations. AWS provides first thousand invaltation parts free per month. Beyond that, you pay per path. The standard best practice is file name versioning. We spoke about this earlier. Instead of style.css, you use style-v2.css. So that when you update, you deploy style-v3.css and update your HTML to reference it and so forth. The new URL is a cache missed the first time. Then it's cached normally. There is no invaltations needed here. Now, why the other answer is wrong? Option B, that is to increase the TTL to reduce invaltations might help but still requires updates to propagate eventually. Option C, that is to disable caching entirely, really eliminates the performance benefits of Claude Front. And option D, that is to use lambda at the edge for cache control, is overkill for cache control. So for an exam tip, remember that frequent invaltations are expensive. So the best practice is to version your file names. The new URL bypasses the old cache automatically. Onto our next question, question number 17, Claude Front versus S3 CRR. The question is, a company has static content that needs to be accessed quickly by user's worldwide. The content rarely changes. What's the optimal solution? Option A is to use S3 cross-region replication to all regions. Option B is to deploy EC to instances globally. Option C is to use Claude Front with S3 origin. And finally, option D is to use S3 transfer acceleration. I'll give you five seconds to think. The correct answer here is C, that is to use Claude Front with S3 origin. And here's why. Claude Front caches static contents at hundreds of edge locations worldwide. For content that rarely changes, this gives users in any location very low latency by serving from the nearest edge. S3 cross-region replication makes copies in multiple regions, but you still need a way to direct users to the closest region. And you'll be paying for storage in every region. So why the other answer is wrong? Option A, that's S3 cross-region replication to all regions like we explained is more expensive and doesn't provide the same edge location performance. Option B, that's to deploy EC to instances globally, is wrong because it's operationally complex and expensive. An option D that is to use S3 transfer acceleration remember that is used for uploading to S3 faster and not for global delivery. As for an example appear, if you see static content plus global users plus low latency then you want to think cloud front. CRR is for replicating data that's needed in specific regions and not for edge caching. On to question number 18, cloud front functions versus lambda at edge. The question is, a team needs to add custom HTTP headers to every response and normally is cache keys at massive scale. That's millions of requests per second. Cost is a concern for them. What should they use? Option A is lambda at the edge, B is regular lambda, option C is API gateway with custom authorizer, and option D is cloud front functions. Think about it. The correct answer here is option D that's cloud front functions and here's why. Cloud front functions are JavaScript functions with sub millisecond execution times designed for massive scale. That's millions per second at one sixth of the cost of lambda at the edge. It's perfect for header manipulation and cache key normalization. Lambda at the edge would work but it's more expensive and has more capability than what is needed for this particular use case. Now why the other answers are wrong? We discussed option A that's using lambda at the edge works but it's six times more expensive and an overkill for this option B that is to use regular lambda would not work at all for this particular use case because that runs in the region and not at edge and it's got normally higher latency. Option C is wrong which was API gateway with custom authorizer. That is used for HTTP APIs and it's not response manipulation. So for an exam tip here if you see simple header manipulation URL re-rides or cache key normalization in the question then think cloud front functions. If you need network access longer execution and complex logic to be included then normally it would be lambda at edge. Now let's look at questions from episode 14 that's monitoring and observability. So question number 19 cloud watch versus cloud trail versus config. The question is you'll see you one day asks who deleted our production database two weeks ago which AWS service helps you answer this question. Option A, AWS cloud trail logs, option B, Amazon cloud watch metrics, option C, AWS config rules and finally option D, Amazon cloud watch logs, think about it. The correct answer here is option A that's AWS cloud trail logs and here's why. Cloud trail answers who did what and when. For an unexpected deletion two weeks ago cloud trail will tell you exactly who made the API call when it was made and from where. Cloud watch on the other hand is for performance monitoring but that config is for configuration tracking. So why are the other answers wrong option B that is using Amazon cloud watch metrics is wrong because that show performance and not actions and option C that is to use AWS config rules is wrong because config tracks configuration changes but the answer to who specifically is in within the cloud trail logs option D which was Amazon cloud watch logs is wrong because cloud watch logs contain application logs and not necessarily AWS API audit data for a quick exam tip here. The mental shortcuts you want to remember is cloud watch tells you how it is performing. Cloud trail tells you who did what and config tells you whether it's compliant and what has changed. All right onto question number 20 cloud trail 90 data retention the question is a security team needs to investigate API activity from six months ago they check cloud trail console and see nothing what's the issue and the solution option A cloud trail wasn't enabled so enable it now option B the events are encrypted and need decryption keys option C cloud trail only retains events for 90 days in the console they should query the s3 export and finally for option D cloud trail data was deleted by an administrator think about it. The correct answer here is option C that is cloud trail only retains events for 90 days in the console so here is the critical point cloud trail itself stores events for only 90 days after that events are no longer visible in the cloud trail console for longer retention you must configure cloud trail to deliver events to an s3 bucket combined with Athena now you can query historical events going back years so why the other answers wrong option A cloud trail was an enable enable it now is unlikely as cloud trail is enabled by default option B that is the events are encrypted and need decryption keys is wrong because cloud trail events aren't encrypted in a way that hides them from view by default option D which is cloud trail data was deleted by an administrator is possible but option C is the much more common scenario here for an exam tip remember that cloud trail console can only store 90 days worth of data for longer term audit you want to log into s3 and then use Athena to query it so set this up before you need it not after an incident that's happened onto question number 21 AWS config detection versus prevention the question is a compliance team wants to ensure no s3 buckets are ever made public what's the best approach they can use option A is to use AWS config rules to detect public buckets and auto remediate option B is to enable cloud trail to log all s3 changes option C is to set up cloud watch alarms for public bucket events and option D is to use I am policies or service control policies with explicit deny think about it the correct answer here is option D that is to use I am policies or service control policies with explicit deny here's the key inside the question asks how to prevent not detect not to remediate not to prevent AWS config detects non-compliance after it happens then it can remediate but to actually prevent users from making buckets public you need I am or a cp with explicit deny on the s3 put bucket policy or put public access block actions so why the other answer is wrong option A that's to use config rules to detect public buckets and auto remediate does not prevent the initial action option B that is to enable cloud trail to log s3 changes only logs but doesn't prevent an option C which is to set up cloud watch alarms for public bucket events again alerts after the fact doesn't prevent so for an example watch for the word prevent in the question config detects I am or cp prevents so for a memory hook think like config as a security camera whereas I am or a cp as a dolog question number 22 cloud watch ram monitoring question is an easy to instance is experiencing memory pressure but cloud watch shows no memory metrics wise this option A the cloud watch agent or unified agent must be installed to capture memory metrics option B ram is not tracked by cloud watch option C the instance needs to be larger an option D detailed monitoring isn't enabled here think about it the correct answer here is option A that's cloud watch agent must be installed for memory metrics and here's why AWS can see cpu network and this metrics from hypervisor outside the VM but memory that's ram and this space inside the file system required an agent running inside the operating system the cloud watch unified agent is the modern solution install it on easy to configure what metrics to collect and it publishes ram the space and other OS level metrics as custom metrics so why the other answers wrong option B that is ram is not tracked by cloud watch it's a bit misleading because ram can be tracked but requires the agent option C which is the instance needs to be larger doesn't address this monitoring gap an option D which is detailed monitoring isn't enabled is wrong because detailed monitoring increases frequency that's one minute versus five minutes but doesn't add new metric types for an example pure remember AWS CEO VM from the outside not the inside if you want information like the ram or disk inside the file system you need to use a unified agent instead want to question number 23 cloud watch logs real time processing question is an application generates logs that need to be processed in real time for security alerts what's the best approach to use option A use cloud watch logs insights to query logs hourly option B use cloud watch logs subscriptions to stream to lambda or kinesis option C export logs to s3 hourly and process with Athena and option D setup cloud watch alarms on all log entries think about it the correct answer here is option B that is to use cloud watch logs subscriptions and here's the explanation log subscriptions are designed for real time streaming of log events to other destinations lambda for custom processing kinesis data streams or firehose for further pipeline processing as logs arrive they're immediately forwarded so why are the other answers wrong option A that is to use cloud watch logs insights to query logs hourly that is used for querying historical logs not real time processing option C that's export logs to s3 hourly and and professional. with Athena, is wrong because it can take up to 12 hours for it to become available, it's not real-time. An option D that is to set up cloud watch alarms, can't be set on all log entries practically and have aggregation periods there. Okay, for an exam tip here, remember real-time log processing equals to subscriptions. Historical log queries equals to insides, and bulk archival that's not real-time equals to S3 export. On to question number 24, composite alarms. Question is, a team is getting flooded with cloud watch alarms when any metric is an alarm state. They only want to be alerted when high CPU and high IOPS happen simultaneously. What's the solution? Option A is to create more individual alarms with stricter thresholds. Option B is to disable some of the alarms. Option C is to use composite alarms and AND logic combining the existing alarms. And option D is to use SNS message filtering. Think about it. The correct answer here is option C that is to use composite alarms with AND logic and here's why. Composite alarms wash the state of multiple other alarms and combine them with AND or logic. You create individual CPU and IOPS alarms which still trigger their own actions if you want, but then you can create a composite alarm that only triggers when both are in alarm state. This dramatically reduces alarm noise. Now why the other answer is wrong? A makes the problem worse that is to create individual alarms with stricter thresholds. Option B means missing real issues that's to disable some of the alarms. And option D, which is to use SNS for message filtering, it could help but doesn't solve the root cause of triggering on individual conditions. So for an example, when you want to only be alerted when multiple conditions are true, then you want to use composite alarms with AND logic. It's great for reducing alarm fatigue. And now let's cover some questions from disaster recovery topic. Question number 25, RPO versus RTO definition. Question is, a company specifies that DR requirement as RPO of 5 minutes and RTO of 1 hour. What does this mean? Option A, maximum 5 times downtime with 1 hour to restore data. Option B, backups done every 5 minutes system check every 1 hour. Option C, 5 minutes to detect 1 hour to recover. Option D, maximum 5 minutes of data loss with 1 hour maximum downtime. Think about it. The correct answer here is Option D that's maximum 5 minutes of data loss with 1 hour maximum downtime. And here's the key distinction. RPO stands for recovery point objective equals to how much data you can afford to lose that's measured before the disaster. RTO on the other hand, that's recovery time objective equals to how long you can be down that's measured after the disaster. So RPO 5 minutes means data backed up every 5 minutes or continuously replicated. RTO of 1 hour here means that the system is backup within 1 hour of that failure. Option A, that's maximum 5 times downtime with 1 hour to restore, flips RPO and RTO. This is the most common confusion. Option B is unrelated to RPO and RTO definitions and C is detection of time and not RTO here. So for an exam tip and the memory hook, RPO remember is the past data loss looking back and RTO is the future that is downtime looking forward data versus downtime. On to question number 26, DR strategy selection. An E-commerce company can tolerate 15 minutes downtime and 5 minutes data loss. Cos matters but availability is critical. They need a DR strategy. What's the best strategy? Option A, backup and restore, option B, warm standby, option C, pided light and option D, multi-site or hot site. Think about it. The correct answer here is option B that is warm standby and here's the reasoning. 15 minute RTO requires servers already running, not just provisioned from backups. 5 minute RPO requires continuous data replication here. Cos matters that rules out multi-site that's full prediction scale costs 2x times. Pided light has app servers off which would take longer than 15 minutes to start up in scale. Warm standby is full systems running at minimum size with continuous replication that hits the sweet spot here. A, that's backup and restore equals to hours or days of RTO. Option C, that's pilot light equals app servers off. Scaling up here takes more than 15 minutes typically and option D multi-sites is an overkill for the scenario and reset the cost matters here. For an example, match strategy to RTO and up you don't over-engineer and for a memory hook you want the thing of warm standby as a backup band rehearsed on stage that's playing softly. On to question number 27, AWS backup versus elastic disaster recovery. The question is, a company has critical oracle databases running on premise. They need to protect them with continuous replication to AWS and the ability to fail over to AWS in minutes if their data center fails. What service is best? Option A, AWS elastic disaster recovery or DRS. Option B, AWS backup. Option C, database migration service or DMS. And option D storage gateway. Think about it. The correct answer here is option A, AWS elastic disaster recovery or DRS. And here's why. AWS elastic disaster recovery formally called cloud endure is specifically designed for protecting on premise virtual and non-AW service. It provides continuous block level replication and provides low cost EC2 EBS staging in AWS. The recovery is generally in minutes when disaster strikes. So why are the other answers wrong? Option B, that is to use AWS backup is wrong because AWS backup is for backing up AWS native services not on premise infrastructure. And option C, database migration service is wrong because DMS migrates databases but isn't designed for whole server DR with fast failover. And option D storage gateway is for hybrid storage not for DR failure. So for an example here, AWS backup handles inside AWS elastic disaster recovery on the other hand actually replicates from outside AWS to inside AWS that's inside versus outside. Okay, on to question number 28, multi-az versus DR. The question is, a company has ideas multi-az deployment and claims they have disaster recovery is this correct? Option A, yes, multi-az provides full disaster recovery. Option B, yes, but only for the database tier. Option C, multi-az and DR are the same thing. Option D, no, multi-az is high availability within a region not cross-region DR. Okay, think about it. The correct answer here is D, multi-az is high availability within a region not cross-region DR. Here's the critical distinction that the exam loves to test. RDS multi-az provides a standby in a different AZ but the same region. If the whole region fails, multi-az won't save you. For true cross-region disaster recovery, you need cross-region read replicas, Aurora global database or AWS backup with cross-region copies. A is wrong because multi-az is high availability not disaster recovery. Option B is wrong because multi-az doesn't address region level failures even for database tier alone. And option C, high availability and disaster recovery are different concepts within region versus across regions. For an exam tip, high availability equals to within region multi-az disaster recovery equals to across region cross region replication. On to question number 29, DMS and SCT. A company needs to migrate their on-premise Microsoft SQL server database to Amazon Aurora MySQL. Both schema conversions and data migration are required. What tool should they use? Option A, DMS only. Option B, SCT only. Option C, both DMS and SCT. And option D, AWS backup. Think about it. The correct answer here is option C, both DMS and SCT. And here's why. The migration here is heterogeneous SQL server that's Microsoft to Aurora MySQL, different engine. For heterogeneous migrations, you need both tools. A city that schema conversion tool converts the database schema from SQL server format to Aurora MySQL format. DMS data migration service handles the actual data migration. For homogeneous migrations that same engine like Postgres SQL to Postgres SQL, you only need DMS. No schema conversion is generally required. A DMS alone can't convert the schema between engines. Option B, SCT alone doesn't migrate data. Option D, AWS backup is for AWS native service backups, not for migrations. For an exam tip here, same engine equals to DMS only. Different engines equals to DMS plus SCT. Watch for the source and target engines in the question. And finally for question 30, Aurora Global Database. Question is, a SAS company needs cross region database replication with sub-second latency and failover under one minute. Option A, RDS multi-AZ, option B, Aurora Global Database, option. c, rd is read replicas across region and option d dynamo db global tables. Think about it. The correct answer here is option b, aurora global database, and here's why. aurora global database provides sub-second cross-region replication latency, failure under one minute, up to 10 secondary regions, and one primary region for rights, multiple secondaries for read. This is the goal standard for multi-region relational database architectures. Option A, rd is multi-az is within a region, not cross-region. Option C, cross-region read replicas have higher replication lag, often seconds to minutes, and generally slower, failure. And option D, dynamo db global tables, is for no sequel. It's not for relational data. So for an exam tip, when you see cross-region relational database, plus sub-second, plus fast-failure, then think aurora global database, memorize these specs. Alright, we have come to the end of the questions, so let's see how you did. Count up your correct answers out of the 30 total questions. If you got 25 to 30 correct, then you are doing an outstanding job here. I think your exam ready on these topics, you have a solid mastery of lambda messaging, cloud-friend monitoring, and disaster recovery. So keep doing practice questions to maintain your sharpness, and I'm sure you'll ace the exam. If you got between 20 and 24 correct, very well done. You're on the right track. You just have to review the questions you missed, especially the explanations. Go back to those specific episodes for the topics that give you trouble, and you're close to exam ready. If you got between 15 to 19 correct, you have a good foundation. You have a solid base, but need more study. Just identify your weakest areas, was it lambda, was it messaging, was it cloud-friend monitoring disaster recovery, focus your review there, take notes from the original episodes. If you got between 10 to 14 correct, that needs review. You have gaps to fill here. Don't worry, these are complex topics. Go back to episodes 12 to 16, take detailed notes, and retake this quiz. You will see significant improvement. If you scored below 10, then don't be discouraged, these episodes cover advanced material. Listen to them again carefully, take notes, and come back to this quiz. With focus study, you will master this material quickly. And on final tip, I want to leave you with is to take this quiz multiple times. Active recall through repeated testing is one of the most effective study methods. Each time you retake it, you will lock in these concepts more solidly. Now, if this Q&A supplement helped you, please consider leaving a five star rating on this podcast episode, and share it with anyone studying for the AWS Solutions Architect exam. The active recall format is proven to be two to three times more effective than passive review, and this episode is gold for exam prep. Also do let me know in the comments below if this new multi-choice format is helpful. So keep testing yourself, keep studying, and I will see you in the next episode. This is Balu signing off. Bye.