Free SAP-C02 practice questions

A financial services company defines its production environment with a single large AWS CloudFormation stack that includes an Amazon RDS database, security groups, and an Auto Scaling group. A release engineer must apply a template change that updates the database instance class and an IAM role, but a previous release caused an unexpected replacement of the database and a long outage. Leadership now requires that before any production update is executed, the team must see exactly which resources will be modified, replaced, or deleted, and obtain a sign-off, without applying anything. Which approach BEST gives the team that pre-execution visibility?

• ACreate a CloudFormation change set from the revised template, review the action and replacement column for each resource to confirm whether the database is modified or replaced, gain sign-off, and only then execute the change set.check_circle Correct
• BRun the stack update directly with rollback triggers configured on CloudWatch alarms, so that if the database is replaced and the alarm fires the stack automatically rolls back to the prior state before users are affected.
• CEnable termination protection on the stack and turn on drift detection before the release, then run the update and rely on the drift report to highlight any resource that the change unexpectedly replaced or deleted during deployment.
• DValidate the template with the CloudFormation linter and the validate-template action in the pipeline, capture the output for the approvers, and proceed with the update once the template is confirmed to be syntactically valid.

Why A is correct: A change set computes the difference between the running stack and the proposed template and lists every resource with its action and whether a replacement is required, so the team can confirm the database will not be replaced and obtain sign-off before executing anything.

Why B is wrong: Rollback triggers act only after the update has already started executing and a resource may have been replaced, so the change is applied first rather than previewed, which fails the requirement to see the impact before anything runs.

Why C is wrong: Termination protection only blocks stack deletion and drift detection compares deployed resources to the template after the fact, so neither previews the pending update or shows planned replacements before execution.

Why D is wrong: Template validation checks only syntax and structure and never compares against the deployed stack, so it cannot reveal that the instance-class change would force a replacement of the live database.

A SaaS provider runs a customer-facing API on Amazon ECS using AWS Fargate behind an Application Load Balancer. Deployments currently shift all tasks to the new version at once, and a recent bad release returned elevated 5xx errors to every customer before anyone noticed. The platform team wants new releases to be exposed to a small slice of live traffic first, monitored against a CloudWatch error-rate alarm, and reverted automatically to the previous task set if the alarm breaches, all without writing custom orchestration scripts. Which deployment approach BEST meets this requirement?

• AKeep the rolling ECS deployment but reduce the minimum healthy percent and raise the maximum percent so tasks cycle more slowly, and have on-call engineers watch the dashboard to stop the rollout manually if the error rate climbs.
• BUse AWS CodeDeploy with the ECS blue/green deployment type, a canary traffic-shifting configuration on the load balancer, and a CloudWatch alarm wired as a rollback trigger so the listener returns to the original task set automatically on breach.check_circle Correct
• CPublish a new task definition revision and update the service in place, then create a CloudWatch alarm that invokes a Lambda function to register the previous task definition again whenever the API error rate exceeds the threshold for the service.
• DDeploy the new version to a second ECS service behind a weighted Amazon Route 53 record, start it at a low weight, and manually raise the weight while an engineer compares error metrics between the two services during the rollout window.

Why A is wrong: Tuning the rolling deployment percentages only changes how fast tasks replace each other and still sends production traffic to every new task, while relying on a human to stop it is exactly the manual, slow reaction the team wants to remove.

Why B is correct: CodeDeploy blue/green for ECS stands up the new task set alongside the old one and shifts a canary percentage of listener traffic first, and an associated CloudWatch alarm acts as an automatic rollback trigger that reverts the listener to the original task set if the error rate breaches.

Why C is wrong: An in-place service update exposes all traffic to the new version immediately with no canary slice, and the custom alarm-to-Lambda rollback is precisely the bespoke orchestration the team asked to avoid building and maintaining.

Why D is wrong: Route 53 weighted records shift traffic at DNS resolution and are subject to client caching, so the slice is imprecise and slow to revert, and the rollout still depends on an engineer manually adjusting weights rather than an automatic trigger.

