Go back

Episode 10.5: Exam Q&A - 35 Rapid-Fire Questions: ASG, S3, Storage, Databases & Route 53 | SAA-C03

21m 48s

Episode 10.5: Exam Q&A - 35 Rapid-Fire Questions: ASG, S3, Storage, Databases & Route 53 | SAA-C03

This interactive Q&A session covers critical AWS exam topics including Auto Scaling Groups, S3 storage classes, EBS and EFS storage, and Route 53 DNS configuration. Key concepts include ASG behavior under manual termination and scaling policies, with emphasis on target tracking and health checks. S3 storage classes are evaluated based on cost and access patterns, while versioning and replication rules highlight common exam traps—such as versioning applying only to new objects and one-way storage transitions. EBS and EFS use cases clarify that EBS volumes are region-locked and cannot be directly moved, and EFS supports multi-instance file sharing only for Linux, with Windows requiring FSX. For databases, RDS read replicas are better for high read loads than multi-AZ, while Aurora offers faster fail-over and automatic storage scaling. Route 53 routing policies such as latency-based routing and geolocation require default records to handle unmatched locations. Health checks are essential for failover and cannot directly access private resources, requiring workarounds like CloudWatch alarms. The session emphasizes active recall as a superior study method and provides a scoring system to assess exam readiness, recommending targeted review based on performance. Mastery of these topics is essential for success on the AWS Solutions Architect exam.

Transcription

2927 Words, 16991 Characters

