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).

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 CloudFormationInfrastructure as Code (IaC)CI/CD pipelines on AWSAWS CodePipelineAWS CodeBuildAWS CodeDeployChange management processesAWS Systems ManagerConfiguration management toolsApplication upgrade paths for new servicesDeployment strategies with rollback mechanismsBlue/green deploymentsCanary deploymentsRolling deploymentsAdopting managed servicesDelegating complex tasks to AWSRoute 53 routing methodsRoute 53 health checksDisaster recovery scenariosBackup and restore DR strategyConfiguring DR solutionsData replication strategiesDatabase replication configurationDR testing proceduresAutomated backup solutionsMulti-AZ backup architecturesCross-Region backup strategiesApplication and infrastructure availabilityCentralized monitoring for recoveryEncryption options for data at restEncryption options for data in transitAWS service endpointsCredential management servicesAWS Secrets ManagerAWS ShieldAWS WAFAmazon GuardDutyPrinciple of least privilege accessSecurity group rules designNetwork ACL rules designAttack mitigation strategiesDDoS protection strategiesService endpoint securityPatch management strategiesCompliance with organizational standardsAWS storage services and replicationAmazon S3 replicationAmazon RDS replicationAmazon ElastiCache replicationMulti-AZ architecturesMulti-Region architecturesAuto scaling policies and eventsAmazon SNSAmazon SQSAWS Step FunctionsService quotas and limitsHighly available application designDesigning for failureLoosely coupled dependenciesApplication failover mechanismsDatabase failover mechanismsRoute 53 latency-based routingRoute 53 geolocation routingRoute 53 failover routingPerformance monitoring technologiesAmazon CloudWatchAWS storage optionsEC2 instance families and use casesPurpose-built databasesLarge-scale application architecture designElastic architecture designCaching strategies for performanceBuffering and queuing patternsRead replicas for performancePurpose-built service selectionRightsizing strategiesAWS cost and usage monitoringPricing models comparisonStorage tiering strategiesData transfer cost optimizationAWS managed service cost benefitsInfrastructure rightsizing for costData transfer modelingExpenditure 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
2404 questions (total)
Start 100 question test