How many questions are on the SAA-C03 exam and how long is it?

The exam delivers 65 questions in 130 minutes, which works out to two minutes per item. Only 50 of those items are scored, and the remaining 15 are unscored pilot questions that AWS never identifies, so you have to answer all 65 as if they count. Every Sailor.sh mock exam gives you 65 questions in the same 130 minute window and scores all of them, so the pacing you practice is the pacing you face.

What is the passing score for the SAA-C03 exam?

SAA-C03 is scored on a scaled range of 100 to 1000 and you need 720 or higher to pass. The model is compensatory, so you pass on the overall score rather than domain by domain, and because exam forms are equated a scaled 720 is not the same as answering 72 percent of items correctly. Every exam in the Sailor.sh bundle totals exactly 1000 marks and reports against the same 720 bar.

What topics does the SAA-C03 exam cover?

Four domains: Design Secure Architectures at 30 percent, Design Resilient Architectures at 26 percent, Design High-Performing Architectures at 24 percent, and Design Cost-Optimized Architectures at 20 percent. Expect IAM policy evaluation, AWS Organizations and service control policies, VPC design and endpoints, encryption with AWS KMS, decoupling with Amazon SQS and Amazon SNS, Auto Scaling and load balancing, Amazon RDS and Amazon DynamoDB choices, Amazon S3 storage classes and lifecycle rules, and the purchasing options that decide the bill.

What experience do I need before taking SAA-C03?

AWS recommends at least one year of hands-on experience designing cloud solutions that use AWS services. There is no formal prerequisite and no exam you must sit first. If you can build a VPC with public and private subnets, put an Auto Scaling group behind a load balancer, and explain why a bucket policy and an IAM policy are both consulted on a request, you are ready to start preparing.

Do these practice questions include a hands-on lab?

No, and neither does the real exam. SAA-C03 uses two response types only, multiple choice with one correct answer and multiple response with two or more, so written questions are the right rehearsal. Multiple response items here are scored all or nothing, exactly as they are on exam day, so a partly correct selection earns nothing.

How should I prepare for the SAA-C03 exam?

Start with the official SAA-C03 exam guide and build the things it describes in your own account: a VPC with public and private subnets, an Auto Scaling group behind an Application Load Balancer, an S3 lifecycle rule, a cross-account role. Read the AWS Well-Architected Framework pillars, because the four exam domains map onto them one to one. Finish with full length mock exams under the real 130 minute limit, read the explanation for every miss, and repeat your weakest domain until you clear 720 consistently.

AWS Certified Solutions Architect - Associate (SAA-C03): Free Practice Test with AI Feedback

Q: What is the AWS Certified Solutions Architect - Associate (SAA-C03) certification?

SAA-C03 is the associate level credential for the solutions architect role. It validates that you can design solutions on the AWS Well-Architected Framework, which in practice means choosing the service and configuration that best satisfies a stated business constraint on security, resilience, performance, or cost. It is the AWS certification most cloud job descriptions ask for, and the credential is valid for three years.

Question #1 Design Resilient Architectures

A company runs an order intake API on AWS Lambda. Each invocation opens a new connection to an Amazon RDS for PostgreSQL Multi-AZ DB instance and closes it on completion. During marketing campaigns, concurrency climbs to several thousand invocations per minute, and the database begins rejecting requests with too many connections errors while its CPU stays under 20 percent. The database team also reports that Multi-AZ failover tests leave the API returning errors for several minutes because functions keep retrying against cached DNS entries. The development team can change the connection string and IAM configuration but has no capacity to rewrite the data access layer. Which solution will meet these requirements with the LEAST application change?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Create an Amazon RDS Proxy in front of the DB instance and point the Lambda functions at the proxy endpoint with IAM authentication. The proxy absorbs the connection storm and hides failover from the functions, and the only application change is the endpoint the functions connect to. RDS Proxy sits between the application and the database and keeps a pool of long lived connections open to the DB instance. Client connections terminate at the proxy, which multiplexes many short client sessions onto that smaller pool. This is exactly the shape of a Lambda workload: every execution environment opens a fresh connection, runs a handful of statements, and disconnects, so the database spends its memory and CPU on connection setup rather than on query work. AWS lists DB instances that hit too many connections errors and Lambda functions that make frequent short connections as the primary candidates for a proxy. When the pool is exhausted, the proxy queues new requests instead of letting the engine reject them, so latency rises briefly rather than the API failing outright. The second symptom, several minutes of errors during Multi-AZ failover, is also a proxy problem. Applications that cache the DNS answer for the instance endpoint keep sending traffic to the old primary until the cache expires. RDS Proxy bypasses those DNS caches and reconnects to the new primary on the application's behalf, which AWS states reduces failover time by up to 66 percent for Multi-AZ DB instances while preserving client connections. Because the proxy can authenticate clients with IAM and fetch the database secret from AWS Secrets Manager, the functions no longer need to handle credentials in code, and enabling it requires no change to the data access layer beyond the hostname. Creating a read replica and splitting reads and writes treats a connection problem as a read scaling problem. Every write still lands on the primary through the same flood of short connections, replication is asynchronous, and splitting traffic by statement type is a code change the team said it cannot make. Replicas answer throughput questions, not connection count questions. Raising max_connections and moving to a larger memory optimized class is vertical scaling of a resource the workload is not short of. CPU sits under 20 percent, so the engine is starved by per connection overhead, not by capacity. A higher ceiling delays the same failure to a bigger campaign, costs more every hour, and does nothing about the DNS caching that stretches failover. Storing credentials in Secrets Manager and building a pool in a Lambda layer misunderstands the Lambda execution model. A layer only packages code and libraries. Each execution environment still holds its own connections, and nothing in a layer can share a pool across thousands of concurrent environments, so the database sees the same number of connections. Secrets Manager is good hygiene but is not a pooling mechanism. Key exam concept: RDS Proxy solves connection exhaustion and slow failover for serverless and bursty clients, read replicas solve read throughput, and Multi-AZ solves availability. When a stem pairs Lambda with too many connections errors, the proxy is the answer.

Question #2 Design Secure Architectures

A company manages 60 AWS accounts with AWS Organizations. Production and staging accounts live under a Workloads OU, and a separate Security OU contains the account that owns the organization trail. Each workload account has several IAM administrators, and account root user credentials are held by the platform team. A recent audit found that an administrator in one workload account stopped logging on a trail for two days. The security team now requires that nobody in a Workloads OU account, including account administrators and the root user, can stop, delete, or alter any CloudTrail trail, while engineers in the Security OU keep full control. Trails in the workload accounts also feed a central log archive bucket, and the audit requires the change to be in place before the next quarter without touching the existing IAM configuration in each account. The team has drafted the following policy: Which solution will meet these requirements with the LEAST operational overhead?

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectTrails",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging",
      "cloudtrail:DeleteTrail",
      "cloudtrail:UpdateTrail",
      "cloudtrail:PutEventSelectors"
    ],
    "Resource": "*"
  }]
}

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Attach the policy as a service control policy to the Workloads OU and keep the default FullAWSAccess policy attached. One attachment at the OU level binds every principal in every account under that OU, including account administrators and the root user, and nobody inside those accounts can remove it. A service control policy is an AWS Organizations guardrail. It never grants a permission. Instead it defines the maximum permissions available to IAM users and roles in the member accounts it applies to, and the effective permissions become the intersection of the SCP and whatever identity or resource policies grant. Because the SCP is managed from the organization, an administrator inside a workload account cannot edit, detach, or work around it, and the documentation is explicit that SCPs restrict the member account root user as well. That single property is what separates an SCP from every account level control in this scenario. Attaching the policy to the Workloads OU means every current and future account placed under that OU inherits it automatically, which is why the operational overhead is a one time attachment rather than a per account rollout. Two details explain the rest of the option. The organization ships with a FullAWSAccess SCP that allows everything, and a deny list strategy relies on keeping it attached so that the Deny statement in the drafted policy removes only the listed CloudTrail actions. Removing FullAWSAccess would cut off every other action in the OU. The Security OU is a sibling of the Workloads OU, so a policy attached to Workloads has no effect on the security account, which keeps its full control over the organization trail. The management account is never affected by SCPs regardless of attachment point, so it also remains a safe place for break glass administration. Attaching the policy as a permissions boundary to every principal through StackSets puts a ceiling on individual IAM users and roles, not on the account. A boundary does not apply to the root user, any administrator with permission to delete a boundary can strip it, and every new role created later starts without one. It also means touching the IAM configuration of each account, which the audit constraint ruled out. Attaching the SCP to the organization root so the management account inherits it is wrong on both counts. The root level policy would flow down to the Security OU and block the very engineers who must keep control of the trail, and SCPs do not affect the management account at all, so the stated goal of covering it is not achievable through an SCP. Adding an inline policy to each administrator role and enabling MFA delete on the log bucket leaves the control in the hands of the people it is meant to restrain. An administrator can edit or delete an inline policy on their own role, the root user is untouched, and MFA delete protects object versions in the bucket rather than the trail configuration that StopLogging changes. Key exam concept: SCPs restrict but never grant, apply to every principal in member accounts including root, and never touch the management account. When a stem says including administrators and the root user, or cannot be bypassed inside the account, the control lives in Organizations, not in IAM.

