AWS Solutions Architect Professional Continuous Improvement for Existing Solutions: 256 practice questions

12 of the 256 Continuous Improvement for Existing 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. Deploy one NAT gateway per Availability Zone and route: Which architecture best satisfies both constraints?

1. Deploy one NAT gateway per Availability Zone and route each private subnet to its local gateway. ✓

   Zonal NAT gateways remove the single-zone dependency and avoid routing private-subnet egress through another Availability Zone.
2. Replace private subnets with public subnets and assign public addresses to application instances.

   Public addressing changes exposure and routing rather than providing private, zonally resilient outbound access required by the design.
3. Move the NAT gateway into the database subnet and route application traffic through the classic standby during failure.

   NAT placement does not make the database standby an egress device, and the standby cannot serve application traffic.
4. Add a second route to the existing NAT gateway and retain both private subnets on that gateway.

   Additional routes to one NAT gateway preserve the single dependency and cannot provide independent outbound access during its zone failure.

Use zonally local NAT gateways so each private subnet retains independent outbound access after a zone failure.

2. Compare EBS and instance EBS limits: Which TWO investigations or corrections are most appropriate?

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

1. Increase EC2 CPU capacity first because low utilization indicates the instances lack sufficient compute.

   Low CPU does not establish a compute bottleneck, while the EBS measurements provide stronger evidence for investigating the storage path.
2. Compare EBS and instance EBS limits, then increase storage or instance capacity after confirming the measured bottleneck. ✓

   High EBS queue depth and near-limit throughput with low CPU indicate that storage or instance EBS limits may be constraining latency.
3. Add ALB path rules to send DynamoDB requests directly to targets in the subnet that succeeds.

   ALB HTTP routing does not repair subnet routes, endpoint policies, or authorization between instances and DynamoDB.
4. Lower CloudFront TTLs so DynamoDB authorization and EBS queue depth information refresh more quickly.

   CloudFront caching affects edge object freshness, not instance storage saturation or private-subnet access to DynamoDB.
5. Compare the failing subnet’s routes, DynamoDB endpoint, and endpoint policy with the successful subnet. ✓

   A subnet-specific DynamoDB failure despite the expected role points to differences in routing, endpoint configuration, or endpoint-policy permissions.

Investigate the measured EBS constraint and the subnet-specific DynamoDB network or endpoint-policy boundary.

3. Inventory unattached volumes: Which action should the provider add?

1. Inventory unattached volumes, review snapshots and owners, then approve deletion or retention. ✓

   This identifies residual EBS resources while ownership and recovery review prevents unsafe deletion.
2. Delete all unattached volumes immediately after instance termination.

   An unattached volume can still contain data needed for recovery, so immediate deletion risks data loss.
3. Use CloudTrail records alone to determine current volume ownership and charges.

   CloudTrail records API activity but is not a complete current inventory or billing-attribution source for EBS volumes.
4. Assume activated cost-allocation tags automatically identify every historical unattached volume owner and retain no inventory.

   Activated tags do not guarantee complete historical attribution or replace an inventory of current unattached volumes.

Inventory unattached volumes and review ownership, age, snapshots, and recovery needs before cleanup.

4. Install and configure the CloudWatch agent to publish: Which TWO actions should the architect recommend?

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

1. Use a rolling update and infer memory health from standard EC2 CPU metrics.

   Rolling updates mix versions and standard EC2 metrics do not provide the missing guest-memory measurement.
2. Install and configure the CloudWatch agent to publish guest-memory metrics before migration. ✓

   Guest-memory visibility generally requires the CloudWatch agent, enabling evidence-based health evaluation during and after migration.
3. Replace the AMI in place and create a change set for automatic application rollback.

   Change sets preview infrastructure changes but do not provide application traffic rollback or guarantee update success.
4. Enable CloudWatch Logs Insights queries and treat query results as a continuously evaluated memory alarm.

   Logs Insights queries are analytical queries, not automatically published metrics that CloudWatch alarms continuously evaluate.