English
Hey everyone, Balu here. Welcome to a special episode of Tech Talk with Balu, your interactive exam prep session. This is our second exam Q&A supplement. In the first one, we covered episodes one through five. That is easy too. I am global infrastructure and ELB. Today we are covering episode six through to nine. That's auto scaling groups, S3, storage, textures, databases, and route 53. Now here's how this works. I'm going to ask you 35 rapid fire questions. And after each question, I'll pause for five seconds. Try to answer in your head or even better say the answer out loud. Then I'll give you the correct answer with a quick explanation. This is active recall, one of the most effective study methods. Testing yourself is two to three times more effective than a passive review. Track your score as we go. At the end, I'll tell you what your score means for exam redness. So are you ready? Let's test your knowledge. If possible, grab a pen and paper to track your score. Let's start with auto scaling groups. Question one, auto scaling groups basic concepts. Question is you have a setting in auto scaling group with a minimum of two desired six and maximum of 10 instances. You manually terminate three instances. What does the ASG do? The answer is the ASG automatically launches three new instances to maintain the desired capacity of six. The desired capacity is the target and ASG always works to maintain it. Even if you manually terminate instances, ASG would replace them well done if you got that correct. Question number two, ASG scaling policies. You need ASG to automatically maintain an average CPU at 50%, which scaling policy should you use? The answer is target tracking scaling. This is the recommended policy. You set target like keep CPU at 50%, and ASG automatically creates both scale out and scaling policies to maintain that target. It's the easiest and the most common approach. On to question number three, ASG health checks. Your ASG uses easy to health checks and instances application crashes, but the instance keeps running. What happens now? The answer is nothing. The instance stays in service because easy to health checks only verify the instances running, not that the application works. For application level health checks you want to use ELB health checks instead. ELB checks if the application responds to HTTP requests. On to question number four, ASG life cycle hooks. You want to run a script to backup logs before an instance terminates. What ASG feature do you use? The answer is life cycle hooks, specifically a terminating life cycle hook. This pauses the instance in terminating weight state, giving your script time to backup the logs into S3. After the script completes, it calls the complete life cycle action API and the instance terminates. Question number five, ASG capacity constraints. An ASG has minimum of five desired of three and a maximum of ten. What actually happens? The answer is, ASG launches five instances, not three. Decide cannot be less than minimum. The relationship is always minimum, less than equal to the desired, less than equal to the maximum. AWS adjusts desired to five automatically here. Question number six, scaling policy types. You have predictable traffic that spikes every weekday at 8 AM, which scaling policy would you use? The answer is schedule scaling. For predictable patterns, schedule the scale out action, even before the traffic arrives like 7.45 AM daily, for example, we spoke about this in detail in our ASG episode. This is proactive, not reactive. The instances are ready then before the users arrive. Question number seven, ASG termination policy. When scaling, the ASG has instances in three A's with five, three, and two instances respectively, which ASG does the ASG terminate from? The answer is the ASG with five instances. ASG first balances across ASG by selecting the ASG with the most instances. Then within that ASG it terminates the oldest instance using the oldest launch template. Okay, now we move on to Amazon S3. Question number eight, S3 storage classes, the cost. This you need to store 100 TB of data that you will access once per year and can wait 12 hours for retrieval, which storage class do you want to use? The answer is S3 Glacier Deep Archive. It costs about one dollar per TB per month that would be the cheapest option. Standard retrieval takes 12 hours. That's for 100 TB that would be $100 per month instead of $2,300 with S3 Standard. So that would be a massive savings right there. Question number nine, S3 minimum storage duration. Question is, you store files in S3 Standard IA and delete them after 15 days. What charges do you incur? The answer is your charge for 30 days of storage. Standard IA has a 30 day minimum storage duration. Remember that. Even if you delete after 15 days, you pay for those 30 days. This trap appears constantly on the exam. Question number 10, S3 versioning. Question is that you enable versioning on a bucket with 50,000 existing objects then upload 10,000 new objects. How many objects have version IDs? Answer is that you would only have that for the 10,000 new objects. You need to remember that versioning only applies to objects uploaded after enabling versioning that is pre-existing objects have version ID equal to null. This is a common misconception. On to question 11, S3 replication. You enable cross region replication on a bucket with 100,000 objects in it. How many objects replicate to the destination? The answer is zero. CRR only replicates new objects uploaded after enabling replication. Existing objects, remember don't replicate automatically. To replicate existing objects, you want to use S3 batch replication as a separate operation. On to question number 12, S3 bucket names. Two AWS accounts want to create a bucket named MyAppData. Can they both do it? You guessed it right? It's a no. S3 bucket names are globally unique across all AWS accounts worldwide. Once one account creates MyAppData, no other account can use that name. It's like domain names. It's first come first served. On to question 13, S3 life cycle policies. Can you create a life cycle rule to automatically transition objects from S3 glacier back to S3 standard? Again, the answer is no. Storage class transitions are one way only. That's moving towards cheaper storage. You can move from standard to ia, ia to glacier, glacier to deep archive. You cannot automatically move back to a more expensive classes. What you can do is to manually restore but life cycle rules only go on one direction. Remember that. Question number 14, S3 multi-part upload. You have a 150 GB file to upload to S3. What upload method should you use? The answer is multi-part upload. It's recommended for files over 100 MB and required for files over 5 GB. Multi-part splits the file into parts, upload them in parallel for faster upload and it can resume if interrupted for 150 GB. This is mandatory. Okay, now we go to storage architecture topic. Question number 15, EBS easy lock. You're easy to instance in US East 1A needs to attach to an EBS volume in US East 1B. How do you do this? The answer is you cannot attach it directly. EBS volumes are easy locked. Remember that we talked about this multiple times. To move the volume, you want to create a snapshot of the volume in US East 1B. Then create a new volume from that snapshot in US East 1A. Then you attach to your instance. Okay, question number 16, EFS versus EBS use case. You have 10 web servers that need to share the same uploaded images. Do you use EBS or EFS? The answer is EFS. EFS is a network file system that multiple instances can mount to it simultaneously. All the 10 servers can mount to the same EFS and then everyone sees the same file. EBS on the other hand can only attach to one instance at a time except for multi-attach which is limited. Question number 17, EBS volume types. Question is, you need a boot volume for an easy to instance. Can you use an ST1 through put optimized HDD? The answer is no. Only. SSD volume types can be boot volumes, that is GB2, GB3, I/O1, or I/O2. HDD volumes like SD1 and SC1 cannot boot. Therefore, data storage with sequential access patterns are not for boot volumes. Question number 18, EFS, Linux only. Windows easy to instances need to share files. Can you use EFS? Answer is no, EFS only works with Linux. For Windows file sharing, use FSX for Windows file server. This is a very common exam trap. Remember, EFS is for Linux only. You use FSX for Windows. Question number 19, S3 as file system. Can you mount S3 as a traditional file system on EC2? No, you cannot natively, S3 is object storage, access to via HTTP APIs, it's not a mountable file system. There are third party tools like S3FS that can mount S3, but they have significant performance limitations. So for shared file systems, you want to use EFS. Question number 20, EBS multi-attach. You want to share an EBS volume across 20 instances in different Asys. Can you use multi-attach? Answer is no, multi-attach only works with I/O1 or I/O2 volumes. And it supports a maximum of 16 instances. And all the instances must be in the same Asys. For cross-Asys file sharing, you need EFS, but not EBS. Question number 21, storage cost comparison. Question is, for dev environment, what is the cheapest shared file storage option? It is EFS 1 zone I/A. EFS standard multi-AZ costs about 30 cents per GB. EFS 1 zone I/A costs about 0.016 dollars per GB, that's 90% savings. It's perfect for development where you don't need multi-AZ redundancy. OK, on to the next topic, databases. Question number 22, RDS multi-AZ versus read replicas. Your application has extremely high read load. Should you enable multi-AZ? Answer is no, multi-AZ is for high availability. It's not for scaling reads. The standby instance in multi-AZ does not serve traffic. For high read load, create read replicas instead. You can have up to 15 read replicas serving read traffic. Question number 23, RDS read replica replication. You write data to the primary RDS database and immediately read it from a read replica. Do you see the new data? The answer is maybe not immediately read replica replication is asynchronous with a small lag, which is usually in milliseconds two seconds. Reads are eventually consistent. You might see all data briefly until replication catches up. Question number 24, Aurora versus RDS fail over time. For fastest automatic fail over, you want to use RDS multi-AZ or Aurora. The answer is Aurora. Aurora fail over happens in under 30 seconds. RDS multi-AZ fail over takes place between 60 to 120 seconds. If minimizing downtime during fail over is critical for your use case, Aurora is always the better choice. On to question number 25, Aurora storage. Your Aurora database is approaching its storage limit. What do you need to do? Answer is nothing. This is a trick question. Aurora storage can autoscale up to 256 TBs automatically. You don't provision storage. It grows as you add data and shrinks as you delete data. Aurora never runs out of storage. Remember that. On to question number 26, RDS encryption. You have an unencrypted RDS database. Can you enable encryption on it? No, you can't directly. You must create a snapshot. Copy the snapshot with encryption enabled. Restore from the encrypted snapshot to create a new encrypted database. Then update your application to use the new database endpoint. Quite some steps. Question number 27. Elastic cache redis versus memcache. You need in-memory caching with automatic fail over in your use case. What would you use redis or memcache? You want to use redis? Redis supports multi-az with automatic fail over and read replicas for high availability. Memcache has no replication or fail over, remember that. For example, questions particularly requiring high availability, you always choose redis. Okay, question number 28. Database load prediction. Your database is overwhelmed with read queries. Do you add more replicas or do you use elastic cache? You would use elastic cache because that will reduce load more dramatically. Now, while read replicas help elastic cache caches data in memory with microsecond latency and can reduce database queries by 80% or more. So what I would do is to check the cache first, read from the database on misses and then write to cache for the next time. Question number 29. Adios stopped instance. You stop an adios database to save costs during a weekend. What charges continue? Answer a storage charges continue. You only stop paying for compute when the database is stopped. EBS volume storing your data still exists and still cost money. For long term shutdowns, what you would do is snapshot and then delete the database. On to question number 30. Aurora global database. What's the typical replication lag for Aurora global database? The answer is under one second. Aurora global replicates to up to 10 secondary regions with typically under one second of lag. This enables disaster recovery with R2 under one minute and provides low latency reads for global uses. On to our next section, Amazon Route 53. Question number 31. C name for zone apex. Question is, you want to point example.com to a load balancer. Can you use a C name record? No, you can't. C name records cannot be used for zone apex. The naked domain like example.com cannot use it. This is a DNS specification limitation, so solution is to use an alias record instead. Alias records work for zone apex and are free for AWS resources. Question number 32. Routing policy selection. You want to route users to the region with the lowest network latency. Which routing policy would you use? You would use latency based routing. Route 53 evaluates the actual network latency from the user to each AWS region and returns the IP of the region with the lowest latency. This gives the users the best performance. Question number 33. Failure routing requirements. For failure routing, our health checks mandatory. The answer is yes, for the primary resource it is mandatory. Without health checks on the primary, route 53 doesn't know when to fail over to the secondary. Health checks are what triggers the fail over. This is mandatory, not an option. Question number 34. Geolocation default record. You configure geolocation routing with records for US and Europe. A user from Australia queries your domain. What happens without a default record? The answer is users get no response. Geolocation routing is strict. If there's no match record for the user's location and no default record, Route 53 returns nothing. So you want to always create a default record for unmatched locations. And finally, question number 35. Health checks for private resources. Can you create a health check for an adias database in a private subnet? The answer is not directly. Health checkers are outside your VPC and cannot access private resources. So solution is to create a cloud watch metric for the adias database. Create a cloud watch alarm based on that metric. Then create a route 53 health check that monitors the alarm state. When the alarm goes to alarm state, the health check fails. Alright, so let's see how you did. Count up your correct answers out of the 35 total questions. If you're interested in this, please subscribe to our channel. If you got 30-35 correct outstanding work, you are exam ready. You have strong mastery of auto scaling, S3 storage, data bases and Route 53. Keep doing practice questions and you will ace the exam. If you got about 25-29 correct, very good you are on the right track, review the questions you missed, go back to those specific episodes and you will be ready. If you got about 20-24 correct, you have good foundation but you need more study, focus on the weakest area, was it storage classes, was it adious, was it a rora topic, was it seen in versus alias, go back to those episodes and take notes. If you got 15-19 correct, you have gaps to fill. These episodes cover critical exam topics. So listen to them again, take detailed notes and retake this quiz. If you got below 15 don't worry, this material is complex, go back to the episode 6-10 and listen to them carefully, take notes and come back to the quiz. You will improve quickly, I promise. Remember active recall through testing is one of the most effective study methods. I recommend you to retake this quiz multiple times until you can answer every question correctly without hesitation. The actual exam will test these exact topics, ASG capacity constraints, S3 storage classes, Minimums, EBS, AZ limitations, multi AZ versus read replicas, C name versus alias and so forth. Master these and your well on your way to passing. If this interactive Q&A helped you, please do consider to leave a 5 star rating on Spotify and share it with anyone studying for the AWS solutions architect exam. Keep testing yourself, keep studying and I will see you in the next episode. This is Baloo signing off, bye.