Question #3 Design High-Performing Architectures

A media analytics company is migrating a 40 TB shared file repository from an enterprise NAS array in its own data center to AWS. Windows Server hosts running a content management system mount the repository over SMB and rely on NTFS permissions from the company's Active Directory. A separate fleet of Linux instances runs nightly analytics jobs that read the same files over NFS, and the two client groups must see a single consistent copy of every file, not two synchronized copies. The storage team's existing runbooks drive scheduled, block level snapshot replication to a second site, and those runbooks must keep working unchanged against a second AWS Region. Roughly 70 percent of the data is cold at any time, and that cold data must tier automatically to lower cost storage. The file system must also survive the loss of an Availability Zone without manual intervention. Which solution will meet these requirements with the least operational overhead?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Amazon FSx for NetApp ONTAP in a Multi-AZ deployment, with SnapMirror replication to a second file system in another Region and the volume tiering policy set to Auto. It is the only AWS file service that presents one volume over SMB and NFS at the same time, resolves NTFS permissions through Active Directory, keeps the existing scheduled replication engine in place, and tiers cold data automatically. Protocol decides most storage questions on this exam, and this stem asks for two protocols over one dataset. FSx for ONTAP is built on NetApp's ONTAP file system and exposes a volume through NFS, SMB, iSCSI, and NVMe at once. The Windows hosts map an SMB share whose NTFS style ACLs are resolved by the Active Directory domain the file system is joined to, and the Linux analytics fleet mounts the same directory tree over NFS. One copy of the data sits behind both protocols, with one namespace and one set of locks, which is what a single consistent copy means in practice. The second filter is the word unchanged. SnapMirror is ONTAP's own scheduled, block level replication feature, and FSx for ONTAP supports it between file systems, including a target file system in another Region. Runbooks that already drive SnapMirror keep driving the same engine after the migration, only now against a managed file system. A design that swaps in a different replication mechanism may protect the data just as well and still fails this requirement, because every operational procedure around it has to be rewritten and retested. The remaining requirements are features rather than extra services. A Multi-AZ file system keeps a standby in a second Availability Zone and fails over without anyone intervening. Automatic tiering moves infrequently accessed data off SSD into the elastic capacity pool based on access patterns, so the 70 percent that is cold stops paying SSD prices, and deduplication, compression, and compaction shrink what is left. That combination is why AWS positions FSx for ONTAP as the landing place for an existing ONTAP estate. FSx for Windows File Server for the SMB clients with an EFS file system for the Linux clients, synchronized hourly by AWS DataSync is a design teams really build, and it breaks on the clause that rules out two synchronized copies. Each service speaks its own protocol well, but they are two file systems with two namespaces, so the analytics jobs read a copy that can be an hour stale and a file changed on both sides has no winner that DataSync can pick. The requirement was one consistent copy, not two that converge. EFS for the Linux hosts with an S3 File Gateway SMB share for the Windows hosts also puts two stores in the architecture. EFS serves NFS only, and a File Gateway presents an SMB share backed by objects in Amazon S3 behind a local cache, so the Windows hosts would write into a different storage system than the Linux hosts read. Neither piece carries SnapMirror, and neither tiers one shared dataset the way the stem describes. FSx for OpenZFS with the Windows hosts mounting the NFS export and AWS Backup copying snapshots is the closest near miss. OpenZFS file systems are reachable only over NFS versions 3 through 4.2, and file and folder access control on them is Unix permissions. Windows does ship an NFS client, so the mount itself can succeed, but it authenticates through UID and GID mapping, which means the content management system loses the NTFS ACLs that Active Directory resolves for it today. Cross Region AWS Backup copies are a real capability and a different mechanism from the runbooks in the stem. Key exam concept: FSx for Windows File Server is SMB with Active Directory, FSx for Lustre is HPC scratch tied to S3, FSx for OpenZFS is low latency NFS with snapshots, FSx for ONTAP is the one that serves NFS and SMB from the same volume and carries SnapMirror, and EFS is Regional NFS for Linux. Read the protocol list and the replication verb in the stem before you read the options.

Question #4 Design Secure Architectures

An IAM role in a member account of an AWS Organizations organization has an identity based policy that allows s3:DeleteObject on every bucket. The service control policy attached to the account's OU allows all Amazon S3 actions. The target bucket's policy contains an explicit Deny for s3:DeleteObject that applies to the role. What happens when the role calls DeleteObject on that bucket?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: The request is denied because an explicit deny in any applicable policy overrides every allow, regardless of the policy type. Three policies say yes and one says no, and in IAM a single no wins. AWS evaluates a request by gathering every policy that applies to it: the SCPs on the account's path in the organization, the resource based policy on the bucket, the identity based policies on the role, any permissions boundary, and any session policy. The evaluation starts from an implicit deny and then looks for an explicit Deny statement in any of those policies. If one matches the action and resource, the decision is final and no Allow anywhere can reverse it. Only when no explicit deny exists does AWS move on to check whether the request is allowed, which requires an Allow inside the SCP ceiling and an Allow in either the identity policy or the resource policy for a same account request. Apply that to the stem. The identity policy allows the delete, and the SCP allows all S3 actions, so on their own the call would pass. The bucket policy carries an explicit Deny for s3:DeleteObject that names the role, and that statement ends the evaluation with a denial. Bucket policies are resource based policies, and they are consulted for principals in the same account just as they are for principals in other accounts. In the same account the allows of identity and resource policies are combined as a union, but a Deny in either one is absolute. Allowed because the resource policy only matters for cross account access gets the scope of resource policies wrong. A bucket policy applies to every principal that touches the bucket, including roles in the bucket owner's own account. Cross account access is where a resource policy is needed to grant, but its Deny statements bind everyone. Allowed because the identity policy is evaluated last and overrides the resource policy imagines an ordering that does not exist. There is no policy type that outranks another by sequence. All applicable policies are considered together, and an explicit deny found anywhere is the final decision. Denied only if the SCP also contains an explicit deny turns the SCP into a tiebreaker. An SCP sets the maximum permissions for the account and cannot rescue a request that another policy denies. The SCP allowing S3 is necessary for the call to succeed, but it is never sufficient on its own. Key exam concept: policy evaluation has no ordering. AWS gathers every applicable policy at once, an explicit deny anywhere ends the decision, and only then does it look for an allow. For a same account request that allow may come from the identity policy or from the resource policy, and the exam probes this by hiding the Deny in the policy type you were not watching.

Question #5 Design Cost-Optimized Architectures

A financial services company generates about 5 TB of report files every night into the reports/ prefix of an S3 bucket. Analysts read the files heavily for the first 30 days. From day 31 to day 90 the files are opened only a few times per month, but each open must return the object immediately. After day 90 the files are kept for 7 years to satisfy a regulator, and a retrieval that completes within 12 hours is acceptable during that period. The compliance policy also states that every report must remain available if a single Availability Zone is lost. The bucket has versioning disabled, and the analysts' access pattern has been stable for three years. A solutions architect reviews the lifecycle rule that the storage team drafted: Which change to the rule will meet these requirements MOST cost-effectively?

