Back to AWS Certified Solutions Architect - Professional (SAP-C02)

Continuous Improvement for Existing Solutions

Determine strategies to improve operational excellence, security, performance, reliability, and identify cost optimization opportunities (~25% of exam).

Covers improving overall operational excellence including alerting and automatic remediation strategies, disaster recovery planning, monitoring and logging with CloudWatch, CI/CD pipelines with deployment strategies (blue/green, all-at-once, rolling), configuration management with Systems Manager, determining optimal logging and monitoring strategies, evaluating deployment processes for improvements, prioritizing automation opportunities, engineering failure scenario activities. Also covers improving security including data retention and regulatory requirements, automated monitoring and remediation with AWS Config rules, secrets management (Systems Manager, Secrets Manager), principle of least privilege access, security-specific AWS solutions, patching practices, backup practices, auditing for least privilege, traceability of users and services, prioritizing automated vulnerability responses, and remediation techniques. Also covers improving performance including high-performing system architectures (auto scaling, instance fleets, placement groups), global service offerings (Global Accelerator, CloudFront, edge computing), monitoring tools and services, SLAs and KPIs, translating business requirements to metrics, testing remediation solutions, adopting new technologies and managed services, rightsizing, and identifying performance bottlenecks. Also covers improving reliability including AWS Global Infrastructure, data replication methods, scaling methodologies (load balancing, auto scaling), high availability and resiliency, disaster recovery methods, service quotas, understanding application growth trends, evaluating reliability gaps, remediating single points of failure, and enabling self-healing and elastic features. Finally covers cost optimization including cost-conscious architecture choices (Spot Instances, scaling policies, rightsizing), price model adoptions (Reserved Instances, Savings Plans), networking and data transfer costs, cost management and alerting, analyzing usage reports for underutilized resources, billing alarms, Cost and Usage Reports, and tagging for cost allocation.
5 minutes 5 Questions

Continuous Improvement for Existing Solutions is a critical domain in the AWS Certified Solutions Architect - Professional exam, focusing on optimizing and enhancing already deployed architectures. This concept emphasizes the iterative process of evaluating, refining, and upgrading AWS infrastructu…

Concepts covered: Alerting and automatic remediation, AWS Lambda for automated remediation, Disaster recovery planning, Amazon CloudWatch monitoring and logging, CloudWatch Logs Insights, Blue/green deployment strategies, All-at-once deployment strategies, Rolling deployment strategies, Systems Manager for configuration management, Optimal logging and monitoring strategies, Deployment process improvements, Automation opportunities in solutions, AWS solutions for configuration automation, Failure scenario engineering, Chaos engineering practices, Data retention requirements, Data sensitivity classification, Data regulatory requirements, AWS Config rules for monitoring, Automated security remediation, Systems Manager for secrets management, Secrets Manager best practices, Principle of least privilege auditing, Security-specific AWS solutions, Patching practices and automation, Backup practices and methods, Secure secrets and credentials management, Security at every layer review, User and service traceability, Automated vulnerability response, Patch and update processes, Security remediation techniques, Auto scaling and instance fleets, EC2 placement groups, AWS Global Accelerator, Amazon CloudFront, Edge computing services, AWS Wavelength, CloudWatch metrics and monitoring, Service level agreements (SLAs), Key performance indicators (KPIs), Business requirements to metrics translation, Testing remediation solutions, New technology and managed service adoption, Rightsizing based on requirements, Performance bottleneck identification, Data replication methods, Load balancing strategies, Elastic Load Balancing, Auto scaling strategies, High availability patterns, Resiliency patterns, Disaster recovery methods and tools, Service quotas management, Application growth and usage trends, Reliability gap evaluation, Single point of failure remediation, Self-healing architectures, Elastic features and services, Cost-conscious architecture choices, Spot Instance strategies, Scaling policies for cost optimization, Resource rightsizing for cost, Reserved Instance planning, Savings Plans selection, Networking cost optimization, Data transfer cost reduction, Cost management and alerting, Usage report analysis, Identifying underutilized resources, Identifying unused resources, Billing alarm design, Cost and Usage Reports analysis, Cost allocation with tagging

Test mode:
Start practice test
SAP-C02 - Continuous Improvement for Existing Solutions Example Questions

Test your knowledge of Continuous Improvement for Existing Solutions

Question 1

What is the recommended approach for validating AWS Config remediation actions before enabling automatic remediation in production?

Correct Answer: Execute the remediation in manual mode first and review the results before switching to automatic execution

The recommended approach for validating AWS Config remediation actions before enabling automatic remediation in production is to execute the remediation in manual mode first and review the results before switching to automatic execution.

This is the correct approach because:

  1. Safe Testing: Manual mode allows you to trigger remediation actions on-demand and observe exactly what changes will be made to your resources without any automatic intervention.

  2. AWS Best Practice: AWS specifically recommends this phased approach - start with manual remediation to understand the impact, verify the remediation works as expected, and then transition to automatic remediation once you're confident in the results.

  3. Risk Mitigation: By reviewing manual remediation results first, you can identify any unintended consequences, verify the SSM Automation documents or Lambda functions work correctly, and ensure the remediation doesn't disrupt production workloads.

  4. Audit and Compliance: Manual execution provides an opportunity to document the remediation behavior and get appropriate approvals before enabling automation.

