How many questions are on the SAP-C02 exam and how long is it?

The exam delivers 75 questions in 180 minutes, which works out to about 2.4 minutes per item. Only 65 of those items are scored, and the remaining 10 are unscored questions that AWS never identifies, so you have to answer all 75 as if they count. There are two response types only, multiple choice with one correct answer and multiple response with two or more, and there is no hands-on lab. Every Sailor.sh mock exam gives you 75 questions in the same 180 minute window and scores all of them, so the pacing you practice is the pacing you face.

What is the passing score for the SAP-C02 exam?

SAP-C02 is scored on a scaled range of 100 to 1,000 and you need 750 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 750 is not the same as answering 75 percent of items correctly. Every exam in the Sailor.sh bundle totals exactly 1,000 marks and reports against the same 750 bar.

What topics does the SAP-C02 exam cover?

Four domains: Design Solutions for Organizational Complexity at 26 percent, Design for New Solutions at 29 percent, Continuous Improvement for Existing Solutions at 25 percent, and Accelerate Workload Migration and Modernization at 20 percent. Expect AWS Organizations and service control policies, Transit Gateway and Direct Connect designs, hybrid DNS with Amazon Route 53 Resolver, AWS KMS key policies, disaster recovery from backup and restore through multi-site, deployment strategies, cost visibility and purchasing options, and migration tooling such as AWS Application Migration Service and AWS DMS.

What experience do I need before taking SAP-C02?

AWS recommends two or more years of experience using AWS services to design and implement cloud solutions. There is no formal prerequisite, and you do not have to hold the associate certification first. Candidates who pass comfortably have usually designed a multi-account environment, connected a data center to AWS, and run at least one real migration, because the exam asks you to choose between designs that all work and only one of which meets every constraint in the stem.

Is SAP-C02 being replaced by SAP-C03?

Yes. AWS has announced SAP-C03, with registration opening October 27, 2026, and SAP-C02 remains available until mid November 2026. AWS states that SAP-C03 keeps the same 75 question, 180 minute, 300 USD format, and its exam guide is due when registration opens. These practice questions are built for the SAP-C02 exam guide (Version 1.2), and a content refresh for SAP-C03 is planned once AWS publishes the new guide. Dates are subject to change, so confirm them on aws.amazon.com before you book.

How should I prepare for the SAP-C02 exam?

Start with the official SAP-C02 exam guide and its twenty task statements, then build the designs it describes in your own accounts: an organization with service control policies and a delegated security administrator, a Transit Gateway hub with a shared services VPC, a cross-Region recovery plan that you actually fail over. Read the reliability, security, and cost optimization pillars of the AWS Well-Architected Framework, because the stems are written in their language. Finish with full length mock exams under the real 180 minute limit, read the explanation for every miss, and repeat your weakest domain until you clear 750 consistently.

AWS Certified Solutions Architect - Professional (SAP-C02): Free Practice Test with AI Feedback

Q: What is the AWS Certified Solutions Architect - Professional (SAP-C02) certification?

SAP-C02 is the professional level credential for the solutions architect role. It validates advanced skill in designing optimized AWS solutions on the AWS Well-Architected Framework, and the exam guide describes a candidate who can give expert architectural guidance across multiple applications and projects inside a complex organization. In practice that means multi-account governance, hybrid networking, disaster recovery against a stated RTO and RPO, and migrations at scale. The credential is valid for three years.

Question #1 Design Solutions for Organizational Complexity

A holding company runs 42 AWS accounts inside one AWS Organizations organization. Seven business units own those accounts outright, and the operating agreement signed when the units were acquired guarantees that every unit keeps the ability to use any AWS service in any AWS Region without central approval. A new group security policy now requires the central security team to learn within minutes whenever an account exposes a resource publicly, leaves a new volume unencrypted, or drifts from the company baseline, and to keep one searchable record of those findings for the annual audit. Today the security team receives nothing. Each business unit runs its own detective tooling and mails a summary once a quarter. The security team has four engineers, and the chief information security officer has ruled out building or maintaining collection code inside 42 member accounts. Which solution will meet these requirements with the LEAST operational overhead?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Delegate AWS Security Hub and Amazon GuardDuty administration to a security account, turn on organization wide enablement for new accounts, and route findings to the team through Amazon EventBridge. Detection and aggregation are the only class of control that survives an agreement promising every unit unrestricted use of AWS. Read the constraint before the requirement list. The acquisition agreement guarantees that each unit may use any service in any Region without central approval. That one sentence removes every preventive instrument from consideration, because service control policies, Control Tower preventive controls and permissions boundaries all work by refusing API calls. What the new policy actually asks for is awareness in minutes plus a durable, searchable record, and that is an aggregation problem rather than a governance problem. Security Hub and GuardDuty are both built for exactly this shape. Each supports a delegated administrator account nominated once from the management account, and after delegation the administrator can enable the service across the whole organization and switch on automatic enablement so that accounts created later are covered with nobody touching them. GuardDuty produces threat findings from CloudTrail, DNS and VPC flow telemetry. Security Hub runs the standards checks, normalizes findings from GuardDuty, Amazon Inspector, Amazon Macie and AWS Config into one schema, and holds them centrally with cross-Region aggregation available on top. Every finding is published to the default EventBridge bus in the administrator account, so one rule filtered on severity gives four engineers alerting in minutes with no collection code anywhere. Note the division of labor the exam keeps probing. GuardDuty detects, Security Hub aggregates and scores, and neither prevents anything. That is precisely why the pair fits an organization where prevention is contractually off limits, and it is also why neither of them alone would satisfy the searchable record requirement. One naming point for the exam room: AWS has renamed the aggregation service in its documentation to AWS Security Hub CSPM, while the SAP-C02 exam guide and the exam itself still print AWS Security Hub. A service control policy at the organization root plus a weekly CloudTrail review breaks the operating agreement on its first day, because an SCP is a permission ceiling that denies the very services the business units were promised. It also answers the wrong question. A weekly read of access denied entries is neither within minutes nor a record of resource exposure. A Config rule pack pushed to each account with a Lambda function that emails the security team is technically workable, which is what makes it tempting, but it is the overhead the CISO explicitly ruled out. It means owning a function, a role and an alerting path in 42 accounts, and a mailbox full of messages is not a searchable finding store. An AWS Config aggregator in a security account, reviewed when the annual audit comes round, is the near miss worth studying, because unlike the others it is both central and detective. It loses on timing first. A view that somebody opens once a year is a periodic read rather than awareness within minutes, and an aggregator carries no notification path of its own. It loses on reach second. AWS documents that an aggregator is a read only view into its source accounts and that rules cannot be deployed through it, so every check that would notice a public resource or an unencrypted volume still has to be switched on in all 42 accounts and every Region before the aggregated view holds anything at all. Key exam concept: when a stem promises that account owners retain full control, every preventive answer is wrong by construction, and the detective options that remain are then separated by how a finding travels. Delegated administration with organization wide automatic enablement is what gives an AWS security service reach into accounts the central team does not govern, and a push onto an event bus is what turns those findings into alerting within minutes, which an aggregated view a human opens later never does.

Question #2 Design for New Solutions

