AWS 3: Resilient Cloud Solutions: 128 practice questions

12 of the 128 3: Resilient Cloud Solutions questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Run active-active services with DynamoDB global tables: Which deployment design best satisfies the resiliency

1. Run one Region with Multi-AZ compute, RDS Multi-AZ, and daily S3 backups.

   These measures address Availability Zone or point-in-time recovery scenarios, not active traffic and rapid recovery after complete Regional failure.
2. Run active-active services with DynamoDB global tables for changing metadata, S3 cross-Region replication for video, and health-based traffic routing. ✓

   This removes regional dependencies from compute, mutable metadata, immutable content, and traffic routing. The design still requires validating replication lag and failover timing.
3. Use CloudFront with one Regional origin and origin failover between Availability Zone endpoints.

   This can improve content delivery availability, but it does not provide a second active Region or replicate entitlement and session state.
4. Run active-active compute with health-based routing, but retain entitlements and session metadata in the primary Region.

   The secondary Region remains dependent on the failed Region for changing state, violating the Regional recovery and RPO requirements.

Use active-active Regional services, DynamoDB global tables, S3 cross-Region replication, and health-based routing.

2. Use an internal Application Load Balancer: Which remediation is most appropriate?

1. Convert the RDS DB instance to Multi-AZ and add another instance in the original Availability Zone.

   RDS Multi-AZ protects the database from an Availability Zone failure, but compute remains single-AZ and sessions remain local.
2. Use an internal Application Load Balancer, a multi-AZ Auto Scaling group, an ElastiCache for Redis replication group with automatic failover for sessions, and RDS Multi-AZ. ✓

   The internal ALB and multi-AZ group provide private redundant compute; Redis provides shared session state with automatic failover; RDS Multi-AZ protects the database.
3. Use an internet-facing load balancer with sticky sessions and local instance storage.

   Sticky sessions and local storage do not survive instance loss, and an internet-facing load balancer does not meet the private administrative-access requirement.
4. Place instances in a multi-AZ Auto Scaling group behind an internal Application Load Balancer.

   This provides private, redundant compute but leaves sessions on instances and leaves the database single-AZ.

Use private multi-AZ compute, a supported shared session store, and RDS Multi-AZ.

3. Use Aurora Global Database with one Regional writer: Which design is most suitable?

1. Use DynamoDB global tables with simultaneous writers in both Regions and application-side conflict resolution.

   This is executable for some multi-Region workloads, but concurrent writers and conflict resolution do not preserve the required single authoritative ordered writer.
2. Use an RDS Multi-AZ DB instance and Route 53 failover records to a second web tier.

   RDS Multi-AZ protects against failures within one Region but does not create a cross-Region database recovery target.
3. Use Aurora Global Database with one Regional writer, a cross-Region secondary, automated secondary promotion, and Route 53 failover after promotion. ✓

   Aurora Global Database provides a cross-Region recovery copy while preserving a single writer. The runbook must promote the secondary, update application connectivity, and then redirect traffic.
4. Use an RDS read replica in another Region and permanently direct writes to both database endpoints.

   A cross-Region read replica can be promoted during recovery, but writing to both endpoints violates the single-writer and ordered-write requirements.

Use Aurora Global Database with a single writer, a cross-Region secondary, automated promotion, and DNS redirection.

4. Configure the ECS service and its capacity provider: (Select TWO.)

Select two. More than one option is correct — every correct one is ticked below.

1. Register only Zone B targets so the NLB sends all connections to the surviving zone.

   This deliberately creates a single-zone dependency and removes capacity if Zone B fails.
2. Increase the NLB TCP idle timeout while retaining the existing zonal placement.

   The supported timeout adjustment does not add zonal capacity or distribute new connections across zones.
3. Enable sticky sessions on the NLB target group to equalize long-lived TCP connections.

   Stickiness preserves client-target affinity and can reinforce imbalance; it does not equalize already established long-lived connections.
4. Configure the ECS service and its capacity provider to place healthy tasks across both Availability Zones. ✓

   Multi-AZ task placement creates independent capacity in both zones, allowing continued service after losing either zone. The capacity provider and subnets must be configured accordingly.
5. Enable cross-zone load balancing on the Network Load Balancer. ✓

   NLB cross-zone load balancing allows nodes to select healthy targets across enabled Availability Zones for new connections. Existing connections are not redistributed.

Enable NLB cross-zone balancing and place ECS tasks across both Availability Zones.

