5 exercises — Auto Scaling Groups, S3 Lifecycle policies, IAM roles, Direct Connect, and SQS. The architecture vocabulary that drives exam questions.
0 / 26 completed
1 / 26
An AWS architecture uses an Application Load Balancer (ALB) in front of an Auto Scaling Group. What does the Auto Scaling Group do?
An Auto Scaling Group (ASG) maintains fleet health by launching new EC2 instances when load increases (scale out) and terminating instances when load decreases (scale in). You configure a minimum, desired, and maximum instance count. Scaling is triggered by scaling policies (e.g. CPU > 70%) or scheduled actions.
The ALB is a separate service that distributes incoming traffic across healthy instances in the ASG. Together they provide both horizontal scaling and high availability.
SSL termination can happen at the ALB, not the ASG. Multi-AZ replication is a database or S3 concept, not ASG.
2 / 26
"We use S3 Lifecycle policies to move objects to cheaper storage classes." What does transitioning an object to S3 Glacier Instant Retrieval mean?
S3 Lifecycle policies automate moving objects between storage classes to reduce cost as data ages. Key classes to know:
S3 Standard — frequent access, highest cost S3 Intelligent-Tiering — auto-moves based on access patterns S3 Standard-IA (Infrequent Access) — lower cost, retrieval fee S3 Glacier Instant Retrieval — archive, millisecond retrieval S3 Glacier Flexible — archive, minutes to hours retrieval S3 Glacier Deep Archive — cheapest, 12 hours retrieval
Lifecycle policies do NOT delete objects unless you configure an expiration action. Replication is a separate feature (Cross-Region Replication). Compression/dedup are not native S3 features.
3 / 26
Complete the sentence: "We attach an IAM role to the EC2 instance instead of storing AWS credentials in the application code — this follows the principle of _____."
"Least privilege" means granting only the permissions actually needed — nothing more. An IAM role attached to an EC2 instance provides temporary credentials automatically via the instance metadata service (IMDS). The application uses the AWS SDK which fetches these credentials without any hardcoded access keys.
This is the AWS-recommended approach because: • Credentials rotate automatically — no expired keys • No secrets stored in code, environment variables, or config files • Permissions are scoped to only what the application needs
Defence in depth = using multiple security layers. Zero trust = never trust, always verify network identity. Both are valid security concepts but not what this sentence is about.
On the SAA-C03 exam, questions about "securely providing AWS credentials to an application running on EC2" always point to IAM roles, not access keys.
4 / 26
A company needs to connect its on-premises data centre to its AWS VPC with a dedicated, private connection (not over the public internet). The correct AWS service is:
AWS Direct Connect provides a dedicated, private physical connection between your on-premises network and AWS. It doesn't go over the public internet, so it offers: • Consistent low latency • Higher bandwidth (1 Gbps, 10 Gbps, 100 Gbps) • Reduced data transfer costs vs internet egress
Key vocabulary distinctions for the exam: • AWS Site-to-Site VPN — encrypted tunnel over the public internet, quick to set up, variable latency • Direct Connect — dedicated line, weeks lead time, consistent latency — used when the question says "private", "dedicated", or "consistent bandwidth" • Transit Gateway — connects multiple VPCs and on-premises networks together (a hub), not a connectivity method itself • VPC Peering — connects two VPCs, not on-premises to AWS
Exam trigger words: "dedicated connection", "private connection", "not public internet" → always Direct Connect.
5 / 26
A solution uses Amazon SQS between a web tier and a processing tier. What problem does SQS solve here?
Amazon SQS (Simple Queue Service) is a fully managed message queue. It enables loose coupling between components — a key architectural principle tested throughout the SAA-C03 exam.
Without SQS: if the web tier sends 1,000 requests/second and the processing tier can handle 200/second, the processing tier fails.
With SQS: the web tier enqueues 1,000 messages. The processing tier polls at 200/second. Messages queue up and are processed when capacity is available. Neither tier knows or cares about the other's speed.
Exam vocabulary: • Decouple = separate so neither depends on the other's availability or speed • Enqueue / produce = add a message to the queue • Dequeue / consume / poll = take a message from the queue • Dead-letter queue (DLQ) = where failed messages go after max retries • Visibility timeout = how long a message is hidden after being read (prevents double-processing)
SQS does NOT cache results (that's ElastiCache) or route by content (that's SNS topic filtering).
6 / 26
Reviewer: 'I'm seeing a lot of calls to the DescribeInstances API. Can you explain why we're not using the DescribeAutoScalingGroups API to get the instance details for scaling decisions? It seems less efficient.'
What is the reviewer primarily questioning?
The reviewer is focused on optimization and best practices. Calling DescribeInstances repeatedly when you only need information about the auto-scaling group's configuration is inefficient. The DescribeAutoScalingGroups API provides a consolidated view of scaling policies and group details, making it the more appropriate choice for determining scaling decisions. This highlights the importance of understanding the nuances of AWS APIs beyond simply knowing they exist.
7 / 26
PR Description: 'Implementing the new user authentication flow. Utilizing Lambda functions for token generation and validation via the AWS Cognito service.'
During a code review, another developer comments: 'This Lambda function seems quite heavyweight – it's performing a full Cognito user pool query every time a request comes in. Can you elaborate on why we're using Cognito directly here instead of leveraging the Cognito User Sessions feature?'
This question assesses understanding of the nuances between direct API usage and feature-level integration within AWS Cognito. The reviewer's comment highlights a potential inefficiency: repeatedly querying the entire user pool. While flexibility is *a* reason to use the full API, the key point here is 'strict control over user data access'. Option 3 correctly identifies this focus – security best practice often dictates minimizing direct interaction with core services when higher-level features exist to manage that risk.
8 / 26
{code}
During a standup meeting, Sarah says: 'We're seeing increased latency when accessing our DynamoDB tables. I suspect it's related to the number of concurrent requests.' David replies: 'Let's investigate the table's throughput capacity and provisioned IOPS settings.'
What is David primarily asking Sarah to examine?
David is focusing on performance monitoring. While understanding application code or security groups *could* contribute to latency issues, his immediate concern is identifying whether the underlying DynamoDB resources are appropriately sized for the workload. Throughput capacity and IOPS directly impact DynamoDB's ability to handle concurrent requests – these are the key metrics to investigate when experiencing increased latency.
9 / 26
{code} During a Slack conversation about optimizing API calls to DynamoDB, Alex says: 'I'm getting really slow response times when querying the `users` table. I suspect it's because we're not using indexes effectively.' Ben replies: 'Let's examine the Global Secondary Index (GSI) configuration for that table – specifically, are you using a mixed mode GSI and if so, how are your key conditions defined?' What is Ben primarily asking Alex to investigate?
Ben is focusing on the GSI – a critical component for optimizing DynamoDB queries. The question highlights slow response times linked to querying, so it's logical to investigate how indexes are configured. Using a mixed-mode GSI with poorly defined key conditions can severely impact performance, leading to inefficient lookups and increased latency. Therefore, examining the GSI configuration is the most pertinent initial step.
10 / 26
Reviewer: 'I'm seeing a lot of calls to the DescribeInstances API. Can you explain why we're not using the DescribeAutoScalingGroups API to get the instance details for scaling decisions? It seems less efficient.'
What is the reviewer primarily questioning?
The reviewer is focused on optimization and best practices. Calling DescribeInstances repeatedly when you only need information about the auto-scaling group's configuration is inefficient. The DescribeAutoScalingGroups API provides a consolidated view of scaling policies and group details, making it the more appropriate choice for determining scaling decisions. This highlights the importance of understanding the nuances of AWS APIs beyond simply knowing they exist.
11 / 26
PR Description: 'Implementing the new user authentication flow. Utilizing Lambda functions for token generation and validation via the AWS Cognito service.'
During a code review, another developer comments: 'This Lambda function seems quite heavyweight – it's performing a full Cognito user pool query every time a request comes in. Can you elaborate on why we're using Cognito directly here instead of leveraging the Cognito User Sessions feature?'
This question assesses understanding of the nuances between direct API usage and feature-level integration within AWS Cognito. The reviewer's comment highlights a potential inefficiency: repeatedly querying the entire user pool. While flexibility is *a* reason to use the full API, the key point here is 'strict control over user data access'. Option 3 correctly identifies this focus – security best practice often dictates minimizing direct interaction with core services when higher-level features exist to manage that risk.
12 / 26
{code}
During a standup meeting, Sarah says: 'We're seeing increased latency when accessing our DynamoDB tables. I suspect it's related to the number of concurrent requests.' David replies: 'Let's investigate the table's throughput capacity and provisioned IOPS settings.'
What is David primarily asking Sarah to examine?
David is focusing on performance monitoring. While understanding application code or security groups *could* contribute to latency issues, his immediate concern is identifying whether the underlying DynamoDB resources are appropriately sized for the workload. Throughput capacity and IOPS directly impact DynamoDB's ability to handle concurrent requests – these are the key metrics to investigate when experiencing increased latency.
13 / 26
{code} During a Slack conversation about optimizing API calls to DynamoDB, Alex says: 'I'm getting really slow response times when querying the `users` table. I suspect it's because we're not using indexes effectively.' Ben replies: 'Let's examine the Global Secondary Index (GSI) configuration for that table – specifically, are you using a mixed mode GSI and if so, how are your key conditions defined?' What is Ben primarily asking Alex to investigate?
Ben is focusing on the GSI – a critical component for optimizing DynamoDB queries. The question highlights slow response times linked to querying, so it's logical to investigate how indexes are configured. Using a mixed-mode GSI with poorly defined key conditions can severely impact performance, leading to inefficient lookups and increased latency. Therefore, examining the GSI configuration is the most pertinent initial step.
14 / 26
Reviewer: 'I'm seeing a lot of calls to the DescribeInstances API. Can you explain why we're not using the DescribeAutoScalingGroups API to get the instance details for scaling decisions? It seems less efficient.'
What is the reviewer primarily questioning?
The reviewer is focused on optimization and best practices. Calling DescribeInstances repeatedly when you only need information about the auto-scaling group's configuration is inefficient. The DescribeAutoScalingGroups API provides a consolidated view of scaling policies and group details, making it the more appropriate choice for determining scaling decisions. This highlights the importance of understanding the nuances of AWS APIs beyond simply knowing they exist.
15 / 26
PR Description: 'Implementing the new user authentication flow. Utilizing Lambda functions for token generation and validation via the AWS Cognito service.'
During a code review, another developer comments: 'This Lambda function seems quite heavyweight – it's performing a full Cognito user pool query every time a request comes in. Can you elaborate on why we're using Cognito directly here instead of leveraging the Cognito User Sessions feature?'
This question assesses understanding of the nuances between direct API usage and feature-level integration within AWS Cognito. The reviewer's comment highlights a potential inefficiency: repeatedly querying the entire user pool. While flexibility is *a* reason to use the full API, the key point here is 'strict control over user data access'. Option 3 correctly identifies this focus – security best practice often dictates minimizing direct interaction with core services when higher-level features exist to manage that risk.
16 / 26
{code}
During a standup meeting, Sarah says: 'We're seeing increased latency when accessing our DynamoDB tables. I suspect it's related to the number of concurrent requests.' David replies: 'Let's investigate the table's throughput capacity and provisioned IOPS settings.'
What is David primarily asking Sarah to examine?
David is focusing on performance monitoring. While understanding application code or security groups *could* contribute to latency issues, his immediate concern is identifying whether the underlying DynamoDB resources are appropriately sized for the workload. Throughput capacity and IOPS directly impact DynamoDB's ability to handle concurrent requests – these are the key metrics to investigate when experiencing increased latency.
17 / 26
{code} During a Slack conversation about optimizing API calls to DynamoDB, Alex says: 'I'm getting really slow response times when querying the `users` table. I suspect it's because we're not using indexes effectively.' Ben replies: 'Let's examine the Global Secondary Index (GSI) configuration for that table – specifically, are you using a mixed mode GSI and if so, how are your key conditions defined?' What is Ben primarily asking Alex to investigate?
Ben is focusing on the GSI – a critical component for optimizing DynamoDB queries. The question highlights slow response times linked to querying, so it's logical to investigate how indexes are configured. Using a mixed-mode GSI with poorly defined key conditions can severely impact performance, leading to inefficient lookups and increased latency. Therefore, examining the GSI configuration is the most pertinent initial step.
18 / 26
Reviewer: 'I'm seeing a lot of calls to the DescribeInstances API. Can you explain why we're not using the DescribeAutoScalingGroups API to get the instance details for scaling decisions? It seems less efficient.'
What is the reviewer primarily questioning?
The reviewer is focused on optimization and best practices. Calling DescribeInstances repeatedly when you only need information about the auto-scaling group's configuration is inefficient. The DescribeAutoScalingGroups API provides a consolidated view of scaling policies and group details, making it the more appropriate choice for determining scaling decisions. This highlights the importance of understanding the nuances of AWS APIs beyond simply knowing they exist.
19 / 26
PR Description: 'Implementing the new user authentication flow. Utilizing Lambda functions for token generation and validation via the AWS Cognito service.'
During a code review, another developer comments: 'This Lambda function seems quite heavyweight – it's performing a full Cognito user pool query every time a request comes in. Can you elaborate on why we're using Cognito directly here instead of leveraging the Cognito User Sessions feature?'
This question assesses understanding of the nuances between direct API usage and feature-level integration within AWS Cognito. The reviewer's comment highlights a potential inefficiency: repeatedly querying the entire user pool. While flexibility is *a* reason to use the full API, the key point here is 'strict control over user data access'. Option 3 correctly identifies this focus – security best practice often dictates minimizing direct interaction with core services when higher-level features exist to manage that risk.
20 / 26
{code}
During a standup meeting, Sarah says: 'We're seeing increased latency when accessing our DynamoDB tables. I suspect it's related to the number of concurrent requests.' David replies: 'Let's investigate the table's throughput capacity and provisioned IOPS settings.'
What is David primarily asking Sarah to examine?
David is focusing on performance monitoring. While understanding application code or security groups *could* contribute to latency issues, his immediate concern is identifying whether the underlying DynamoDB resources are appropriately sized for the workload. Throughput capacity and IOPS directly impact DynamoDB's ability to handle concurrent requests – these are the key metrics to investigate when experiencing increased latency.
21 / 26
{code} During a Slack conversation about optimizing API calls to DynamoDB, Alex says: 'I'm getting really slow response times when querying the `users` table. I suspect it's because we're not using indexes effectively.' Ben replies: 'Let's examine the Global Secondary Index (GSI) configuration for that table – specifically, are you using a mixed mode GSI and if so, how are your key conditions defined?' What is Ben primarily asking Alex to investigate?
Ben is focusing on the GSI – a critical component for optimizing DynamoDB queries. The question highlights slow response times linked to querying, so it's logical to investigate how indexes are configured. Using a mixed-mode GSI with poorly defined key conditions can severely impact performance, leading to inefficient lookups and increased latency. Therefore, examining the GSI configuration is the most pertinent initial step.
22 / 26
Reviewer: 'The Lambda function is using a synchronous API call to S3. This will likely lead to timeouts if the bucket is unavailable. Could we explore an asynchronous approach with SQS for better resilience?' What does the reviewer primarily suggest? aws s3 sync
The reviewer is focusing on improving the Lambda function's resilience to potential S3 unavailability. Option C—using SQS for asynchronous processing—directly addresses this concern by decoupling the Lambda function from the direct S3 call and introducing a more robust mechanism for handling failures. Options A, B, and D represent alternative approaches that don't address the core issue of timeout vulnerabilities.
23 / 26
Alex: 'I'm seeing a high number of errors in our CloudWatch logs related to DynamoDB transactions. Specifically, I'm seeing 'ProvisionedThroughputExceededException' frequently. It seems like we might be hitting the read capacity unit limits.' What does Alex likely mean? Error: ProvisionedThroughputExceededException
Alex's message indicates an issue with DynamoDB's throughput limits. The `ProvisionedThroughputExceededException` specifically points to exceeding the configured read capacity units—meaning the application is attempting to read more data than DynamoDB can handle at its current provisioned settings. Options B, C and D are possible contributing factors but don't explain the *cause* of the error message.
24 / 26
'Updating our EC2 instance fleet with a new AMI. Using Auto Scaling Groups to manage scaling and Elastic Load Balancing for traffic distribution. Monitoring metrics via CloudWatch alarms.' What is the primary benefit highlighted in this PR description? aws ec2 auto-scaling group
The description emphasizes the key benefits of Auto Scaling Groups and Elastic Load Balancing: dynamically adjusting resources based on demand (A) and distributing traffic efficiently across multiple instances (B). While IaC and CDN are important concepts, they aren't directly highlighted as primary outcomes in this specific update. The core focus is on scalability and availability.
25 / 26
David: 'We've noticed a significant spike in API requests to our Redis cache. I suspect this is triggering eviction policies and impacting performance.' What potential issue does David identify? redis evict-policy
David's observation suggests a potential bottleneck related to request volume. A high number of concurrent requests can overwhelm the cache, triggering eviction policies (C) and impacting overall performance. While memory capacity (A) is a possibility, the focus here is on *how* the cache is being used, not just its size.
26 / 26
Reviewer: 'I'm seeing frequent calls to the `DescribeScheduledActions` API. Can you explain why we aren't using `DescribeAutoScalingGroups` to determine which scaling actions are currently scheduled? It seems less efficient and provides a more targeted view.' What is the reviewer suggesting? aws autoscaling describe-scheduled-actions
The reviewer argues that using `DescribeAutoScalingGroups` offers a more targeted approach compared to `DescribeScheduledActions`. `DescribeScheduledActions` provides information about *all* scheduled actions, whereas `DescribeAutoScalingGroups` allows you to specifically query for the actions related to an Auto Scaling Group—leading to reduced API calls and improved efficiency. Option B is incorrect as it describes the *reasoning*, not the core difference.
What will I practice in "AWS Core Vocabulary — Certification Language Exercises"?
This is a Certification Prep exercise set. It walks through 26 scenario-based multiple-choice questions built around real usage of Certification Prep terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 26 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Certification Prep vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Certification Prep exercises?
See the Certification Prep exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Certification Prep vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.