A retail company runs its checkout API as an Amazon ECS service on AWS Fargate behind an Application Load Balancer. A release last month reached every customer at once, and a defect in it was found only after 20 minutes of failed payments. The release policy now states three things. A new revision must serve 10 percent of production traffic for 15 minutes before the remaining traffic moves. Returning to the previous revision must take effect for every client immediately rather than waiting for a cache to expire. The service must keep full request capacity for the whole deployment. The build pipeline already produces and pushes container images on every merge. Which deployment approach will meet these requirements?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Move the service to the CodeDeploy deployment controller with a second target group on the existing load balancer and a canary deployment configuration that shifts 10 percent of traffic and waits 15 minutes. A traffic shift performed at the load balancer is what holds a precise share for a fixed interval and then takes all of it back in a single operation. Amazon ECS offers two paths to a controlled traffic shift. One is the CodeDeploy deployment controller, where the service is created with the CODE_DEPLOY controller and the shift is described by an AppSpec file and a CodeDeploy deployment configuration. That is the path this option selects. The other is the ECS deployment controller's own blue/green strategy, configured on the service with a bake time, lifecycle hooks and alarm based rollback, which AWS now recommends and which it also documents in linear and canary forms driven by a canary percentage and a canary bake time. No option in this set offers the native path, so the CodeDeploy mechanism is the one to reason about here. On the CodeDeploy path the load balancer is given two target groups, one holding the original task set and one waiting empty for the replacement. CodeDeploy launches the replacement task set at full size first, optionally sends synthetic traffic to it through a separate test listener, and then rewrites the production listener according to the deployment configuration. Because the replacement runs at full size before any customer sees it, request capacity never dips. The deployment configuration is where the 10 percent and the 15 minutes come from. AWS publishes canary configurations such as CodeDeployDefault.ECSCanary10Percent15Minutes, which moves 10 percent of traffic in the first increment and the remaining 90 percent fifteen minutes later, and custom canary and linear configurations can be defined when the published ones do not match the policy. Rollback is what makes this shape valuable. The original task set is still registered and still running until the termination wait expires, so aborting the deployment points the production listener back at it in one load balancer operation that every in flight and new connection follows at once. One caveat belongs in the exam room alongside it. On the CodeDeploy path a Network Load Balancer leaves only the all at once predefined configuration available, so a canary shift there wants an Application Load Balancer. The ECS controller's own blue/green, linear and canary deployments do work with a Network Load Balancer, at the cost of an added delay on the traffic shift stages. A currency note is worth carrying with this topic. Exam guide era material names the CodeDeploy controller whenever it asks about blue/green on Amazon ECS, while the current console and user guide lead with the native Amazon ECS blue/green deployment, and the CodeDeploy page in the ECS developer guide now opens by recommending that native path. Expect either wording in front of you and let the option text say which controller is actually on the table. Keeping the rolling update deployment controller with minimum healthy percent 100 and maximum percent 200 protects capacity, which is why it looks close. What it describes is the rolling strategy, and a rolling update controls how many tasks run each revision, never what share of traffic each receives. The load balancer spreads requests evenly across whatever tasks are registered, the ratio drifts as tasks are replaced, and rolling back means running a second rolling deployment of the previous task definition. A second load balancer with a weighted Amazon Route 53 record starting at 10 percent puts the traffic split in DNS, where the company has already been burned. Resolvers and client libraries cache answers for the record's time to live and often longer, so neither the 10 percent share nor the rollback is precise or immediate, which is the exact requirement the policy calls out. Publishing the revision as an AWS Lambda alias with a canary configuration describes a real CodeDeploy capability applied to the wrong compute platform. Alias weighting shifts invocations between two versions of a function. There is no function here, only a containerized service, so nothing in the checkout path would be shifted. Key exam concept: a rolling deployment controls how many tasks run each version, a blue/green deployment controls what share of traffic each version receives and gives a single switch to undo it. When a stem fixes a percentage, an interval, and an immediate rollback, the answer lives at the load balancer, never in DNS.

Question #3 Accelerate Workload Migration and Modernization

A manufacturing company is closing a regional data center in 30 days. One NFS file server at the site holds 90 TB of engineering drawings that must be in an Amazon S3 bucket before the power is cut, and the drawings must stay readable on the file server until the final cutover weekend. The site reaches AWS over an existing Direct Connect connection and a separate internet circuit. The network team published what each path can give the migration. Company policy forbids sending engineering data across the public internet, every transferred file must be checked against the source after it is written, and the company has never ordered an AWS Snow Family device. Which solution will meet these requirements MOST cost-effectively?

Path                         Link speed   Capacity free for migration
Direct Connect private VIF   1 Gbps       600 Mbps, 22:00 to 10:00 only
Site internet circuit        200 Mbps     50 Mbps, all day

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: Deploy an AWS DataSync agent in the data center and run a scheduled task from the NFS share to the S3 bucket inside the nightly transfer window, letting the task verify what it wrote. The existing private circuit already carries enough capacity in the free window to finish inside the deadline, so nothing new has to be bought or shipped. Do the arithmetic before looking at services, because on this exam the numbers decide the design. The window offers 600 Mbps from 22:00 to 10:00, which is 12 hours. Six hundred megabits per second is 75 megabytes per second, and 75 megabytes per second across 43,200 seconds is roughly 3.24 TB moved per night. Ninety terabytes divided by 3.24 TB is about 28 nights, which lands inside the 30 day window with a small margin. Run the same sum on the internet circuit and it collapses. Fifty megabits per second is a little over 6 megabytes per second, which needs more than five months, and the policy forbids that path anyway. DataSync is the managed service for exactly this movement. A virtual agent deployed next to the file server mounts the NFS export, talks to the DataSync service endpoint, and copies data to Amazon S3 with parallelism and compression the service manages. Tasks can be scheduled so they only run inside the agreed window, a bandwidth limit keeps the copy from eating production capacity, and the task verifies transferred data so the integrity requirement is satisfied without a hand written checksum job. Because the agent reads the share rather than replacing it, engineers keep using the file server until the cutover weekend, and the final incremental run only carries what changed. Ordering a 10 Gbps dedicated connection and aggregating it with the existing one confuses bandwidth with time. A dedicated connection has to be requested, allocated at a Direct Connect location, and cross connected by the colocation provider, which routinely takes longer than the 30 days that remain. A link aggregation group also requires member connections of the same port speed at the same location, so a 10 Gbps connection could not be bundled with the 1 Gbps one. Deploying an Amazon S3 File Gateway and pointing users at its share answers a hybrid access question instead of a migration question. The gateway presents a cached share backed by the bucket, so existing files still have to be copied through the same Direct Connect capacity, the arithmetic does not change, and the team gains an appliance to run on a site that is being switched off. Requesting AWS Snowball Edge devices to ship the data is no longer an option for this company. AWS Snowball Edge is closed to new customers, and the AWS guidance for a customer in this position is DataSync for online transfers or AWS Data Transfer Terminal for a physical handover. Offline shipping would also break the requirement that the drawings stay readable until cutover. Key exam concept: when a migration stem prints a link speed, a usable window and a deadline, multiply them out first. Online transfer with DataSync wins whenever the sum fits, and the offline options only enter the picture when it does not.

Question #4 Design Solutions for Organizational Complexity

A finance team asks whether committing to a Compute Savings Plan will also guarantee that the quarterly close job can launch 200 instances in one named Availability Zone on the first business day of every quarter. The architect has to explain how commitment based discounts and capacity assurance differ in Amazon EC2 before the commitment is signed. Which statement is correct?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: A Savings Plan only lowers the rate on matching usage, so an On-Demand Capacity Reservation in that Availability Zone is what guarantees the capacity. Discount and capacity are separate products in Amazon EC2, and the exam tests whether a candidate keeps them separate. A Savings Plan is a billing construct. The company commits to spending a certain amount per hour for one or three years, and AWS applies a discounted rate to matching usage as it occurs. A Compute Savings Plan matches the broadest set of usage, covering EC2 instances regardless of family, size, operating system, tenancy or Region, and also covering AWS Fargate and AWS Lambda. An EC2 Instance Savings Plan matches a chosen instance family in a chosen Region and gives a deeper discount in exchange for that narrower scope. Neither one asks AWS to hold hardware aside. If the Availability Zone is short of the instance type on close day, the launch fails at the same rate it would without any commitment. Capacity assurance comes from two constructs. An On-Demand Capacity Reservation reserves capacity for a specified instance type, platform and tenancy in one Availability Zone. A reservation created for immediate use carries no term commitment at all, so the team can create one shortly before the close window and cancel it afterwards, paying On-Demand rates for the reserved capacity whether or not instances are running in it. A zonal Reserved Instance also reserves capacity in a single Availability Zone, and unlike a Capacity Reservation it carries a billing discount, at the cost of a one or three year commitment. The two constructs combine cleanly, because a Capacity Reservation provides no discount of its own but the usage inside it can be covered by a Savings Plan or a regional Reserved Instance. A Compute Savings Plan reserving capacity across the Region states the misconception the finance team already holds. The AWS comparison of these purchase options records no capacity benefit for Savings Plans at all, so signing a larger commitment changes nothing about whether 200 instances can start. A regional Reserved Instance reserving capacity in every Availability Zone inverts the trade that regional and zonal Reserved Instances make. The regional scope buys Availability Zone flexibility and instance size flexibility on the discount, and it explicitly gives up the capacity reservation that the zonal scope provides. An On-Demand Capacity Reservation needing a one or three year term mistakes it for a Reserved Instance. Reservations created for immediate use can be created, modified and cancelled whenever the team wants, which is precisely why they suit a workload that only needs certainty for a few days each quarter. Only a future dated reservation carries a commitment duration. Key exam concept: Savings Plans and regional Reserved Instances buy a lower price, Capacity Reservations and zonal Reserved Instances buy capacity, and a scenario that asks for both needs one of each. Watch for the word guarantee in a stem, because that is the signal that a discount alone will not answer the question.

