Exams / SAP-C03 / Study guide / Resilience assessment and testing (Resilience Hub, Fault Injection Service)
Resilience assessment and testing (Resilience Hub, Fault Injection Service): SAP-C03 study notes and practice questions
What to know about Resilience assessment and testing (Resilience Hub, Fault Injection Service) for the SAP-C03 exam, from the Resilience, Migration, and Business Continuity domain (15% of the exam guide), then 2 free questions to test it. Part of the SAP-C03 study guide.
SAP-C03 asks how to prove that an application meets its resilience targets, find weak points before customers do, and keep proving it as the application changes.
AWS Resilience Hub
Define an application from CloudFormation stacks, Terraform state, resource groups, AppRegistry applications or EKS clusters.
Attach a resiliency policy with RTO and RPO targets for each disruption type: application, infrastructure, Availability Zone and Region.
Run an assessment: Resilience Hub estimates achievable RTO and RPO from the actual configuration (backups, replication, Multi-AZ, Auto Scaling) and reports whether the policy is met.
Recommendations cover resiliency fixes (such as enabling Multi-AZ or cross-Region backup), CloudWatch alarms, standard operating procedures as Systems Manager Automation runbooks, and AWS FIS experiments to validate the design. Export them as CloudFormation templates.
Schedule daily assessments and turn on drift detection so a change that breaks the policy is flagged; integrate assessments into CI/CD to stop a deployment that lowers resilience.
Use Systems Manager runbooks for recovery procedures (restore from backup, scale up, promote a replica) so recovery is repeatable.
AWS Fault Injection Service (FIS)
Experiment templates define actions (stop or terminate instances, inject CPU or memory stress, add network latency or packet loss, throttle or fail API calls, fail over an Aurora or RDS database, disrupt connectivity in a subnet, stop ECS tasks or EKS pods, pause DynamoDB global table replication), targets (by tag, resource ID or filter) and stop conditions.
Stop conditions are CloudWatch alarms; if the alarm fires, FIS stops the experiment so it can’t cause a real outage.
The scenario library offers prebuilt scenarios such as an AZ power interruption and cross-Region connectivity disruption.
IAM roles limit what an experiment can touch; run experiments across accounts with multi-account experiments.
Chaos engineering practice
Define steady state with business metrics (orders per minute, error rate, p99 latency).
Form a hypothesis: “If one AZ loses power, error rate stays below 1% and the service recovers within 5 minutes.”
Run the smallest experiment in a lower environment, then in production with guardrails.
Measure, fix and repeat; automate experiments in pipelines or on a schedule.
Measuring recovery
Run game days and DR drills (Elastic Disaster Recovery drills, ARC Region switch plans, AWS Backup restore testing) and record actual recovery time.
Use Route 53 health check status, CloudWatch alarms and CloudWatch Synthetics canaries to timestamp when service was lost and restored, and compare with the RTO.
Compare restored data timestamps with the failure time to measure actual RPO.
How to choose
Scenario wording
Pick
“Check whether the app meets its RTO and RPO and get fixes”
Resilience Hub assessment with a resiliency policy
“Detect when a change breaks resilience”
Resilience Hub drift detection and scheduled assessments
“Simulate an AZ failure safely”
FIS AZ power interruption scenario with stop conditions
“Halt the test if errors spike”
FIS stop condition on a CloudWatch alarm
“Prove backups restore”
AWS Backup restore testing
Common traps
Terminating instances by hand or with scripts instead of FIS with guardrails.
Experiments without stop conditions.
Treating a Resilience Hub assessment as a test; it estimates, FIS and drills prove.
A retailer has a documented recovery target for each of its 12 critical applications: a recovery time objective and a recovery point objective. The resilience team does not know which applications would actually meet those targets if a Region or an Availability Zone failed.
The team wants an assessment that compares each application's design with its targets and recommends fixes, with the results kept for the audit committee. The team does not want to break anything in production to find the answer.
Which approach meets these requirements?
Choose one answer.
AA. Run AWS Fault Injection Service experiments in production against each application, measure how long each one takes to recover, and compare the recovery times with each application's targets.
BB. Use AWS Resilience Hub with a resiliency policy that holds each application's recovery targets, assess the applications against it, and review the recommendations and stored results.
CC. Ask each application team to write a recovery plan in a shared document, and have the resilience team sign off on each plan after a review meeting.
DD. Schedule a full disaster recovery drill for each Region once a year, and record the outcome of each drill in the audit file.
Show the answer and explanation
Answer: B
A. Wrong: Production experiments can disrupt customers, which the team wants to avoid for this assessment. Measured recovery times also come without design recommendations for closing the gaps.
B. Right: Correct. Resilience Hub compares each application's design with its recovery targets and recommends fixes, and it keeps the assessment results for review. The assessment reads the design and does not disrupt production.
C. Wrong: A written plan does not test the design against the targets, and the review gives no repeatable evidence for the audit committee. The option does not meet the assessment requirement.
D. Wrong: A yearly drill is a real test but a rare one, and it disrupts the environment during the drill. It does not compare the designs with the targets or recommend fixes.
Explanation
Resilience Hub assesses each application's design against its recovery targets, recommends fixes and keeps the results, without disrupting production. Production fault experiments, written plans and yearly drills each miss the assessment, the recommendations or the no-disruption need.
A streaming service's recommendation API runs on EC2 instances in three Availability Zones behind an Application Load Balancer. The team wants to prove in production that the API keeps serving users when one zone's instances become unreachable, and that load balancer traffic can be moved away from an impaired zone.
Each test must affect only one zone at a time and must stop automatically if a CloudWatch alarm on customer errors goes into the ALARM state. The team also wants the zonal traffic shift tested on a regular schedule, not just once.
Which TWO designs meet these requirements? (Choose two.)
Choose two answers.
AA. Write a script that terminates random production instances across all three zones every hour, and have the on-call engineer watch the dashboards and stop the script by hand if needed.
BB. Run the experiment only in the staging account, which has no real customer traffic, and count the staging results as proof for production.
CC. Create an AWS Fault Injection Service experiment template that disrupts network connectivity for the subnets in one zone, with the customer error alarm set as the experiment's stop condition.
DD. Turn on zonal autoshift for the load balancer, and configure its practice runs with the customer error alarm as the outcome alarm, so that ARC shifts traffic away from one zone each week.
EE. Turn off cross-zone load balancing on the target group, and have an engineer deregister one zone's instances during a monthly maintenance window while watching the error dashboards.
Show the answer and explanation
Answers: C, D
A. Wrong: Random termination across all zones is not limited to one zone, and it has no automatic stop condition. The manual stop is slow compared with the agreed threshold.
B. Wrong: Staging has no production traffic or production-scale data, so it cannot prove what happens in production. The option does not meet the requirement to test production instances.
C. Right: Correct. The template limits the fault to one zone's subnets, so the instances there become unreachable while the other zones keep serving. The stop condition ends the experiment automatically when the error alarm fires.
D. Right: Correct. Practice runs regularly shift the load balancer's traffic away from one zone for a short period, which proves the shift works on a schedule. ARC ends a practice run when its outcome alarm fires, which gives the automatic stop. Learn more: Zonal autoshift in ARC (opens in a new tab)
E. Wrong: Deregistering one zone's targets does move traffic away from it, but the test depends on an engineer watching dashboards. There is no automatic stop when customer errors rise.
Explanation
A FIS experiment scoped to one zone's subnets, with the error alarm as its stop condition, proves the API survives the zone failure. Zonal autoshift practice runs shift traffic away from one zone every week and end when the outcome alarm fires. A random termination script, a staging-only test and a manual deregistration each miss the scope, the automatic stop or the production need.
Want more on Resilience assessment and testing (Resilience Hub, Fault Injection Service)? The 5 full-length practice sets have 6 more Resilience assessment and testing (Resilience Hub, Fault Injection Service) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Resilience assessment and testing (Resilience Hub, Fault Injection Service)