AWS Solutions Architect Professional Design for New Solutions: 297 practice questions

12 of the 297 Design for New Solutions questions in the Certsqill AWS Solutions Architect Professional 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 Solutions Architect Professional? Take the free 5-min readiness check →

1. Use blue-green environments with expand-contract schema: Which architecture best satisfies both requirements?

1. Continue rolling deployment and run a CloudFormation change set before each release.

   A change set previews infrastructure changes, but rolling deployment still mixes versions and does not ensure schema compatibility.
2. Use a canary release while applying an irreversible schema change before compatibility testing.

   Canary traffic limits exposure, but an irreversible schema change can prevent reliable rollback to the previous application.
3. Replace the old environment in place and restore its previous AMI if errors occur.

   In-place replacement can leave partial changes and does not provide a separately validated environment or safe schema transition.
4. Use blue-green environments with expand-contract schema changes, validate green, then shift traffic. ✓

   A separate validated environment enables traffic reversal, while expand-contract changes keep the schema compatible with both application versions.

Use blue-green deployment with expand-contract schema evolution.

2. Commit only to the measured baseline with a Compute: Which approach is most appropriate?

1. Use a budget threshold as a guaranteed hard spending cap for all compute usage.

   Budgets monitor configured thresholds and actions but do not universally guarantee an immediate service-wide spend cap.
2. Run all analytics on Spot Instances without fallback capacity or interruption handling.

   Spot can reduce cost for interruptible workloads, but using it exclusively conflicts with workloads needing dependable baseline capacity.
3. Commit only to the measured baseline with a Compute Savings Plan and keep uncertain peaks on demand. ✓

   A baseline commitment can reduce eligible steady usage cost while on-demand capacity preserves flexibility for uncertain growth.
4. Purchase commitments for the highest projected seasonal demand before production measurements exist.

   Overcommitting against an uncertain forecast risks paying for unused commitment when adoption or seasonal demand is lower.

Commit to measured baseline usage and retain on-demand elasticity for uncertain peaks.

3. Configure a DLQ and redrive policy: Which action is most appropriate?

1. Remove database idempotency because Standard queues already suppress duplicate deliveries.

   Standard queues are at-least-once and can redeliver messages, so consumer idempotency remains necessary for safe side effects.
2. Increase visibility timeout indefinitely so malformed messages cannot return to the queue.

   A longer timeout delays retries but can hide failures and does not isolate messages that cannot ever process successfully.
3. Change the queue to FIFO and assume deduplication makes downstream processing exactly once.

   FIFO provides ordering and bounded deduplication semantics, but it does not make external side effects exactly once automatically.
4. Configure a DLQ and redrive policy, and scale consumers using backlog or queue-age signals. ✓

   A DLQ isolates repeatedly failing messages, while backlog-aware scaling addresses growing work that average CPU can miss.

Use a DLQ for poison messages and scale from backlog or queue age rather than CPU alone.

4. Perform a measured restore rehearsal through dependencies: Which TWO actions should the architect require befo

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

1. Switch DNS when replication reports healthy.

   Replication health does not establish dependency readiness, application recovery time, logical-corruption protection, or a rollback boundary.
2. Perform a measured restore rehearsal through dependencies and application validation. ✓

   A measured rehearsal establishes whether the four-hour recovery objective is achievable and verifies dependency readiness and application correctness.
3. Create and retain an immutable point-in-time source backup through destination validation. ✓

   An isolated immutable point-in-time copy protects against logical corruption and preserves a pre-cutover recovery point while the destination is validated.
4. Delete the source immediately after cutover.

   Immediate deletion removes the rollback boundary before destination validation and increases exposure to migration defects or logical errors.
5. Rely on an untested backup policy for rollback.

   A backup policy may retain recovery material, but an untested restore does not establish recovery time, application correctness, or an operational rollback sequence.

Measure full recovery and retain an immutable pre-cutover recovery point.

5. Enforce authorization in the application: Which option best addresses the limitation?

1. Enforce authorization in the application. ✓

   Application authorization can evaluate authenticated identity, tenant ownership, requested object, and business permissions for every operation.
2. Use signed CloudFront URLs for API account requests.

   Signed URLs control configured delivery access but do not replace application identity, session validation, or tenant authorization.
3. Add more WAF rules for every account path.

   WAF filters request characteristics but cannot reliably determine authenticated identity, tenant ownership, or business authorization decisions.
4. Enable GuardDuty findings to deny unauthorized account requests.

   GuardDuty detects supported threats; it does not automatically enforce application permissions or authorize individual API operations.

WAF can filter traffic, but only application authorization can enforce identity and tenant ownership.

6. Use the Aurora reader endpoint for read connections: Which component is missing?

1. Add an RDS Proxy while leaving all application reads on the cluster endpoint.

   RDS Proxy can pool and manage connections, but leaving reads on the cluster endpoint does not provide the required reader routing.
2. Add more Aurora Replicas while leaving applications connected to the cluster endpoint.

   Additional replicas do not receive read sessions when applications continue targeting the writer-oriented cluster endpoint.
3. Use the Aurora reader endpoint for read connections. ✓

   The reader endpoint distributes new read connections among available Aurora Replicas instead of directing every connection to the writer.
4. Export portal read data to S3 and query the objects instead of using Aurora readers.

   S3 object storage does not replace the portals’ transactional relational queries or provide Aurora connection distribution.