Question #5 Design for New Solutions

A logistics company is designing a new shipment tracking service. Amazon API Gateway will accept up to 12,000 requests per second at peak, and an AWS Lambda function will validate each shipment before registering it with a carrier partner over the partner's REST API. The partner contract caps the company at 500 requests per second and states that sustained bursts above that figure suspend the account. The same partner API returns HTTP 500 responses for several minutes during its own nightly maintenance window. The business requires that no shipment registration is ever lost, that registrations catch up on their own once the partner recovers without an engineer intervening, and that a small number of permanently malformed shipments can be inspected later instead of blocking everything behind them. Reserved concurrency is already set on the validation function. Which combination of steps should the solutions architect take to meet these requirements? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: buffer the registrations in an Amazon SQS queue and cap the maximum concurrency on that queue's Lambda event source mapping, then retry partner failures with exponential backoff and jitter behind a dead-letter queue. Together they decouple the arrival rate from the partner rate and give failures somewhere to go. The shape of this problem is a fast producer in front of a slow, fragile consumer. A queue is the only component that absorbs a 12,000 request per second arrival rate while releasing work at whatever pace the downstream can take, and it is also what keeps the registrations durable while the partner is down. Messages sit in Amazon SQS for up to 14 days, so a maintenance window measured in minutes costs nothing but latency. Releasing work at the right pace is the part candidates usually miss. Left alone, a Lambda event source mapping on a standard queue starts with five concurrent invocations and adds up to 300 more per minute, which would sail straight past the partner's 500 request per second ceiling. The maximum concurrency setting on the event source mapping is the control for that. It is configured per event source, accepts a value between 2 and 1,000, costs nothing, and limits how many function instances that queue may invoke. AWS also notes that maximum concurrency and the function's reserved concurrency are independent settings, so the reserved concurrency already in place must be at least as large as the sum of the maximum concurrency values across the function's queue triggers. The second half is failure handling. Retrying immediately against an API that is returning HTTP 500 simply burns the partner's rate budget, so retries inside the function use exponential backoff with jitter to spread attempts out. Messages that keep failing after the queue's maximum receive count is reached move to a dead-letter queue, where malformed shipments can be inspected and, once fixed, replayed to the source queue with redrive. That is exactly the inspect later requirement, and it stops one poison message from consuming the concurrency budget forever. Raising the Lambda concurrent execution quota and the reserved concurrency on the carrier function aims a quota increase at the wrong bottleneck, the pattern the exam repeats constantly. Concurrency is not what limits this design. The partner contract is, and more concurrency only pushes the account past 500 requests per second sooner. Reserved concurrency is the wrong instrument here in any case, because it bounds how many function instances run at once rather than a rate, so the requests per second that a given concurrency produces still drifts with the partner's response time. Calling the partner from a Step Functions Express workflow with a Map state increases parallelism, which is the opposite of what a rate limited dependency needs. Express workflows also provide at least once execution with a five minute ceiling and are not a durable buffer, so registrations in flight during the maintenance window would still have to be retried from somewhere. Throttling the API Gateway stage to 500 requests per second and returning HTTP 429 to the excess callers applies the limit at the front door rather than at the partner boundary. Usage plans and stage throttling govern callers of the company's own API, so the effect is rejecting roughly 11,500 customer requests a second, which loses the registrations the business says must never be lost. Answering those callers with an explicit 429 does not rescue the work either, it moves the duty to retry onto client applications the company does not control. Key exam concept: a queue decouples arrival rate from processing rate, and the event source mapping's maximum concurrency is what converts that queue into a rate limiter for a downstream dependency. Throttling the entry point drops work, throttling the consumer delays it.

Question #6 Continuous Improvement for Existing Solutions

A gaming company runs a session service in three AWS Regions behind Network Load Balancers. Clients speak a proprietary UDP protocol, and enterprise customers allow the service through their own firewalls by IP address. Traffic reaches the Regions through Amazon Route 53 latency records today. During a Regional impairment last month, players stayed pinned to the failing Region for several minutes because resolvers and the client library held the cached answer. The company wants Regional failover to take effect within seconds, wants customer firewall entries to stop changing whenever a load balancer is replaced, and will not rewrite the protocol. 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 one endpoint group per Region, add the Network Load Balancers as endpoints, and publish the two static anycast addresses to customers. It is the only entry point in the list that carries UDP, presents fixed addresses, and fails over without waiting on DNS. Three requirements have to hold at once, and each one eliminates a whole family of answers. The protocol is UDP, which rules out every service that only understands HTTP. The customers allowlist by address, which rules out anything whose addresses change when infrastructure is replaced. Failover must take seconds, which rules out anything that depends on a cached DNS answer expiring. Global Accelerator satisfies all three because it works at the network layer. A standard accelerator is given two static anycast IP addresses from the AWS edge network, and those addresses belong to the accelerator rather than to any load balancer, so customers can keep them in a firewall rule permanently even if every Network Load Balancer behind them is rebuilt. Traffic enters the AWS backbone at the nearest edge location and is carried to an endpoint group, and because accelerators handle TCP and UDP the proprietary protocol crosses unchanged. Global Accelerator runs its own health checks against the endpoints, and when a Region fails the anycast addresses simply stop being answered from that endpoint group. Clients keep connecting to the same addresses and reach a healthy Region, which is why the change takes effect in seconds rather than at the mercy of a resolver cache. An Amazon CloudFront distribution with origin failover between the Regional origins fails at the first requirement. CloudFront is an HTTP and HTTPS content delivery network, so it cannot proxy a proprietary UDP protocol at all, and origin failover reacts per request for HTTP status codes rather than steering a session protocol. Shortening the record time to live to 10 seconds and attaching health checks is the fix teams reach for first, and it still leaves the outcome in the hands of client resolvers. Recursive resolvers and language runtimes routinely keep answers longer than the published value, and the enterprise firewall entries still change every time a load balancer is replaced. Assigning Elastic IP addresses to the load balancers and using a Route 53 failover record fixes half the problem and leaves the harder half. Each Region still has its own addresses, so customers must allowlist all of them and update the list as Regions are added, and the switch between Regions is still a DNS operation subject to caching. Key exam concept: static IP addresses or a non HTTP protocol point at AWS Global Accelerator, while caching, signed URLs or origin shielding point at Amazon CloudFront. When a stem complains that failover took minutes because of cached answers, the fix is to stop steering with DNS.

Question #7 Design Solutions for Organizational Complexity

A media company keeps its curated content catalog in an Amazon S3 bucket in a central data account, encrypted with a customer managed AWS KMS key in that same account. A new analytics account runs an Amazon EMR cluster under a role named DataReader. The bucket policy in the data account already grants that role s3:GetObject on the catalog prefix, and the role's identity policy in the analytics account allows the same action on the same prefix. Every read still fails with an access denied error that names AWS KMS rather than Amazon S3. The security team supplied the key policy that is in force. Account 111122223333 is the data account. The catalog must stay encrypted under a key that the data account controls. Which solution will resolve this issue?

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableIAMUserPermissions",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowKeyAdministrators",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/KeyAdmin" },
      "Action": [ "kms:Create*", "kms:Describe*", "kms:List*", "kms:Put*" ],
      "Resource": "*"
    }
  ]
}

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: add a key policy statement allowing the DataReader role kms:Decrypt on the key, and allow kms:Decrypt on the key ARN in that role's identity policy. Cross-account use of a KMS key needs a grant of permission on both sides, and the key policy in force names only the data account. Start by reading the error. Amazon S3 returned access denied on behalf of AWS KMS, which tells you the object level authorization succeeded and the failure came when S3 asked KMS to decrypt the data key. That narrows the problem to key permissions and rules out every answer that adjusts Amazon S3. AWS KMS documents the rule plainly. No principal, not even the account root user or the key creator, has any permission on a KMS key unless a key policy, an IAM policy or a grant allows it, and an IAM policy can only allow what the key policy has already made available. The statement in the artifact with the account root as the principal is the standard enabling statement, and it delegates authority to IAM policies in account 111122223333 only. Nothing in this key policy mentions the analytics account, so no identity policy written there can grant access to the key. The fix is therefore two sided. The data account adds a statement that allows the DataReader role principal to call kms:Decrypt, and optionally kms:DescribeKey, on the key. The analytics account then allows kms:Decrypt on the key ARN in the role's identity policy, because the key policy opening the door does not by itself give the role permission to walk through it. Both halves have to be present, which is the single most tested fact about cross-account KMS on this exam, and the key stays in the data account so the control requirement holds. Adding the DataReader role to the bucket policy repeats work that the stem says is already done and aims at the wrong service. Even a perfect bucket policy cannot authorize the KMS call that decrypting an SSE-KMS object requires. Replacing the customer managed key with the AWS managed key for Amazon S3 would make the situation worse rather than better. An AWS managed key can only be used by principals in the account that holds it, its key policy cannot be edited, and AWS documents that resources encrypted under one cannot be shared with other accounts. Having the analytics account create a grant for itself inverts who may issue a grant. Creating a grant requires kms:CreateGrant permission on the key, which only a principal already authorized by the key policy holds, so the analytics account has nothing to grant from. Key exam concept: a KMS key policy is the primary control and identity policies are secondary. Cross-account use always needs the key policy in the owning account to name the external principal and the caller's own identity policy to allow the key action.