Podcast Summary

Key Points:

  1. Auto Scaling Groups (ASG) maintain desired capacity by launching new instances when manually terminated, ensuring the target number is preserved.
  2. Target tracking scaling policies automatically adjust instance counts to maintain a specific metric (e.g., CPU at 50%), making them ideal for dynamic workloads.
  3. ASG health checks only verify instance availability; application-level health requires ELB health checks to validate HTTP responses.
  4. Life cycle hooks like terminating hooks allow scripts to back up logs before instance termination, enabling safe and automated cleanup.
  5. S3 storage classes like Glacier Deep Archive offer lowest cost for infrequent access, while Standard IA has a 30-day minimum retention period.
  6. Versioning applies only to objects uploaded after enabling it; pre-existing objects have no version IDs.
  7. Cross-region replication (CRR) only replicates new objects; existing objects require S3 Batch Replication.
  8. Route 53 cannot use CNAME records at zone apex; alias records are required, and health checks are mandatory for failover.

Summary:

This interactive Q&A session covers critical AWS exam topics including Auto Scaling Groups, S3 storage classes, EBS and EFS storage, and Route 53 DNS configuration. Key concepts include ASG behavior under manual termination and scaling policies, with emphasis on target tracking and health checks. S3 storage classes are evaluated based on cost and access patterns, while versioning and replication rules highlight common exam traps—such as versioning applying only to new objects and one-way storage transitions.