A retailer manages 120 AWS accounts in AWS Organizations grouped into organisational units. The security team must deploy an identical baseline of guardrail resources, an IAM role, an AWS Config rule, and a logging bucket policy, into every existing account and into any account added later, from a single point of control, while keeping the templates version-controlled and the rollout repeatable. They want to avoid logging into each account or running per-account pipelines. Which approach deploys and maintains this baseline MOST efficiently across the organisation?

• AStore the template in a central account and run a CodePipeline that assumes a cross-account role into each member account in turn to create the stack, adding a new pipeline stage by hand whenever an account joins the organisation.
• BPlace the template in an Amazon S3 bucket and ask each account owner to launch it from the CloudFormation console using a shared launch link, then track completion in a spreadsheet to confirm the baseline exists everywhere.
• CDeploy a CloudFormation StackSet with service-managed permissions targeting the organisational units, and enable automatic deployment so the stack instances are created in current accounts and rolled out to any account that joins later.check_circle Correct
• DUse AWS Config aggregator with an organisation conformance pack to detect accounts missing the baseline, then notify the relevant teams to create the IAM role, Config rule, and bucket policy manually in any account flagged as non-compliant.

Why A is wrong: A pipeline assuming a role into each account can work but requires a stage and role per account and manual edits as accounts are added, which does not scale to 120 accounts or automatically cover newly created accounts.

Why B is wrong: Self-service launches depend on every account owner acting and offer no central update path or guaranteed coverage, so the baseline drifts and new accounts are missed, defeating the goal of a single point of control.

Why C is correct: A service-managed StackSet targets organisational units and, with automatic deployment enabled, creates stack instances in all current member accounts and automatically deploys to accounts added to those OUs later, giving one version-controlled, repeatable rollout with no per-account access.

Why D is wrong: An aggregator with a conformance pack is detective and reports non-compliance but does not provision the IAM role or bucket policy, so remediation falls back to manual per-account work rather than a repeatable central deployment.

A multinational runs around 200 VPCs spread across 40 AWS accounts under a single organisation, and the count grows monthly as new product teams onboard. Every VPC must reach a shared services VPC for DNS and patching, and many must also reach each other, with full transitive routing and central control of which routes propagate where. The networking team wants to avoid managing an ever-expanding mesh of point-to-point links. Which design MOST scalably meets these requirements?

• ADeploy an AWS Transit Gateway shared through AWS Resource Access Manager, attach every VPC to it, and use Transit Gateway route tables to control which attachments can route to the shared services VPC and to each other.check_circle Correct
• BCreate a full mesh of VPC peering connections between every pair of VPCs and add the shared services VPC as another peer, relying on the peering links for any VPC to reach any other VPC directly.
• CExpose the shared services through AWS PrivateLink endpoint services and create interface endpoints in every VPC, then add PrivateLink endpoints between product VPCs wherever two teams need to reach each other.
• DDesignate one central VPC as a transit hub, run software routers on EC2 instances inside it, and peer every other VPC to that hub so traffic is forwarded between VPCs through the EC2 routing layer.

Why A is correct: A Transit Gateway is a hub that provides transitive routing for all attached VPCs and accounts, scales to thousands of attachments, and its route tables centrally govern which VPCs reach the shared services VPC or each other.

Why B is wrong: A peering mesh seems to give any-to-any reachability, but peering is non-transitive and the number of links grows roughly with the square of the VPC count, which becomes unmanageable well before 200 VPCs.

Why C is wrong: PrivateLink cleanly publishes the shared services, but it exposes single services rather than whole VPCs, so building any-to-any product connectivity from endpoints does not provide the general transitive routing the estate needs.

Why D is wrong: EC2 software routers can forward traffic to work around non-transitive peering, but they add instances to patch, scale and make highly available, duplicating a managed capability Transit Gateway already provides.