Direct read sessions to Aurora’s reader endpoint; healthy replicas cannot help while applications target the cluster endpoint.

7. Add canary alarms with automatic rollback: Which change is the smallest complete solution?

1. Require an overnight operator to approve rollback manually.

   Manual approval violates the stated unattended operation requirement and does not provide automatic failure response.
2. Create a CloudFormation change set before deployment.

   A change set previews infrastructure changes but does not monitor application health or automatically roll back traffic.
3. Increase the canary duration without adding alarms.

   A longer canary supplies exposure time but cannot detect failure or initiate automatic rollback without configured monitoring.
4. Add canary alarms with automatic rollback. ✓

   Configured health alarms connected to traffic shifting provide the monitoring and automatic rollback missing from the proposed canary.

Connect existing health metrics to canary rollback alarms so traffic shifts can reverse automatically.

8. Use diversified Spot workers: Which architecture best fits these constraints?

1. Run all jobs on one large On-Demand instance and copy checkpoints only after the nightly schedule completes.

   A single host creates a capacity bottleneck, and delayed checkpoint copying prevents timely recovery after interruption.
2. Use Lambda workers with reserved concurrency and store checkpoints in ephemeral execution state.

   Reserved concurrency limits simultaneous executions, while ephemeral execution state cannot reliably preserve progress across interruption or replacement.
3. Use an Auto Scaling group of only On-Demand instances with local checkpoint files.

   Only On-Demand capacity misses the cost objective, and local checkpoint files may be lost when instances are replaced.
4. Use diversified Spot workers, On-Demand fallback, and durable checkpoints. ✓

   Diversified Spot capacity lowers cost, fallback capacity protects deadlines, and durable checkpoints allow interrupted jobs to resume safely.

Combine diversified Spot capacity, On-Demand fallback, and durable checkpoints for resilient interruptible batch processing.

9. Map additional accounts to stable groups and scale: Which change best resolves the backlog without violating o

1. Map additional accounts to stable groups and scale consumers from backlog. ✓

   Ordering remains intact within each account’s stable group, while more independently active groups expose parallelism. Backlog-based scaling then adds consumers when queued work exists.
2. Use an SQS Standard queue.

   Standard queues provide best-effort ordering and cannot satisfy the required per-account ordering guarantee.
3. Add consumers while retaining only the 40 current groups.

   Consumers beyond the available message groups cannot create additional parallel FIFO work.
4. Increase the visibility timeout for the existing groups.

   Visibility timeout changes redelivery timing but does not increase the number of independently executable message groups.

Use more stable account groups and scale consumers from backlog.

10. Use warm standby with reduced-capacity instances already: Which strategy should the architect recommend?

1. Use backup and restore with automated deployment after detecting the regional outage.

   Restoration and deployment would add work to an already measured 55-minute provisioning path, exceeding the RTO.
2. Use active-active deployment with full production capacity in both Regions continuously.

   Active-active could reduce interruption, but it exceeds the stated reduced-capacity funding tradeoff without a requirement for full duplicate capacity.
3. Use warm standby with reduced-capacity instances already running. ✓

   A functional reduced-capacity environment avoids the measured 55-minute provisioning delay and is aligned with the approved continuous-capacity budget.
4. Use pilot light and provision the application tier on demand during regional failure.

   The measured application provisioning and validation time already exceeds the 30-minute recovery objective.

Use warm standby because measured provisioning exceeds the RTO and reduced continuous capacity is funded.

11. Grant the workload role KMS use and S3 access separately: Which design is most appropriate?

1. Grant the workload role KMS use and S3 access separately. ✓

   Separate KMS usage from S3 permissions lets the workload decrypt objects while operators retain key administration without document access.
2. Rotate the KMS key.

   Rotation does not grant permissions or repair cross-account authorization relationships.
3. Add an IAM allow while leaving the cross-account KMS key policy unchanged.

   Cross-account KMS use requires compatible key-policy authorization; an IAM allow alone cannot overcome the key policy.
4. Give operators S3 read access for key troubleshooting.

   This violates separation of duties and unnecessarily grants document access.

Authorize KMS use and S3 data access independently.

12. Keep classic Multi-AZ and add a read replica for reporting: Which architecture should the architect recommend?

1. Keep classic Multi-AZ and add a read replica for reporting. ✓

   The classic Multi-AZ standby supplies high availability, while a read replica supplies separate read capacity for reporting queries.
2. Add an Aurora reader without migrating the relational database.

   Aurora readers belong to Aurora clusters, so this does not add read capacity to the existing classic RDS deployment.
3. Remove Multi-AZ and use only a read replica.

   A read replica supports read scale but does not replace synchronous standby high availability for the primary database instance.
4. Read from the classic Multi-AZ standby.

   A classic Multi-AZ standby supports failover but cannot serve application read traffic for reporting workloads.

Retain classic Multi-AZ for failover and add a read replica for reporting traffic.

Other AWS Solutions Architect Professional domains

• Design Solutions for Organizational Complexity — 266 questions →
• Continuous Improvement for Existing Solutions — 256 questions →
• Accelerate Workload Migration and Modernization — 205 questions →
• All 1024 AWS Solutions Architect Professional questions →
• AWS Solutions Architect Professional certification: requirements, cost and exam format →