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.

A pharmaceutical group runs about 50 accounts in a single AWS Organization. A central encryption account must own one KMS key that protects regulated datasets replicated into S3 buckets in eu-west-1 and us-east-1, so a workload in either Region can decrypt the same ciphertext without a cross-Region KMS call, and the encryption team must remain the only party that can administer the key while named workload accounts may only encrypt and decrypt. The security team also wants yearly cryptographic rotation handled automatically with no re-encryption of existing objects. Which TWO actions together BEST deliver this design? (Select TWO.)

• AProvision a separate single-Region KMS key in each Region and write a scheduled Lambda function that re-encrypts every replicated object with the destination Region's key whenever data lands so both copies stay readable.
• BUse an AWS managed key for S3 in each Region so AWS handles rotation and availability, and rely on the default service key policy to let the workload accounts decrypt the regulated objects across the organisation.
• COperate an AWS CloudHSM cluster in each Region, generate the key material in the hardware security modules, and have the workloads call the clusters directly so the encryption team retains single-tenant control of the keys.
• DCreate a KMS multi-Region key in the encryption account and replicate it to eu-west-1 and us-east-1, so each Region holds a replica sharing the same key material and key ID and can decrypt objects encrypted by the other Region locally.check_circle Correct
• EAuthor a key policy that grants the encryption account's administrators full kms key administration and grants only kms:Encrypt and kms:Decrypt to the named workload account principals, and enable automatic annual key rotation on the key.check_circle Correct

Why A is wrong: Independent single-Region keys plus a re-encryption job can make both copies readable, but it forces bulk re-encryption on every replication and adds a custom pipeline, which is far more overhead than a multi-Region key that shares material across Regions.

Why B is wrong: AWS managed keys rotate automatically but their key policy cannot be edited and they are scoped to a single account and Region, so they cannot grant the cross-account access or provide the shared cross-Region material this scenario requires.

Why C is wrong: CloudHSM gives single-tenant control but is a cluster the team must size, patch and replicate itself, it does not provide KMS-style multi-Region replicas or automatic rotation, and it adds the operational burden the team is trying to avoid.

Why D is correct: A KMS multi-Region key has replicas in each Region that share the same key material and key ID, so ciphertext produced in one Region decrypts against the local replica in the other without any cross-Region KMS call, which is exactly the portability the design needs.

Why E is correct: Scoping key administration to the encryption team while granting workload accounts only the encrypt and decrypt actions enforces the stated separation of duties, and KMS automatic rotation rotates the backing material yearly without re-encrypting existing objects, satisfying both control and rotation requirements.

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 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.

An enterprise is starting a large migration and wants a single place to track progress across hundreds of servers spread over several on-premises sites and multiple AWS accounts. The programme office needs an automatically updated inventory of servers, with utilisation data and network dependencies between applications, gathered with the least manual effort, and it wants each application grouped so that migration status rolls up to a dashboard the steering committee can read. Which approach BEST delivers this discovery and tracking capability?

• AAsk each site owner to fill in a shared spreadsheet of servers and dependencies every fortnight, then import it into a custom Amazon QuickSight dashboard, so the inventory stays current without deploying any agents into the on-premises estate.
• BDeploy AWS Config across the on-premises servers to record configuration items and dependencies, and use AWS Config aggregators to roll the inventory up across accounts into the steering committee dashboard for migration tracking.
• CRun AWS Application Discovery Service against the sites to collect server inventory, utilisation and network dependencies automatically, and view and group the data in AWS Migration Hub to track migration status across accounts on one dashboard.check_circle Correct
• DUse Amazon Inspector to scan the on-premises servers for inventory and software, exporting its findings into AWS Migration Hub so the programme office sees a single dependency map and migration status across every account.

Why A is wrong: Manual spreadsheets fed into QuickSight can show status, but they depend on people updating them by hand, capture no real utilisation or live network dependencies, and drift quickly, which directly fails the least-manual-effort and automatic-inventory requirement.

Why B is wrong: AWS Config records configuration of AWS resources and supports a multi-account aggregator, but it is not a pre-migration discovery tool for on-premises servers, does not capture host utilisation or application dependency maps, and offers no migration status tracking.

Why C is correct: Application Discovery Service collects server inventory, utilisation and dependency data automatically by agent or agentless connector, and Migration Hub aggregates that data across accounts, lets you group servers into applications and tracks each application's migration status on a single dashboard, meeting every stated requirement.

Why D is wrong: Amazon Inspector is a vulnerability and software assessment service, not a discovery or dependency-mapping tool, and it does not feed server utilisation or migration progress into Migration Hub, so it cannot build the inventory the programme office needs.

A logistics company must vacate its leased data centre in four months and migrate around two hundred Linux and Windows virtual machines, including several stateful application servers with locally attached disks. The applications are bespoke and the team cannot change their code or operating system configuration before the move, and they need to keep cutover downtime per server to a few minutes with the ability to test in AWS before the final switch. The programme wants the fastest, lowest-risk rehost that meets the deadline. Which migration tooling and strategy BEST fits these constraints?

• AUse AWS Database Migration Service together with the schema conversion tooling to replicate each virtual machine into AWS, run validation tasks against the migrated targets, then cut over, treating the whole estate as a rehost that needs no application changes.
• BUse AWS DataSync to copy the file systems and locally attached disks of each virtual machine into Amazon S3 and Amazon EFS, then rebuild the servers from those files in AWS as a rehost requiring no application changes.
• CRefactor each application into containers on Amazon ECS before the move so the workloads become portable, then deploy the container images into AWS within the four-month window as the lowest-risk path off the leased data centre.
• DUse AWS Application Migration Service to continuously replicate the source virtual machines block by block into a staging area, run non-disruptive test launches, then perform a short cutover as a rehost needing no application or operating-system changes.check_circle Correct

Why A is wrong: Database Migration Service moves data between database engines, not entire virtual machines with their operating systems and local disks, so it cannot rehost bespoke application servers and would leave the compute and OS layers unmigrated despite the validation tasks.

Why B is wrong: DataSync transfers files and objects between storage systems efficiently, but it does not replicate a bootable server image or preserve installed software and configuration, so rebuilding two hundred stateful servers from copied files would be slow, manual and risky against the deadline.

Why C is wrong: Refactoring bespoke applications into containers is a code-level rewrite that the team is explicitly forbidden to do and cannot complete in four months, so it carries the highest effort and risk and breaks the no-application-changes constraint.

Why D is correct: Application Migration Service performs continuous block-level replication of whole servers into a staging area, supports non-disruptive test instances and a short final cutover, and requires no changes to the application or operating system, which is exactly the lift-and-shift rehost the four-month deadline demands.