{
  "Rules": [{
    "ID": "reports-retention",
    "Filter": { "Prefix": "reports/" },
    "Status": "Enabled",
    "Transitions": [
      { "Days": 30, "StorageClass": "ONEZONE_IA" },
      { "Days": 90, "StorageClass": "GLACIER" }
    ],
    "Expiration": { "Days": 2555 }
  }]
}

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Replace ONEZONE_IA with STANDARD_IA for the day 30 transition and replace GLACIER with DEEP_ARCHIVE for the day 90 transition. That is the cheapest combination that keeps every report resilient to the loss of an Availability Zone and immediately readable until day 90. Two mistakes hide in the drafted rule, and both are about matching a storage class to a stated constraint rather than to price alone. S3 One Zone-IA is cheaper than S3 Standard-IA because it stores objects in a single Availability Zone, and AWS states plainly that the data is not resilient to the physical loss of that zone. The compliance sentence in the stem therefore removes it from consideration, however attractive the per GB price looks. S3 Standard-IA stores objects across at least three Availability Zones, returns them in milliseconds like S3 Standard, and charges a per GB retrieval fee plus a 30 day minimum storage duration. A few opens per month on files that stay in the class for 60 days is exactly the access profile it is designed for. The second mistake is the API name GLACIER, which is S3 Glacier Flexible Retrieval, not the deepest tier. Flexible Retrieval offers retrievals in minutes to 12 hours and a 90 day minimum duration, and it costs several times more per GB than S3 Glacier Deep Archive. Deep Archive is the lowest cost storage class in AWS, its standard retrieval completes within 12 hours, and its 180 day minimum duration is irrelevant to objects held for 7 years. The stem accepts a 12 hour retrieval, so the extra money spent on Flexible Retrieval buys nothing. Standard-IA to Deep Archive is a supported transition in the waterfall model, and because the objects spend 60 days in Standard-IA before moving, no minimum duration charge applies at the transition. Keeping ONEZONE_IA and switching only the archive tier to DEEP_ARCHIVE is the tempting cost trap. It is the cheapest option on paper and it violates the one requirement that is not about cost. One Zone-IA is meant for data that can be recreated or for replica copies, not for the primary copy of regulated records. Switching to STANDARD_IA but keeping GLACIER satisfies every constraint and still overpays for the longest phase of the object's life. Seven years in Flexible Retrieval costs far more than seven years in Deep Archive, and the faster retrieval tiers it offers were never asked for. Moving everything to INTELLIGENT_TIERING with the archive tiers activated is the answer for unknown or changing access patterns, and this pattern is known and stable. The class adds a monthly monitoring charge per object, the Archive Access tier only takes objects after 90 consecutive days without access, and the Deep Archive Access tier waits 180 days, so the data reaches the cheapest tier later than the explicit rule would move it. Key exam concept: One Zone-IA fails any sentence that says the data must survive an AZ loss, GLACIER in the API means Flexible Retrieval, and Deep Archive is the answer whenever a retrieval window of 12 hours or more is acceptable. Minimum storage durations of 30, 90, and 180 days decide whether an early transition or deletion is charged.

Question #6 Design Resilient Architectures

An insurance company runs its claims processing platform in a single AWS Region: an Auto Scaling group of EC2 instances behind an Application Load Balancer, an Amazon Aurora MySQL cluster, and 20 TB of scanned documents in Amazon S3. The application tier is stateless, and its AMIs are already built by a pipeline that can copy them to any Region. Regulators require the company to demonstrate recovery from a full Region outage with an RTO of 15 minutes and an RPO of under 1 minute. Finance has rejected any design that runs a second full production fleet continuously. The recovery Region already has a VPC, matching subnets, and security groups created by the same infrastructure pipeline that builds the primary. The operations team wants failover to be a scripted, repeatable procedure rather than a rebuild, and it wants to run the recovery environment through a quarterly test with real traffic at reduced capacity. Which disaster recovery strategy will meet these requirements at the lowest cost?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Create an Aurora global database with a secondary cluster in the recovery Region, replicate the S3 bucket, run a minimum size Auto Scaling group behind a load balancer there, and fail over with Route 53. That is a warm standby, the only rung of the disaster recovery ladder that fits a 15 minute RTO, a sub minute RPO, and quarterly tests with live traffic, and it is the cheapest rung that does, because the one cheaper rung cannot meet the numbers and the one faster rung needs the second full fleet that finance refused. AWS describes four strategies in order of rising cost and falling recovery time: backup and restore, pilot light, warm standby, and multi site active/active. The distinction the exam keeps probing is between the middle two. In a pilot light the data stores are live in the recovery Region but the application servers are switched off or not deployed, so the environment cannot process a single request until someone turns them on. In a warm standby the full stack is deployed and running at reduced capacity, so it can serve traffic immediately and only needs to scale up. The stem's demand for a quarterly test with real traffic at reduced capacity is a warm standby by definition, because only a rung whose stack is already serving can be exercised that way, and asking for failover to be a scripted procedure rather than a rebuild points at the same rung. The data pieces follow from the RPO. Aurora Global Database replicates to a secondary Region with typical lag under a second and lets you promote the secondary to read write in under a minute, which comfortably meets an RPO under 60 seconds. S3 Cross Region Replication keeps the document bucket current asynchronously. Route 53 failover records backed by health checks, or a scripted change of the record, move users once the secondary is promoted. Finance's veto lands one rung higher than this design: a warm standby pays for the replicated database and a minimum size fleet around the clock, which is a fraction of what a second production fleet costs. Hourly AWS Backup copies rebuilt with CloudFormation is backup and restore. An hourly copy means an RPO of up to an hour, and recreating a cluster and fleet from backups in a fresh Region takes far longer than 15 minutes. It is the cheapest rung and the one the regulator's numbers rule out. Aurora global database and S3 replication with the application tier left undeployed is a pilot light. The data would meet the RPO, but the compute must be launched and health checked before any request is served, which puts the 15 minute RTO at the mercy of control plane operations, and an undeployed tier cannot take part in a test with real traffic. A full fleet in both Regions with latency routing and DynamoDB global tables is multi site active/active. It delivers near zero recovery time but at the cost of a second production fleet, which finance rejected, and it swaps the Aurora engine for DynamoDB, a rewrite the scenario never asked for. Key exam concept: match RTO and RPO to the rung. Backup and restore is hours, pilot light is data live and compute off, warm standby is a scaled down copy that already serves traffic, and active/active is near zero RTO at full price. The phrase can handle traffic at reduced capacity is the fingerprint of warm standby.

Question #7 Design Secure Architectures

A startup is building a photo sharing mobile app. Users must be able to sign up with an email address or sign in with a social identity provider, and the app must upload photos directly from the device to an S3 bucket without routing the bytes through the company's API servers. Each user may write only to the prefix that matches their own user identifier. The security team forbids embedding long lived AWS access keys in the app binary and does not want to operate its own token service. The app must also keep working for a user whose session spans several hours without signing in again. Which combination of steps should a solutions architect take to meet these requirements with the least operational overhead? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: Create an Amazon Cognito user pool with the social identity providers configured so the app authenticates users and receives tokens, and create an Amazon Cognito identity pool that trusts the user pool and maps authenticated users to an IAM role scoped to each user's own prefix. The user pool answers who this person is and the identity pool answers what AWS credentials this person may hold, and together they remove any need for keys in the binary. A user pool is a managed user directory and OpenID Connect provider. It handles sign up, sign in, password policy, MFA, and federation with social providers such as Google, Apple, Amazon, and Facebook, and it returns JSON Web Tokens to the app. Those tokens prove identity but they are not AWS credentials, so on their own they cannot sign an S3 request. That is the job of an identity pool. The app presents the user pool token to the identity pool, which exchanges it through AWS STS for temporary credentials tied to an IAM role you choose. Because the credentials are short lived and issued per session, nothing permanent ships with the app, and the SDK refreshes them as long as the user's token remains valid, which covers a session that spans several hours. Scoping each user to their own prefix is done inside the role's policy rather than in application code. The policy grants s3:PutObject on a resource ARN that ends in the Cognito identity variable, so the same role serves every user while S3 enforces that a user can only write under the prefix that carries their identifier. This is the standard pattern for direct device to S3 uploads and it keeps the API servers out of the data path entirely. Allowing anonymous s3:PutObject in the bucket policy and relying on Block Public Access to filter uploads contradicts itself. Block Public Access exists to reject public bucket policies, so the policy would be blocked outright, and if it were somehow applied anyone on the internet could write to the bucket with no per user scoping at all. Creating an IAM user for each app user and sending a scoped access key to the device is the anti pattern the security team forbade. IAM users carry long lived credentials, the account has a hard quota on how many IAM users it can hold, and revoking or rotating thousands of keys on phones is unmanageable. IAM users are for people and systems you administer, not for the public. Creating IAM Identity Center permission sets and redirecting users to the access portal mixes up workforce and customer identity. IAM Identity Center provides single sign on for employees and partners into AWS accounts and business applications. It has no self service sign up, no social login for consumers, and its access portal is not a mobile app login screen. Key exam concept: Cognito user pools authenticate and issue tokens, Cognito identity pools trade tokens for temporary AWS credentials through a role, and IAM Identity Center is workforce SSO. A consumer app that must call AWS services directly needs both Cognito components.

Question #8 Design High-Performing Architectures

