Free Exams learning guide
Pass the AWS Solutions Architect Exam: Advanced Guide
Pass the AWS Solutions Architect Exam: Advanced Guide — a free advanced-level guide covering how to pass the aws certified solutions architect exam....
What you will learn
- Exam Architecture & Decision Frameworks
- Compute: Trade-offs at Scale
- Storage: Tiering, Performance & Consistency Edge Cases
- Networking: VPC Design Patterns & Hybrid Connectivity
- Databases: Selection Criteria & Performance Tuning
- Security: Defense in Depth on AWS
- Resilience: Multi-AZ vs Multi-Region Architecture
- Event-Driven & Decoupled Architectures
- Edge Services & Global Content Delivery
- Cost & Governance at Enterprise Scale
- Migration & Modernization Patterns
- Exam Simulation & Trap Avoidance
1. Exam Architecture & Decision Frameworks
The Anatomy of an AWS Architect Question You are 90 minutes into the exam. You have 35 questions left. Question 52 presents a scenario: a retail company needs to process real-time inventory updates from 10,000 IoT sensors. The data must be ingested with minimal latency, transformed, and stored for sub-second querying by a downstream analytics dashboard. The options present a matrix of compute, storage, and integration services. You know the services. You know the use cases. But the question doesn't ask "What is SQS used for?" It asks you to balance ingestion latency against query performance, while implicitly weighing operational overhead against cost. The AWS Certified Solutions Architect - Professional (or Associate) exam is not a trivia contest. It is a test of architectural judgment under simulated business constraints. Advanced learners often fail not because they lack AWS knowledge, but because they misread the exam's implicit constraints. This chapter establishes the mental frameworks required to decode question patterns, apply the Well-Architected Pillars as decision-making tools, and manage the clock so that architectural judgment—not panic—dictates your final answers. Mapping the Well-Architected Pillars to Service Selection The AWS Well-Architected Framework is not just a consulting tool; it is the grading rubric for the exam. When a scenario-based question forces you to choose between two technically viable architectures, the tie-breaker is almost always rooted in one of the six pillars. The exam tests your ability to identify which pillar is the highest priority based on the specific phrasing of the scenario. Operational Excellence: The "Minimal Overhead" Heuristic When a question mentions a small engineering team, a lack of dedicated operations staff, or a desire to "focus on application code," the Operational Excellence pillar takes precedence. Exam Heuristic: Favor managed services, serverless architectures, and AWS Fargate over self-managed Amazon EC2. If a scenario describes an event-driven workload where the team wants to avoid infrastructure provisioning, AWS Lambda and EventBridge will almost always beat EC2 and cron jobs. Distractors will offer EC2 with Auto Scaling—it solves availability, but fails the operational overhead constraint. Security: The "Least Privilege" and "Data Protection" Heuristic Security questions on advanced exams rarely test basic IAM usage; they test defense-in-depth and data state protection. Exam Heuristic: If the scenario mentions compliance, auditing, or sensitive data, map the requirement to the data state: - Data in transit: TLS, ACM, API Gateway custom domains. - Data at rest: KMS (Customer Managed Keys for granular control), S3 Object Lock, EBS encryption. - Data in use: AWS Nitro Enclaves (for highly sensitive multi-party computation). If an option mentions "store the credentials in an environment variable" while another mentions "AWS Secrets Manager with automatic rotation," the latter is the correct application of the Security pillar. Reliability: …
2. Compute: Trade-offs at Scale
Placement Groups: Failure Domain Semantics and Latency When the exam presents a scenario requiring low-latency HPC or an isolated multi-tenant database topology, the decision matrix must immediately pivot to EC2 Placement Groups. The exam probes not just your ability to identify the three types—cluster, spread, and partition—but your understanding of their underlying failure domain semantics and strict hardware limitations. Cluster Placement Groups A cluster placement group packs instances into a single low-latency group within a single Availability Zone (AZ). Because instances reside on the same underlying hardware rack (often leveraging the AWS Nitro System for non-bare-metal instances), they benefit from the highest network throughput and lowest latency available in EC2. Failure Domain: The entire AZ is the failure domain. If the AZ goes down, the whole placement group fails. Latency Requirements: Sub-millisecond latency, up to 100 Gbps network throughput (depending on instance type). Exam Trap: You cannot launch instances of mixed instance types in a cluster placement group if they require different underlying hardware architectures. Furthermore, if you receive a capacity error during launch, you must stop all instances in the group and start them again to attempt a new allocation. Indicators: HPC workloads, ultra-low latency requirements, tightly coupled node-to-node communication, Big Data clusters. Spread Placement Groups Spread placement groups strictly place instances on distinct underlying hardware racks. Failure Domain: The rack. Each instance is isolated from rack-level failures (power, network). Limitations: A maximum of 7 running instances per AZ per spread placement group. Exam Trap: The exam will offer spread placement groups as an option for a massive, distributed fleet (e.g., 50 instances). This is an immediate elimination strategy due to the 7-instance limit. Spread is strictly for critical, small-scale isolation. Indicators: "Critical instances that must be isolated from each other," small primary/secondary database topologies, or licensing nodes that cannot co-locate on the same hardware. Partition Placement Groups Partition placement groups divide instances into logical segments called partitions. AWS ensures that instances within different partitions do not share underlying hardware (racks). Failure Domain: The partition (rack-level). Limitations: Up to 7 partitions per AZ. This scales across multiple AZs, making it suitable for large distributed systems. Exam Trap: The exam will present a large-scale distributed data store (e.g., Hadoop, Cassandra, Kafka) and suggest spread placement groups to isolate nodes. Because of the 7-instance limit on spread, partition is the only mathematically viable answer for large topologies. Indicators: Large distributed databases, grid computing, topologies that require rack isolation but exceed 7 instances per AZ. AWS Lambda: Execution Context, Provisioned Concurrency, and Scaling Laws Architectural Judgment on serverless compute requires understanding the invisible mechanics of AWS Lambda. The exam tests your ability to predict performance bottlenecks based on memory allocation, cold-starts, and …
3. Storage: Tiering, Performance & Consistency Edge Cases
The S3 Intelligent-Tiering Break-Even Math A common trap on the AWS exam is defaulting to S3 Intelligent-Tiering for any workload with "unknown" or "unpredictable" access patterns. While Intelligent-Tiering eliminates retrieval fees, it introduces a small per-object monitoring and automation fee. If your access frequency is truly unknown but happens to be high, Standard is cheaper. If it’s predictably low, S3 Standard-Infrequent Access (S3 Standard-IA) is cheaper. To apply the Exam Heuristic: Trade-offs over Absolutes, you must calculate the break-even access frequency for a given workload. The Variables: Let’s define the costs for the first 50 TB tier (prices are approximate for exam math): S3 Standard: $0.023 per GB/month, $0.004 per 1,000 PUTs, $0.0004 per 1,000 GETs. S3 Standard-IA: $0.0125 per GB/month, $0.01 per 1,000 PUTs, $0.001 per 1,000 GETs, $0.01 per GB retrieval. S3 Intelligent-Tiering: $0.023 per GB/month (same as Standard for frequent tier), $0.005 per 1,000 PUTs, $0.0004 per 1,000 GETs, plus a $0.0025 per 1,000 objects monitoring/automation fee. Intelligent-Tiering vs. Standard: Because the storage price and GET/PUT costs are identical between Standard and Intelligent-Tiering's frequent access tier, the only difference is the monitoring fee. Break-even: You must access the data enough times to justify the $0.0025 per 1,000 objects fee. If you access objects less than ~once a month, Intelligent-Tiering saves money by moving them to the Infrequent Access tier (after 30 days of inactivity). If you access them multiple times a month, Standard is cheaper. Intelligent-Tiering vs. Standard-IA: Standard-IA charges a retrieval fee ($0.01/GB) but no monitoring fee. Intelligent-Tiering charges a monitoring fee ($0.0025/1,000 objects) but no retrieval fee for objects in the IA tier. Break-even: Assume a 1 MB object (0.001 GB). Retrieving it from Standard-IA costs $0.00001. The monitoring fee for Intelligent-Tiering is $0.0000025 per object. You would need to retrieve this 1 MB object roughly 4 times a month to justify Intelligent-Tiering over Standard-IA. For larger objects (e.g., 1 GB), the retrieval fee is $0.01, meaning you only need to access the object once every 4 months to justify Standard-IA over Intelligent-Tiering. Architectural Judgment: On the exam, look for object size. Intelligent-Tiering’s monitoring fee is per object. If a scenario describes millions of tiny 1 KB objects with unpredictable access, the monitoring fee will dwarf the storage cost—Standard or Standard-IA is likely better. If the scenario features large media files with unpredictable access, Intelligent-Tiering is the correct choice. EBS Volume Performance: Queue Depth and Multi-Attach Edge Cases In Compute: Trade-offs at Scale, we discussed how instance type limits burst performance. EBS volumes have their own performance ceilings dictated by IOPS, throughput, and queue depth. The exam will test your ability to map workload requirements to specific EBS volume types (gp3, io2 Block Express, st1, …
4. Networking: VPC Design Patterns & Hybrid Connectivity
The Topology Trap: When "Best Practice" Becomes a Bottleneck An enterprise runs 50 VPCs across three AWS accounts. Initially, they followed the "best practice" of using VPC peering to connect them. Fast forward 18 months: they are managing 1,225 peering connections. A new security mandate requires routing all egress traffic through a centralized inspection VPC. The network team stares at the routing tables, realizing that VPC peering’s strict non-transitivity means they must build dozens of new connections just to hairpin traffic. The mesh is unmanageable, and blast radius is completely decentralized. When designing multi-VPC topologies and hybrid connectivity on AWS, the biggest trap is treating AWS networking like traditional data center networking. The AWS Certified Solutions Architect - Professional exam tests your ability to navigate the nuances of transitivity, blast radius, and traffic engineering. Applying the Trade-offs over Absolutes principle from our Exam Architecture framework, we will evaluate these networking constructs not by which is "best," but by which constraints are acceptable for a given scenario. Multi-VPC Topologies: Peering vs. Transit Gateway vs. PrivateLink Connecting VPCs requires choosing between decentralized mesh (VPC Peering), centralized routing (Transit Gateway), or private service consumption (PrivateLink). The decision hinges on four factors: bandwidth, cost, transitivity, and blast radius. VPC Peering VPC peering connects two VPCs directly using the AWS network backbone, acting as a point-to-point link. Transitivity: Strictly non-transitive. If VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot route to VPC C. This is the most common exam trap. Bandwidth: No bandwidth bottleneck. Traffic stays on the AWS backbone without traversing a centralized gateway, meaning aggregate throughput is virtually unlimited. Cost: Cheapest data transfer option. No hourly attachment fees; only standard cross-AZ or cross-region data transfer rates apply. Blast Radius: Highly decentralized. A routing misconfiguration in VPC B only affects VPC B and its direct peers. However, managing hundreds of connections leads to operational fragility. AWS Transit Gateway (TGW) TGW acts as a cloud router, sitting in the middle of a hub-and-spoke topology. Transitivity: Controlled by route tables. By default, TGW routes between all attachments, but you can segment traffic using multiple TGW route tables. This allows you to explicitly design transitivity (e.g., allowing Spoke VPCs to reach a Shared Services VPC, but not each other). Bandwidth: A potential bottleneck. The TGW is a highly available, scalable service, but it has a per-attachment throughput limit (historically 50 Gbps, though AWS has introduced inter-region peering limits and ECMP support that alter this). For most workloads, this is fine, but massive data transfers between VPCs might hit this ceiling. Cost: Incurs hourly charges per attachment (VPC, VPN, Direct Connect) plus per-GB data processing fees. A 50-VPC mesh via …
5. Databases: Selection Criteria & Performance Tuning
The Relational vs. Non-Relational Inflection Point A database migration workload is running 15% over its allotted completion window. The engineering team proposes swapping the source database’s cross-Region read replica for an Aurora Global Database to reduce replication lag, while simultaneously shifting a highly spiky user-session tracking table to DynamoDB on-demand capacity. Are these the right moves? On the AWS Certified Solutions Architect - Professional exam, the answer requires dissecting the exact mechanics of failover semantics, storage architectures, and capacity break-even points. Drawing on the Architectural Judgment framework established in Chapter 1, database selection on the SAP-C02 exam is rarely about identifying a "good" database. It is about identifying the only database that survives a specific edge case. This requires abandoning assumptions about generalized performance and focusing on strict operational constraints: failover RTO, replication latency, write distribution, and capacity throttling behavior. RDS Multi-AZ vs. Aurora: Storage and Failover Mechanics The exam frequently tests the architectural distinction between RDS Multi-AZ and Aurora by forcing you to predict failover times and write-latency behaviors under duress. The core difference lies in how they handle storage and replication. The Synchronous Standby Problem RDS Multi-AZ maintains a synchronous standby replica in a different Availability Zone. When a write occurs, it is written to the primary instance's EBS volume and synchronously replicated to the standby instance's EBS volume. The transaction does not acknowledge until both volumes are durably written. Write Latency Impact: This synchronous EBS replication adds I/O latency. If an exam scenario mentions a write-heavy transactional workload experiencing high commit latency in a Multi-AZ configuration, the underlying cause is the synchronous standby acknowledgment. Failover RTO: During a failure, RDS must promote the standby instance. This requires DNS updates and reconfiguring the connection string. The automated failover process typically takes 60 to 120 seconds (often capped at 2 minutes for most engines). Aurora’s Distributed Storage Layer Amazon Aurora decouples the compute instances from a distributed, shared storage volume. The storage layer spans three Availability Zones, with six copies of your data (two copies per AZ). Write Optimization: Aurora does not replicate entire EBS volumes synchronously. Instead, the primary instance writes log records to the storage layer, and the storage nodes apply those logs to build the data pages in the background. This offloading dramatically reduces write commit latency compared to RDS Multi-AZ. Failover RTO: Because the storage volume is shared and continuously accessible, an Aurora failover does not involve storage rebuilding. The cluster simply promotes an existing Aurora Replica (in the same region) to primary. The RTO is typically under 30 seconds. Exam Heuristic: If a scenario demands sub-minute RTO for a relational database failure, RDS Multi-AZ is eliminated. Aurora is the only valid choice. If a …
6. Security: Defense in Depth on AWS
The IAM Policy Evaluation Pipeline A developer assumes a role in your production account. The role’s identity-based policy grants s3:GetObject on a critical configuration bucket. The bucket policy explicitly allows access from the developer’s IAM role ARN. Yet, the AccessDenied error persists. Why? At an advanced level, IAM is not a simple matrix of "allow" vs "deny." It is a hierarchical evaluation pipeline. To predict access decisions in multi-layer scenarios, you must trace the exact order of operations AWS executes when a principal makes a request. The evaluation pipeline filters a request through up to four distinct layers before granting access. If any layer returns an explicit Deny, the evaluation short-circuits and the request fails immediately. The Evaluation Logic Sequence 1. Organization SCPs (Service Control Policies): Evaluated first. SCPs act as guardrails. They do not grant permissions; they only define the maximum available permissions for an account or Organizational Unit (OU). If an SCP denies the action, or simply does not explicitly allow it (due to default Deny), the request fails. 2. Resource-based Policies: Evaluated in parallel with session policies and identity-based policies. For most services (like S3), if the resource-based policy explicitly allows the principal, it can override an implicit deny from the identity-based policy. However, an explicit deny in a resource-based policy short-circuits the entire pipeline. 3. Session Policies: Evaluated when a principal assumes a role via STS. A session policy is an inline policy passed programmatically during AssumeRole. It further restricts the permissions of the resulting temporary session. The effective permissions are the intersection of the role’s identity-based policies and the session policy. 4. Identity-based Policies: Evaluated last. If the SCPs allow the action, and no resource-based policy explicitly denies it, and the session policy allows it, the identity-based policy makes the final determination. Permission Boundaries: The Intersection Permission boundaries add a complex twist. A permission boundary is an advanced IAM feature where you set the maximum permissions an identity-based policy can grant to an entity. When a permission boundary is applied to a role, the effective permissions are the intersection of the identity-based policy and the permission boundary. Exam Heuristic: If a scenario mentions a developer who has an identity-based policy granting s3:, but they can only read objects, check for a permission boundary. The boundary likely restricts them to s3:Get. The identity-based policy allows the action, but the boundary does not, resulting in an implicit deny. Multi-Layer Scenario Walkthrough Consider an EC2 instance running with an attached IAM role (AppRole). AppRole has an identity-based policy allowing s3:GetObject for arn:aws:s3:::finance-data/. The account is governed by an SCP that denies access to arn:aws:s3:::finance-data/classified/. The finance-data bucket has a bucket policy allowing s3:GetObject for AppRole. - Request: AppRole …
7. Resilience: Multi-AZ vs Multi-Region Architecture
The RTO/RPO Spectrum: Classifying DR Strategies When the exam presents a disaster recovery scenario, your first task is to anchor the requirements to the Recovery Time Objective (RTO) and Recovery Point Objective (RPO). As established in the Exam Architecture & Decision Frameworks, AWS defines four primary DR strategies. At the advanced level, you must not only recognize them but instantly map them to specific AWS service combinations and their inherent architectural trade-offs. 1. Backup & Restore (High RPO, High RTO): Mechanism: Automated backups, cross-region snapshot copies, and periodic EBS/S3 snapshots. Exam Nuance: This is the most cost-effective but slowest strategy. If an exam question mentions a scenario where the business can tolerate 24 hours of downtime and data loss, this is the answer. However, watch for traps: if the question requires restoring a massive relational database quickly, point out that restoring from S3 backups to RDS takes hours. 2. Pilot Light (Low RPO, Medium RTO): Mechanism: A minimal version of the core environment runs continuously in the DR region. Data is replicated asynchronously (e.g., Aurora Global Database, DynamoDB Global Tables), but compute layers are scaled to zero or minimal sizes. Exam Nuance: The "scaling up" phase is the critical factor. You must provision AMIs and Auto Scaling groups in a suspended state. When failover occurs, you modify the Auto Scaling group desired capacity, promote the database replica, and update Route 53 to point to the new Application Load Balancer (ALB). 3. Warm Standby (Low RPO, Low RTO): Mechanism: A scaled-down, fully functional replica of the production environment runs continuously in the DR region. Exam Nuance: The primary action during a disaster is scaling out (not up). You increase the instance count in the DR Auto Scaling group. This avoids the bootstrapping time of launching entirely new instances from scratch, offering a lower RTO than Pilot Light but at a higher baseline cost. 4. Multi-Site Active-Active (Zero/Near-Zero RPO, Zero/Near-Zero RTO): Mechanism: Workloads run simultaneously in multiple regions, serving live traffic. Exam Nuance: This requires bi-directional data replication (e.g., DynamoDB Global Tables) and Route 53 weighted or latency-based routing. It is the most expensive and complex, but the only solution for workloads where even minutes of downtime violate SLAs. Exam Heuristic: If an exam question asks for the "most cost-effective" DR strategy that still maintains a secondary region, lean toward Pilot Light. If it asks for the "fastest recovery" or "lowest RTO," lean toward Warm Standby or Multi-Site. Route 53 Routing Policies and Health Check Interactions Route 53 is the brain of multi-region resilience. The exam will test your ability to select the correct routing policy and, crucially, understand how health checks modify that behavior. Policy Selection Criteria Latency Routing: Routes users …
8. Event-Driven & Decoupled Architectures
The Coupling Trap: When "Asynchronous" Becomes a Liability An e-commerce platform processes 10,000 orders per minute during a flash sale. The architecture is "fully decoupled": an API Gateway writes orders to an SQS queue, and a fleet of Lambda functions consumes them. On paper, this is flawless. In practice, during the sale, a downstream payment gateway begins throttling. The Lambda functions retry the payment calls, exhaust their timeouts, and throw exceptions. Because the architect didn't fully understand visibility timeout interactions with partial batch failures, the queue drains incredibly slowly. Worse, orders are processed out of order, causing inventory overselling. As we established in Compute: Trade-offs at Scale and Resilience: Multi-AZ vs Multi-Region Architecture, decoupling does not automatically equate to resilience. Event-driven architectures introduce entirely new failure modes: poison pills, head-of-line blocking, at-least-once duplication, and orphaned orchestrations. For the AWS Certified Solutions Architect - Professional exam, you must move beyond the "SQS decouples, SNS fans out" heuristics. You must evaluate edge cases, concurrency limits, and the precise semantics of message delivery across SQS, SNS, Kinesis, EventBridge, and Step Functions. SQS Deep Dive: Standard, FIFO, and Lambda Concurrency Edge Cases Amazon SQS is the backbone of AWS decoupling, but its interaction with compute resources—specifically Lambda—is fraught with exam traps. Visibility Timeout and Lambda Batch Failures When Lambda polls an SQS queue, it receives a batch of messages. The queue's Visibility Timeout hides these messages from other consumers, assuming the processing Lambda will delete them upon success. The critical Exam Heuristic: The Lambda function timeout must be shorter than the SQS visibility timeout. If the Lambda times out while processing a batch, SQS makes the messages visible again before the Lambda environment is torn down. Another Lambda invocation picks them up, resulting in duplicate processing while the first instance is still winding down. Historically, if a Lambda received a batch of 10 messages and failed on the 9th, all 10 messages were returned to the queue. This created massive duplication. The modern solution is ReportBatchItemFailures. - When configured, Lambda returns a list of failed message IDs to SQS. - SQS only makes those specific failed messages visible again; the successful ones are deleted. - The Trap: If your function fails to call the SQS DeleteMessage API for successful items and fails to return the partial batch failure response, the entire batch retries. Furthermore, if the partial batch failure causes the message to exceed its Max Receive Count, the entire batch can still be routed to a Dead-Letter Queue (DLQ) if not carefully monitored. Standard vs. FIFO: Exactly-Once and Concurrency SQS Standard offers at-least-once delivery, meaning duplicates are possible. SQS FIFO offers exactly-once processing, but with strict caveats. 1. Exactly-Once Caveats: FIFO exactly-once is …
9. Edge Services & Global Content Delivery
Cache Behavior Tuning and the Art of the Cache Key A global media platform serves personalized user dashboards. To reduce origin load, they implement CloudFront but quickly find their cache hit ratio plummeting. The culprit? Appending session IDs and user tokens directly to the query string. CloudFront diligently caches a unique version of the object for every user, defeating the purpose of a CDN. At an advanced level, CloudFront configuration is less about connecting origins and more about cache-key normalization and precise cache behavior tuning. The cache key is the specific string CloudFront uses to uniquely identify a cached object. If your cache key is too broad, you serve the wrong content. If it is too narrow, your origin suffers from a "cache stampede." Cache Key Normalization CloudFront allows you to include headers, cookies, and query strings in the cache key. The architectural goal is always to include only what causes the object to differ, and exclude everything else. - Headers: Viewer requests often contain headers like User-Agent or Accept-Language. If you whitelist these for caching, the cache hit ratio collapses. Use Origin Request Policies to pass these headers to the origin for business logic without including them in the Cache Policy (which determines the cache key). - Cookies: Similar to headers, passing session cookies to the origin is often necessary for personalization, but caching on them is dangerous. Separate the cache policy from the origin request policy to pass the cookie downstream while keeping the cache key pristine. - Query Strings: Parameters like ?utmsource=email are marketing noise. Configure CloudFront to ignore specific query strings or only whitelist the ones that actually change the payload (e.g., ?format=json). Exam Heuristic: If a scenario describes a low cache hit ratio alongside personalized content or tracking parameters, the solution is almost always to normalize the cache key by decoupling the Cache Policy from the Origin Request Policy. TTL Trade-offs When configuring cache behaviors, you establish a Minimum TTL, Maximum TTL, and Default TTL. However, origin headers (Cache-Control: max-age, Expires) override CloudFront settings unless you explicitly enforce a CloudFront TTL. For highly volatile data (e.g., real-time stock tickers), you might set a Minimum TTL of 0. This doesn't completely disable caching; rather, it forces CloudFront to forward the request to the origin, but the origin can still respond with a 304 Not Modified if the If-None-Match (ETag) matches, saving bandwidth and origin compute. Securing Private Content: Signed URLs vs. Signed Cookies When distributing premium content, restricting access to CloudFront distributions is paramount. As established in Security: Defense in Depth on AWS, CloudFront uses AWS-backed signed requests rather than standard IAM roles for end-user authorization. The architectural decision comes down to Signed URLs versus Signed …
10. Cost & Governance at Enterprise Scale
The Multi-Account Paradigm: Organizations and SCP Architecture An enterprise launches a new machine learning platform. The data science team spins up a fleet of p4d.24xlarge instances in a shared application account, intending to run them for a month. Because they lack permissions to create IAM roles in that account, they attach an existing IAM role that happens to have AdministratorAccess. Within 48 hours, a misconfigured security group exposes the instance to the open internet, and a botnet hijacks the instance to mine cryptocurrency. The subsequent AWS bill spikes by $45,000 over the weekend. When scaling AWS across an enterprise, Identity and Access Management (IAM) alone is insufficient to prevent this class of failure. IAM defines what identities can do, but it relies on least-privilege enforcement at every layer. At enterprise scale, you need Service Control Policies (SCPs). SCPs define what identities cannot do, acting as absolute guardrails that override IAM permissions. Navigating the FullAWSAccess Inheritance Trap The most subtle and dangerous pitfall in AWS Organizations governance is the FullAWSAccess inheritance trap. By default, AWS Organizations attaches the FullAWSAccess managed policy to every OU and account in the organization. This policy explicitly allows actions on resources. Because SCPs operate on a "default deny" model—where an action is only allowed if every SCP in the hierarchy allows it—leaving FullAWSAccess attached means your restrictive SCPs will still work. However, the trap occurs when an architect removes FullAWSAccess from an OU, assuming they will replace it with a tightly scoped allow-list. If they attach a new SCP that only allows ec2: and s3:, they have inadvertently blocked STS token vending, CloudWatch logging, and IAM user creation. Worse, if an architect removes FullAWSAccess from the Root OU, every account below it loses the ability to use any service not explicitly allowed by a lower SCP. Exam Heuristic: SCPs are permission filters, not identity grants. They intersect with IAM policies. An action is permitted only if the SCP allows it and the IAM policy allows it. If an SCP explicitly denies an action, no IAM policy can override it. When designing an SCP strategy, the best practice is to leave FullAWSAccess attached to the Root and most OUs, and enforce governance through explicit deny SCPs. For highly sensitive OUs (like a "Sandbox" or "Data Lake" OU), you can remove FullAWSAccess and apply an explicit allow-list SCP. Designing Guardrails Without Blocking Legitimate Usage Consider a scenario where you need to prevent users from launching EC2 instances in regions outside the US and EU, but you must not break legitimate global services like CloudFront or IAM. Strategy: Apply an SCP that explicitly denies EC2 operations in non-approved regions, rather than trying to allow-list all approved services globally. This …
11. Migration & Modernization Patterns
A legacy enterprise application relies on a tightly coupled, monolithic architecture running on aging on-premises VMware clusters. The infrastructure team has mandated a strict 4-hour maintenance window for the upcoming migration cutover. However, the application's backend database is 15TB, and the storage throughput at the source datacenter caps out at 50 MB/s. A pure backup-and-restore strategy would take days, shattering the maintenance window. This is the reality of cloud migration. It is rarely a simple lift-and-shift; it is a complex orchestration of data replication, network routing, and identity federation. For the AWS Certified Solutions Architect exam, migration scenarios are designed to test your ability to navigate constraints—downtime, bandwidth, and compatibility—by selecting the precise AWS tool and architectural pattern required to bridge the gap. This chapter dissects the advanced migration patterns the exam tests, focusing on the 6R framework, database replication modes, server migration tooling, and the nuances of hybrid Active Directory integration. The 6R Framework: Strategic Mapping and Outcomes The 6R migration framework (Rehost, Replatform, Repurchase, Refactor, Retain, Retire) is not just a categorization tool; it is a decision matrix that dictates the AWS services you will use and the architectural outcomes you will achieve. The exam frequently presents a business scenario and asks you to map it to the correct "R" and the corresponding AWS tool. Rehosting ("Lift-and-Shift") Rehosting involves moving applications to AWS without modifying the underlying architecture. Architectural Outcome: The application runs on EC2 instances identical to their on-premises counterparts. It is the fastest way to migrate but often leaves technical debt. Exam Indicator: The scenario emphasizes speed, lack of developer resources, or a "get to the cloud first, optimize later" mandate. Primary Tool: AWS Application Migration Service (MGN). MGN is the default tool for lift-and-shift. It installs an agent on the source server, replicates block-level data to AWS, and performs a non-disruptive cutover by launching an EC2 instance from the replicated volume. Replatforming ("Lift-Tinker-and-Shift") Replatforming involves making a few targeted cloud optimizations without fundamentally changing the core architecture. Architectural Outcome: The application might move from self-managed MySQL on EC2 to Amazon RDS for MySQL, or from local file storage to Amazon EFS. The operating system and application code largely remain the same, but the managed services layer changes. Exam Indicator: The scenario mentions a desire to reduce operational overhead (like backups or patching) without the budget to rewrite the application. Primary Tools: AWS DMS (for database replatforming) and AWS DataSync (for moving data to EFS or FSx). Repurchasing Repurchasing involves moving to a completely different, typically SaaS-based, product. Architectural Outcome: The legacy application is abandoned. Data is exported and imported into the new SaaS platform. Exam Indicator: The scenario mentions moving from an on-premises CRM to …
12. Exam Simulation & Trap Avoidance
The Anatomy of a Trap You are 90 minutes into the exam. Your cognitive load is peaking. You encounter a question describing a legacy financial application migrating to AWS. It requires strict ordering of messages, high durability, and the ability to process messages exactly once. You immediately look for SQS FIFO. The options present SQS FIFO with a Visibility Timeout, SQS FIFO with a Message Group ID, Kinesis Data Streams, and MQ for Apache ActiveMQ. Under time pressure, the brain pattern-matches "strict ordering + exactly-once" and gravitates toward SQS FIFO. You select it and move on. You just fell for a distractor trap. The hidden indicator was "legacy application." If the scenario mentions lifting and shifting an existing application that relies on specific messaging protocols (like JMS or AMQP), the architectural judgment dictates Amazon MQ, not building a new cloud-native SQS pipeline. At the advanced stage, you already know the services. The exam is no longer a test of knowledge; it is a test of executive function under stress. This chapter transitions your preparation from passive learning to active simulation, focusing on question dissection, trap avoidance, and final-week optimization. Full-Length Simulation and Structured Post-Exam Analysis Reading documentation and doing fragmented practice questions builds Knowledge Recall, but it does not build the stamina required for Architectural Judgment under a ticking clock. You must execute two full-length, timed practice exams before sitting for the real certification. Executing the Simulation Do not take these exams casually. Replicate the test center environment as closely as possible. Strict Timing: Adhere strictly to the 130-minute limit. Do not pause. Environment: Use a quiet room, disable notifications, and use only the provided whiteboard/markers for note-taking. Do not look up answers during the exam. Flagging Threshold: Implement a strict flagging threshold. If a question takes more than 90 seconds to parse, flag it and move on. Return to it during your dedicated review window. The Post-Exam Dissection Methodology Your score on a practice exam is secondary to the data it provides. A passing score hides latent weaknesses; a failing score highlights them. For every missed or flagged question, you must perform a structured root cause analysis. Categorize each error into one of three buckets: 1. Knowledge Gap You simply did not know the technical limitation of the service. Example: You selected AWS Global Accelerator to route TCP traffic to a static IP in a different Region, not realizing it only routes to AWS endpoints. Remediation: Targeted study of the specific service limitation. 2. Misread (Cognitive Fatigue) You knew the material, but you missed a critical keyword in the question stem. Example: The question asked for the most cost-effective storage for data accessed once a month. You selected S3 …
Continue learning
- Pass the AWS Solutions Architect Associate ExamPass the AWS Solutions Architect Associate Exam — a free intermediate-level guide covering how to pass the aws solutions architect exam. Learn with...
- PMP Exam Prep: Complete Study Guide for 2024PMP Exam Prep: Complete Study Guide for 2024 — a free intermediate-level guide covering how to pass the pmp exam. Learn with clear explanations, real...
- CMA Medical Assistant Exam Prep: Complete Study GuideCMA Medical Assistant Exam Prep: Complete Study Guide — a free intermediate-level guide covering how to pass the cma medical assistant exam. Learn with...
- CompTIA Network+ Exam Study RoadmapCompTIA Network+ Exam Study Roadmap — a free intermediate-level guide covering how to pass the comptia network+ exam. Learn with clear explanations,...