Question #8 Design for New Solutions

A payments company is building a settlement ledger for a market it enters next quarter. The application is PostgreSQL based, leans on stored procedures and foreign keys, and writes through a single primary by design, so the team cannot shard writes or reconcile conflicting updates. The regulator requires that the loss of an AWS Region cost no more than 5 seconds of committed transactions and that the ledger accept writes again within 5 minutes. The same regulator requires a documented failover rehearsal twice a year that loses no committed transaction at all. Reporting queries already account for most of the read volume, and the reporting team sits in a second AWS Region. The ledger starts at roughly 2 TB and grows steadily. The platform group has four engineers and has told the architect that it will not own replication scripts, lag monitors, or promotion tooling. Which solution will meet these requirements with the least operational overhead?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: run an Amazon Aurora PostgreSQL global database with a secondary cluster in the reporting Region, serve reporting reads from that secondary, and use managed planned failover for the rehearsals. It is the only option that meets a seconds level recovery point across Regions without the team building anything. Two numbers decide this item. A recovery point of 5 seconds means replication has to be continuous and measured in about a second, which removes anything based on snapshots or scheduled copies. A recovery time of 5 minutes means promotion has to be a managed operation rather than a runbook someone executes under pressure. A third requirement, the twice yearly rehearsal that loses nothing, quietly asks for a planned switchover rather than an emergency promotion. An Aurora global database is purpose built for this shape. Replication is performed by the storage layer with dedicated infrastructure, so it does not consume database capacity, and AWS documents typical cross-Region replication latency of under a second. A secondary cluster serves reads locally, which also answers the reporting load in the second Region without a separate copy of the data. When a Region is genuinely lost, a secondary can be promoted to accept reads and writes in under a minute. For the rehearsals, managed planned failover performs an orderly role reversal that waits for the secondary to catch up first, so no committed transaction is lost and the global topology is preserved afterwards. AWS documentation now calls this operation a switchover and records managed planned failover as its former name, so expect the older wording in exam era study material and the newer wording in the console and the user guide. Aurora also exposes the recovery point lag of every secondary as a metric, which the regulator's evidence pack needs. The distinction the exam presses on is availability inside a Region versus continuity across Regions. A Multi-AZ deployment protects against the loss of one Availability Zone, and it is not a disaster recovery strategy across Regions no matter how many readable standbys it carries. An Amazon RDS for PostgreSQL Multi-AZ DB cluster with two readable standbys improves availability and adds read capacity inside one Region, and that is where it stops. All three instances live in the same Region, so the regulator's Regional loss scenario is not addressed at all. Amazon RDS for PostgreSQL with a cross-Region read replica promoted on failure is the closest wrong answer and the one worth understanding. Replication is asynchronous through the database engine rather than the storage layer, lag is larger and less predictable, promotion is a manual operation that includes a reboot and takes minutes, and rehearsing it destroys the replication relationship the team then has to rebuild by hand. Remodelling the ledger onto Amazon DynamoDB global tables trades one requirement for another. Global tables do accept writes in every Region, but they reconcile concurrent updates with a last writer wins rule, which no settlement ledger can accept, and the stored procedures and foreign keys the application depends on have no equivalent, so this is a rewrite rather than a continuity design. Key exam concept: match the replication mechanism to the recovery point figure. Storage level replication in an Aurora global database gives about a second, engine level read replicas give minutes and a manual promotion, and snapshots give hours.

Question #9 Continuous Improvement for Existing Solutions

An insurance company has finished the review of a four hour outage that started when one Availability Zone lost power. The workload runs on Amazon EC2 instances in an Auto Scaling group spread across three Availability Zones behind an Application Load Balancer, with an Amazon Aurora cluster whose writer and reader sit in different zones. The review named two causes. First, every private subnet sent outbound traffic through a single NAT gateway that happened to live in the failed zone, so instances in the two healthy zones could not reach the license service or pull patches and were marked unhealthy. Second, the recovery runbook has a CloudFormation stack build the standby environment in a second Region at the moment failover is declared, and that morning the stack stopped part way through because the account had never raised its instance quotas in that Region. Application code cannot change this quarter. Which combination of changes will address these causes with the LEAST change to the architecture? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: put a NAT gateway in every Availability Zone and route each private subnet to the gateway in its own zone, and stand the recovery environment up ahead of time at reduced capacity with the quotas already raised. Each one removes a dependency that turned a zonal event into a total outage. A NAT gateway is a zonal resource. It is created in one subnet in one Availability Zone and it lives and dies with that zone, so a route table in zone B whose default route points at a gateway in zone A has quietly made zone B depend on zone A. AWS guidance is to create a NAT gateway in each Availability Zone and give every private subnet a route to the gateway in its own zone. The change is confined to route tables and two extra gateways, it touches no application code, and it also removes the cross zone data transfer charge that the original layout was paying on every outbound byte. The second cause is a static stability problem. A recovery plan that creates resources during the event depends on control plane operations, and control planes are designed for lower availability targets than data planes. In this outage the dependency showed up as a quota the account had never raised, but it could equally have been a launch failure, a template error found under pressure, or capacity pressure in the recovery Region during a widespread event. The remedy is to deploy the standby environment in advance at reduced capacity, raise the service quotas there before they are needed, and leave failover with nothing to do but scale out and shift traffic. The AWS disaster recovery guidance is explicit that quotas in the recovery Region must be high enough not to limit scaling to production capacity. Requesting a quota increase for NAT gateway port allocation is a quota increase aimed at a bottleneck that was never hit. The outage came from losing the Availability Zone that held the only gateway, not from exhausting simultaneous connections toward one destination, so a larger allocation changes nothing about the failure mode. Copying templates and images into a bucket in the second Region looks like static stability and is not. The templates were available during the event. What failed was the act of creating resources in the recovery Region while under pressure, so having the same template closer to hand leaves every control plane call and every default quota exactly where they were. Replacing the NAT gateway with a NAT instance plus an EC2 recovery alarm moves backwards. A single instance is still a single point of failure, automatic recovery takes minutes and cannot help if the whole zone is gone, and a self managed instance brings back the patching, sizing and throughput ceiling that the managed gateway removed. Key exam concept: zonal resources such as NAT gateways must be duplicated per Availability Zone or they import a dependency the architecture diagram does not show, and a recovery plan that builds resources during the disaster has taken a dependency on the very Region or control plane that failed.

Question #10 Continuous Improvement for Existing Solutions

A brokerage must retain seven years of database backups in a form that no principal can shorten or delete early, including the AWS account root user, once a short settling window has passed. The internal auditor will test the guarantee and will not accept a control that a sufficiently privileged administrator could simply switch off. Which control provides that assurance?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: AWS Backup Vault Lock in compliance mode, with its grace time already expired. It is the only control in the list that becomes immutable to every principal rather than remaining subject to whoever holds the strongest permissions. Vault Lock applies a write once read many policy to a backup vault. It is configured with an optional minimum and maximum retention period, and the mode decides who can undo it later. In governance mode a principal with the right IAM permissions can remove the lock, which makes it a guardrail against mistakes rather than a regulatory control. In compliance mode the configuration carries a cooling off period that AWS calls grace time, which must be at least three days, and during that window the lock can still be removed or adjusted. Once the grace time expires, AWS documents that the vault and its lock are immutable and cannot be changed or deleted by any user or by AWS, and that any user including the root user attempting to delete a backup or change its lifecycle properties will have the operation denied. That last clause is what an auditor is asking about when the requirement names the root user. Most access controls in AWS are ultimately editable by someone, because a policy is a document and a sufficiently privileged principal can rewrite it. Compliance mode is different in kind, since the restriction is enforced by the service rather than by an evaluated policy. The practical cost of that strength is that backups cannot be removed early even when the team wants them gone, so retention settings have to be chosen deliberately and a recovery point with an indefinite retention would be kept forever. Amazon S3 Object Lock in compliance mode gives the same property for objects and is the answer when the data in question is in a bucket rather than a backup vault. Vault Lock in governance mode encodes the exact distinction being tested. AWS states that a vault locked in governance mode can be managed or deleted by users who hold the appropriate IAM permissions, so an administrator with enough privilege can lift the lock and then delete the recovery points, which is what the auditor said would not be accepted. A service control policy denying the delete action across the organization has two weaknesses in this scenario. Service control policies do not apply to the management account, so a root user acting there is unaffected, and the policy itself can be edited or detached by anyone with organization level permissions. A backup vault access policy that denies deletion is a resource policy attached to the vault. Whoever administers the vault can rewrite or remove that statement at any time, so the guarantee lasts exactly as long as nobody with vault permissions decides otherwise. Key exam concept: when a requirement says no principal including the root user, an editable policy of any kind is the wrong answer. Compliance mode locks, whether AWS Backup Vault Lock or S3 Object Lock, are the controls that survive a privileged principal.