A logistics company stores telemetry from 50,000 delivery vehicles in an Amazon DynamoDB table configured in on-demand capacity mode. Each vehicle sends one reading per second, and each reading is about 500 bytes. The table uses the calendar date as a string for the partition key and the reading timestamp as the sort key, so that a nightly reporting job can query a full day of readings with a single query. Since the fleet doubled in size, the ingestion service receives ProvisionedThroughputExceededException errors every day even though the table's consumed capacity stays far below the account's on-demand throughput quota, and CloudWatch shows the throttling concentrated on one partition at a time. The company wants ingestion to scale linearly with the fleet, and the application must be able to fetch all readings for a single vehicle over a time range. The company has no plans to change the ingestion service's write path beyond the key it uses. What should a solutions architect recommend?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Change the table's partition key to the vehicle identifier and keep the reading timestamp as the sort key. A high cardinality partition key spreads 50,000 writers across many partitions, and the sort key still supports the per vehicle time range query. DynamoDB stores a table in partitions, and every partition is designed to deliver at most 3,000 read units and 1,000 write units per second no matter which capacity mode the table uses. Items that share a partition key value always live in the same partition, so a partition key with one value per day funnels every write from the entire fleet into a single partition for 24 hours. At one reading per second per vehicle the fleet needs tens of thousands of writes per second against a partition that can absorb one thousand, which is exactly the throttling the stem describes: the account level on-demand quota is nowhere near exhausted, but one partition is saturated and CloudWatch shows the hot spot rolling to a new partition at midnight. Adaptive capacity can boost a busy partition and isolate a hot item, but it cannot lift one partition key value above the partition limit. The fix is a key that distributes writes as evenly as the writers themselves. The vehicle identifier has 50,000 distinct values arriving at the same rate, so DynamoDB places them across partitions and each partition sees a small, even share. Because ingestion capacity now grows with the number of distinct vehicles, it scales with the fleet. The timestamp sort key lets the application issue one Query with a partition key of a vehicle and a sort key range for the time window, which is the access pattern the stem requires. The nightly report can read across vehicles with a parallel Scan or through a secondary index built for that purpose. Switching to provisioned mode with 50,000 write capacity units raises a table level number that was never the bottleneck. Provisioned throughput is spread across partitions, and the 1,000 write unit ceiling per partition still applies to the single hot partition key. The bill goes up and the throttling stays. Keeping the date key and appending a random suffix is the write sharding technique from the AWS guidance, and it does spread writes across up to 200 partition key values. It sacrifices the read path though: fetching one vehicle's readings would mean querying every suffix for every day in the range and filtering, which breaks the stated access pattern when a natural high cardinality key is available. Adding a global secondary index on the vehicle identifier leaves the base table unchanged. Every write still hits the date partition first and is throttled there, and the index only adds a second write per item. Secondary indexes solve read patterns, not base table write distribution. Key exam concept: a low cardinality partition key such as a date, a status, or a country creates a hot partition that no capacity setting can fix. Choose a key with many evenly used values, and reach for write sharding only when the natural key is unavoidably narrow.

Question #9 Design Cost-Optimized Architectures

A company runs a data processing fleet of EC2 instances in private subnets across two Availability Zones in one AWS Region. The instances read raw files from and write results to S3 buckets in the same Region, send roughly a third of their outbound bytes to an Amazon Kinesis Data Streams stream in the same Region, and call a partner's public REST API to enrich records. Cost Explorer shows that NAT gateway data processing charges are now the largest line item in the account. VPC flow logs attribute about 60 percent of the NAT gateway bytes to Amazon S3, about 30 percent to the streaming endpoint, and the remainder to the partner API. A security review has asked that neither the S3 traffic nor the streaming traffic traverse the internet. The instances must stay in private subnets with no public IP addresses, and the partner API must remain reachable. The VPC's two route tables look like this: Which solution will meet these requirements at the lowest total cost?

rtb-priv  (private subnets)
Destination   Target
10.0.0.0/16   local
0.0.0.0/0     nat-0a1b2c3d4e5f67890

rtb-pub  (public subnets)
Destination   Target
10.0.0.0/16   local
pl-6da54004   vpce-0b1c2d3e4f5a67890
0.0.0.0/0     igw-0fedcba9876543210

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: associate the existing S3 gateway endpoint with the private route table and create an interface VPC endpoint for Kinesis Data Streams in both Availability Zones. The S3 bytes leave the NAT gateway's meter at no charge, the streaming bytes move onto AWS PrivateLink instead of the internet, and the partner API keeps the default route it still needs. The route tables are the diagnosis. A gateway endpoint for Amazon S3 already exists in this VPC, but its prefix list route sits in the public route table, and the private subnets that actually generate the traffic use a table whose only way out is 0.0.0.0/0 to the NAT gateway. AWS adds the endpoint route to the route tables you associate with the endpoint and to no others, and instances in subnets that are not associated keep reaching the service through its public endpoint. Associating the private route table inserts the S3 prefix list route with the endpoint as its target, and because a prefix list is more specific than 0.0.0.0/0 the longest prefix match sends S3 bound packets to the endpoint while every other destination still follows the default route. There is no additional charge for a gateway endpoint, so the 60 percent of metered bytes going to S3 simply stop being metered. The streaming traffic cannot be solved the same way, and that is the mechanic the item turns on. Gateway endpoints exist for exactly two services, Amazon S3 and DynamoDB. Every other AWS service that supports private access does it through an interface endpoint, an elastic network interface with a private IP address in your subnet, powered by AWS PrivateLink. The Kinesis Data Streams documentation says so plainly: an interface VPC endpoint prevents traffic between the VPC and the service from leaving the Amazon network and requires no internet gateway, NAT device, VPN connection, or Direct Connect connection. Interface endpoints are billed per hour for each endpoint network interface plus a charge per gigabyte processed, which is more than nothing and still well below the NAT path for this volume, and it is the only way to take the streaming bytes off the internet. What is left on the bill after both changes is the NAT gateway hourly charge plus the small share of bytes that genuinely belong on the internet, the interface endpoint hours and gigabytes for the stream, and nothing at all for Amazon S3. The instances keep their private addresses and resolve the same Regional service names, so no application change is needed. Creating a second gateway endpoint for Kinesis Data Streams is not something AWS offers. Gateway endpoints are available only for Amazon S3 and DynamoDB, so there is no Kinesis Data Streams gateway endpoint service to select. The misconception is common because the two endpoint types look interchangeable on an architecture diagram, and the exam probes it directly. Interface endpoints for both Amazon S3 and Kinesis Data Streams is the expensive version of the right answer. It satisfies the security review, but it pays hourly and per gigabyte charges on the S3 traffic that a gateway endpoint already carries for free, and it throws away an endpoint that costs nothing to keep. An interface endpoint for S3 earns its cost when the request comes from a data center over Direct Connect or from a peered VPC, neither of which applies here. Associating the gateway endpoint and adding a second NAT gateway in the other Availability Zone gets the S3 half of the problem right and leaves the streaming bytes exactly where they were, on the internet path the security review asked to close. It also addresses a different dimension of the design entirely. Whatever else changes, each gateway still meters and bills every gigabyte it forwards, so the streaming traffic is split across two gateways rather than taken off the meter, and the hourly charge doubles. Key exam concept: S3 and DynamoDB traffic from private subnets belongs on a free gateway endpoint, every other AWS service needs a paid interface endpoint, and the NAT gateway should be left carrying only genuine internet destinations. When a stem pairs a NAT data processing bill with two AWS destinations, decide which of them is gateway eligible before you price anything.

Question #10 Design Secure Architectures

A company hosts a three tier application in a VPC. Application servers run in the subnet 10.0.20.0/24, and an Amazon RDS for MySQL instance runs in the subnet 10.0.30.0/24. To satisfy an audit, a network engineer replaced the default network ACL on the database subnet with a custom one and confirmed that the RDS security group allows inbound TCP 3306 from the application security group and has its default outbound rule. The application subnet still uses the default network ACL, which allows all traffic in both directions, and both subnets share the VPC's main route table, so no routing changed. Immediately afterward, every connection attempt from the application servers to the database began timing out. The custom network ACL contains these rules: What should the engineer change to restore connectivity while keeping the network ACL as restrictive as possible?

Inbound
Rule  Type        Protocol  Port   Source         Allow/Deny
100   Custom TCP  TCP       3306   10.0.20.0/24   ALLOW
*     All         All       All    0.0.0.0/0      DENY