The other options are less optimal:

  • Deploying with automatic execution in a test account may not accurately reflect production conditions, resource configurations, or dependencies that exist in the production environment.

  • Creating duplicate rules with modified parameters running simultaneously adds unnecessary complexity and could cause conflicts or confusion in tracking which remediation actually corrected issues.

  • Enabling automatic remediation on non-critical resources first still risks unintended changes without first understanding what the remediation action will do, and the definition of 'non-critical' can be subjective and risky.

Question 2

A global logistics company operates a container tracking system built on AWS that ingests telemetry data from 50,000 IoT devices deployed across shipping vessels worldwide. The system uses Amazon Kinesis Data Streams for ingestion, AWS Lambda for processing, and Amazon DynamoDB for storage. The operations team has configured CloudWatch alarms on individual Lambda function metrics including duration, errors, and concurrent executions. However, during a recent incident where shipment tracking data was delayed by 4 hours, the team discovered that while all individual component alarms remained in OK state, the end-to-end data processing latency had degraded significantly because multiple components experienced minor performance degradations that compounded across the pipeline. The team needs to implement a monitoring strategy that detects scenarios where the cumulative effect of minor degradations across multiple services results in unacceptable end-to-end latency, while avoiding alert fatigue from individual component metrics. The solution must support automated scaling decisions based on pipeline health. Which monitoring architecture should the Solutions Architect implement?

Correct Answer: Create CloudWatch metric math expressions that calculate composite scores by combining weighted metrics from Kinesis iterator age, Lambda duration percentiles, and DynamoDB consumed capacity, then configure alarms on these calculated metrics with anomaly detection bands to identify when the aggregate pipeline health deviates from baseline patterns

The correct answer involves creating CloudWatch metric math expressions that calculate composite scores by combining weighted metrics from Kinesis iterator age, Lambda duration percentiles, and DynamoDB consumed capacity, then configuring alarms on these calculated metrics with anomaly detection bands.

This solution directly addresses the core problem: detecting when multiple minor degradations across the pipeline compound to create unacceptable end-to-end latency. Here's why this is the best approach:

  1. Metric Math Expressions: CloudWatch metric math allows you to combine metrics from multiple services into a single calculated metric. This enables creation of a composite 'pipeline health score' that considers contributions from all components simultaneously.

  2. Weighted Metrics: By weighting the contributions from Kinesis iterator age (which indicates ingestion backlog), Lambda duration (processing time), and DynamoDB consumed capacity (storage bottlenecks), you can create a meaningful aggregate that reflects actual pipeline health.

  3. Anomaly Detection Bands: Rather than setting static thresholds, anomaly detection learns baseline patterns and alerts when the aggregate deviates abnormally. This catches the scenario described where individual components are within normal ranges but the combination is problematic.

  4. Native Integration: This approach uses native CloudWatch capabilities, enabling seamless integration with Auto Scaling policies and EventBridge for automated scaling decisions.

The Prometheus/Grafana solution, while capable of metric aggregation, introduces additional infrastructure complexity and operational overhead. It's better suited for containerized workloads and doesn't provide the same native AWS integration for automated scaling decisions.

The X-Ray with Synthetics approach focuses on tracing and synthetic testing rather than real-time metric aggregation. X-Ray traces individual requests but doesn't naturally aggregate into pipeline-wide health metrics. Additionally, injecting synthetic records every minute may not catch all degradation patterns in a 50,000 device system.

The Container Insights approach is technically flawed because Container Insights is designed for containerized applications (ECS/EKS), not Lambda functions. Lambda has its own enhanced monitoring capabilities. Furthermore, triggering automations based on 'visual thresholds' in dashboards is not a valid CloudWatch capability - you cannot programmatically trigger actions from dashboard widget appearances.

Question 3

In chaos engineering methodology, what does the term 'blast radius' specifically refer to?

Correct Answer: The scope and boundary of potential impact that a chaos experiment may cause to systems and users

In chaos engineering methodology, 'blast radius' specifically refers to the scope and boundary of potential impact that a chaos experiment may cause to systems and users. This is a fundamental concept in chaos engineering that helps teams understand and control the extent of disruption an experiment might create.

The blast radius concept is crucial for implementing chaos engineering safely. It encompasses:
- Which systems, services, or components could be affected
- How many users might experience degraded service
- The severity of potential impact
- The containment boundaries for the experiment

Starting with a small blast radius (like testing on a single instance or small percentage of traffic) and gradually expanding it is a best practice in chaos engineering. This allows teams to validate their hypotheses while minimizing risk to production systems and end users.

The other answers are incorrect because:

  • Geographic distribution of AWS resources is not what blast radius refers to. While experiments may involve resources across regions, blast radius is about impact scope, not physical location.

  • The rate of failure propagation describes cascade behavior, which is something you might observe during an experiment, but it's not the definition of blast radius. Blast radius is about the predetermined boundary of impact, not the speed of failure spread.

  • Maximum experiment duration refers to time-based limits or stop conditions, which is a separate concept in chaos engineering typically called 'experiment duration' or 'abort conditions,' not blast radius.

More Continuous Improvement for Existing Solutions questions
2217 questions (total)
Start 100 question test