A software vendor hosts a payments API behind a Network Load Balancer in its own VPC and account. Dozens of customer accounts, each with their own VPC and some using overlapping private CIDR ranges, must call only this single API over private networking, never reach anything else in the vendor VPC, and onboard without the vendor coordinating IP addressing with them. The vendor also wants no transitive path back into customer networks. Which approach BEST satisfies these constraints?

• AAttach the vendor VPC and every customer VPC to a shared AWS Transit Gateway and use route tables so that customer attachments can route only to the subnet hosting the payments API in the vendor VPC.
• BExpose the payments API as an AWS PrivateLink endpoint service fronted by the Network Load Balancer and let each customer create an interface endpoint to it, so they reach only that service over private connectivity.check_circle Correct
• CCreate VPC peering connections from the vendor VPC to each customer VPC and add specific routes and security group rules so that only the payments API instances are reachable from each peered customer network.
• DPublish the payments API as a Gateway VPC endpoint and have each customer create a gateway endpoint with a route table entry so traffic to the service stays on the AWS private network.

Why A is wrong: A Transit Gateway can scope routes per attachment, but it relies on IP routing, so overlapping customer CIDR ranges break it and it exposes a routed path into the vendor VPC rather than a single service.

Why B is correct: PrivateLink publishes the single API as an endpoint service, and each customer interface endpoint reaches only that service with no IP routing between VPCs, so overlapping CIDR ranges are irrelevant and nothing else is exposed.

Why C is wrong: Peering can restrict reachable hosts with routes and security groups, yet peering cannot be established between VPCs with overlapping CIDR ranges and still exposes IP-level reachability into the vendor VPC.

Why D is wrong: Gateway VPC endpoints exist only for Amazon S3 and DynamoDB, so they cannot expose a customer-built payments API and are not a mechanism for sharing a private service across accounts.

Two teams in the same account each own a VPC in eu-west-1 with non-overlapping CIDR ranges. A reporting service in one VPC must query a database in the other with high, sustained throughput and the lowest possible inter-VPC latency. There are only these two VPCs, no plan to add more, and no requirement for either VPC to route through to any third network. The architect must keep both data-transfer cost and operational overhead to a minimum. Which connectivity option is MOST appropriate?

• AProvision an AWS Transit Gateway in the Region, attach both VPCs to it, and configure its route tables so the reporting service reaches the database through the gateway as a central hub.
• BFront the database with a Network Load Balancer, publish it as an AWS PrivateLink endpoint service, and create an interface endpoint in the reporting VPC for the service to connect through.
• CEstablish a single VPC peering connection between the two VPCs and add routes on each side so the reporting service and the database communicate directly over the AWS backbone.check_circle Correct
• DCreate a Site-to-Site VPN between the two VPCs over the public internet using virtual private gateways so the reporting service tunnels through to the database securely.

Why A is wrong: A Transit Gateway would connect the two VPCs, but it adds an hourly attachment charge and a per-gigabyte data processing fee, so it is needless cost and overhead when only two VPCs need to talk and no transitivity is required.

Why B is wrong: PrivateLink suits exposing a single service across account boundaries, but here both VPCs are in one account and it adds endpoint and per-gigabyte charges plus a load balancer to manage for a simple two-VPC link.

Why C is correct: VPC peering gives a direct, full-bandwidth path over the AWS backbone with no per-gigabyte processing charge or appliance to run, which is the cheapest and lowest-overhead fit for connecting just two VPCs that need no transitive routing.

Why D is wrong: A Site-to-Site VPN is meant for hybrid or cross-network connectivity, caps throughput per tunnel, and adds encryption overhead and latency, which is the wrong tool for two VPCs already inside the same Region.

A payments company runs a fleet of Amazon EC2 instances behind an Application Load Balancer. About once a week a memory leak causes individual instances to stop responding to health checks, and an on-call engineer currently logs in to reboot the affected instance, which takes around twenty minutes overnight. The team wants the recovery to happen automatically the moment an instance becomes unhealthy, with no standing servers added and no custom code to patch. Which approach MOST efficiently remediates the recurring failure?