Outbound
Rule  Type        Protocol  Port   Destination    Allow/Deny
100   Custom TCP  TCP       3306   10.0.20.0/24   ALLOW
*     All         All       All    0.0.0.0/0      DENY

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: change outbound rule 100 on the custom network ACL to allow TCP ports 1024 to 65535 to 10.0.20.0/24. The inbound side of the conversation is fine. The outbound side permits only destination port 3306, and no MySQL reply is ever sent to port 3306 on the client. A network ACL is stateless. It inspects every packet crossing the subnet boundary in each direction against its own rule list and keeps no memory of the connection a packet belongs to. When an application server at 10.0.20.15 opens a connection, it picks an ephemeral source port, typically somewhere between 1024 and 65535 depending on the operating system, and sends a SYN to 10.0.30.20 port 3306. Inbound rule 100 allows that packet. The database replies from source port 3306 to the application server's ephemeral port, and that reply is evaluated against the outbound rules. Outbound rule 100 matches only destination port 3306, so the reply falls through to the wildcard deny and is dropped. The client never sees the SYN ACK, retries, and reports a timeout rather than a refusal, which is the classic symptom of a stateless filter eating return traffic. Direction is worth being precise about, because it is where candidates lose this item. A network ACL evaluates its inbound list for packets entering the subnet it protects and its outbound list for packets leaving it, no matter which side opened the connection. On the database subnet's ACL the client's SYN arrives on port 3306 and the database's reply departs toward an ephemeral port, so the ephemeral range belongs in the outbound list here. The mirror image of that rule, an ephemeral range in the inbound list, is what the application subnet's ACL would need, and in this VPC that subnet still carries the permissive default ACL. Scoping the new outbound rule to 10.0.20.0/24 keeps the ACL tight: the database subnet still accepts nothing but 3306 from the application subnet and still sends nothing anywhere else. Security groups behave differently, which is why the engineer's check of the RDS security group came back clean. A security group is stateful: once inbound traffic is allowed, the response is allowed automatically regardless of outbound rules. The two controls layer on top of each other, so a subnet level ACL can break a flow that the instance level security group happily permits. Adding an outbound rule to the RDS security group for the ephemeral range targets a stateful control that is not blocking anything. Return traffic for an allowed inbound connection leaves a security group without any matching outbound rule, and this group already has the default outbound allow on top of that. The edit is harmless and changes nothing, which is exactly what makes it tempting after the ACL has been ruled out. Renumbering the wildcard deny rule to 200 misreads how ACL rules are ordered. Rules are evaluated from the lowest number upward and the asterisk rule is always evaluated last no matter what, so rule 100 is already reached first. It cannot be renumbered either. The allow is simply too narrow for the reply packets, and ordering was never the problem. Adding inbound rule 90 for TCP ports 1024 to 65535 from 10.0.20.0/24 opens the right port range in the wrong direction. The inbound list is consulted only for packets entering the database subnet, and those already match rule 100 on port 3306, so nothing changes for them. The packets being dropped are the replies on their way out, and only the outbound list is consulted for those. The rule also widens the ACL without cause, which the question asks the engineer to avoid. Key exam concept: security groups are stateful and allow only, network ACLs are stateless with numbered allow and deny rules, and any custom ACL must open the ephemeral port range for return traffic in the opposite direction from the request. When both controls look right and connections time out rather than being refused, follow the return path through the ACL.

Question #11 Design Resilient Architectures

A company is moving an order management application to AWS. The application's components exchange messages through a self managed Apache ActiveMQ broker using JMS and the OpenWire protocol, and the software vendor will not modify the messaging code. Which AWS service should a solutions architect recommend to host the broker with the LEAST amount of application change?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Amazon MQ with an ActiveMQ broker deployed in an active/standby configuration across two Availability Zones. It is a managed ActiveMQ, so the application keeps its JMS client, its OpenWire connections, and its queue and topic names, and the only change is the broker endpoint. Amazon MQ is a managed message broker service for Apache ActiveMQ Classic and RabbitMQ. AWS operates the broker software, applies patches and version upgrades in a maintenance window, stores messages redundantly, and exposes the same industry standard APIs and protocols the open source brokers speak: JMS and NMS as APIs, and AMQP, STOMP, MQTT, OpenWire, and WebSocket as wire protocols. That protocol compatibility is the whole point of the service. An application written against a JMS ConnectionFactory that today points at a self managed ActiveMQ can be pointed at an Amazon MQ endpoint with no change to its messaging code, which is the exact constraint a vendor supplied application imposes. The active/standby deployment places a standby broker in a second Availability Zone with shared durable storage, so a broker failure or zone event fails over automatically while clients reconnect through the failover transport they already use. The exam draws a firm line here. When a stem describes a new, cloud native design, the answer is one of the purpose built AWS messaging services because they scale further and cost less to operate. When a stem describes an existing application that speaks JMS, AMQP, MQTT, or OpenWire and cannot be changed, the answer is Amazon MQ. Reading which of the two situations you are in is the whole skill being tested. Amazon SQS FIFO queues with Amazon SNS topics is the right pair for a new decoupled application and the wrong one for this migration. SQS and SNS expose their own APIs rather than a broker protocol, so the application would need new client code, and OpenWire connections have nowhere to land. Even the SQS Java Messaging Library, which offers a JMS style interface, means swapping dependencies and connection code, which the vendor will not do. Amazon EventBridge with a custom event bus is an event router for AWS service events, SaaS integrations, and application events delivered to targets by rules. It is not a broker that a JMS client can connect to, it does not offer queue semantics with consumer acknowledgements, and it would require the application to publish events through the EventBridge API. Amazon Kinesis Data Streams with one shard per queue is a streaming service for ordered, replayable records read by consumers with the Kinesis client libraries. It has no JMS or OpenWire interface, no per message acknowledgement and deletion model, and it would force a complete rewrite of both producers and consumers. Key exam concept: Amazon MQ is the answer when an existing application depends on a standard messaging protocol and cannot change. SQS, SNS, and EventBridge are the answers for new designs that can adopt AWS native APIs.

Question #12 Design High-Performing Architectures

An online retailer collects clickstream events from its website at a sustained rate of 30,000 events per second, each a small JSON document. Events must be kept in the order they were produced for each user session. The analytics team needs the events landed in Amazon S3 as Apache Parquet files partitioned by date so that analysts can query them with Amazon Athena, and it wants delivery to occur within a few minutes with no servers to manage. A separate fraud detection service must read every event within one second of its arrival, and it must be able to rewind and reprocess the last 24 hours of events after a bug fix without the producers resending anything. The retailer wants both consumers to share a single ingestion path and to keep the number of custom components to a minimum. Which combination of steps should a solutions architect take to meet these requirements with the LEAST operational overhead? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: Ingest the events into an Amazon Kinesis Data Streams stream keyed by session identifier with a 24 hour retention period and let the fraud service consume it, and create an Amazon Data Firehose stream that reads from that data stream, converts records to Parquet with a Glue Data Catalog schema, and delivers them to S3. The data stream provides ordering, multiple consumers, and replay, and Firehose provides managed, serverless delivery with built in format conversion. Kinesis Data Streams is the ingestion layer when more than one consumer must read the same records or when a consumer must be able to replay. Records are stored in shards, ordered within each partition key, so keying by session identifier preserves per session order. Retention defaults to 24 hours and can be raised to 365 days, and any consumer can start reading from an earlier position, which is how the fraud service reprocesses a day of events after a fix without asking producers for anything. Consumers read within milliseconds of a record being written, and enhanced fan out gives a dedicated read pipe per consumer when several read at once. Amazon Data Firehose is the delivery layer. It has no servers, buffers records by size or time, and writes batches to destinations such as S3, Amazon Redshift, Amazon OpenSearch Service, and HTTP endpoints. Two features do the analytics team's work for free: a Kinesis data stream can be configured as the source of a Firehose stream, and Firehose can convert incoming JSON to Parquet or ORC using a schema stored in the AWS Glue Data Catalog before writing, with S3 prefixes that include the date for partitioned Athena queries. Columnar Parquet with date partitions is what makes Athena scans cheap and fast, and no ETL job, cluster, or cron schedule is involved. An SQS standard queue polled by both consumers breaks on three counts. A message delivered to one consumer is hidden from the other, so the two services would split the events rather than each seeing all of them. Standard queues do not guarantee order, and once a message is deleted there is no replay. SQS is a work queue, not a shared event log. A Glue ETL job scheduled every 5 minutes to write Parquet is a batch component the retailer said it wants to avoid. Glue can run streaming and scheduled jobs, but here it duplicates what Firehose does natively while adding job scripts, checkpoints, and a schedule to operate. It is more overhead for the same output. Sending events straight to Firehose and subscribing the fraud service as a second destination misreads Firehose. It is a delivery service with a single destination per stream, and nothing can consume from it. It also keeps no replayable history, so the 24 hour rewind is impossible, and even with the buffering interval set to zero seconds it writes to a destination within a few seconds rather than handing individual events to a consumer. Key exam concept: Kinesis Data Streams for ordered, replayable, multi consumer ingestion, Firehose for managed delivery and format conversion into S3, and the two chained together when both real time consumers and a data lake need the same events. Firehose alone has no consumers and no replay.

