AWS Solutions Architect – Professional (SAP-C02) — Free Sample Questions
Challenge yourself with 30 free Professional-level sample questions. SAP-C02 is one of the hardest AWS exams, requiring deep knowledge of multi-account architectures, hybrid networking, and enterprise migration strategies.
Exam Domains
- Design Solutions for Organizational Complexity (26%) — AWS Organizations, multi-account governance, cross-account access, Control Tower
- Design for New Solutions (29%) — event-driven architectures, microservices, serverless at scale, data lake design
- Continuous Improvement for Existing Solutions (25%) — cost optimization, performance tuning, reliability improvements, migration from monolith
- Accelerate Workload Migration and Modernization (20%) — 7 Rs of migration, database migration strategies, VMware Cloud on AWS, containerization
Why SAP-C02 Is Harder Than SAA-C03
Professional questions are longer (often 200+ words), involve multiple AWS accounts, and require you to satisfy 4-5 constraints simultaneously. The exam expects you to:
- Design cross-region, cross-account architectures with least-privilege access
- Choose between Direct Connect, Site-to-Site VPN, and Transit Gateway for hybrid connectivity
- Optimize costs across Reserved Instances, Savings Plans, and Spot at enterprise scale
- Plan phased migrations preserving availability during cutover
Preparation Strategy
- Master AWS Organizations: SCPs, delegated administrators, consolidated billing
- Understand Transit Gateway routing, peering, and multicast
- Study disaster recovery: pilot light, warm standby, multi-site active-active
- Know database migration: DMS, SCT, heterogeneous migrations, zero-downtime approaches
Continue Practicing
Access 600 SAP-C02 questions in 30 quizzes and 2 full-length 75-question practice exams with detailed domain-mapped explanations.
All 30 Free Sample Questions
Question 1 — Domain 1: Design Solutions for Organizational Complexity
A financial services company has a hybrid architecture with on-premises data centers connected to AWS via AWS Direct Connect. The company has 20 VPCs across multiple AWS accounts in the same Region. On-premises applications must resolve DNS queries for resources in all AWS VPCs, and AWS resources must resolve DNS queries for on-premises private domains. The solution must minimize management overhead and support future VPC additions without reconfiguration. What is the MOST efficient solution?
- Configure VPC DNS settings to use on-premises DNS servers as custom DNS resolvers
- Deploy DNS servers on EC2 instances in each VPC and configure conditional forwarders to on-premises DNS servers
- Configure Route 53 Resolver inbound and outbound endpoints in a central VPC, share the resolver rules using AWS Resource Access Manager, and configure forwarding rules for on-premises domains — Correct answer
- Use Route 53 private hosted zones associated with all VPCs and configure on-premises DNS servers to forward queries to Route 53 public resolvers
Explanation:
- Why correct (C): Route 53 Resolver endpoints provide centralized hybrid DNS resolution. Inbound endpoints allow on-premises to query AWS resources. Outbound endpoints with forwarding rules enable AWS resources to query on-premises domains. Sharing resolver rules via RAM eliminates the need to deploy endpoints in every VPC. This solution scales automatically as new VPCs are added and minimizes management overhead.
- Why A is wrong: Using on-premises DNS servers as custom DNS resolvers for VPCs breaks AWS service integrations that rely on the VPC DNS resolver (e.g., VPC endpoints, ECS service discovery). This approach also creates a dependency on on-premises infrastructure for AWS-internal DNS resolution, introducing latency and a potential single point of failure.
- Why B is wrong: Deploying and managing DNS servers on EC2 in every VPC creates significant operational overhead. This approach requires manual configuration for each new VPC and does not scale efficiently. EC2-based DNS servers also introduce additional costs and maintenance requirements (patching, monitoring, high availability).
- Why D is wrong: Route 53 public resolvers cannot resolve private on-premises domains. Private hosted zones handle AWS-side resolution but do not provide a mechanism for AWS resources to resolve on-premises private domains. This solution only addresses one direction of the bidirectional DNS requirement.
Question 2 — Domain 1: Design Solutions for Organizational Complexity
A healthcare organization stores patient records in Amazon S3 with strict HIPAA compliance requirements. The organization must ensure that all S3 buckets containing patient data are never made public and that any attempt to make buckets public is automatically blocked. The solution must work across 50 AWS accounts. Which approach provides the MOST effective protection?
- Use IAM policies to prevent users from making buckets public
- Enable Amazon Macie to detect public S3 buckets and send alerts
- Enable S3 Block Public Access at the account level for all accounts and use AWS Organizations SCPs to prevent disabling Block Public Access — Correct answer
- Use S3 bucket policies to deny public access and enable AWS Config rules to detect public buckets
Explanation:
- Why C is correct: S3 Block Public Access at the account level is a single toggle that overrides any bucket policy or ACL that would grant public access. It prevents all buckets in the account from being made public regardless of individual bucket settings. Organizations SCPs can include a deny statement for s3:PutAccountPublicAccessBlock with a condition that prevents disabling Block Public Access. This provides defense-in-depth: even if an administrator has full S3 permissions, the SCP prevents them from removing the account-level protection.
- Why A is wrong: IAM policies can be complex to manage across 50 accounts and may have gaps. Users with sufficient permissions (including the account root user) could modify or delete IAM policies. IAM policies alone do not provide the same level of protection as S3 Block Public Access, which is a purpose-built, account-level control specifically designed to prevent public bucket access.
- Why B is wrong: Amazon Macie discovers and classifies sensitive data and can detect publicly accessible buckets, but it is a detective control — it alerts after a bucket is already public. Macie does not prevent buckets from being made public in the first place. The requirement is to automatically block attempts, not just detect them.
- Why D is wrong: S3 bucket policies can be modified or deleted by users with sufficient IAM permissions, potentially re-enabling public access. AWS Config rules detect non-compliant configurations after they occur but do not prevent them. This approach is reactive (detect-and-alert) rather than preventive (block-the-action). Block Public Access with SCPs provides stronger, preventive protection.
Question 3 — Domain 1: Design Solutions for Organizational Complexity
Select TWO. A healthcare organization operates a patient portal that must maintain 99.95% availability. The application runs on EC2 instances behind an Application Load Balancer in us-east-1. The company wants to improve resilience against AZ and Region failures. Which TWO architectural improvements provide the MOST significant availability gains?
- Implement CloudWatch alarms for monitoring
- Use larger EC2 instance types for better performance
- Enable Auto Scaling to maintain minimum instance count
- Deploy instances across multiple Availability Zones with ALB health checks — Correct answer
- Deploy a secondary environment in us-west-2 with Route 53 health checks and failover routing — Correct answer
- Use Spot Instances to reduce costs
Explanation:
- Why correct: Multi-AZ deployment (D) protects against AZ failures by distributing instances across isolated infrastructure. The ALB automatically routes traffic only to healthy instances in available AZs. Multi-Region deployment with Route 53 failover (E) protects against Region-level failures by maintaining a secondary environment that can serve traffic if the primary Region becomes unavailable. Together, these address both AZ and Region failure scenarios, significantly improving availability toward 99.95%.
- Why A is wrong: CloudWatch alarms provide visibility and alerting but do not improve availability by themselves. Alarms are detective controls that notify operators of issues; they do not prevent or automatically recover from AZ or Region failures. Monitoring is necessary but not sufficient for improving availability.
- Why B is wrong: Larger instance types improve per-instance performance capacity but do not protect against AZ or Region failures. If the AZ hosting a large instance fails, the application is still unavailable. Availability is improved through redundancy and failover across fault-isolation boundaries, not by increasing instance size.
- Why C is wrong: Auto Scaling maintains desired capacity and replaces unhealthy instances, but it must be combined with multi-AZ deployment to provide AZ-level resilience. Auto Scaling within a single AZ does not protect against AZ failure. While valuable, Auto Scaling alone is not one of the two most significant improvements for AZ and Region resilience.
- Why F is wrong: Spot Instances can be reclaimed by AWS with a two-minute warning, which directly reduces availability. For a patient portal requiring 99.95% uptime, Spot Instances introduce unacceptable interruption risk and are inappropriate for the application tier.
Question 4 — Domain 1: Design Solutions for Organizational Complexity
Select TWO. A technology company operates 80 AWS accounts with workloads in multiple Regions. The company requires centralized logging and monitoring across all accounts and Regions. Which TWO services should be configured organization-wide?
- AWS CloudTrail organization trail for centralized API logging across all accounts and Regions — Correct answer
- Amazon CloudWatch with cross-account log aggregation for centralized monitoring — Correct answer
- AWS X-Ray in each account for distributed tracing
- AWS CodePipeline for deployment automation
- Amazon GuardDuty for threat detection
- AWS Systems Manager in each account for patch management
Explanation:
- Why correct: CloudTrail organization trail automatically collects API logs from all accounts and Regions into a centralized S3 bucket. CloudWatch with cross-account log aggregation enables centralized monitoring of metrics and logs from all accounts through cross-account observability. Together, these two services provide comprehensive centralized logging and monitoring across the multi-account environment.
- Why C is wrong: AWS X-Ray is an application-level distributed tracing service used to analyze and debug specific application requests. It does not provide broad centralized logging or monitoring of all account activity and is not designed for organization-wide audit visibility.
- Why D is wrong: AWS CodePipeline is a CI/CD service for automating build, test, and deploy workflows. It has no role in centralized logging or monitoring of account activity.
- Why E is wrong: Amazon GuardDuty is a threat detection service that analyzes CloudTrail, VPC Flow Logs, and DNS logs for malicious activity. While valuable for security, it is not a general-purpose logging or monitoring service.
- Why F is wrong: AWS Systems Manager provides operational management capabilities like patch management and parameter storage. It does not provide centralized log aggregation or cross-account monitoring.
Question 5 — Domain 1: Design Solutions for Organizational Complexity
Select TWO. An e-commerce company operates EC2-based web applications with variable traffic patterns. The company wants to optimize compute costs while maintaining performance. Which TWO strategies provide the BEST cost optimization?
- Run all instances 24/7 regardless of traffic
- Use Spot Instances for all production workloads
- Use Compute Savings Plans for baseline capacity with On-Demand for variable capacity — Correct answer
- Use only the largest instance types for better performance
- Disable Auto Scaling to maintain fixed capacity
- Use Auto Scaling to match capacity to demand, eliminating over-provisioning — Correct answer
Explanation:
- Why correct (C and F): Auto Scaling automatically adjusts capacity based on demand, eliminating costs from over-provisioned resources during low-traffic periods. Compute Savings Plans provide up to 66% savings for baseline capacity while On-Demand handles variable traffic spikes. Together, these strategies optimize costs for variable workloads by committing to known baseline usage and dynamically scaling for everything else.
- Why A is wrong: Running instances 24/7 regardless of traffic wastes costs during low-traffic periods. For a variable-traffic e-commerce application, matching capacity to actual demand through Auto Scaling provides far better cost efficiency.
- Why B is wrong: Spot Instances can be interrupted with a 2-minute warning, making them unsuitable for customer-facing production web applications that require consistent availability. Spot is appropriate for fault-tolerant batch workloads, not primary production serving capacity.
- Why D is wrong: Larger instance types are more expensive per hour and do not optimize costs. Right-sizing instances to actual performance needs is a key cost optimization principle. Oversized instances also create a larger blast radius during failures.
- Why E is wrong: Disabling Auto Scaling forces fixed capacity, leading to over-provisioning during low traffic (wasted cost) and under-provisioning during high traffic (degraded performance). Auto Scaling is essential for cost optimization with variable workloads.
Question 6 — Domain 1: Design Solutions for Organizational Complexity
A company has 30 AWS accounts managed through AWS Organizations. Employees authenticate through Okta as their corporate identity provider. The security team needs to provide federated access to AWS accounts with centralized permission management. Which approach meets these requirements with the LEAST operational overhead?
- Create IAM users in each account that match corporate identities and manage passwords with AWS Secrets Manager
- Configure SAML 2.0 federation with IAM roles individually in each of the 30 accounts
- Use Amazon Cognito user pools federated with Okta and map groups to IAM roles in each account
- Configure AWS IAM Identity Center with Okta as an external identity provider and use permission sets to manage access across accounts — Correct answer
Explanation:
- Why correct: IAM Identity Center (successor to AWS SSO) integrates with external SAML 2.0 identity providers such as Okta, enabling federated access. Permission sets define the IAM roles and policies users receive in each target account. This provides centralized, scalable access management across all AWS accounts in the organization without creating IAM users in each account.
- Why A is wrong: Creating individual IAM users in each account defeats federation and centralized management. This approach is not scalable for 30 accounts, forces password management per account, and does not integrate with the corporate IdP. It also violates the principle of centralized identity management.
- Why B is wrong: While IAM SAML federation (identity provider + IAM roles) works for a single account, managing 30 separate SAML configurations and role mappings per account is operationally complex. IAM Identity Center centralizes this and natively supports multi-account access with permission sets, making it the better choice at scale.
- Why C is wrong: Amazon Cognito is designed for customer-facing application authentication (web/mobile apps), not for managing employee access to AWS accounts and the AWS Management Console. It does not provide multi-account AWS Console access or integration with AWS Organizations.
Question 7 — Domain 2: Design for New Solutions
Select TWO. A company has separate AWS accounts for development, staging, and production. The development team deploys a containerized microservices application on Amazon ECS. The team wants to implement a CI/CD pipeline that automatically builds container images, runs integration tests in the staging account, and deploys to production only after manual approval. Which TWO components are essential for this pipeline?
- AWS CodePipeline with cross-account IAM roles to orchestrate build, test, and deployment stages across accounts — Correct answer
- Amazon CloudWatch Logs to trigger deployments when error rates decrease
- AWS CodeBuild to compile source code, build container images, push to Amazon ECR, and run automated tests — Correct answer
- Amazon S3 lifecycle policies to manage deployment artifacts
- AWS Trusted Advisor to validate deployment readiness
- Amazon SQS to queue deployment requests between accounts
Explanation:
- Why correct (A): AWS CodePipeline is the native CI/CD orchestration service that supports cross-account deployments through cross-account IAM roles. It can coordinate the full pipeline: source, build, test, approval, and deploy stages spanning multiple accounts. Cross-account roles allow CodePipeline in the tools account to trigger actions in dev, staging, and production accounts without sharing credentials.
- Why correct (C): AWS CodeBuild handles the build and test phases — compiling source code, building Docker container images, pushing images to Amazon ECR, and executing automated integration tests. CodeBuild is serverless and scales automatically, eliminating the need to manage build servers. It integrates natively with CodePipeline as a build and test action.
- Why B is wrong: CloudWatch Logs is a monitoring and log aggregation service. It does not trigger deployments or orchestrate CI/CD pipelines. While it can be used to monitor application behavior, it has no role in build, test, or deployment orchestration.
- Why D is wrong: S3 lifecycle policies manage object storage transitions (e.g., moving objects to Glacier after 90 days) and expiration. They do not manage deployment artifacts in a CI/CD context. While CodePipeline uses S3 to store pipeline artifacts, lifecycle policies are unrelated to deployment orchestration.
- Why E is wrong: AWS Trusted Advisor provides best-practice recommendations for cost optimization, security, fault tolerance, performance, and service limits. It does not validate deployment readiness, run tests, or participate in CI/CD workflows.
- Why F is wrong: Amazon SQS is a message queuing service for decoupling application components. While it could theoretically pass messages between accounts, it is not designed for CI/CD orchestration. CodePipeline with cross-account IAM roles is the purpose-built solution for cross-account deployments.
Question 8 — Domain 2: Design for New Solutions
A financial institution runs a mission-critical trading application on Aurora MySQL in us-east-1. The application requires an RPO of less than 1 second and an RTO of less than 1 minute for cross-region disaster recovery. The database handles 50,000 transactions per second during peak hours. Which approach meets these recovery requirements?
- Configure Aurora MySQL cross-region read replicas with Aurora Global Database, and use Route 53 failover routing to redirect traffic to the secondary Region where the read replica can be promoted to a primary cluster — Correct answer
- Use AWS Database Migration Service (DMS) for continuous replication to an Aurora MySQL cluster in us-west-2 with change data capture (CDC) enabled
- Take automated Aurora snapshots every 5 minutes and copy them to us-west-2 using a Lambda function, then restore from the latest snapshot during a disaster
- Configure Aurora MySQL native binary log replication to a standalone MySQL instance on EC2 in us-west-2
Explanation:
- Why correct: Aurora Global Database provides cross-region replication with typical lag under 1 second, meeting the sub-1-second RPO. Promoting a secondary Region cluster to primary typically completes in under 1 minute, meeting the RTO requirement. Route 53 failover routing automates DNS cutover to the promoted cluster.
- Why B is wrong: DMS with CDC introduces higher and more variable replication lag than Aurora Global Database, typically several seconds or more. DMS is better suited for heterogeneous database migration scenarios, not for ultra-low RPO disaster recovery of Aurora databases.
- Why C is wrong: 5-minute snapshot intervals create a minimum 5-minute RPO, far exceeding the sub-1-second requirement. Restoring from a snapshot also takes significant time (potentially 15-30+ minutes depending on database size), failing the sub-1-minute RTO.
- Why D is wrong: Native binary log replication to a standalone MySQL on EC2 introduces variable replication lag, lacks Aurora's managed failover capabilities, and requires manual promotion and endpoint reconfiguration. This cannot reliably achieve the sub-1-minute RTO that Aurora Global Database's managed promotion provides.
Question 9 — Domain 2: Design for New Solutions
Select TWO. A company is migrating a legacy application to AWS. The application runs on EC2 instances and connects to an Amazon RDS PostgreSQL database. Currently, database credentials are hardcoded in configuration files on each server. The security team mandates that no long-term credentials should exist on any compute resource and all secrets must be automatically rotated. Which TWO actions should the solutions architect implement to meet these requirements?
- Use IAM roles attached to EC2 instance profiles instead of storing AWS access keys on instances — Correct answer
- Store credentials in environment variables on the EC2 instances
- Hardcode access keys in the application source code and rotate them annually
- Store database credentials in AWS Secrets Manager with automatic rotation enabled — Correct answer
- Create a shared IAM user and distribute the access keys to all EC2 instances
- Store credentials in an unencrypted S3 bucket accessible by the application
Explanation:
- Why correct (A, D): IAM roles for EC2 instances eliminate the need to store long-term access keys on the instance. The instance profile delivers temporary credentials that are automatically rotated by STS, reducing the risk of credential compromise. AWS Secrets Manager with automatic rotation stores database credentials securely and rotates them on a schedule without manual intervention, using managed rotation for RDS. Together, these ensure no static credentials exist in the environment.
- Why B is wrong: Storing credentials in environment variables on the instance exposes them to any process or user on the instance. Environment variables can be read from /proc and are visible in process listings. This is not a secure credential management approach.
- Why C is wrong: Hardcoded access keys in application code are a critical security anti-pattern. Keys committed to source control can be leaked, and rotating them requires code changes and redeployment. IAM roles eliminate this risk entirely.
- Why E is wrong: Shared IAM user credentials across instances violate least privilege and make auditing impossible since all actions appear as the same identity. IAM roles provide per-instance identity with temporary credentials.
- Why F is wrong: Storing credentials in an unencrypted S3 bucket exposes them to anyone with bucket access. Even with S3 encryption, this approach lacks rotation and lifecycle management that Secrets Manager provides natively.
Question 10 — Domain 2: Design for New Solutions
A company operates a customer-facing application across two AWS Regions in an active-passive configuration. The primary Region handles all production traffic. The company wants to automate failover to the secondary Region with minimal downtime and ensure users are routed to the healthy Region. The application is stateful and uses a relational database. Which approach provides automated failover with the LEAST operational overhead?
- Configure Route 53 latency-based routing with health checks pointing to ALBs in both Regions. Use Amazon Aurora Global Database with write forwarding enabled in the secondary Region. — Correct answer
- Configure Route 53 simple routing to the primary Region ALB. Create a CloudWatch alarm that triggers a Lambda function to update the DNS record to the secondary Region when the primary becomes unhealthy.
- Configure Route 53 weighted routing with 100% weight on the primary Region. Manually update the weight to 0 during a failure event and set the secondary Region weight to 100%.
- Configure Amazon CloudFront with the primary Region ALB as the origin. Set up CloudFront origin failover with the secondary Region ALB as the failover origin.
Explanation:
- Why correct (A): Route 53 latency-based routing with health checks automatically routes traffic to the healthy, lowest-latency endpoint. If the primary Region fails health checks, Route 53 automatically directs traffic to the secondary Region with no manual intervention. Aurora Global Database provides cross-Region replication with sub-second lag. Write forwarding is useful during normal operations because it lets the secondary Region handle occasional writes by forwarding them to the primary, reducing application complexity. During an actual Regional failover, the secondary cluster would be promoted to a standalone primary to accept writes directly. This combination provides automated traffic failover with minimal operational overhead.
- Why B is wrong: Lambda-based DNS updates introduce additional latency and complexity. Route 53 health checks natively support failover without custom automation. Custom Lambda functions add operational burden and potential failure points. If the Lambda function itself fails or is throttled, the failover does not occur.
- Why C is wrong: Manual weight updates require human intervention, increasing RTO. This does not meet the requirement for automated failover. During off-hours, manual intervention may be significantly delayed.
- Why D is wrong: CloudFront origin failover works well for static content and stateless applications, but it operates at the HTTP layer and does not address the database layer failover needed for a stateful relational application. CloudFront origin failover triggers on 5xx errors or timeouts from the primary origin, which may not cover all application-level failure modes.
Question 11 — Domain 3: Continuous Improvement for Existing Solutions
A healthcare organization operates an application with slow ALB response times. CloudWatch metrics show high target response time. Which approach improves ALB performance?
- Reduce number of targets
- Disable health checks
- Increase ALB idle timeout without backend optimization
- Optimize backend target performance, implement connection draining for graceful scaling, use appropriate health check intervals, and enable HTTP/2 for better performance — Correct answer
Explanation:
- Why correct: Backend optimization reduces target response time. Connection draining enables graceful scaling without dropped connections. Appropriate health checks ensure traffic goes to healthy targets. HTTP/2 provides better performance through multiplexing. This approach addresses both backend and ALB configuration for optimal performance.
- Why A is wrong: Increasing idle timeout does not reduce response time; it only allows longer waits. Backend optimization is required to reduce response time. Timeout does not address root cause.
- Why B is wrong: Reducing targets when performance is poor will worsen performance by overloading remaining targets. More targets may be needed for better load distribution. This approach makes performance worse.
- Why C is wrong: Disabling health checks allows traffic to unhealthy targets, worsening performance and reliability. Health checks are essential for routing traffic to healthy targets. This approach reduces reliability.
Question 12 — Domain 2: Design for New Solutions
A company runs a predictable, steady-state web application on c5.xlarge EC2 instances 24/7 and commits to running the workload for at least 3 years. A separate team runs batch analytics jobs that can use any instance family and run across multiple Regions. Which pricing strategy minimizes cost for BOTH workloads?
- On-Demand Instances for all workloads to maintain flexibility
- EC2 Instance Savings Plans for the web application and Compute Savings Plans for the analytics jobs — Correct answer
- 3-year All Upfront Reserved Instances for both workloads using the same instance family
- Spot Instances for both workloads
Explanation:
- Why B is correct: EC2 Instance Savings Plans offer the deepest discount (up to 72%) for the web application because the company commits to a specific instance family (c5) in a specific Region, which matches their fixed workload. Compute Savings Plans offer flexibility across instance families, Regions, and operating systems — ideal for the analytics jobs that vary across families and Regions. This combination matches each discount model to its workload profile.
- Why A is wrong: On-Demand provides maximum flexibility but zero discount. For workloads with 3-year commitments and predictable usage, On-Demand is the most expensive option. It fails the cost minimization objective.
- Why C is wrong: Reserved Instances for a single instance family cannot cover the analytics workload that uses varying instance families and Regions. Standard RIs are tied to a specific instance type, Region, and platform. This leaves the analytics jobs at full On-Demand pricing.
- Why D is wrong: Spot Instances can be interrupted with 2 minutes notice. The steady-state web application needs continuous availability and cannot tolerate interruptions. Spot is appropriate for the fault-tolerant analytics jobs but not for a production web application.
Question 13 — Domain 2: Design for New Solutions
A media company stores 500 TB of video assets in Amazon S3. Access patterns show: files are accessed frequently during the first 30 days after upload, occasionally between 30 and 90 days, and rarely after 90 days. Compliance requires that all files remain retrievable within 12 hours. The company wants to minimize storage costs. Which S3 storage strategy meets these requirements?
- Keep all data in S3 Standard and rely on S3 analytics to identify cold objects manually
- Use S3 lifecycle policies to transition to S3 Standard-IA at 30 days and S3 Glacier Flexible Retrieval at 90 days — Correct answer
- Use S3 Intelligent-Tiering for all objects and disable lifecycle policies
- Move all data to S3 Glacier Deep Archive after 30 days with bulk retrieval enabled
Explanation:
- Why A is wrong: S3 Standard for everything ignores the clear access pattern tiers. After 30 days, most files are rarely accessed, so Standard pricing wastes money on storage that could use cheaper tiers.
- Why B is correct: S3 lifecycle policies automate transitions based on the known access patterns. Standard handles the high-access first 30 days. Standard-IA is cheaper for infrequent access (30-90 days) with per-GB retrieval fees that are acceptable for occasional access. Glacier Flexible Retrieval at 90 days provides low-cost archival with retrieval within 3-5 hours, meeting the 12-hour retrieval SLA. This tiered approach optimizes cost for each phase.
- Why C is wrong: S3 Intelligent-Tiering works well when access patterns are unpredictable, but here the patterns are well-known and predictable. Intelligent-Tiering charges a monthly monitoring fee per object, which at 500 TB with millions of objects adds unnecessary cost compared to deterministic lifecycle rules.
- Why D is wrong: Glacier Deep Archive has a retrieval time of up to 48 hours for bulk retrieval, which violates the 12-hour retrieval requirement. While it is the cheapest option, it does not meet the compliance constraint.
Question 14 — Domain 3: Continuous Improvement for Existing Solutions
A company runs a stateful application on Amazon EC2 instances with Amazon EBS volumes. The current backup process consists of manual weekly EBS snapshots, giving a 7-day RPO. The business now requires an RPO of 1 hour or less with cross-Region disaster recovery capability. Which approach meets the RPO requirement with the LEAST operational overhead?
- Increase EBS volume size to improve durability and reduce the likelihood of data loss during failures
- Use Amazon Data Lifecycle Manager with an hourly EBS snapshot schedule, enable cross-Region snapshot copy rules, and tag snapshots for lifecycle management — Correct answer
- Create an Amazon Machine Image of each instance daily and store the AMIs in the secondary Region
- Enable EBS Multi-Attach on io2 volumes so that data exists on multiple instances simultaneously for redundancy
Explanation:
- Why B is correct: Amazon Data Lifecycle Manager automates EBS snapshot creation on a schedule as frequent as every hour, directly achieving the 1-hour RPO. Cross-Region copy rules automatically replicate snapshots to the DR Region without manual intervention. Tag-based lifecycle policies handle retention and cleanup, minimizing operational overhead.
- Why A is wrong: Increasing EBS volume size affects storage capacity, not backup frequency or RPO. EBS volumes already provide 99.999% durability within a single AZ. Volume size has no effect on how often data is backed up or whether backups are copied cross-Region.
- Why C is wrong: Daily AMIs provide a 24-hour RPO at best, which does not meet the 1-hour RPO requirement. AMIs also capture the entire instance image including the OS and application binaries, making them slower to create and larger to store than incremental EBS snapshots.
- Why D is wrong: EBS Multi-Attach allows multiple EC2 instances in the same AZ to access a single io2 volume concurrently. It does not create redundant copies of data, does not work cross-AZ or cross-Region, and does not replace backups. If the volume is corrupted or the AZ fails, all attached instances lose access.
Question 15 — Domain 3: Continuous Improvement for Existing Solutions
A technology company operates 200 AWS accounts in an AWS Organization. A security review revealed that many IAM roles have overly broad permissions, and some S3 buckets are unintentionally shared with external accounts. The security team needs to continuously audit for least privilege violations and external resource access across all accounts. Which approach is MOST effective?
- Manually review all IAM policies in each account on a quarterly schedule and document findings in a spreadsheet
- Use the IAM policy simulator to test each policy individually across all accounts and flag over-permissive policies
- Enable IAM Access Analyzer at the organization level to identify external access and generate least-privilege policy recommendations from CloudTrail activity — Correct answer
- Restrict all IAM policies to explicit deny by default and require teams to submit exception requests for each API action
Explanation:
- Why correct: IAM Access Analyzer continuously monitors resource policies (S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues) to identify resources shared with external principals outside the AWS Organization. It also validates IAM policies against best practices and generates least-privilege policy suggestions based on CloudTrail activity. At the organization level, it provides a centralized view across all 200 accounts, making it purpose-built for auditing and enforcing least privilege at scale.
- Why A is wrong: Manually reviewing IAM policies across 200 accounts is impractical and error-prone. IAM policies are complex, context-dependent, and change frequently. Manual reviews cannot keep pace with policy changes and do not provide continuous monitoring. This approach does not scale.
- Why B is wrong: Using IAM policy simulator on individual policies tests whether specific API calls are allowed or denied, but it requires knowing which policies and actions to test. It does not proactively identify over-permissive policies or external access. At 200 accounts, testing each policy individually is impractical.
- Why D is wrong: Restricting all IAM policies to explicit deny by default would break most workloads. IAM already uses implicit deny—any action not explicitly allowed is denied. Adding explicit deny to everything is operationally destructive and does not help identify which existing policies are over-permissive.
Question 16 — Domain 3: Design Solutions for Continuous Improvement
A financial services company runs a high-performance computing application for risk modeling on 200 tightly coupled EC2 instances. The application performs frequent inter-node communication using MPI and requires the lowest possible network latency between nodes. Intermediate computation results must be shared across all nodes with high throughput. Which architecture meets these performance requirements?
- Launch the instances in a cluster placement group within a single Availability Zone, use enhanced networking with Elastic Fabric Adapter, and store intermediate results on a shared Amazon FSx for Lustre file system — Correct answer
- Launch the instances in a spread placement group across three Availability Zones with Amazon EFS for shared storage
- Launch the instances in a partition placement group and use Amazon S3 for inter-node data exchange
- Launch the instances across multiple Regions using AWS Global Accelerator to reduce inter-node latency
Explanation:
- Why correct: Cluster placement groups place instances on the same underlying hardware rack, providing the lowest network latency and highest throughput for inter-node communication. Elastic Fabric Adapter (EFA) is purpose-built for HPC and provides OS-bypass capabilities that reduce latency below what enhanced networking alone achieves — critical for MPI workloads. FSx for Lustre is a high-performance parallel file system designed for HPC that provides sub-millisecond latencies and hundreds of GB/s throughput for shared data access.
- Why B is wrong: Spread placement groups distribute instances across distinct hardware to maximize fault tolerance, which is the opposite of what tightly coupled HPC needs. Spreading across three AZs introduces cross-AZ latency (typically 1-2ms) that is unacceptable for MPI workloads requiring sub-millisecond communication. EFS provides lower throughput and higher latency than FSx for Lustre for HPC patterns.
- Why C is wrong: Partition placement groups are designed for large distributed workloads like HDFS and Cassandra where groups of instances share hardware but partitions do not. They do not optimize for the lowest inter-node latency. Using S3 for inter-node data exchange introduces latency of tens of milliseconds per request, which is far too slow for HPC intermediate results.
- Why D is wrong: Distributing instances across multiple Regions introduces latencies of 50-200ms between nodes, making tightly coupled MPI communication impossible. Global Accelerator optimizes client-to-endpoint routing, not inter-node compute communication.
Question 17 — Domain 3: Continuous Improvement for Existing Solutions
A company operates a customer-facing application in us-east-1 with a warm standby in eu-west-1. Currently, when us-east-1 becomes unhealthy, an engineer must manually update the DNS record. During the last incident, the engineer was unavailable for 40 minutes. The company requires automated failover with an RTO of 15 minutes. What should a solutions architect recommend?
- Manually update DNS records to point to the secondary Region when the primary Region fails
- Configure Route 53 health checks on the primary Region endpoint and use a failover routing policy to automatically direct traffic to the secondary Region — Correct answer
- Use Amazon CloudFront with origin failover to automatically route traffic between Regions
- Reduce the DNS TTL to 30 seconds so clients quickly switch when an administrator updates the record
Explanation:
- Why correct (B): Route 53 health checks continuously monitor endpoint health and failover routing policies automatically redirect traffic to the healthy Region when the primary fails. This provides automated multi-Region failover without manual intervention, directly addressing the 15-minute RTO.
- Why A is wrong: Manual DNS updates require human intervention, which cannot reliably meet a 15-minute RTO—especially during off-hours. Route 53 failover routing automates this process with health check evaluation every 10-30 seconds.
- Why C is wrong: CloudFront does not perform origin failover based on regional application health for dynamic content routing at the DNS level. CloudFront origin failover handles individual request failures to origins, not Region-level application failures requiring traffic redirection.
- Why D is wrong: Reducing TTL alone does not trigger failover—it only controls how long resolvers cache DNS records. Without health checks and failover routing, clients would still resolve to the failed Region's IP addresses. Low TTL combined with health checks would be useful, but TTL reduction alone is insufficient.
Question 18 — Domain 3: Continuous Improvement for Existing Solutions
A company runs steady-state workloads across EC2, AWS Fargate, and AWS Lambda. The workload composition is expected to remain stable for 3 years, but the team anticipates migrating some EC2 workloads to Fargate containers over the next year. The finance team wants to maximize savings with a single commitment that accommodates this evolution. Which pricing model is MOST appropriate?
- Purchase Standard Reserved Instances for each EC2 instance type with 3-year All Upfront payment
- Purchase a 3-year Compute Savings Plan with All Upfront payment — Correct answer
- Use On-Demand pricing with AWS Budgets alerts to monitor spending
- Purchase Convertible Reserved Instances for each instance type separately
Explanation:
- Why correct: Compute Savings Plans provide up to 66% savings (similar to Convertible RIs) and apply automatically to EC2, Fargate, and Lambda usage regardless of instance family, Region, OS, or tenancy. As the company migrates from EC2 to Fargate, the same Savings Plan commitment continues to apply — no changes needed. The 3-year All Upfront option maximizes the discount rate.
- Why A is wrong: Standard Reserved Instances are locked to a specific instance family, Region, OS, and tenancy. They apply ONLY to EC2 — not Fargate or Lambda. When the team migrates EC2 workloads to Fargate, the Standard RIs become unused and the company must sell them on the RI Marketplace (if eligible) to recover value. This doesn't accommodate the planned migration.
- Why C is wrong: On-Demand pricing provides zero discount. While AWS Budgets alerts help with cost awareness, they don't reduce costs. For a 3-year steady-state workload, On-Demand pricing is the most expensive option — roughly 40-66% more than committed pricing.
- Why D is wrong: Convertible RIs offer flexibility to exchange for different instance types but still only apply to EC2. They don't cover Fargate or Lambda. Purchasing separately for each instance type adds management overhead, and the discounts (~33% for 1-year, ~55% for 3-year) are lower than Compute Savings Plans for the same term and payment option.
Question 19 — Domain 2: Design for New Solutions
A healthcare organization is building a new application requiring load balancing for web traffic. Which solution provides application load balancing?
- Single instance
- No load balancing
- Manual traffic distribution
- Application Load Balancer for Layer 7 load balancing with HTTP/HTTPS — Correct answer
Explanation:
- Why correct: Application Load Balancer provides Layer 7 load balancing for HTTP/HTTPS traffic with advanced routing. This provides application load balancing.
- Why A is wrong: No load balancing creates single point of failure. Load balancing is required for high availability. This approach does not meet requirements.
- Why B is wrong: Single instance creates single point of failure. Multiple instances with load balancing are required. This approach does not meet requirements.
- Why C is wrong: Manual traffic distribution does not scale and is inefficient. Automated load balancing is required. This approach is inefficient.
Question 20 — Domain 4: Accelerate Workload Migration and Modernization
A solutions architect is conducting a portfolio assessment for migrating 200 on-premises servers to AWS. The team needs to discover server specifications, utilization patterns, and inter-server network dependencies to plan migration waves. The on-premises environment includes Windows and Linux servers with no existing inventory system. Which approach provides the MOST comprehensive discovery data?
- Deploy AWS Application Discovery Service agents on the servers to collect detailed configuration, performance, and network dependency data — Correct answer
- Use AWS Config to inventory all on-premises servers and their configurations
- Manually survey application owners across departments and compile the results into a migration inventory
- Run AWS Systems Manager inventory on the on-premises servers to collect application metadata
Explanation:
- Why correct: AWS Application Discovery Service with agents installed on servers collects detailed data including server configuration, CPU/memory/disk utilization over time, running processes, and TCP network connections between servers. The network dependency data is critical for identifying application groupings for wave planning. Agent-based discovery provides the most comprehensive data set.
- Why B is wrong: AWS Config is a service for tracking configuration changes of AWS resources. It does not discover or inventory on-premises servers. It has no capability to collect data from non-AWS environments.
- Why C is wrong: Manual surveys are time-consuming, error-prone, and cannot capture accurate utilization metrics or network dependency data. Application owners often have incomplete knowledge of all dependencies, especially at the network level. This approach does not scale for 200 servers.
- Why D is wrong: AWS Systems Manager requires the SSM Agent and connectivity to AWS endpoints. While it can collect some inventory data from on-premises servers (as managed instances), it does not capture network dependency mapping between servers, which is essential for migration wave planning.
Question 21 — Domain 4: Accelerate Workload Migration and Modernization
A manufacturing company is migrating 500 virtual machines running on VMware vSphere to AWS. The servers include a mix of Windows Server and Linux workloads. The company wants a lift-and-shift approach with continuous replication that allows non-disruptive cutover testing and a cutover window of less than one hour per wave. Which migration approach meets these requirements?
- Use VM Import/Export to convert each VMware image to an AMI, then launch EC2 instances from the AMIs
- Create new EC2 instances and manually reinstall each application from deployment scripts and configuration management tools
- Use AWS Application Migration Service (MGN) to perform continuous block-level replication and automated cutover testing — Correct answer
- Use AWS Migration Hub to orchestrate the migration and automatically convert VMware images to EC2 instances
Explanation:
- Why C is correct: AWS Application Migration Service (MGN) installs a lightweight agent on each source server that continuously replicates block-level data to AWS. This enables non-disruptive testing by launching test instances at any time, and the actual cutover window is minutes — not hours — because only the final delta needs to sync. MGN is the AWS-recommended tool for large-scale lift-and-shift migrations from VMware, Hyper-V, or physical servers.
- Why A is wrong: VM Import/Export is snapshot-based — it captures a point-in-time image, converts it, and imports. For 500 VMs, each snapshot creates a long cutover window because changes made after the snapshot require a new export. There is no continuous replication, so the cutover downtime is significantly longer.
- Why B is wrong: Manually rebuilding 500 servers is not a lift-and-shift approach. It requires validated deployment scripts for every application, introduces configuration drift risk, and takes weeks or months instead of the short cutover window MGN provides.
- Why D is wrong: AWS Migration Hub is a tracking and orchestration dashboard — it provides visibility into migration progress but does not perform the actual server replication or conversion. It integrates with MGN but is not itself a migration execution tool.
Question 22 — Domain 4: Accelerate Workload Migration and Modernization
A startup runs a customer-facing Node.js web application on EC2 instances. Developers spend significant time managing OS patches, configuring load balancers, and tuning Auto Scaling policies. The application uses standard Express.js patterns and the team wants to reduce operational overhead while retaining the ability to customize the runtime environment, install native OS packages, and SSH into instances for debugging. Which migration approach best meets these requirements?
- Amazon Lightsail with a Node.js blueprint
- AWS Elastic Beanstalk with a managed Node.js platform — Correct answer
- Amazon ECS on AWS Fargate with an Application Load Balancer
- AWS Lambda functions behind Amazon API Gateway
Explanation:
- Why correct: AWS Elastic Beanstalk provides a managed platform that handles provisioning, load balancing, Auto Scaling, and OS patching while still allowing full access to the underlying EC2 instances. Developers can customize the environment through .ebextensions, install native packages, and SSH into instances. This directly reduces the stated operational overhead while preserving customization requirements.
- Why A is wrong: Amazon Lightsail provides a simplified compute platform but has limited Auto Scaling capabilities and less flexibility for customizing the runtime environment. It is designed for simpler workloads and does not offer the same level of platform customization (custom AMIs, .ebextensions, platform hooks) that Elastic Beanstalk provides.
- Why C is wrong: Amazon ECS on Fargate eliminates server management but requires containerizing the application first, which adds migration complexity. Fargate is serverless, so there are no instances to SSH into for debugging, which conflicts with the stated requirement. This approach trades one form of operational overhead for container orchestration complexity.
- Why D is wrong: AWS Lambda with API Gateway requires re-architecting the Express.js application to fit the Lambda execution model (handler functions, stateless execution, 15-minute timeout). This is not a minimal-change migration and does not support SSH debugging or native OS package installation.
Question 23 — Domain 4: Accelerate Workload Migration and Modernization
A media company runs a legacy image-processing pipeline on EC2 instances that generates thumbnails whenever users upload images. The instances run 24/7 but process images only 15% of the time. During the other 85%, the instances sit idle. The company wants to reduce costs, eliminate server management, and maintain processing initiation within seconds of an upload. Which modernization approach best meets these requirements?
- Move the image-processing code to AWS Lambda functions triggered by Amazon S3 event notifications — Correct answer
- Replace the EC2 instances with smaller instances in an Auto Scaling group that scales between 1 and the current capacity
- Containerize the image-processing code and run it on Amazon ECS with Fargate using a scheduled scaling policy
- Keep the EC2 instances but use AWS Instance Scheduler to run them only during business hours
Explanation:
- Why correct (A): AWS Lambda triggered by S3 event notifications provides a fully serverless, event-driven solution. Lambda scales to zero when no uploads occur, eliminating idle costs. Each upload event automatically triggers processing with no server management required. Lambda functions can process images within seconds of upload.
- Why B is wrong: An Auto Scaling group cannot scale to zero EC2 instances (minimum is 1). The team still manages server patching, AMIs, and scaling policies. Costs persist even during idle periods.
- Why C is wrong: Scheduled scaling on ECS with Fargate does not respond to individual upload events. It scales based on time, not demand. Tasks may be running when no uploads occur, or may not be running when uploads arrive outside the schedule.
- Why D is wrong: Instance Scheduler restricts instances to business hours, but users upload images at any time. Uploads outside business hours would not be processed until the next scheduled start, failing the requirement for processing within seconds of upload.
Question 24 — Domain 4: Accelerate Workload Migration and Modernization
A company runs a legacy mainframe-based payroll system. The vendor no longer provides support, and the application uses COBOL code that no internal developers can maintain. The HR department has evaluated cloud-based payroll SaaS providers and found one that meets all functional requirements at lower total cost. The company wants to minimize migration effort. Which migration strategy is MOST appropriate?
- Rehost the mainframe application on Amazon EC2 z1d instances to maintain compatibility
- Refactor the application by rewriting COBOL code in Java and deploying on Amazon ECS
- Replatform by moving the mainframe database to Amazon RDS and wrapping COBOL programs in APIs
- Repurchase by retiring the mainframe application and adopting the evaluated SaaS payroll provider — Correct answer
Explanation:
- Why correct (D): Repurchase (buy) is the appropriate 7Rs strategy when a suitable SaaS alternative exists and the company wants to minimize migration effort. The mainframe uses unsupported COBOL code with no internal expertise, making rehost, replatform, or refactor extremely costly and risky. Adopting the evaluated SaaS provider eliminates the need to maintain legacy code, reduces operational burden, and aligns with the goal of minimal effort.
- Why A is wrong: Rehosting a mainframe application on EC2 preserves all the problems — unsupported vendor, unmaintainable COBOL code, and operational burden. EC2 z1d instances are memory-optimized x86 instances, not mainframe-compatible, so the application would need significant rework regardless.
- Why B is wrong: Refactoring by rewriting COBOL in Java is the highest-effort approach. With no COBOL expertise to understand business logic, the rewrite risk is enormous. This contradicts the requirement to minimize migration effort.
- Why C is wrong: Replatforming by wrapping COBOL programs in APIs still requires maintaining unsupported COBOL code. Moving just the database to RDS does not address the core problem of unmaintainable application code.
Question 25 — Domain 2: Design for New Solutions
A technology company runs monthly batch processing jobs that analyze large datasets. The jobs are fault-tolerant, can checkpoint progress to S3, and take 4-12 hours to complete. The workload scales from 50 to 500 instances depending on dataset size. The company currently uses On-Demand instances costing $80,000/month and wants to reduce costs. Which compute strategy provides the MOST cost savings while maintaining job completion reliability?
- Use a single On-Demand instance type (c5.4xlarge) with Auto Scaling based on SQS queue depth to match processing demand precisely and eliminate any interruption risk
- Use a Spot Instance fleet diversified across multiple instance families and AZs with capacity-optimized allocation, an On-Demand base of 10%, and SQS for job queue management — Correct answer
- Purchase 1-year Reserved Instances for 500 c5.4xlarge instances to cover peak capacity, guarantee availability for all batch runs, and avoid Spot interruptions entirely
- Use Spot Instances of a single instance type (c5.4xlarge) in one Availability Zone to simplify fleet management and maximize the per-instance Spot discount
Explanation:
- Why correct: A diversified Spot Instance fleet across multiple instance types and AZs maximizes the likelihood of obtaining capacity and reduces interruption risk—if one instance type's Spot pool is reclaimed, others continue running. The capacity-optimized allocation strategy selects instances from pools with the most available capacity, reducing interruption frequency. An On-Demand base provides a minimum capacity floor that cannot be interrupted. SQS ensures that interrupted work is retried automatically by other instances. This architecture is purpose-built for fault-tolerant batch processing at lowest cost.
- Why A is wrong: A single On-Demand instance type eliminates the 60-90% Spot savings. On-Demand is the most expensive option for batch processing that is explicitly fault-tolerant and can handle interruptions. The workload characteristics (fault-tolerant, batch, variable) make it ideal for Spot.
- Why C is wrong: Reserved Instances require a 1-year or 3-year commitment to a specific instance type. Monthly batch jobs with variable processing times don't provide the consistent utilization that justifies RI commitment. The company would pay for reserved capacity during the weeks when no batch jobs run, wasting the investment.
- Why D is wrong: A single Spot Instance type in one AZ concentrates interruption risk. If that specific instance type's Spot pool is reclaimed, the entire fleet is interrupted simultaneously. Diversifying across instance types and AZs is a fundamental Spot best practice to reduce correlated interruptions.
Question 26 — Domain 1: Design Solutions for Organizational Complexity
Select TWO. A multinational e-commerce company needs active-active capabilities across us-east-1 and eu-west-1. Product catalog data is stored in Amazon DynamoDB and product images are stored in Amazon S3. Users in each Region must read and write with low latency, and data must stay synchronized. Which TWO actions should the solutions architect take?
- Enable DynamoDB Global Tables to replicate the product catalog across both Regions — Correct answer
- Use DynamoDB Streams with AWS Lambda to replicate catalog changes to a separate DynamoDB table in eu-west-1
- Enable S3 Cross-Region Replication from the source bucket to a destination bucket in eu-west-1 — Correct answer
- Schedule nightly S3 object copies to eu-west-1 using an AWS Batch job
- Deploy ElastiCache Global Datastore to replicate DynamoDB data across Regions
- Create separate DynamoDB tables in each Region and synchronize using application-level writes
Explanation:
- Why correct (A): DynamoDB Global Tables provide fully managed, active-active multi-Region replication with single-digit millisecond read and write latency in each Region. Conflicts are resolved using a last-writer-wins strategy, which works well for product catalog updates.
- Why correct (C): S3 Cross-Region Replication (CRR) automatically replicates objects from a source bucket in one Region to a destination bucket in another Region. Combined with S3 versioning (required for CRR), this keeps product images synchronized across Regions.
- Why B is wrong: Using DynamoDB Streams with Lambda to replicate data to another Region is a custom-built replication solution. It requires managing the Lambda function, handling error retries, dealing with throttling, and ensuring exactly-once delivery — all of which DynamoDB Global Tables handles automatically with less operational overhead.
- Why D is wrong: Nightly batch copy of S3 objects would leave images out of sync for up to 24 hours. For an active-active e-commerce site, newly uploaded product images must be available in both Regions promptly, which CRR provides in near-real-time.
- Why E is wrong: ElastiCache Global Datastore provides cross-Region replication for Redis caches. It cannot replicate DynamoDB data — it serves a completely different purpose (caching vs. primary data storage).
- Why F is wrong: Application-level synchronization between separate DynamoDB tables requires complex custom code for conflict resolution, retry logic, and consistency guarantees. DynamoDB Global Tables provides this natively with much less operational burden.
Question 27 — Domain 1: Design Solutions for Organizational Complexity
A financial services company stores sensitive customer data encrypted with AWS KMS in an S3 bucket in Account A. A data analytics team in Account B needs to decrypt and process this data for regulatory reporting. The security team requires that Account A retains full control over the encryption key and can revoke Account B's access instantly without modifying S3 bucket policies. Which approach meets these requirements?
- Export the KMS key material from Account A and import it into a new KMS key in Account B so both accounts have identical encryption keys
- Create a new KMS key in Account B, re-encrypt all objects with Account B's key, and grant the analytics team access to the new key
- Update the KMS key policy in Account A to allow Account B's analytics IAM role to perform kms:Decrypt, and grant cross-account S3 read access via bucket policy — Correct answer
- Copy all encrypted objects to a new S3 bucket in Account B using S3 default encryption, which automatically re-encrypts with Account B's aws/s3 managed key
Explanation:
- Why correct (C): Updating the KMS key policy in Account A to allow Account B's specific IAM role to perform kms:Decrypt gives Account A full control. Account A can revoke access instantly by removing the key policy statement, independent of S3 bucket policies. The S3 bucket policy also needs cross-account read access, but the key policy is the mechanism for revocation control.
- Why A is wrong: KMS symmetric keys do not support key material export. Even if using imported key material, creating a separate key in Account B means Account A loses control — they cannot revoke Account B's use of their own key.
- Why B is wrong: Re-encrypting with Account B's key transfers control to Account B. Account A can no longer revoke decryption access since Account B owns the key. This directly violates the requirement.
- Why D is wrong: Copying objects to Account B and using S3 default encryption re-encrypts the data under Account B's control. Account A loses the ability to revoke access and has no control over the key.
Question 28 — Domain 1: Design Solutions for Organizational Complexity
A large enterprise operates 15 AWS accounts across three business units. The company needs to enforce a policy that prevents any account from launching EC2 instances in Regions outside of us-east-1 and eu-west-1, while still allowing the management account to operate in all Regions for centralized tooling. How should a solutions architect implement this requirement?
- Create an SCP that denies all actions when the aws:RequestedRegion condition key does not match us-east-1 or eu-west-1, and attach it to the root OU but exclude the management account — Correct answer
- Create an SCP that denies all actions when the aws:RequestedRegion condition key does not match us-east-1 or eu-west-1, and attach it to the management account
- Create IAM policies in each account that deny actions outside the allowed Regions and attach them to all IAM users and roles
- Enable AWS Control Tower and use the Region deny guardrail, then manually allow the management account in the Control Tower console
Explanation:
- Why A is correct: SCPs attached to the root OU apply to all member accounts but never affect the management account (by design — SCPs do not restrict the management account). Using the aws:RequestedRegion condition key in a deny statement effectively restricts all member accounts to the specified Regions while leaving the management account unrestricted for centralized tooling.
- Why B is wrong: SCPs cannot be applied to the management account. Even if you attach an SCP to the management account, it has no effect. SCPs only restrict member accounts within the organization.
- Why C is wrong: Creating IAM policies in each individual account is not scalable across 15 accounts and requires ongoing maintenance. Users with administrative access could remove these policies. SCPs provide a centralized, account-level boundary that cannot be overridden by any IAM principal within the member account.
- Why D is wrong: While AWS Control Tower does offer a Region deny control, the management account exclusion is inherent to SCPs by design — it is not something you configure manually in the Control Tower console. This answer misrepresents how Control Tower implements Region restrictions.
Question 29
A company operates 50 AWS accounts under AWS Organizations. The central operations account must receive all Auto Scaling lifecycle events and Amazon ECS task state changes from every member account in near real-time to power a centralized operational dashboard. New accounts are added monthly. The solution must scale automatically to include new accounts with minimal manual effort. Which approach is BEST?
- Create an Amazon EventBridge rule in each member account that sends matching events to the central account's custom event bus, deploy rules automatically via CloudFormation StackSets with service-managed permissions and auto-deployment enabled, and grant cross-account PutEvents permission on the central event bus — Correct answer
- Configure AWS CloudTrail in each account to deliver API logs to a central S3 bucket and parse them with Lambda for state-change events
- Install the Amazon CloudWatch agent on every EC2 instance and ECS container to push custom metrics to the central account
- Create a Lambda function in the central account that periodically polls the DescribeAutoScalingGroups and DescribeTasks APIs in each member account using cross-account roles
Explanation:
- EventBridge rules in each member account can forward matching events to a central custom event bus using cross-account PutEvents permissions. CloudFormation StackSets with service-managed permissions and auto-deployment automatically deploy the rules to new accounts as they join the Organization, requiring no manual intervention.
- #### Why B is wrong
- CloudTrail logs API calls, not service state-change events directly. Parsing CloudTrail logs introduces delay (typically minutes) and complexity, failing the near real-time requirement.
- #### Why C is wrong
- The CloudWatch agent collects OS-level and custom metrics from compute resources. It does not capture Auto Scaling lifecycle events or ECS task state changes, which are control-plane events published to EventBridge.
- #### Why D is wrong
- Polling APIs from a central Lambda creates increasing latency as accounts grow, risks API throttling, and does not provide near real-time event delivery. It also requires maintaining a list of all accounts and cross-account roles manually.
Question 30
A regulated enterprise needs an organization-wide logging strategy. Application logs must be retained for 400 days, searchable for the first 30 days, and immutable once stored. Teams operate across 120 AWS accounts. Which design BEST meets these requirements?
- Store all logs only in local CloudWatch log groups in each account
- Write logs to EBS volumes on EC2 and snapshot weekly
- Use CloudWatch Logs subscription filters to stream logs to a centralized account, deliver to S3 with Object Lock for immutability, and index the most recent 30 days for search — Correct answer
- Use Amazon S3 Transfer Acceleration to speed log uploads from all Regions
Explanation:
- Centralized aggregation with CloudWatch Logs subscription filters scales across 120 accounts by streaming logs to a dedicated account. S3 Object Lock provides immutability guaranteeing logs cannot be altered once stored, meeting the regulatory requirement. Indexing only the most recent 30 days (for example, using OpenSearch or CloudWatch Logs Insights) balances the searchability requirement with cost efficiency, while S3 lifecycle policies handle the full 400-day retention.
- #### Why A is wrong
- Storing logs only in local CloudWatch log groups per account creates 120 isolated silos, complicating centralized search, governance, and consistent enforcement of immutability controls.
- #### Why B is wrong
- Writing logs to EBS volumes and snapshotting weekly is operationally heavy, does not provide immutability guarantees, and is not optimized for centralized search or retention management at scale.
- #### Why D is wrong
- S3 Transfer Acceleration speeds up uploads to S3 but does not address governance requirements such as immutability, centralized search, or retention policy enforcement.
JavaScript is required to use this application.
Please enable JavaScript in your browser to access the full NestedCerts platform.
Contact: support@nestedcerts.com