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

Design for New Solutions

Design deployment strategies, business continuity solutions, security controls, reliability, performance objectives, and cost optimization strategies (~29% of exam).

Covers designing deployment strategies including Infrastructure as Code (CloudFormation), CI/CD pipelines, change management processes, configuration management with Systems Manager, upgrade paths for new services, deployment strategies with rollback mechanisms, and adopting managed services. Also covers business continuity including AWS Global Infrastructure, Route 53 routing methods, RTO/RPO requirements, disaster recovery scenarios (backup/restore, pilot light, warm standby, multi-site), DR solution configuration, data and database replication, DR testing, automated backup solutions, and centralized monitoring for proactive recovery. Also covers security controls including IAM, route tables, security groups, network ACLs, encryption for data at rest and in transit, service endpoints, credential management, AWS managed security services (Shield, WAF, GuardDuty, Security Hub), least privilege access, attack mitigation strategies, and patch management. Additionally covers reliability including AWS storage services, replication strategies, Multi-AZ and multi-Region architectures, auto scaling, application integration (SNS, SQS, Step Functions), service quotas, DNS routing policies, and high-availability architectures. Also covers performance objectives including monitoring technologies, storage options, instance families, purpose-built databases, large-scale architecture design, caching, buffering, replicas, and rightsizing. Finally covers cost optimization including cost monitoring tools, pricing models, storage tiering, data transfer costs, and expenditure awareness strategies.
5 minutes 5 Questions

Design for New Solutions is a critical domain in the AWS Certified Solutions Architect - Professional exam, focusing on creating scalable, resilient, and cost-effective architectures from the ground up. This domain typically represents approximately 31% of the exam content, making it the largest we…

Concepts covered: AWS CloudFormation, Infrastructure as Code (IaC), CI/CD pipelines on AWS, AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, Change management processes, AWS Systems Manager, Configuration management tools, Application upgrade paths for new services, Deployment strategies with rollback mechanisms, Blue/green deployments, Canary deployments, Rolling deployments, Adopting managed services, Delegating complex tasks to AWS, Route 53 routing methods, Route 53 health checks, Disaster recovery scenarios, Backup and restore DR strategy, Configuring DR solutions, Data replication strategies, Database replication configuration, DR testing procedures, Automated backup solutions, Multi-AZ backup architectures, Cross-Region backup strategies, Application and infrastructure availability, Centralized monitoring for recovery, Encryption options for data at rest, Encryption options for data in transit, AWS service endpoints, Credential management services, AWS Secrets Manager, AWS Shield, AWS WAF, Amazon GuardDuty, Principle of least privilege access, Security group rules design, Network ACL rules design, Attack mitigation strategies, DDoS protection strategies, Service endpoint security, Patch management strategies, Compliance with organizational standards, AWS storage services and replication, Amazon S3 replication, Amazon RDS replication, Amazon ElastiCache replication, Multi-AZ architectures, Multi-Region architectures, Auto scaling policies and events, Amazon SNS, Amazon SQS, AWS Step Functions, Service quotas and limits, Highly available application design, Designing for failure, Loosely coupled dependencies, Application failover mechanisms, Database failover mechanisms, Route 53 latency-based routing, Route 53 geolocation routing, Route 53 failover routing, Performance monitoring technologies, Amazon CloudWatch, AWS storage options, EC2 instance families and use cases, Purpose-built databases, Large-scale application architecture design, Elastic architecture design, Caching strategies for performance, Buffering and queuing patterns, Read replicas for performance, Purpose-built service selection, Rightsizing strategies, AWS cost and usage monitoring, Pricing models comparison, Storage tiering strategies, Data transfer cost optimization, AWS managed service cost benefits, Infrastructure rightsizing for cost, Data transfer modeling, Expenditure and usage awareness

Test mode:
Start practice test
SAP-C02 - Design for New Solutions Example Questions

Test your knowledge of Design for New Solutions

Question 1