Question #13 Design Cost-Optimized Architectures

An online retail company keeps 12 years of order history in an Amazon DynamoDB table that has grown to 9 TB. The table uses on-demand capacity mode, has one global secondary index, and has point in time recovery enabled. The customer portal must still return any historical order in single digit milliseconds, but analysis of the Cost and Usage Report shows that storage accounts for 80 percent of the table's monthly charge while read and write request charges are small and steady. A legal hold requires every order record to remain in the table, and the portal's code cannot be changed this quarter. Which solution will reduce the table's cost MOST while meeting these requirements?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Change the table class to DynamoDB Standard-Infrequent Access and keep the capacity mode and indexes unchanged. The table class changes the price of storage relative to requests, which is exactly the lever this bill needs, and it changes nothing about how the portal reads. DynamoDB offers two table classes. DynamoDB Standard is the default and is the cheapest choice when read and write requests dominate the bill. DynamoDB Standard-IA charges less per gigabyte stored and more per request, and AWS positions it for tables where storage is the dominant cost: application logs, old social media posts, order history, past gaming achievements. The documentation gives a concrete rule of thumb: once storage exceeds about 50 percent of the throughput cost of a Standard table, Standard-IA can lower the total. At 80 percent storage this table is well past that line. The change is made on the existing table with the console, CLI, or SDK, it runs as a background process while the table stays available, and the global secondary index automatically adopts the same class. What does not change is just as important for the stem. Standard-IA tables offer the same performance, durability, and availability as Standard tables, so the portal keeps its single digit millisecond reads. The same APIs and endpoints are used, so no code changes. On-demand mode, point in time recovery, TTL, backups, and secondary indexes all continue to work. The only operational limit is that a table class can be switched no more than twice in a rolling 30 day window, which matters only if someone plans to flip it back and forth. Switching to provisioned capacity with auto scaling and reserved capacity attacks the wrong 20 percent. Reserved capacity discounts provisioned throughput, and this table's request charges are already small and steady. The storage line, which is four fifths of the bill, is priced identically in both capacity modes. Enabling Time to Live to expire orders older than 2 years would delete records that a legal hold requires the table to retain. TTL is the right tool for data that genuinely expires, and it removes items at no request cost, but expiry is deletion and this data cannot be deleted. Exporting old orders to S3, deleting them, and querying with Athena fails three constraints at once. Deleting the items violates the hold, Athena answers in seconds rather than single digit milliseconds, and the portal would need new code to look in two places. It is a data lake pattern, not a serving pattern. Key exam concept: capacity mode and reserved capacity tune the request side of a DynamoDB bill, the Standard-IA table class tunes the storage side, and TTL removes data rather than making it cheaper. Read the Cost and Usage Report breakdown in the stem to see which side dominates.

Question #14 Design Secure Architectures

A company has hired a SaaS vendor to monitor storage growth and produce cost reports. The vendor runs its service from its own AWS account and serves hundreds of other customers from that same account. It needs to list and read objects in three of the company's S3 buckets and to read Amazon CloudWatch metrics, and nothing else. The company's security policy prohibits creating IAM users for external parties and requires that the vendor's access can be revoked instantly and that the vendor cannot be tricked into acting on the company's resources on behalf of another of its customers. Which combination of steps should a solutions architect take to meet these requirements MOST securely? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: Create an IAM role in the company's account with read only permissions on the three buckets and CloudWatch metrics and a trust policy naming the vendor's AWS account, and add a condition on sts:ExternalId to that trust policy using a value the vendor generated for the company. The role gives the vendor temporary credentials with exactly the permissions listed, and the external ID makes sure the vendor can only use the role when it is genuinely working for this company. The documented pattern for third party access is a cross account IAM role. The company creates a role whose permissions policy grants only the actions the vendor needs, and whose trust policy names the vendor's account ID as the principal. The vendor calls the AWS STS AssumeRole API and receives short lived credentials, so no long term secret ever leaves the company's account. Revocation is instant and total: removing the vendor's account from the trust policy, or deleting the role, ends every future AssumeRole call in one edit. Nothing about the vendor's own credentials matters to the company, which is the point of delegating with a role rather than issuing keys. The external ID addresses the confused deputy problem, which is precisely the risk the stem describes. A vendor that serves hundreds of customers from one account could be induced by one customer to assume a role that belongs to another. The vendor generates a unique external ID per customer and passes it in every AssumeRole request, and the company's trust policy requires that exact value with a StringEquals condition on sts:ExternalId. A request made on behalf of a different customer carries a different ID and is refused. AWS notes that the external ID is not a secret, it is an assertion of which customer the vendor is acting for, and that the vendor rather than the customer must generate it so every customer's value is unique. An IAM Identity Center permission set for the vendor targets the wrong kind of identity. Identity Center provides single sign on for a workforce through the company's identity provider. A vendor's automated service running in another AWS account is not a workforce user, and permission sets cannot be assumed programmatically by an external account. Bucket policies granting the vendor's whole account plus a cross account CloudWatch dashboard scatters the grant across four places, gives every principal in the vendor account the same access, and provides no external ID check because bucket policies have no role assumption to condition on. Revoking means editing three bucket policies and a monitoring link rather than one trust policy. Creating an IAM user for the vendor with a rotated access key is the option the security policy forbids. An access key is a long lived credential that lives in the vendor's systems, rotation every 90 days does not shorten the exposure window between rotations, and there is no per customer assertion to stop the vendor from using the same key while acting for someone else. Key exam concept: third party access is always an IAM role assumed with STS, never an IAM user, and a vendor that serves many customers from one account needs an external ID in the trust policy to defeat the confused deputy. Identity Center is for your own people, not for external automation.

Question #15 Design Resilient Architectures

A company runs a video thumbnail service. A web tier writes one message per uploaded video to an Amazon SQS standard queue, and a fleet of EC2 workers polls the queue, generates thumbnails, and deletes the message when finished. Each job takes between 2 and 6 minutes. After the fleet was doubled to clear a backlog, the team noticed that many videos receive thumbnails twice and the S3 request bill rose, while CloudWatch shows no worker errors and no failed jobs. The upload service logs show one send per video. Messages are about 1 KB, and the queue has no dead-letter queue configured. A solutions architect retrieves the queue attributes: The workers must keep running unchanged apart from queue configuration, and the duplicates must stop. What should the solutions architect do?

$ aws sqs get-queue-attributes     --queue-url https://sqs.eu-west-1.amazonaws.com/123456789012/thumbnails     --attribute-names VisibilityTimeout ReceiveMessageWaitTimeSeconds DelaySeconds                       ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
{
    "Attributes": {
        "VisibilityTimeout": "30",
        "ReceiveMessageWaitTimeSeconds": "20",
        "DelaySeconds": "0",
        "ApproximateNumberOfMessages": "412",
        "ApproximateNumberOfMessagesNotVisible": "184"
    }
}

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: set the queue's VisibilityTimeout attribute to 480 seconds. The queue still carries the default 30 second timeout while jobs run for as long as 6 minutes, so every message becomes visible again long before its worker finishes, and the newly enlarged fleet has idle workers standing by to take it a second time. When a consumer receives a message from an SQS queue, the message is not removed. It stays in the queue and becomes invisible to other consumers for the visibility timeout, which defaults to 30 seconds and can be set as high as 12 hours. The consumer is expected to process the message and call DeleteMessage inside that window. If the window closes first, SQS assumes the consumer failed and makes the message visible again so another consumer can retry it. That behavior is what protects a queue from a crashed worker, and it is also what manufactures duplicates when the timeout is shorter than the work. Nothing in this pipeline is failing, which is why no errors appear: two healthy workers are finishing the same job because the queue handed it out twice. The attribute dump settles the other three options before they are even considered. ReceiveMessageWaitTimeSeconds is already 20 seconds, the maximum, so long polling is switched on. DelaySeconds is 0, so nothing is being deferred on the way in. A count of 184 messages not visible against 412 visible is exactly what a fleet doing multi minute work looks like, not a symptom. The single number out of step with the stem is VisibilityTimeout at 30 seconds against jobs that run 2 to 6 minutes, and 480 seconds covers the longest job with margin. Doubling the fleet made the symptom worse rather than causing it. Before the change most workers were busy, so a message that reappeared often sat unclaimed until the original worker deleted it. With spare capacity, a message that reappears after 30 seconds is claimed almost immediately. The documented practice is to set the visibility timeout to the maximum time the application needs to process and delete a message, and for jobs of variable length to extend it from the worker with ChangeMessageVisibility as a heartbeat. A heartbeat means new code, which the stem rules out, so raising the queue level timeout is the configuration only fix. Recreating the queue as a FIFO queue with content based deduplication targets producer side duplicates. Deduplication discards a second copy of the same message body sent by a producer within a 5 minute interval. It does nothing about one message being received twice because its visibility timeout expired, the upload logs already show a single send per video, and a standard queue cannot be converted in place anyway. Setting ReceiveMessageWaitTimeSeconds to 0 confuses polling with visibility. That attribute only controls how long a ReceiveMessage call waits for a message to arrive, and dropping it to 0 switches the queue from long polling back to short polling. Reappearing messages would be handed out just as readily, empty responses would rise, and the request bill the team is already worried about would climb. Setting DelaySeconds to 300 delays the first delivery of a newly sent message. It has no effect on a message that has already been received and becomes visible again when its timeout expires, so the second delivery still happens, only later. Delay queues defer work that has not started, they do not protect work that is in flight. Key exam concept: a visibility timeout shorter than processing time causes duplicate processing, a timeout much longer than processing time delays retries after a real failure, and the two knobs that have nothing to do with this problem are long polling and delay queues. Standard queues are at least once delivery, so consumers should be idempotent as well.