EBS and EFS use cases clarify that EBS volumes are region-locked and cannot be directly moved, and EFS supports multi-instance file sharing only for Linux, with Windows requiring FSX. For databases, RDS read replicas are better for high read loads than multi-AZ, while Aurora offers faster fail-over and automatic storage scaling. Route 53 routing policies such as latency-based routing and geolocation require default records to handle unmatched locations.

Health checks are essential for failover and cannot directly access private resources, requiring workarounds like CloudWatch alarms. The session emphasizes active recall as a superior study method and provides a scoring system to assess exam readiness, recommending targeted review based on performance. Mastery of these topics is essential for success on the AWS Solutions Architect exam.

FAQs

The ASG automatically launches new instances to maintain the desired capacity. It ensures the target number of instances is always met, regardless of manual terminations.

Target tracking scaling. This policy automatically adjusts instance counts to maintain the specified target, such as 50% CPU usage, ensuring consistent performance.

The instance remains in service because EC2 health checks only verify if the instance is running, not if the application is functioning properly. Application-level checks require ELB health checks.

Use a terminating life cycle hook. This pauses the instance termination process, allowing a script to backup logs, typically to S3, before the instance is terminated.

Five instances are launched. The desired capacity cannot go below the minimum, so the ASG adjusts it to 5 automatically to maintain constraints.

Schedule scaling. This policy proactively scales out before traffic arrives, ensuring resources are ready and reducing latency during peak times.

Chat with AI

Loading...

Pro features

Go deeper with this episode

Unlock creator-grade tools that turn any transcript into show notes and subtitle files.