A biotechnology research company is building a collaborative research platform where scientists across multiple global laboratories share experimental results, research papers, and molecular structure data. The platform must support complex queries such as finding all researchers who have collaborated with a specific scientist within three degrees of separation, identifying research papers that cite common sources and share similar molecular compounds, and discovering potential collaboration opportunities based on overlapping research interests. The data model consists of researchers, publications, experiments, molecular structures, and funding sources with intricate many-to-many relationships. Initial queries using their PostgreSQL database with multiple JOIN operations are timing out after 30 seconds when traversing more than two relationship levels. The company needs query response times under 500 milliseconds for relationship traversals up to six levels deep, while maintaining ACID compliance for data updates. The solution should integrate with their existing AWS infrastructure and support both SPARQL and Apache TinkerPop Gremlin query languages for flexibility. Which AWS database architecture should the solutions architect recommend?

Correct Answer: Deploy Amazon Neptune as the primary database engine to store and query the highly connected research data, using Neptune's native graph storage and optimized traversal algorithms to efficiently navigate multi-level relationships between researchers, publications, and molecular structures with sub-second response times.

Amazon Neptune is the correct solution for this biotechnology research platform scenario. Here's why:

Why Neptune is the Best Choice:

  1. Purpose-Built Graph Database: Neptune is specifically designed to store and query highly connected data with billions of relationships. It uses native graph storage optimized for traversing relationships, which directly addresses the requirement of navigating six levels of relationship depth.

  2. Query Language Support: Neptune natively supports both SPARQL (for RDF graphs) and Apache TinkerPop Gremlin (for property graphs), which is explicitly required in the scenario.

  3. Performance for Graph Traversals: Neptune's graph algorithms are optimized for multi-hop traversals (like finding researchers within three degrees of separation), providing sub-second response times even for complex relationship queries that traditional relational databases struggle with.

  4. ACID Compliance: Neptune provides full ACID transactions, meeting the requirement for data integrity during updates.

  5. AWS Integration: As a fully managed AWS service, it integrates seamlessly with existing AWS infrastructure.

Why Other Options Are Not Suitable:

Amazon DocumentDB: While DocumentDB offers $graphLookup for basic graph-like queries, it's fundamentally a document database. The $graphLookup stage has performance limitations for deep traversals (typically practical for 2-3 levels), and it doesn't natively support SPARQL or Gremlin query languages as required.

Amazon Aurora PostgreSQL with Apache AGE: Although AGE adds graph capabilities to PostgreSQL, this is essentially trying to fix the existing PostgreSQL problem with extensions. Recursive CTEs and materialized views add complexity and may not achieve the required sub-500ms performance for six-level traversals. It also doesn't natively support the required SPARQL and Gremlin query languages.

Amazon OpenSearch Service: OpenSearch is a search and analytics engine, not a graph database. Simulating graph traversals through denormalized documents and nested queries is inefficient for deep relationship traversals. It's not designed for complex multi-hop relationship queries and doesn't support SPARQL or Gremlin. Additionally, OpenSearch doesn't provide ACID compliance required for data updates.

Question 2

When implementing the principle of least privilege in AWS IAM, what is the recommended approach for determining the appropriate permissions for a new IAM entity?

Correct Answer: Start with minimum permissions and incrementally add access based on documented operational requirements

The principle of least privilege is a fundamental security concept in AWS IAM that states users, applications, and systems should only be granted the minimum permissions necessary to perform their required tasks.

The correct approach is to start with minimum permissions and incrementally add access based on documented operational requirements. This is the recommended AWS best practice because:

  1. It minimizes the attack surface from the beginning
  2. It ensures every permission granted has a clear business justification
  3. It creates an audit trail of why specific permissions were added
  4. It prevents permission creep and over-privileged entities
  5. AWS provides tools like IAM Access Analyzer to help identify required permissions

The approach of beginning with broad permissions and restricting later is fundamentally flawed because:
- It exposes the environment to unnecessary risk during the monitoring period
- Six months of broad access could lead to significant security incidents
- It reverses the security-first mindset that least privilege requires