5. Use an EventBridge global endpoint with Regional event: Which design best meets these requirements?

1. Use two active consumers on one Regional SQS queue and rely on visibility timeouts for duplicate control.

   Visibility timeouts provide temporary message leasing, not Regional recovery or durable protection against repeated payment side effects.
2. Use an RDS Multi-AZ database for processed events and Route 53 failover between identical Regional consumer fleets.

   RDS Multi-AZ protects a database within one Region, while DNS failover alone does not replicate queued events or establish durable cross-Region idempotency.
3. Use an EventBridge global endpoint with Regional event buses and queues, a DynamoDB global table for conditional idempotency records, and payment-provider idempotency keys. ✓

   The global endpoint redirects new events to the healthy Region, while conditional durable records and provider keys prevent repeated processing and duplicate external charges.
4. Use EventBridge buses in both Regions and let independent consumers charge before reconciling duplicate transactions afterward.

   Concurrent consumers can perform the same external charge before reconciliation, and later reconciliation cannot reliably prevent or reverse the duplicate side effect.

Use an EventBridge global endpoint, Regional queues, replicated conditional idempotency state, and provider keys.

6. Buffer work in Amazon SQS: Which change best addresses the observed scaling failure?

1. Buffer work in Amazon SQS, scale consumers from backlog per worker, and cap worker or database concurrency below the database limit. ✓

   SQS preserves requests during bursts, backlog per worker measures pending work, and a concurrency cap prevents the database from being overwhelmed.
2. Buffer work in Amazon SQS and scale consumers from backlog per worker.

   A queue and backlog-based scaling address bursts, but without a concurrency cap workers can exceed the database connection limit.
3. Use Lambda provisioned concurrency for synchronous burst processing with unrestricted database access.

   Provisioned concurrency reduces cold starts but does not durably buffer requests or limit database concurrency.
4. Increase instance size and continue scaling workers on average CPU.

   Larger instances add compute capacity, but CPU remains poorly correlated with queued work and database connections remain uncontrolled.

Use SQS, backlog-based scaling, and a database-aligned concurrency cap.

7. Use CloudFront: Which design is best?

1. Use CloudFront, regional load balancers with target-based scaling, and DynamoDB global tables without health-checked traffic failover.

   The components support caching, scaling, and replicated data, but traffic is not automatically redirected when a Region fails.
2. Use CloudFront, one Regional ALB, and larger instances during traffic peaks.

   CloudFront reduces origin load, but one Regional ALB and manual resizing do not provide regional recovery or elastic response.
3. Use ElastiCache in one Region as the primary user-data store and schedule application scaling nightly.

   A single-Region cache is not the authoritative replicated store, and scheduled scaling cannot handle unpredictable bursts.
4. Use CloudFront, multi-Region ALBs with Route 53 health-checked failover, target tracking, and DynamoDB global tables. ✓

   CloudFront caches eligible content, target tracking scales stateless regional fleets, health-checked routing redirects new traffic, and global tables replicate user data.

Combine CloudFront, demand-based scaling, health-checked regional routing, and DynamoDB global tables.

8. Use an ECS Fargate service with the private subnets: The existing ALB is internal; private ECR access and task

Select two. More than one option is correct — every correct one is ticked below.

1. Use an ECS Fargate service with the private subnets, ALB and ECR image. ✓

   Fargate removes host management, while an ECS service maintains tasks and can register them with the ALB in private networking.
2. Deploy one Fargate task and rely on the ALB to replace failed tasks.

   An ALB reports target health but does not independently maintain ECS service desired count or scale tasks.
3. Target-track ALB requests with ECS service bounds of two to ten tasks. ✓

   Request count per target measures service demand, while ECS Service Auto Scaling adjusts tasks within the configured minimum and maximum.
4. Use EKS managed nodes and configure only cluster CPU scaling.

   This is executable but adds unnecessary platform management, and node CPU scaling does not implement request-based application replica scaling.
5. Run containers on manually maintained EC2 instances and scale hosts nightly.

   Manual hosts increase operations work, and nightly scaling cannot respond to request demand or implement task bounds.

Use ECS on Fargate and ECS Service Auto Scaling based on ALB request count.

9. Use regional stacks: Which deployment design best satisfies these requirements?

1. Use one Regional ALB across both Regions and a Multi-AZ RDS database.

   A Regional ALB cannot span Regions, and Multi-AZ RDS does not provide cross-Region profile availability.