Question #16 Design High-Performing Architectures

A gaming company hosts the matchmaking service for a multiplayer game in two AWS Regions, each fronted by a Network Load Balancer. Game clients communicate with the service over UDP, and several console platform partners require the company to publish a fixed set of IP addresses that never changes so the partners can add them to allow lists. Players in Asia currently reach the European Region over the public internet and complain about jitter. The company wants clients to be routed to the nearest healthy Region and to fail over to the other Region within seconds if it becomes unhealthy. The company does not want to depend on how quickly clients refresh cached DNS answers. Which solution will meet these requirements?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Create an AWS Global Accelerator standard accelerator with a UDP listener and an endpoint group in each Region targeting the Network Load Balancers, and publish the accelerator's static IP addresses. Every requirement in the stem is a Global Accelerator feature: static anycast addresses, UDP support, routing to the nearest healthy Region over the AWS network, and failover in seconds that does not wait for DNS. A standard accelerator gives you two static IPv4 addresses that are anycast from the AWS edge network and stay assigned for the life of the accelerator. Clients connect to the nearest edge location, and their traffic rides the AWS global network to the optimal Regional endpoint based on health, client location, and the traffic dials you configure. Listeners support TCP and UDP, and endpoint groups can contain Network Load Balancers, Application Load Balancers, EC2 instances, or Elastic IP addresses in one or many Regions. Health checks run continuously and the service reacts to an unhealthy endpoint by shifting traffic to the next closest healthy Region without any change to the addresses clients are using, which is why the console partners can allow list the two addresses once and never revisit them. The contrast the exam expects you to draw is with Amazon CloudFront and with DNS based routing. CloudFront is a content delivery network for HTTP and HTTPS, it caches and terminates web requests, and it publishes a domain name backed by a changing pool of edge addresses. Route 53 routing policies are excellent when clients honor DNS, but a failover expressed in DNS takes effect only when caches expire, which is the dependency the company rejected. Global Accelerator was built for the non HTTP, static address, fast failover corner that neither of those services covers. A CloudFront distribution with the load balancers in an origin group cannot carry this traffic. CloudFront accepts HTTP and HTTPS from viewers, not UDP, and it offers no fixed IP addresses for partners to allow list. Origin failover also happens per request after a failed fetch, not through continuous health checks. Route 53 latency records with health checks and published load balancer addresses gets nearest Region routing but fails the other constraints. Failover waits for cached DNS answers to expire, traffic still crosses the public internet to the Region, and the addresses behind a Network Load Balancer's DNS name are not a fixed, published set unless Elastic IPs are assigned, which the option does not do. Elastic IP addresses on the load balancers with Route 53 failover records solves the static address requirement and nothing else. Failover is still bound to DNS TTLs, the record set is active passive rather than nearest healthy Region, and players in Asia still traverse the internet with the same jitter. Key exam concept: static IP addresses, UDP or other non HTTP protocols, and deterministic fast failover mean Global Accelerator. Caching, HTTP, signed URLs, and edge functions mean CloudFront. DNS based policies are the choice when clients can tolerate TTL delays.

Question #17 Design Secure Architectures

A financial services company stores customer statements in an S3 bucket that receives several million small PDF objects per day. Compliance now requires that every object be encrypted at rest with a key the company controls, that every use of the key be recorded in AWS CloudTrail, that the company be able to revoke a specific application's ability to decrypt without touching bucket policies, and that unencrypted uploads be rejected. The finance team has also asked the architect to keep AWS KMS request charges low given the object volume. The application fleet uploads with the AWS SDK and can be redeployed with new configuration, and the objects are read by several internal applications that each run under their own IAM role. A developer has already added the following statement to the bucket policy: Which set of changes will meet these requirements?