5. Deploy the new AMI as a separate environment and use blue/green traffic shifting with validation before retirement. ✓

   Blue/green deployment preserves the old environment for rapid traffic rollback while validating the replacement independently.

Publish guest-memory metrics and retain the old environment through blue/green traffic control.

5. Reject the proposal: Which assessment is correct?

1. Store credentials in an S3 bucket encrypted with SSE-KMS and grant access only through an SCP.

   S3 encryption protects stored objects, but an SCP cannot grant access and the design omits suitable secret rotation orchestration.
2. Use IAM Identity Center permission sets as the runtime credential source for every workload.

   Identity Center federates workforce access; workload roles are the appropriate identity pattern for application runtime permissions.
3. Reject the proposal; use workload roles and Secrets Manager, while granting KMS use through both key and caller permissions. ✓

   Workload roles remove long-lived credentials, Secrets Manager supports configured rotation, and cross-account KMS use requires key-policy and caller authorization.
4. Accept the proposal because an SCP grants member-account workloads KMS access and CloudFormation encrypts plaintext template values automatically.

   SCPs set permission ceilings rather than grants, and plaintext template values remain an inappropriate secret-management design.

Replace embedded credentials with workload roles and Secrets Manager, and authorize KMS use through the required policies.

6. Add an independently tested cross-Region database recovery: Which TWO missing components should the architect

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

1. Add an independently tested cross-Region database recovery design matched to measured RTO and RPO requirements. ✓

   Regional recovery requires replicated or restored data, dependencies, capacity, and tested runbooks rather than DNS failover alone.
2. Use SQS FIFO deduplication to guarantee that retried order effects occur exactly once.

   FIFO deduplication does not guarantee exactly-once external effects, so it cannot replace idempotent order processing.
3. Add application retry with bounded backoff and connection reestablishment after endpoint changes. ✓

   Bounded retry and connection recreation address stale pooled connections and allow clients to recover after database endpoint failover.
4. Increase DNS TTL so clients retain the failed regional endpoint longer during recovery.

   A longer TTL delays endpoint correction and worsens recovery time instead of helping clients reach the recovered service.
5. Read orders from the classic Multi-AZ standby during primary failover to avoid connection interruption.

   The classic Multi-AZ standby cannot serve read traffic, so it cannot be used as an application recovery endpoint.

Add bounded connection recovery and a tested cross-Region data-recovery design; DNS alone is insufficient.

7. Move the workload to a larger EC2 instance type: Which change should the architect recommend?

1. Add an EBS volume and stripe application files across both volumes.

   Additional EBS throughput does not remove an EC2 instance network limit already identified as the bottleneck.
2. Configure an Auto Scaling group with more identical instances behind an ALB.

   Horizontal scaling requires application distribution and state handling, neither of which is available in this stateful design.
3. Move the workload to a larger EC2 instance type with higher network capacity. ✓

   A larger instance directly removes the observed network ceiling while preserving the application, storage, and deployment model.
4. Place the instance in a cluster placement group to increase network performance.

   Cluster placement groups improve network locality for suitable fleets but do not raise an instance type's network cap.

Resize the instance because measured network saturation, not storage or CPU, limits this unchanged application.

8. Rightsize the instance type using representative peak: Which approach is most appropriate?

1. Replace all instances with Spot capacity and remove the minimum capacity requirement.

   Spot interruptions and removing minimum capacity conflict with maintaining tested baseline availability for the marketplace API.
2. Migrate the API to an EFS-based architecture before changing instance sizes.

   EFS addresses shared file semantics, not the observed compute overcapacity, and introduces unnecessary architectural change.
3. Rightsize the instance type using representative peak metrics, then validate capacity. ✓

   Rightsizing based on measured peaks reduces excess capacity while preserving the tested minimum and existing scaling architecture.