Assigning permissions based on job title hierarchy is problematic because:
- Job titles don't necessarily correlate with technical access requirements
- It doesn't account for the specific resources and actions needed
- Team lead recommendations may not align with actual operational needs

Granting permissions equivalent to similar roles and refining based on access denied errors is reactive rather than proactive:
- It assumes existing roles have appropriate permissions (they may be over-privileged)
- Waiting for access denied errors can impact operations
- It doesn't ensure intentional, documented permission decisions

Question 3

A multinational pharmaceutical company operates a clinical trial management system behind Amazon CloudFront with Application Load Balancer origins in us-east-1, eu-west-1, and ap-southeast-1. The system allows researchers from partner institutions to submit trial data through authenticated API endpoints. The security team has discovered a sophisticated attack pattern where adversaries are exploiting their /api/trials/data endpoint by crafting requests that pass initial AWS Managed Rules inspection but contain deeply nested JSON payloads with recursive structures designed to exhaust backend parsing resources. These payload bombs have JSON nesting depths exceeding 500 levels and array sizes over 10,000 elements within the 'trialResults' field. The attacks cause Lambda function timeouts and elevated costs due to extended execution times. Standard SQL injection and XSS rules do not detect these payloads because they contain no malicious code patterns - only legitimate JSON characters arranged to maximize computational complexity. The company needs to implement AWS WAF protection that can evaluate the structural characteristics of JSON request bodies and block requests exceeding safe complexity thresholds before they reach the application tier. Their existing architecture uses CloudWatch for monitoring and requires that any solution maintain consistent protection across all three regions. Which AWS WAF configuration approach should the security architect implement to mitigate these JSON complexity attacks?

Correct Answer: Create a custom rule using body size constraints combined with AWS WAF's request body inspection limits, configure the web ACL to block requests where the body exceeds a defined byte threshold, and deploy the web ACL to CloudFront for global protection across all regional origins

The correct answer involves creating a custom rule using body size constraints combined with AWS WAF's request body inspection limits, configuring the web ACL to block requests where the body exceeds a defined byte threshold, and deploying the web ACL to CloudFront for global protection across all regional origins.

This is the best solution for several reasons:

  1. Body Size Constraints: AWS WAF allows you to create size constraint rules that can limit the request body size. While this doesn't directly measure JSON nesting depth, large deeply-nested JSON structures with 500+ levels of nesting and 10,000+ element arrays will inevitably result in larger payload sizes. Setting appropriate body size thresholds provides a practical defense against these payload bombs.

  2. CloudFront-Level Protection: Deploying the web ACL at CloudFront provides global, consistent protection across all three regional origins (us-east-1, eu-west-1, and ap-southeast-1) with a single web ACL configuration. This meets the requirement for consistent protection across all regions without managing multiple regional web ACLs.

  3. Early Inspection: WAF at CloudFront inspects and blocks malicious requests before they reach the Application Load Balancers or Lambda functions, preventing the resource exhaustion and elevated costs.

The other options are incorrect:

Bot Control managed rule group is designed to detect and manage bot traffic based on behavioral patterns and fingerprinting, not to analyze JSON structural complexity. It cannot evaluate nesting depths or array sizes within JSON payloads.

Lambda@Edge with CloudWatch alarms approach is flawed because Lambda@Edge would suffer from the same resource exhaustion problem - parsing deeply nested JSON to calculate complexity metrics would cause the Lambda@Edge function to timeout or exhaust resources. Additionally, AWS WAF cannot reference Lambda function evaluation results for blocking decisions in this manner.

ATP (Account Takeover Prevention) managed rule group is designed specifically for credential stuffing and account takeover attacks, not JSON payload complexity analysis. Rate-based rules track request counts per IP, not 'complexity scores' - AWS WAF doesn't have a native complexity scoring mechanism. Managing synchronized regional web ACLs is also operationally complex compared to a single CloudFront web ACL.

More Design for New Solutions questions
2505 questions (total)
Start 100 question test