• APublish a custom memory metric from each instance and create an Amazon CloudWatch alarm that emails the on-call rota through Amazon SNS when the metric breaches the threshold so the engineer can respond sooner during the night.
• BCreate an Amazon CloudWatch alarm on the StatusCheckFailed metric for each instance and configure the EC2 instance-recovery alarm action to reboot the instance automatically as soon as the alarm enters the ALARM state.check_circle Correct
• CMove the workload into an Amazon EC2 Auto Scaling group with a target tracking policy on average CPU utilisation so that capacity scales out and replaces the failing instances during the weekly memory event.
• DSchedule an AWS Lambda function with Amazon EventBridge to run every fifteen minutes, list the fleet, and reboot any instance whose health check has been failing, writing the action to a log group for audit.

Why A is wrong: Faster paging still depends on a human logging in to reboot the instance, so it shortens but does not remove the manual recovery the team wants to eliminate, and it does not act automatically.

Why B is correct: A CloudWatch alarm with a built-in EC2 action triggers the recovery the instant the status check fails, so the unhealthy instance is rebooted automatically with no added servers and no custom code for the team to maintain.

Why C is wrong: Target tracking on CPU scales for load, not for an unhealthy host, so a leaking instance that still consumes CPU would not be replaced, and this changes the architecture rather than directly remediating the fault.

Why D is wrong: A polling Lambda adds custom code the team must patch and can leave an instance unhealthy for up to fifteen minutes between runs, so it is slower and higher overhead than a native alarm action.

A SaaS provider runs dozens of microservices on Amazon ECS across several accounts, and each service writes application logs to its own Amazon CloudWatch Logs log group. The operations team wants engineers to search and correlate logs from every service and account in one place, retain the data for two years, and run ad hoc queries during incidents, all with minimal infrastructure to operate. Which approach BEST centralises the logs for cross-service investigation?

• AInstall the unified CloudWatch agent on every task to ship logs straight to a self-managed OpenSearch cluster running in one central account, and have engineers use the cluster dashboards to search and correlate events across all of the services.
• BExport each log group to Amazon S3 on a daily schedule, build an AWS Glue crawler over the buckets, and have engineers query the partitions with Amazon Athena whenever they need to correlate events across the services.
• CStream every log group to a central account with CloudWatch Logs subscription filters through Amazon Kinesis into a destination log group, then query the consolidated data with CloudWatch Logs Insights and set retention to two years.check_circle Correct
• DEnable AWS CloudTrail Lake in the central account and direct the service logs into the event data store so that engineers can run SQL queries across two years of activity collected from every account.

Why A is wrong: A self-managed OpenSearch cluster gives strong search but adds nodes, scaling and patching that the team must operate, which conflicts with the requirement to keep operational infrastructure to a minimum.

Why B is wrong: Daily exports add hours of delay so logs are not available during a live incident, and the Glue plus Athena pipeline is more moving parts to operate than a near real time streaming approach to a central log store.

Why C is correct: Subscription filters forward log events in near real time to a central account, and CloudWatch Logs Insights provides ad hoc cross-service queries while a per-group retention setting keeps the data for two years with no servers to run.

Why D is wrong: CloudTrail Lake stores API and selected activity events, not arbitrary application log lines from the microservices, so it cannot hold or correlate the ECS application logs the team needs to investigate.

An online retailer has noticed that its checkout error rate climbs gradually over several hours before customers complain, by which time the team is already firefighting. The application emits a per-minute error-rate metric to Amazon CloudWatch, but the rate is naturally noisy and a fixed threshold either pages too early on harmless spikes or too late on a real degradation. The team wants alerting that adapts to normal daily and weekly patterns and notifies on-call before the error rate becomes severe. Which approach BEST delivers earlier, lower-noise alerting?