Question #11 Accelerate Workload Migration and Modernization

An engineering firm must leave its data center in 90 days. The workload is a Windows based computer aided design suite. Twelve application servers run a .NET service that reads and writes a 40 TB share over SMB, and the share carries NTFS access control lists mapped to groups in an on-premises Active Directory forest that the firm intends to keep running. A licensing daemon on one server is bound to that server's host name and cannot be reinstalled, because the vendor no longer supports the version in use. A Site-to-Site VPN already connects the data center to a landing zone account, and the firm has no Direct Connect circuit and no time to order one. The firm employs no Windows storage specialists, wants to stop patching and resizing file servers after the move, and will not change application code or file permissions during the migration. Which solution will meet these requirements with the least amount of effort?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: rehost the application servers with AWS Application Migration Service and move the share to Amazon FSx for Windows File Server joined to an AWS Managed Microsoft AD directory that trusts the on-premises forest. It is the only combination that keeps SMB, keeps NTFS permissions, keeps the host names, and hands the storage administration to AWS. Three facts in the stem do the elimination. The share is SMB with NTFS access control lists, which limits the storage choice to a service that speaks SMB natively and understands Windows security identifiers. The permissions map to groups in a directory the firm is keeping, which means the file system must authenticate against that directory rather than a copy of it. The licensing daemon is bound to a host name and cannot be reinstalled, which rules out any answer that rebuilds servers instead of moving them. Amazon FSx for Windows File Server is a fully managed Windows file system built on Windows Server, so shares are SMB, NTFS access control lists move with the data, and AWS handles patching, backups and capacity. It has to be joined to a Microsoft Active Directory, and the two supported shapes are the customer's self managed directory or an AWS Managed Microsoft AD directory. Creating an AWS Managed Microsoft AD directory in the VPC and establishing a forest trust to the on-premises forest lets the file system resolve and honor the existing on-premises groups without moving the identity estate, which matters because the firm is keeping its forest. AWS Application Migration Service completes the picture on the compute side. It replicates the source servers block by block while they keep running, lets the team launch test instances for a rehearsal without disturbing production, and cuts over the real servers with their host names, installed software and license state intact. That is what preserves the licensing daemon, and it is also why the deadline is achievable. Note the naming drift here, because it catches candidates who study from the console: the user guide now titles this service AWS Transform MGN, while the SAP-C02 exam guide prints AWS Application Migration Service, and the exam uses the guide name. Amazon EFS with AD Connector pairs two services that cannot do the job. Amazon EFS presents NFS to Linux clients with POSIX permissions, so a Windows application cannot mount it as an SMB share and NTFS access control lists have no representation on it. AD Connector is a directory proxy for AWS applications and does not make a file system Windows aware. Replatforming the servers into Windows containers on Amazon ECS runs into the one constraint the firm cannot negotiate away. A container image is built by installing the software into it, and that is exactly what cannot be done with a licensing daemon that is bound to a single server's host name and abandoned by its vendor, so the tasks would come up unlicensed. What tempts here is the storage half, which is sound, because Amazon FSx for Windows File Server accepts self managed domain controllers as its directory just as readily as a managed one, so SMB and the NTFS permissions really would survive. The compute half is where the answer dies, and repackaging a .NET service that the firm asked to leave untouched adds application work a 90 day deadline cannot absorb. Running a pair of Windows file servers on Amazon EC2 with DFS Replication is technically workable, which is exactly why it is offered, and it is the option that fails the effort test. The firm would keep patching Windows, sizing volumes, monitoring replication health and testing failover, which is the work it said it wants to stop doing, and it needs Windows storage skills it does not have. Key exam concept: storage choice follows the protocol and the permission model. SMB with Active Directory means FSx for Windows File Server, shared POSIX on Linux means Amazon EFS, and a workload with host name or license bindings is rehosted rather than rebuilt.

Question #12 Design for New Solutions

A health technology company is building a new claims processing service in a dedicated VPC. Amazon EC2 instances in private subnets read reference data from an Amazon S3 bucket and write audit records to an Amazon DynamoDB table, and every private subnet currently sends outbound traffic through NAT gateways. The security team wrote the bucket policy below after reading the public addresses off those NAT gateways. A NAT gateway was replaced during maintenance last week, its address changed, and the service lost access to the bucket for two hours. The design must guarantee that only requests originating inside this VPC reach the bucket and the table, must survive the replacement of any component, and must not depend on a list of addresses. Which solution will meet these requirements?

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnlessFromSiteAddresses",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::claims-reference-data",
        "arn:aws:s3:::claims-reference-data/*"
      ],
      "Condition": {
        "NotIpAddress": { "aws:SourceIp": [ "198.51.100.14/32", "198.51.100.15/32" ] }
      }
    }
  ]
}

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: create gateway endpoints for Amazon S3 and Amazon DynamoDB, route the private subnets to them, and condition the bucket policy on the endpoint identifier with aws:SourceVpce. The endpoint identifier is a stable property of the VPC, so the control no longer depends on an address that maintenance can change. The current policy identifies callers by where their packets appear to come from on the internet. Because the instances reach Amazon S3 through NAT gateways, the request arrives at the public service endpoint carrying the gateway's public address, and any event that replaces the gateway rewrites the identity the policy is matching. That is the fragility the incident exposed, and no amount of careful address management removes it. A gateway endpoint changes the path rather than the permissions. It is created in the VPC for Amazon S3 or Amazon DynamoDB and associated with route tables, and AWS adds a route whose destination is the service prefix list and whose target is the endpoint. Instances in subnets using those route tables then reach the service privately, and the request that arrives at Amazon S3 now carries VPC context. Two condition keys become available with that context. The key aws:SourceVpce matches a specific endpoint identifier, which is the tightest form and the one this requirement asks for, while aws:SourceVpc matches the VPC and is the right choice when several endpoints in the same VPC should all be accepted. Both identifiers survive instance replacement, gateway replacement and address changes. One documented consequence deserves a place in every architect's notes. Once traffic traverses a VPC endpoint, an aws:SourceIp condition in a bucket policy or identity policy no longer works for Amazon S3 requests, and aws:VpcSourceIp is the key that matches the private address instead. Remember also that a deny statement of this shape blocks console access to the bucket, because console requests do not originate from the endpoint. Changing the key to aws:SourceVpc while leaving traffic on the NAT path looks like the right family of condition key and fails on mechanics. The VPC context keys are only present on requests that arrive through a VPC endpoint, so with traffic still leaving through NAT the key is absent, the deny statement matches everything, and the service loses access entirely. Turning on S3 Block Public Access and dropping the condition answers a different question. Those account and bucket settings prevent access control lists and bucket policies from granting public access, and they have no effect on an authenticated request made with valid credentials from outside the VPC, which is precisely the traffic the requirement is about. Conditioning on the organization identifier builds an identity perimeter where the requirement asks for a network perimeter. Every principal in the organization would pass the test from any network, including a laptop, so the bucket would no longer be restricted to this VPC. Key exam concept: address based conditions break whenever infrastructure is replaced. Gateway endpoints supply VPC context, and the exam keeps testing whether a candidate reaches for aws:SourceVpce for one endpoint, aws:SourceVpc for a whole VPC, and neither of them when the traffic never passes through an endpoint.

Question #13 Design Solutions for Organizational Complexity