{
  "Sid": "DenyUnencryptedUploads",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::sailor-sh-statements/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Change the condition value to aws:kms, set default encryption to SSE-KMS with a customer managed key, and enable S3 Bucket Keys. A customer managed KMS key is the only option that the company controls through a key policy, that logs every cryptographic use in CloudTrail, and that lets access be revoked per application, while bucket keys keep the request bill in check. The value AES256 in the drafted policy selects SSE-S3, where Amazon S3 owns and manages the keys. That satisfies encryption at rest but nothing else in the list: there is no key policy to edit, no per application grant to revoke, and no CloudTrail record of key use because S3 never calls AWS KMS. Switching the condition value to aws:kms makes the policy reject any upload that does not request SSE-KMS. Be careful about what a negated operator does when the header is missing altogether: AWS documents that when a condition requires a key not to match, such as StringNotEquals, and that key is absent from the request context, the condition evaluates to true. The Deny therefore fires and a PutObject with no encryption header is rejected with a 403 rather than landing quietly under the bucket default. That is exactly why the stem allows the fleet to be redeployed, because the SDK clients have to be configured to send the header. Bucket default encryption with the customer managed key then decides which key is used when a request asks for aws:kms without naming a key ARN. With a customer managed key the company writes the key policy, so an application's role can be granted kms:Decrypt today and removed tomorrow without touching a single bucket policy, and every GenerateDataKey and Decrypt call is a CloudTrail event that names the caller. Millions of small objects would normally mean millions of KMS requests, because S3 requests a fresh data key from KMS for every object under SSE-KMS. An S3 Bucket Key changes that: KMS issues a short lived bucket level key, S3 derives per object data keys from it locally, and requests to KMS drop by up to 99 percent. CloudTrail still records the bucket level key operations, and each requester triggers at least one KMS call so its access is captured, which keeps the audit requirement intact while the request charges fall. Keeping AES256, enabling default SSE-S3, and turning on CloudTrail data events confuses two kinds of logging. Data events record S3 object level API calls such as PutObject and GetObject, they do not record key usage, and SSE-S3 has no key policy the company can control or use to revoke an application. The compliance requirements about the key are simply not met. Using the AWS managed key aws/s3 with bucket keys gets the request cost and CloudTrail logging right but fails on control. The key policy of an AWS managed key cannot be edited, so the company cannot grant or revoke a specific application's decrypt permission through it, and the key cannot be used for cross account access if that is ever needed. Switching to SSE-C with a key held in Secrets Manager moves the wrong way. With SSE-C the client supplies the raw key on every request, AWS does not store it, KMS is never involved, so there is no CloudTrail record of key use, no key policy, and no way to revoke one application without rotating the key for all of them. Key exam concept: SSE-S3 is encryption with no key control, SSE-KMS with an AWS managed key adds auditing but not a key policy you can edit, SSE-KMS with a customer managed key adds full control and revocation, and SSE-C hands the key problem back to the client. S3 Bucket Keys are the answer to KMS request cost at high object counts.

Question #18 Design Cost-Optimized Architectures

A company wants to commit to one year of steady compute spend for a discount. During the term it will move workloads to a different instance family, shift some services from Amazon EC2 to AWS Fargate, and run new functions on AWS Lambda in another Region. Which purchasing option provides a discount that continues to apply through all of these changes?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: A Compute Savings Plan with a one year term. It is the only commitment whose discount follows usage across instance families, Regions, and compute services, including Fargate and Lambda. Savings Plans are a commitment to spend a fixed amount per hour on compute for one or three years, and in return AWS bills the covered usage at a discounted rate. The Compute Savings Plan is the flexible member of the family. AWS applies it automatically to EC2 usage regardless of instance family, instance size, operating system, tenancy, or Region, and it also covers AWS Fargate and AWS Lambda usage. The documentation's own examples are the stem's plan almost word for word: move a workload from one family to another, shift usage from one Region to another, or migrate an application from EC2 to Fargate, and keep the discount throughout. The price for flexibility is a slightly lower maximum discount, up to 66 percent off On-Demand, compared with the less flexible options. The way to keep the family straight is to ask what each commitment is tied to. Standard Reserved Instances are tied to an instance family in a Region and, for zonal reservations, to an Availability Zone. EC2 Instance Savings Plans are tied to an instance family in a Region but float across sizes, operating systems, and tenancy within that family. Compute Savings Plans are tied to nothing but a dollar per hour amount. Only the last one survives a change of family, a change of Region, and a move off EC2 entirely. Standard Reserved Instances for the current family and Region stop applying the moment the workload moves to a different family or Region, and they never cover Fargate or Lambda. Convertible Reserved Instances allow an exchange to another family, but that is a manual exchange rather than an automatic discount, and they too are EC2 only. An EC2 Instance Savings Plan for the current family and Region offers the deepest discount, up to 72 percent, precisely because it is locked to that family in that Region. Changing families, moving Regions, or shifting to Fargate and Lambda all fall outside the plan. On-Demand Capacity Reservations in each Region are not a discount at all. They reserve capacity in a specific Availability Zone so instances can always launch, and they are billed at On-Demand rates whether or not the capacity is used. A Savings Plan or Reserved Instance can be combined with them to add a discount, but on their own they raise cost rather than lower it. Key exam concept: the more flexible the commitment, the smaller the discount. Compute Savings Plans span families, Regions, Fargate, and Lambda, EC2 Instance Savings Plans and Reserved Instances are family and Region bound, and Capacity Reservations buy availability rather than savings.

Question #19 Design Resilient Architectures

A company runs a customer portal in a single VPC. An Application Load Balancer spans public subnets in two Availability Zones and forwards to a single EC2 instance in a private subnet in the first Availability Zone. The instance downloads software updates through one NAT gateway that sits in the public subnet of the first Availability Zone, and the private subnets in both Availability Zones share one route table that points to that NAT gateway. The database is an Amazon RDS for PostgreSQL Multi-AZ instance. Last month a failure in the first Availability Zone took the portal offline for four hours. The company has already moved session data from the instance's memory to Amazon ElastiCache. It now wants the portal to keep serving customers and to keep outbound internet access during the loss of any single Availability Zone, with the LEAST change to the existing design. Which combination of steps should a solutions architect take to meet these requirements? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: Launch the application from an Auto Scaling group with a minimum of two instances across both Availability Zones as the load balancer's target group, and add a NAT gateway in the second Availability Zone's public subnet with a separate route table that sends that zone's private subnet to it. Those two changes remove the two remaining single points of failure, the lone instance and the lone NAT gateway, while leaving the load balancer, the database, and the cache exactly as they are. The load balancer already spans both zones and the database is already Multi-AZ, so the first zone's outage hurt because everything behind the load balancer lived in that zone. An Auto Scaling group with a minimum of two instances and both private subnets in its configuration keeps one instance in each zone, replaces any instance that fails its health check, and registers instances with the load balancer's target group automatically. Because session state now lives in ElastiCache, any instance can serve any customer, which is the precondition for running more than one. That is horizontal scaling doing its second job: not capacity, but availability. The NAT gateway is the subtler single point of failure. A zonal NAT gateway is created in a specific Availability Zone and is redundant only within that zone. AWS states directly that when resources in several zones share one NAT gateway and that gateway's zone goes down, the other zones lose internet access. The fix is one NAT gateway per zone and per zone route tables, so each private subnet reaches the internet through the gateway in its own zone. That also stops cross zone data transfer charges for the outbound traffic. AWS has since added a regional availability mode for NAT gateways that expands across zones automatically, but the pattern the exam tests, and the least change to an existing zonal design, is the per zone gateway with its own route table. Enabling cross zone load balancing changes how load balancer nodes spread requests across registered targets in all zones. Application Load Balancers already do this by default, and it makes no difference when there is only one target. One instance behind any load balancer is still one instance. Sharing the EBS volume with a second instance in the other zone through Multi-Attach is not possible. EBS volumes are bound to a single Availability Zone, and Multi-Attach only lets io1 and io2 volumes attach to several instances in that same zone with a cluster aware file system. An EBS volume can never span zones. Replacing the NAT gateway with NAT instances in each zone swaps a managed, in zone redundant service for self managed EC2 instances that must be patched, sized for bandwidth, and monitored, and that fail as a unit when the instance fails. It is more change and less resilience than adding a second NAT gateway. Key exam concept: a load balancer across zones does not make a single instance highly available, an Auto Scaling group with a minimum of two across zones does, and a NAT gateway is a zonal resource that needs one copy per zone with matching route tables. Look for every component that exists exactly once in one zone.

Question #20 Design High-Performing Architectures

A media company processes uploaded images with a fleet of EC2 instances in an Auto Scaling group. A web tier drops one message per image into an Amazon SQS standard queue, and each instance takes an average of 0.5 seconds to process a message. Upload volume varies unpredictably from a few hundred to a hundred thousand images per hour with no daily pattern. The group currently scales on average CPU utilization, which stays low because the workers spend most of their time waiting on S3 and network calls, so the queue backlog grows to hours during spikes while CPU never crosses the threshold. The product team has set a target that no image waits more than 60 seconds before processing begins. The architect wants the fleet size to track the amount of work actually waiting rather than a proxy signal, and wants to avoid running a custom metric publisher on the workers. Which combination of steps should a solutions architect take to meet these requirements with the LEAST operational overhead? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: define a metric math expression that divides the queue's ApproximateNumberOfMessagesVisible by the group's GroupInServiceInstances to produce a backlog per instance metric, and create a target tracking scaling policy on that metric with a target value of 120 messages per instance. Backlog per instance is the signal AWS recommends for queue driven fleets, metric math builds it from metrics CloudWatch already publishes, and 120 is what this scenario's own numbers produce. The AWS guidance on scaling with Amazon SQS explains why raw queue length is the wrong signal. The number of messages waiting says nothing on its own about how many instances are needed, because that depends on how long a message takes and how much delay the business will accept. The right metric is backlog per instance, the approximate number of visible messages divided by the number of instances in service. The target value is the acceptable backlog per instance, and it comes from one division: the latency you can tolerate divided by the average processing time per message. Here that is 60 seconds divided by 0.5 seconds, which is 120 messages per instance. When the backlog per instance climbs above 120 the group scales out in proportion to the excess, and when it drops the group scales in, which is the tracking behavior the architect asked for. Historically this pattern needed a script on an instance to compute the ratio and publish it as a custom metric. The current documentation points to metric math inside the target tracking policy instead: an expression with ApproximateNumberOfMessagesVisible from the SQS namespace as one input, GroupInServiceInstances from the Auto Scaling namespace as the other, and the division as the returned series. Target tracking then creates and manages the CloudWatch alarms itself. That is why these two steps are one solution rather than two alternatives: the expression defines the metric and the policy acts on it, and neither does anything useful alone. A step scaling policy on ApproximateNumberOfMessagesVisible with a fixed threshold of 1,000 messages uses the raw queue length, so a thousand waiting messages triggers the same two instance response whether the group is running two instances or two hundred. Fixed steps also cannot be sized against a latency target, and the group would oscillate as the fleet grew. A target tracking policy on the same backlog per instance metric with a target value of 30 picks the right metric and runs the arithmetic backwards. Thirty is 60 multiplied by 0.5 instead of 60 divided by 0.5, and the acceptable backlog per instance is a division of the tolerable latency by the per message processing time. Holding every instance to 30 queued messages holds queue wait to 15 seconds, which over provisions the fleet by roughly a factor of four and pays for it every hour. Choosing a target that is far tighter than the requirement is an ordinary production mistake rather than a trick. Target tracking on CPU utilization with a lower target of 20 percent keeps the metric that has already proven blind to the backlog. These workers are bound by S3 and network waits, so CPU stays low no matter how deep the queue gets, and lowering the target only makes the group react to noise instead of to demand. Key exam concept: queue driven fleets scale on backlog per instance, and the target value is acceptable latency divided by average processing time per message, never the raw queue depth and never CPU. Target tracking is the default policy type on this exam, scheduled scaling is for known recurring patterns, and step scaling is for responses that must vary with the size of the breach.

AWS Certified Solutions Architect - Associate Practice Test

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Why this is correct

Frequently asked questions about the SAA-C03 exam