• ASet a static CloudWatch alarm threshold at the historical ninety-fifth percentile of the error rate and notify Amazon SNS, lowering the threshold by hand each time the team finds that an incident was missed.
• BConfigure a metric math expression that averages the error rate over a rolling sixty-minute window and alarms when that smoothed value exceeds a fixed level, paging on-call through Amazon SNS once it is breached.
• CForward the error-rate metric to a scheduled AWS Lambda function that compares the current value with the same minute one week earlier and publishes to Amazon SNS when the difference is large enough to matter.
• DCreate a CloudWatch alarm that uses anomaly detection on the checkout error-rate metric so the band learns the expected daily and weekly pattern, then notify Amazon SNS when the metric moves outside the band.check_circle Correct

Why A is wrong: A fixed percentile threshold does not adapt to time of day or week, so it keeps producing the early or late pages the team is trying to avoid, and manual retuning after each miss is reactive and ongoing toil.

Why B is wrong: Smoothing over a long window reduces noise but adds latency and still relies on a single fixed level, so it tends to alert later on a slow climb and does not adapt to the normal daily and weekly shape of the metric.

Why C is wrong: A bespoke week-over-week Lambda is custom code to build and maintain and compares against a single past point, so a one-off anomaly last week skews it, unlike a trained anomaly-detection band over the full history.

Why D is correct: CloudWatch anomaly detection builds a model of the metric's normal daily and weekly behaviour and alarms when values fall outside the learned band, so it catches a gradual drift earlier than a fixed line while ignoring routine spikes.

A manufacturer running an AWS Migration Hub portfolio assessment must label two workloads with one of the seven common migration strategies before wave planning begins. The first is a self-managed Microsoft SQL Server estate the team is willing to retire in favour of a managed engine, accepting a database engine swap but no application rewrite, to cut patching and backup overhead. The second is a VMware-based line-of-business application the business will not let the team change at all and which must move within an eight-week lease deadline that rules out re-imaging each host. Which TWO strategy classifications correctly pair with these two workloads? Select TWO.

• AThe SQL Server estate is a refactor, because re-architecting it into a serverless event-driven design on AWS is the only way to remove the patching and backup burden that the team has identified as the problem.
• BThe SQL Server estate is a replatform, because moving it onto Amazon RDS for SQL Server keeps the application unchanged while offloading patching, backups and failover to the managed service through a targeted change.check_circle Correct
• CThe SQL Server estate is a rehost, because lifting the database servers to Amazon EC2 unchanged is the lowest-effort move and still lets the team stop managing on-premises hardware after the migration.
• DThe VMware application is a relocate, because moving the virtual machines to VMware Cloud on AWS lifts them as-is with no operating system or application change and the fastest path to meet the eight-week deadline.check_circle Correct
• EThe VMware application is a retire, because workloads bound by a hard lease deadline are decommissioned to avoid migration effort and the business case treats them as end-of-life candidates by default.

Why A is wrong: Refactor means re-architecting the application and is far heavier than needed, since a managed RDS engine already removes patching and backup overhead without rewriting the application.

Why B is correct: Replatform (the lift-and-tinker strategy) is exactly an engine move to a managed RDS service without rewriting the application, which matches the willingness to swap the database while reducing operational overhead.

Why C is wrong: Rehost lifts servers to EC2 with no engine change, so it leaves the team still patching and backing up SQL Server itself, which contradicts the stated goal of offloading that overhead to a managed engine.

Why D is correct: Relocate moves VMware workloads to VMware Cloud on AWS without changing the guest operating system or application, which fits the no-change mandate and the short deadline that rules out re-imaging hosts.

Why E is wrong: Retire applies only to applications no longer needed, but this line-of-business application is still required, so a deadline alone never justifies decommissioning a workload the business depends on.

A finance team is building a three-year total cost of ownership comparison between staying on-premises and migrating to AWS, and the chief financial officer has rejected an earlier model that compared only AWS instance and storage list prices against current server hardware prices. The team must make the comparison defensible by reflecting the genuine full cost of each option rather than only the most visible line items. Which TWO adjustments MOST improve the accuracy and credibility of the total cost of ownership model? Select TWO.