A pharmaceutical group runs 30 AWS accounts in one organization. A shared services VPC in the network account holds interface endpoints for Amazon ECR, AWS Systems Manager and AWS Secrets Manager, and it hosts the private hosted zones for the group's internal domain. Workload VPCs in the other accounts attach to a Transit Gateway that also carries a transit virtual interface to two data centers over AWS Direct Connect. Two resolution problems remain after the network build. Servers in the data centers cannot resolve the private names of the interface endpoints or any record in the internal private hosted zones, so integration jobs fall back to public service endpoints. Instances in the workload VPCs cannot resolve the legacy corp.example.com names that the data center DNS servers own, and each account works around that today with a hosts file that the configuration management run keeps overwriting. Which combination of steps should the solutions architect take to resolve both problems? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: create a Route 53 Resolver inbound endpoint in the shared services VPC and point the data center conditional forwarders at it, and create an outbound endpoint with a forwarding rule for the legacy domain that is shared through AWS RAM and associated with the workload VPCs. Hybrid DNS is directional, so two problems in two directions need two endpoints. The Route 53 Resolver is the DNS server that every VPC already uses at the base of its address range plus two. It answers for records in private hosted zones associated with that VPC, for the private names of interface endpoints in that VPC, and for public records. What it does not do is accept queries from outside the VPC, which is exactly why data center servers cannot resolve anything private today and fall back to public endpoints. An inbound endpoint fixes that direction. It places elastic network interfaces with private addresses in chosen subnets of the shared services VPC, and those addresses become a DNS target the data center resolvers can reach over Direct Connect. Conditional forwarders on the on-premises servers send the group's internal domain and the AWS service domains to those addresses, and the Resolver answers from the private hosted zones and the interface endpoint records. Note that the private hosted zones must be associated with the VPC that holds the inbound endpoint for its records to be returned. An outbound endpoint fixes the other direction. It gives the Resolver a source of private addresses from which to send queries into the data centers, and forwarding rules name the domains to forward and the target DNS server addresses. The scale problem is that a rule is a resource in one account. Rather than rebuilding endpoints and rules in all 30 accounts, the network account shares the rules with the organization through AWS RAM, and each participant account associates the shared rule with its own VPCs. One set of endpoints then serves the estate and the hosts files can go. The documentation now titles this component the Route 53 VPC Resolver, while the SAP-C02 exam guide prints Amazon Route 53 Resolver, so expect the older wording on the exam. Associating the private hosted zones with the data center DNS servers describes an operation that does not exist. A private hosted zone is associated with VPCs, including VPCs in other accounts through an authorization and association pair, and there is no mechanism for attaching one to a server outside AWS. Enabling Route 53 Resolver DNS Firewall with a rule group that allows the legacy domain confuses filtering with resolution. DNS Firewall inspects outbound queries from a VPC and allows, blocks or overrides them by domain, and an allow rule on a name that the Resolver cannot resolve still returns nothing useful. Creating duplicate interface endpoints in every workload VPC and turning off private DNS in the shared services VPC multiplies endpoint charges across 30 accounts, leaves the internal private hosted zone records unresolvable, and does nothing for the data center direction, which is the problem that pushed integration jobs onto public endpoints. Key exam concept: inbound Resolver endpoints carry queries from a network into AWS, outbound endpoints and forwarding rules carry queries from AWS into a network, and AWS RAM is how one set of rules reaches every account instead of one set per account.

Question #14 Accelerate Workload Migration and Modernization

During a portfolio assessment, a team plans to move a self managed MySQL database off physical servers onto Amazon RDS for MySQL. The application's SQL and business logic stay exactly as they are, and only the connection string changes. The operating system build, the storage layout, and the backup scripts on the old servers are all retired. Which of the seven common migration strategies does this plan describe?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: replatform, which moves a workload to AWS while exchanging one underlying component for a managed equivalent. The application is untouched, the platform underneath it is upgraded, and that combination is the definition of a replatform. AWS describes seven strategies for moving a workload, and the exam expects a candidate to place a scenario in the right one from a sentence or two of description. Rehost moves a server as it is, usually with a replication tool onto Amazon EC2, with no change to the operating system, the application or the database engine. Replatform keeps the application unchanged but swaps a component for a managed equivalent, most often a self managed database for Amazon RDS or a self managed web tier for AWS Elastic Beanstalk. Repurchase abandons the running software in favor of a commercial or software as a service product. Refactor, sometimes called re-architect, rewrites the workload around cloud native services. Retire switches off something that is no longer needed, which portfolio assessments routinely find. Retain leaves a workload where it is for now, usually because of a dependency or a contract. Relocate moves a hosting environment as a whole without changing the servers inside it. Apply those definitions here. Nothing in the application changes, so refactor is out. The servers themselves are not carried over, since the operating system build, the storage layout and the backup scripts are retired, so rehost and relocate are out. What survives is the application and its SQL, running against the same engine on a managed platform, which is replatform. The tell in the wording is the phrase that the team stops owning something operational, in this case patching, backups and failover, while the code stays still. Two boundaries cause most of the errors on this topic. The rehost to replatform boundary turns on whether any platform component is exchanged, not on how much effort the move takes. The replatform to refactor boundary turns on whether the application itself is rewritten, so swapping in a managed database is a replatform while decomposing the application into functions and a purpose built data store is a refactor. Rehost, the strategy that carries a workload across unchanged would describe the same database lifted onto Amazon EC2 with the same operating system and the engine still self managed, which is what replication tooling produces when nothing about the platform is meant to change. Here the engine moves to a managed service, so an operational layer has been exchanged and the move goes one rung further. Refactor, the strategy that redesigns a workload around cloud native services requires the application itself to be rewritten, for example replacing the relational access layer with a purpose built data store or moving logic into functions. The stem states that the SQL and the business logic are unchanged, which is the opposite of that. Relocate, the strategy that moves a hosting environment as a whole covers transferring virtualized servers into AWS without converting them, or moving accounts between environments. It leaves everything running inside that environment intact by definition, and here the operating system build, the storage layout and the backup scripts are all retired. Key exam concept: the 7Rs are decided by what changes. No change to server or application is rehost, a managed platform underneath an unchanged application is replatform, and a rewritten application is refactor.

Question #15 Design Solutions for Organizational Complexity

A utility company runs a legacy enterprise resource planning suite on 60 servers. Forty are virtual machines in a company data center and twenty are Amazon EC2 instances in one AWS Region, and all of them run operating systems that the company's agent tooling supports. A regulator now requires a documented plan for the loss of the primary site, with a recovery time objective of 30 minutes and a recovery point objective of 5 minutes, exercised twice a year without disturbing production. The suite cannot run active in two places at once, because of both its license terms and its clustered file locks. The finance director has rejected any proposal that funds a second copy of the fleet running around the clock. The operations team is four people, will not maintain replication scripts, and has no budget line for a contractor to run the plan on its behalf. Which strategy will meet these requirements MOST cost-effectively?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: replicate all 60 servers continuously with AWS Elastic Disaster Recovery into a low cost staging area in the recovery Region, and launch recovery instances from the latest point in time for drills and for a real event. It is the only rung of the ladder that reaches these objectives without paying for a second running fleet. Work the ladder against the two numbers. Backup and restore is measured in hours because data is captured periodically and infrastructure has to be redeployed, so it cannot reach a 5 minute recovery point or a 30 minute recovery time for 60 servers. Pilot light replicates data continuously while compute stays switched off, warm standby keeps a scaled down but running copy that can take traffic immediately, and multi site active/active runs everything everywhere. Cost rises with every rung, and the finance constraint sets a ceiling on how far up the company may go. Elastic Disaster Recovery sits at the pilot light rung and is the modern answer whenever a stem describes server level recovery of mixed on-premises and EC2 estates. An agent replicates each source server block by block into a staging area subnet in the recovery Region that AWS designs around inexpensive storage and minimal compute, so there is no second fleet to fund. Replication is continuous rather than scheduled, which is what puts the recovery point in the seconds range and comfortably inside 5 minutes. On a drill or a declared disaster, the service converts the replicated volumes and launches instances that boot natively on AWS within minutes, either from the most recent state or from an earlier point in time. Drills launch into a test subnet without interrupting replication or production, which satisfies the twice yearly exercise, and failback is built in once the primary site returns. A warm standby running all 60 servers at reduced sizes would meet the recovery objectives, which is exactly why it is offered, and it fails the constraint the finance director set. Every one of those 60 instances runs and bills around the clock, and warm standby is the rung above pilot light precisely because it trades money for a shorter recovery time the regulator did not ask for. Hourly AWS Backup with cross-Region and cross-account copies is a strong ransomware and retention control and the wrong instrument here. An hourly schedule can never deliver a 5 minute recovery point, and restoring and rebuilding 60 servers from recovery points takes far longer than the 30 minutes allowed. Running the suite active in two Regions behind a global entry point is barred by the application itself, since the license terms and the clustered file locks forbid two live instances, and it is the most expensive rung on the ladder for objectives that a far cheaper option already meets. Key exam concept: read the recovery point figure to choose the replication mechanism and the recovery time figure to choose how much runs in advance, then let the budget sentence break any remaining tie. Continuous block level replication with compute switched off is the cheapest rung that still delivers minutes.