2. Use regional stacks, Route 53 health-checked latency routing, DynamoDB global tables, and application conflict handling that routes each profile's writes through one owning Region. ✓

   Regional stacks and health-checked routing support traffic shifts, global tables replicate profiles, and a single writer per profile prevents concurrent regional updates from being lost while either endpoint can accept and forward writes.
3. Use stateless regional containers and ElastiCache Global Datastore for profiles.

   ElastiCache Global Datastore replicates Redis data and is not the durable profile system of record.
4. Use one active Region, Route 53 failover, and periodic profile exports.

   Periodic exports create replication gaps and do not support active regional scaling or timely profile updates.

Use regional stacks, health-checked routing, global tables, and deterministic per-profile write ownership.

10. Use security-owned SSE-KMS artifacts with scoped access: Which design best meets the requirements with the lea

1. Use security-owned SSE-KMS artifacts with scoped access and SAM alarm-gated canary releases. ✓

   Resource policies can permit the workload deployment role to retrieve and decrypt artifacts without granting key administration. SAM and CodeDeploy provide managed progressive delivery, while CloudWatch alarms trigger rollback on elevated errors.
2. Use the security account for storage, grant the deployment role broad KMS permissions, and use SAM canary deployment.

   The managed deployment is suitable, but broad KMS permissions violate least privilege and unnecessarily expose key administration capabilities.
3. Package functions in CloudFormation and use log subscriptions to decide rollback.

   CloudFormation packages resources, but log subscriptions do not provide CodeDeploy traffic shifting or automatic deployment rollback.
4. Copy artifacts to the workload account, use an AWS owned key, and edit Lambda aliases manually.

   AWS owned keys do not satisfy the customer-managed-key requirement, and manual alias changes lack automated rollback.

Use least-privilege cross-account S3/KMS access and SAM CodeDeploy canary deployment with alarms.

11. Use AWS Resilience Hub assessments: Which approach provides the strongest controlled validation?

1. Use Amazon Route 53 health checks to fail production traffic, then compare application metrics after forcing an Availability Zone outage.

   Health checks can influence DNS routing, but deliberately failing production traffic risks customers and omits restore and dependency validation.
2. Use AWS Resilience Hub assessments, AWS Backup restore testing, and controlled ARC routing-control exercises against isolated recovery resources. ✓

   The combined approach evaluates architecture, validates actual restores, and safely exercises routing controls without disrupting customer traffic.
3. Run AWS Fault Injection Service experiments against one production database instance and observe application error rates.

   Fault Injection Service can test selected failures, but this alone does not validate secondary-Region routing, restore procedures, or permissions.
4. Schedule AWS Backup restore testing for representative resources and separately exercise controlled Route 53 failover in a test environment.

   Restore testing validates recovery points, but a separate test environment may not prove the production topology and operational failover path.

Combine architecture assessment, automated restore testing, and isolated routing-control exercises to validate the complete recovery process safely.

12. Create a quarterly AWS Backup restore testing plan: Select TWO actions that best close the stated resilience a

Select two. More than one option is correct — every correct one is ticked below.

1. Keep the existing copy rule and review backup-job completion reports quarterly.

   Backup completion reports do not prove that selected recovery points can be restored, so this leaves the audit gap unresolved.
2. Grant workload administrators key-administrator access in the security account before each recovery exercise.

   Broad key administration violates separation of duties and is unnecessary when narrowly scoped backup and restore use is authorized.
3. Create a quarterly AWS Backup restore testing plan for representative protected resources. ✓

   Restore testing runs scheduled restore jobs and records completion results, providing evidence that retained recovery points are usable.
4. Configure the destination vault and KMS key policy for cross-Region, cross-account AWS Backup copies. ✓

   A destination vault and compatible cross-account KMS permissions make encrypted recovery points independently available after Regional loss.
5. Replicate backup-vault objects to S3 and verify recovery by listing replicated objects.

   AWS Backup recovery points are not validated by S3 object replication or listing; resource restoration must be tested through AWS Backup.

Correct the cross-account KMS and vault configuration, then schedule AWS Backup restore testing.

Other AWS domains

• 1: SDLC Automation — 187 questions →
• 2: Configuration Management and IaC — 144 questions →
• 6: Security and Compliance — 144 questions →
• 4: Monitoring and Logging — 127 questions →
• 5: Incident and Event Response — 119 questions →
• All 849 AWS questions →
• AWS certification: requirements, cost and exam format →