4. Move the API to a larger instance type to provide additional performance headroom.

   The supplied CPU, memory, network, and storage measurements show substantial unused capacity, making enlargement counterproductive.

Rightsize from representative peak measurements while retaining the tested Auto Scaling minimum.

9. Emit request and failure metrics with EMF: Which implementation should the architect choose?

1. Use a CloudTrail selector for failed payments and send the resulting activity to SNS.

   CloudTrail records AWS API activity, not the application request and payment-failure denominator required for this percentage.
2. Query the logs periodically with Logs Insights and review the calculated percentage.

   Logs Insights can calculate the percentage for analysis but does not create the continuously evaluated metric required by a CloudWatch alarm.
3. Emit request and failure metrics with EMF, calculate their ratio with metric math, and alarm to SNS. ✓

   EMF publishes the application metrics without maintained parsing rules, metric math evaluates failures divided by requests, and the alarm invokes the existing SNS workflow. The supplied intervals evaluate to 1.5% and 2.5%, so only the latter breaches the threshold.
4. Maintain metric filters for both JSON fields, publish their counts, and configure a ratio alarm without metric math.

   Metric filters can publish counts, but the alarm still requires metric math to evaluate the failure-to-request ratio; maintaining parsing rules also conflicts with the stated preference.

Publish EMF metrics, use metric math for the ratio, and notify SNS.

10. Configure an organization trail with delegated security: Which change should the architect recommend?

1. Use a Config aggregator to collect the missing API activity and write it to the archive bucket.

   Config aggregation collects resource configuration and compliance information, not CloudTrail management API activity.
2. Configure an organization trail with delegated security administration and centralized archival. ✓

   An organization trail can cover enrolled member accounts, while delegated administration separates security operations from management-account duties.
3. Use an SCP requiring each member account to create a trail before deploying workloads.

   An SCP limits permissions but does not create trails or ensure centralized delivery and archive controls.
4. Create separate trails manually in every member account and grant the archive account read access.

   Manual trails increase administration and do not reliably ensure coverage for future accounts.

Use organization-wide CloudTrail coverage with delegated administration and centralized archival protection.

11. Use asynchronous replication: Which architecture fits?

1. Use asynchronous replication, warm standby, tested failover, and independent backups. ✓

   Asynchronous replication fits the accepted loss window, warm standby supports the recovery deadline, and independent backups provide a separate corruption-recovery source.
2. Create daily backups and provision the entire application after declaring disaster.

   Unmeasured backup restoration and full provisioning may not meet the 30-minute recovery objective.
3. Run active/active applications in both Regions without historical backups.

   Active/active operation can propagate logical corruption and lacks isolated historical recovery copies.
4. Promote the corrupted replica and change DNS.

   The promoted replica contains the same logical corruption and is not a clean recovery source.

Use asynchronous replication, warm standby, tested recovery, and independent backups.

12. Place Amazon SQS Standard between Lambda: Which single architectural change most directly provides durable bac

1. Use an ALB in front of Lambda and route excess requests to a second function.

   Additional synchronous targets do not create durable queueing and can multiply calls against the throttled partner.
2. Enable DynamoDB on-demand capacity and retain direct synchronous partner calls.

   On-demand DynamoDB capacity does not protect the partner API or preserve requests outside the synchronous invocation path.
3. Place Amazon SQS Standard between Lambda and the downstream processing function. ✓

   SQS buffers bursts durably, supports retry through visibility timeout, and lets consumers scale under controlled concurrency.
4. Increase Lambda memory and provisioned concurrency for the existing synchronous integration.

   More execution capacity can increase downstream pressure and does not provide durable buffering or controlled backpressure.

Insert SQS to absorb bursts, preserve work, and let controlled consumers apply downstream backpressure.

Other AWS Solutions Architect Professional domains

• Design for New Solutions — 297 questions →
• Design Solutions for Organizational Complexity — 266 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 →