Question #16 Continuous Improvement for Existing Solutions

A platform team is asked why Amazon CloudWatch has become the largest line in a shared observability account while application traffic has been flat for a year. The billing breakdown shows that ingested data, not stored data, drives almost all of the charge. The team pulled the three busiest log groups. Engineers must be able to capture debug detail for the checkout service for the duration of an open incident, and any debug data that is captured must remain available for three days afterward. Application code may not be rewritten in this quarter, although configuration flags can be changed at any time. Which change will MOST reduce the CloudWatch charges?

Log group                    Ingested last month   Retention      Read pattern
/app/checkout/debug          41 TB                 never expire   during open incidents only
/app/checkout/access          6 TB                 never expire   weekly reporting
/aws/lambda/pricing-sync       0.4 TB              30 days        rarely opened

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: stop emitting debug events to CloudWatch Logs by default, raising the log level through a configuration flag only while an incident is open, and set a three day retention period on that log group. The charge follows what is ingested, so the only large saving comes from not sending 41 TB in the first place. CloudWatch Logs bills on separate dimensions. There is a charge for data ingested into a log group, a charge for data stored there over time, and charges for queries and other features on top. The billing breakdown quoted in the stem says plainly that ingestion is where the money goes, and that single sentence decides the item. Any answer that changes how long data is kept, or where it is copied afterwards, is working on a smaller dimension than the one that is actually growing. Look at the proportions as well. One log group accounts for roughly 41 of the 47 TB ingested, and its content is only ever opened while an incident is running. That is the classic shape of a debug level logger left switched on in production after a launch. Because the team can change configuration flags, the cheapest correct fix is to move the default level back to a normal production level and raise it deliberately when an incident is open, which keeps the investigative capability the engineers asked for while removing the steady state volume. The three day retention on that group is the second and much smaller saving, and it is what keeps the debug detail captured during an incident available for the three days the requirement asks for. The general lesson is worth carrying into the exam room. When a monitoring bill grows without a matching growth in traffic, the cause is nearly always verbosity, cardinality or retention left at a default, and the order of impact is almost always volume first and retention second. Setting a three day retention period and changing nothing else is the half answer the item is built around, and it is tempting because it does satisfy every requirement the stem states. Retention governs stored data, so the application carries on emitting all 41 TB and the ingestion charge that the billing breakdown identifies as the problem is untouched. Turning the default log level down applies the same three day retention alongside it and removes the emission as well, which is why it moves the bill by far more on the dimension that is actually growing. Creating a metric filter on the debug log group misunderstands where a metric filter sits. It evaluates events after they have already been ingested and turns matches into a metric, so it adds a custom metric charge on top of the ingestion the team is trying to avoid. Streaming the debug group to Amazon S3 and querying it with Amazon Athena is a reasonable archive design that solves a different problem, because events still enter CloudWatch Logs and are still billed for ingestion before anything is exported. It adds a delivery pipeline to operate and a second copy of 41 TB a month to store. Key exam concept: separate ingestion from storage before proposing a logging saving. Retention periods, archive exports and storage classes all act on data that has already been paid for once, so the large saving lives in what the application chooses to emit.

Question #17 Design for New Solutions

A visual effects studio is designing a render pipeline on AWS for a show that starts next month. Every night between 20:00 and 02:00 the pipeline renders roughly 9,000 frames on a fleet of compute optimized instances, and the renders must finish before the compositing shift begins at 08:00. A frame takes four to nine minutes, the renderer already writes a checkpoint every 30 seconds and resumes from it, and a frame that fails is simply rendered again. Finished frames land in Amazon S3, where the compositing team reads each frame at least once during the first 30 days and then almost never touches it again, although the studio's contracts require the frames to be kept for seven years. The studio has no other steady AWS usage to commit against, and the show may be cancelled after three months. Which combination of choices will meet these requirements MOST cost-effectively? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: run the render fleet on Spot capacity through an EC2 Fleet with the price capacity optimized allocation strategy, and add an S3 Lifecycle rule that moves finished frames to S3 Standard-IA after 30 days and to S3 Glacier Deep Archive after 90 days. One choice matches the compute purchase to an interruptible workload, the other matches the storage class to an access pattern the studio already knows. Start with the shape of the compute. The work is interruptible by construction, because the renderer checkpoints every 30 seconds and a failed frame is simply re-rendered, and it runs for six hours a night with a deadline two hours later that leaves slack for retries. That is the textbook Spot profile. An EC2 Fleet can draw from many instance types and Availability Zones, and the allocation strategy decides which pools it draws from. AWS recommends price capacity optimized, which chooses pools that combine low price with high capacity availability and therefore the lowest chance of interruption in the near term, and AWS explicitly notes that checkpointing is what makes that strategy a good fit for work with a higher cost of interruption. The lowest price strategy is documented as not recommended because it ignores capacity and carries the highest interruption rate. Now the storage. The access pattern is known rather than uncertain, which is the whole decision. Frames are read in the first 30 days and then effectively never, and they must be kept for seven years. A lifecycle rule expresses that directly. Objects become eligible to move to S3 Standard-IA once they are 30 days old, and moving them to S3 Glacier Deep Archive at 90 days puts the long tail of the seven year obligation on the cheapest class AWS offers. Because the frames are large render outputs rather than tiny files, the per object transition and retrieval characteristics work in the studio's favor. A three year EC2 Instance Savings Plan sized for the nightly peak commits money by the hour for three years against a fleet that runs six hours a night on a show that may be cancelled in three. Most of the commitment would go unused, and the stem says there is no other steady usage for the discount to land on. On-Demand Dedicated Hosts to avoid interruptions buys the most expensive compute in the list to solve a problem the renderer already solves with checkpoints. Dedicated Hosts exist for licensing that is bound to sockets or cores and for physical isolation, neither of which this workload needs. S3 Intelligent-Tiering on the frame prefix is the right answer when nobody can predict the access pattern, and here it is fully predicted. It adds a per object monitoring and automation charge to discover a behavior the studio already described, so a lifecycle rule reaches the same classes for less. Key exam concept: purchase options follow workload shape, so interruptible and flexible work goes on Spot while steady baseline usage justifies a commitment. Storage classes follow the certainty of the access pattern, so a known pattern goes on lifecycle rules and an unknown pattern goes on Intelligent-Tiering.

Question #18 Continuous Improvement for Existing Solutions

An operations team supports 40 AWS accounts across four Regions for a media group. When AWS schedules an EC2 instance retirement, the affected account's contact receives a notice, someone forwards it to the operations mailbox, and an engineer stops and starts the instance by hand in the next change window. Two instances were missed last quarter and were retired while still running. Every instance in the estate is already managed by AWS Systems Manager, and the team already deploys and updates baseline resources into every account and Region from a single organization wide pipeline. The team wants the stop and start to happen automatically wherever the event occurs. A sample of the event that AWS publishes is shown below. Which solution will meet these requirements with the LEAST operational overhead?