• AInclude the on-premises indirect costs the first model omitted, such as data-centre space, power, cooling, hardware refresh and the staff time spent operating the physical estate, so the on-premises side reflects its true running cost.check_circle Correct
• BExclude all migration project costs from the model, because one-off rehosting and data-transfer effort is a sunk cost that should not influence a three-year run-rate comparison between the two platforms.
• CModel the AWS side using commitment-based pricing such as Savings Plans or Reserved Instances and account for elasticity, rather than assuming every workload runs at on-demand list price twenty-four hours a day for three years.check_circle Correct
• DReplace the comparison with a single blended dollar-per-vCPU rate for each platform, since reducing both estates to one unit price is the most transparent way to present the decision to the steering committee.
• EBase the AWS estimate on peak-hour capacity held permanently in every Region the company might one day use, to be conservative and ensure the model never understates future cloud spend.

Why A is correct: A defensible total cost of ownership counts the hidden operational costs of running a data centre, not just hardware purchase price, so adding facilities, power, refresh and staff time corrects the bias against the on-premises baseline.

Why B is wrong: It is tempting to treat migration as a sunk cost, but a defensible business case includes the one-off cost of migrating so the steering committee sees the true investment, not an artificially low AWS figure.

Why C is correct: Steady production workloads attract deep commitment discounts and many workloads scale down when idle, so pricing only at on-demand list rates overstates the AWS cost and a credible model reflects realistic purchasing and elasticity.

Why D is wrong: A single blended rate hides the very indirect and elasticity factors that make the comparison accurate, so it oversimplifies the model and reintroduces the bias the chief financial officer already rejected.

Why E is wrong: Provisioning permanent peak capacity across speculative Regions inflates the AWS side far beyond real usage, producing a pessimistic and indefensible estimate rather than the genuine cost the model is meant to reflect.

A retailer is planning a data-centre exit and has hundreds of servers to move within a fixed lease deadline. The portfolio includes a packaged commercial ERP suite the vendor sells only as a per-server licence and a self-hosted Microsoft SQL Server estate the team is willing to retire in favour of a managed engine. The licensing and finance teams want the team to label every application with one of the seven common migration strategies before any move begins, so that wave planning, effort estimates and the business case all use the same vocabulary. Which classification correctly pairs each of these two workloads with the appropriate 7Rs strategy?

• AClassify the commercial ERP suite as refactor because it is packaged software that should be re-architected, and the self-hosted SQL Server estate as relocate, moving both workloads into AWS with the least possible change so the existing licences and configuration carry across untouched.
• BClassify the commercial ERP suite as repurchase because it is licensed packaged software better moved to a SaaS or new licensing model, and the SQL Server estate as replatform because it moves to a managed engine such as Amazon RDS with only configuration changes.check_circle Correct
• CClassify the commercial ERP suite as rehost because its servers can be lifted unchanged onto EC2, and the SQL Server estate as retire because moving its data to a managed engine means the old database is decommissioned and its function ends entirely after cutover.
• DClassify the commercial ERP suite as retain because licensed software cannot move to AWS, and the SQL Server estate as rehost, lifting the database servers onto EC2 unchanged so the existing engine and licences carry across without modification.

Why A is wrong: Refactor means re-architecting an application you control, which a closed packaged ERP suite does not allow, and relocate is the VMware Cloud on AWS hypervisor move rather than a database engine change, so both labels are mismatched to the stated facts.

Why B is correct: Repurchase fits packaged or licensed software that is dropped for a SaaS or new commercial product, and replatform fits a lift-and-optimise move of a self-managed database onto a managed service like Amazon RDS without rewriting the application, so each label matches the workload.

Why C is wrong: Rehost ignores that the ERP is licensed per server and a SaaS move is the stated intent, and retire means switching an application off for good, not migrating its data to a managed engine, so both classifications misread the seven strategies.

Why D is wrong: Retain means deliberately keeping a workload in place this wave, which contradicts the data-centre exit deadline, and rehosting SQL Server onto EC2 keeps the self-managed engine the team explicitly wants to drop, so both labels conflict with the requirements.