{
  "source": [ "aws.health" ],
  "detail-type": [ "AWS Health Event" ],
  "detail": {
    "service": [ "EC2" ],
    "eventTypeCategory": [ "scheduledChange" ],
    "eventTypeCode": [ "AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED" ]
  }
}

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: use a CloudFormation StackSet to deploy an Amazon EventBridge rule carrying this pattern into every account and Region, with a Systems Manager Automation runbook as the target that stops and starts the affected instance. The remediation has to run in the account that owns the instance, so the rule and the role it uses belong there too. AWS Health publishes an account specific event to the default EventBridge bus of the account the event concerns. The detail carries the service, the category and an event type code, and for a retirement scheduled on an EBS backed instance that code is the one in the artifact. An EventBridge rule filtering on those fields fires the moment AWS schedules the retirement rather than when a human reads a message, which is what closes the gap that let two instances be missed. The target completes the automation. Systems Manager publishes a runbook that restarts an EC2 instance, and because a stop and start moves an instance to new underlying hardware it is the standard remediation for a scheduled retirement. The rule passes the affected instance from the event's resources field into the runbook through an input transformer, and the rule needs a role that Systems Manager and EventBridge can assume with permission to stop and start instances. AWS notes that the instances must already be managed by Systems Manager, which this estate satisfies. The multi account question is where candidates lose the mark, and delivery is not what settles it. An EventBridge rule receives only its own account's events by default, but AWS Health closes that gap on its own terms. Once organizational view is turned on, the management account or a delegated administrator account receives a single feed of AWS Health events from every account in the organization, and AWS records that turning it on leaves the member accounts' own rules running. Centralized delivery is therefore available. What settles the item is execution locality. A Systems Manager Automation target on a rule in the management account starts the automation in the management account, and acting on an instance that lives in a member account means running that automation with target locations and an AWS-SystemsManager-AutomationExecutionRole already present in the account being targeted. AWS documents creating that role in every account you want to target and recommends CloudFormation StackSets for exactly that job, alongside an administration role in the central account. A central design therefore still puts something in all 40 accounts and adds an administration role and a transformer that has to derive the affected account from the event, so it buys nothing over deploying the small rule and its role where the instances already are. Deploying the same pair everywhere is not a workaround, it is the design, and the organization wide deployment path the team already operates makes the incremental effort close to zero. A StackSet with service managed permissions is how that reach is normally implemented, because it targets organizational units rather than a list of accounts and picks up accounts added later without another deployment. One rule in the management account fed by organizational view is the trap this item is built on, and it fails one step later than most candidates expect. With organizational view turned on the events really do reach the management account bus, so the rule matches and fires. The runbook it targets then runs in the management account, where nothing gives it authority over an instance in a member account. Granting that reach means adding target locations and placing the Systems Manager automation execution role in all 40 accounts first, which is the footprint this option was chosen to avoid and the operational overhead the question asks to minimize. A CloudWatch alarm on the system status check with an instance recovery action reacts to an instance that has already become impaired. A scheduled retirement is an advance notice, the status check stays healthy until the retirement happens, and recovery is designed for underlying hardware failure rather than for planned maintenance. A scheduled Lambda function that assumes a role in each account and polls for instance status rebuilds a notification system that AWS already provides. It adds a function, a schedule, a cross-account role in 40 accounts and a polling delay, which is the operational overhead the question asks to minimize. Key exam concept: AWS Health can feed one organization wide stream to a management or delegated administrator account, so the multi account question is rarely where the event arrives. It is where the remediation holds permission to act, and Systems Manager Automation acts in the target account, which is why the rule and its execution role get deployed everywhere. The chain itself does not change: an EventBridge rule on the Health event, then a Systems Manager Automation runbook as the target.

Question #19 Design for New Solutions

A genomics company is designing a variant calling pipeline. Several hundred compute instances will read a 40 TB reference dataset that already lives in Amazon S3 and will write results back to the same bucket. The pipeline is a POSIX application that memory maps its input files, so it needs a shared file system rather than object calls, and it stalls whenever aggregate read throughput falls below several gigabytes per second. Clusters run for a few hours and are then torn down. Results must appear in the bucket as soon as a run finishes. The company employs two infrastructure engineers and no storage specialists. Which solution will meet these requirements with the least operational overhead?

Pick an answer to reveal the explanation.

Why this is correct

Correct answer: provision an Amazon FSx for Lustre file system linked to the S3 bucket as a data repository, so the cluster reads through the file system and exports results back to the bucket. It is the only option that gives a POSIX file system at parallel file system throughput while keeping Amazon S3 as the durable home of the data. Three requirements narrow this quickly. The application memory maps files, so it needs a real file system rather than an object API or a translation layer. Aggregate read throughput must reach several gigabytes per second across hundreds of clients, which is parallel file system territory. Clusters are ephemeral, so the storage has to be created and destroyed alongside them without a long staging step. FSx for Lustre is built for exactly that combination. Lustre stripes files across storage servers so throughput scales with the size of the file system and many clients can read in parallel, which is why it is the standard choice for high performance computing, machine learning and media processing. The feature that matters most here is the data repository association with Amazon S3. The file system presents the objects in the linked bucket or prefix as files, loads their contents as they are first read rather than requiring a 40 TB copy up front, and can export new and changed files back to the bucket. A short lived cluster can therefore create the file system, link it to the reference bucket, run, export results and delete the file system, with the bucket remaining the durable source of truth. The service is managed, so the two engineers never size metadata servers, tune a parallel file system or patch storage nodes, which is what the operational overhead constraint is asking about. Amazon EFS with Elastic throughput and a copy of the dataset per run is a genuine shared POSIX file system, which makes it the closest wrong answer. It is a general purpose NFS service rather than a parallel file system, so it is not aimed at the aggregate throughput this pipeline needs, and copying 40 TB into it before every short run adds hours and cost that the linked repository model removes entirely. An Amazon EBS io2 Block Express volume attached with Multi-Attach is block storage, not a file system. Multi-Attach supports only a small number of instances in one Availability Zone and requires a cluster aware file system on top, so it cannot serve hundreds of clients and would corrupt data under an ordinary file system. A self managed parallel file system on an Amazon EC2 cluster would meet the throughput requirement, which is precisely why it is tempting, and it hands a specialist administration job to a team that has said it has no storage specialists. Every run would also need the reference dataset staged onto it first. Key exam concept: match the file system to the access pattern. Shared POSIX on Linux at general purpose scale is Amazon EFS, high performance computing throughput with an Amazon S3 backing store is FSx for Lustre, and block storage is never a substitute for a shared file system.

Question #20 Accelerate Workload Migration and Modernization

A wholesaler runs a monolithic order management application on Amazon EC2 behind an Application Load Balancer. Invoice generation inside the monolith takes up to 40 seconds for large orders and holds a request thread for the whole time, which pushes the checkout path past its latency budget every month end. A small team will extract invoice generation into its own service first and modernize the rest of the application later. The client applications belong to trading partners and cannot be asked to change the URLs they call during this phase. The monolith and the new service will run in the same VPC. Which combination of steps should the solutions architect take to meet these requirements with the least change to the existing application? (Select TWO.)

Pick two answers to reveal the explanation.

Why this is correct

Correct answers: add a path based rule on the existing load balancer listener that sends the invoice path to a new target group, and have the invoice request go onto an Amazon SQS queue so the caller gets an identifier immediately while the new service does the work. One step moves the traffic without moving the address, the other removes the long running work from the request thread. This is the strangler fig pattern, and the exam tests whether a candidate can apply it without disturbing the parts that still work. The constraint that partners cannot change the URLs they call is the hinge. An Application Load Balancer evaluates listener rules in priority order and can route by path, host header, HTTP method, query string and headers, so a single rule for the invoice path can be added to the listener that already serves the application. Everything else continues to fall through to the default rule and the monolith's target group. Partners keep calling the same host name and the same paths, the new service receives only its own traffic, and the change is reversible by deleting one rule. The second step attacks the actual symptom. A 40 second synchronous operation holds a connection and a thread, so it consumes checkout capacity even after the code has been extracted. Writing the request to an Amazon SQS queue and returning an identifier turns the call into an asynchronous request and reply exchange. The queue absorbs the month end surge, the new service consumes at whatever rate it can sustain, failures retry without the partner noticing, and the invoice service can scale on queue depth independently of the checkout path. The partner polls a status resource or collects the finished invoice later, which is a contract change at the invoice endpoint only. Taken together the two steps give an incremental path. Traffic for one capability is peeled off at the load balancer, that capability is decoupled behind a queue, and the monolith keeps serving everything else until the next capability is ready. Rewriting the order workflow as an AWS Step Functions state machine is a re-architecture of the whole flow when the team has asked to extract one capability. It is a large change to the existing application, which the question explicitly limits, and it does not address how partner traffic reaches the new component. Placing Amazon API Gateway in front of the monolith and issuing a new stage URL breaks the one constraint the stem repeats. Partners would have to change the address they call, and API Gateway in this position also adds a new front door to operate for a benefit the existing load balancer already provides. Repackaging the monolith as a container on AWS Fargate changes where the code runs without changing how it runs. Invoice generation would still execute inside the same process on the same request thread, so the checkout latency at month end would be exactly what it is today. Key exam concept: a strangler fig migration routes selected paths to new services at the existing entry point so clients never learn that anything moved, and a long running synchronous operation is decoupled with a queue and a status resource rather than by moving the same blocking code to a new platform.

AWS Certified Solutions Architect - Professional 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 SAP-C02 exam