Amazon Web Services
Advanced
SAP-C02
AWS Certified Solutions Architect - Professional
The AWS Certified Solutions Architect - Professional (SAP-C02) validates advanced technical skills and experience in designing distributed applications and systems on the AWS platform. This is one of the most challenging and prestigious cloud certifications available, targeted at individuals with two or more years of comprehensive hands-on experience.
The exam covers four domains: Design Solutions for Organizational Complexity (26%), Design for New Solutions (29%), Continuous Improvement for Existing Solutions (25%), and Accelerate Workload Migration and Modernization (20%). Candidates must demonstrate the ability to design and deploy dynamically scalable, highly available, fault-tolerant, and reliable applications, select appropriate AWS services for complex requirements, migrate complex multi-tier applications, and design enterprise-wide cost control strategies.
This exam is significantly more difficult than the Associate-level exam. Questions are scenario-based with longer question stems and multiple correct answers. Key areas include multi-account strategies with AWS Organizations, hybrid connectivity with Direct Connect and Transit Gateway, advanced networking with VPC peering and PrivateLink, data lake architectures, disaster recovery strategies, and complex migration scenarios. The SAP-C02 version was released in November 2022.
Updated Nov 2024
Cloud Computing
75
Questions
6
Tests Pratiques
75%
Score de Réussite
38
Vues
0
Tentatives Totales
0%
Score Moyen
0%
Taux de Réussite
0
Discussions
SAP-C02 Practice Exam 1
Comprehensive practice exam covering core AWS Solutions Architect Professional topics including multi-account strategies, organizational complexity, advanced solution design, operational improvements, and migration scenarios across 75 challenging professional-level questions.
75 Q
180 minutes
75%
SAP-C02 Practice Exam 2
Practice Exam 2 for AWS Certified Solutions Architect - Professional (SAP-C02). Covers all exam domains with professional-level scenario questions on hybrid cloud architectures and advanced networking.
75 Q
180 minutes
75%
SAP-C02 Practice Exam 3
Practice Exam 3 for AWS Certified Solutions Architect - Professional (SAP-C02). Covers all exam domains with professional-level scenario questions on data architectures and analytics.
75 Q
180 minutes
75%
SAP-C02 Practice Exam 4
Practice Exam 4 for AWS Certified Solutions Architect - Professional (SAP-C02). Covers all exam domains with professional-level scenario questions on advanced security governance and compliance.
75 Q
180 minutes
75%
SAP-C02 Practice Exam 5
Practice Exam 5 for AWS Certified Solutions Architect - Professional (SAP-C02). Covers all exam domains with professional-level scenario questions on cost optimization and operational excellence.
75 Q
180 minutes
75%
SAP-C02 Practice Exam 6
Practice Exam 6 for AWS Certified Solutions Architect - Professional (SAP-C02). Covers all exam domains with professional-level scenario questions on migration strategies and application modernization.
75 Q
180 minutes
75%
Débloquer Tout le Contenu pour SAP-C02
6 Test(s) Pratique(s) + Flash Cards — accès de 3 mois
€39.99
€26.99
Économisez 30%
ou inclus avec l'abonnement Mensuel / Pack de Contenu
Aperçu (10 / 120)
What is AWS Organizations and how does it enable centralized management of multiple AWS accounts?
AWS Organizations is a free account management service that allows you to consolidate multiple AWS accounts into an organization that you create and centrally manage. It provides a hierarchical structure with a management account (formerly master account) at the root and member accounts organized into organizational units (OUs). The management account is the payer account responsible for all charges incurred by member accounts and has full administrative control over the organization. AWS Organizations supports two feature sets: consolidated billing only, which provides a single bill across all accounts with volume pricing benefits, and all features, which adds service control policies, tag policies, backup policies, and AI services opt-out policies. You can invite existing AWS accounts to join your organization or create new accounts programmatically using the CreateAccount API. Each account maintains its own IAM users, roles, and resources, providing strong blast radius isolation. Organizations integrates with many AWS services as a trusted service, enabling organization-wide features like CloudTrail organization trails, GuardDuty organization detectors, and Security Hub organization configurations. The Organizations API supports automation of account provisioning, OU management, and policy attachment through infrastructure-as-code tools like CloudFormation StackSets. For the SAP-C02 exam, understand that Organizations is the foundational service for multi-account architecture, and the management account should be restricted to organization management tasks only, not application workloads.
What are Service Control Policies (SCPs) and how do they work within AWS Organizations?
Service Control Policies (SCPs) are organization-level permission guardrails that define the maximum available permissions for IAM entities in member accounts. SCPs do not grant permissions; they restrict what actions IAM users and roles can perform, acting as a permissions boundary at the account level. SCPs use the same JSON policy language as IAM policies with Effect, Action, Resource, and Condition elements. They support both allow-list and deny-list strategies. The deny-list approach starts with a default FullAWSAccess policy and adds explicit deny statements for restricted services or actions. The allow-list approach removes the default FullAWSAccess policy and explicitly lists only permitted services. Deny-list is recommended because it requires less maintenance as new services launch. SCPs can be attached to the organization root, OUs, or individual accounts, and they inherit down the hierarchy. An action must be allowed at every level of the SCP chain from root to account. SCPs do not affect the management account, which always retains full permissions regardless of attached SCPs. SCPs do not affect service-linked roles, which enable other AWS services to integrate with Organizations. Key SCP use cases include preventing member accounts from leaving the organization, restricting which AWS regions can be used, preventing disabling of CloudTrail or GuardDuty, and enforcing encryption requirements. SCPs apply to all IAM principals in the account including the root user, but do not affect resource-based policies that grant cross-account access. For the exam, remember that the effective permissions for an IAM entity are the intersection of SCPs, IAM permission boundaries, identity policies, and resource policies.
How do Organizational Units (OUs) work and what is the recommended OU structure for enterprise organizations?
Organizational Units (OUs) are logical groupings of AWS accounts within an AWS Organization, forming a tree hierarchy under the organization root. An OU can contain accounts and other OUs, enabling nested structures up to five levels deep. Each account can belong to exactly one OU. OUs serve as targets for Service Control Policies, tag policies, backup policies, and other organization policies, allowing differentiated governance for different account groupings. The AWS recommended OU structure follows a pattern designed for enterprise organizations. The Security OU contains the log archive account (centralized logging from all accounts) and the security tooling account (running GuardDuty, Security Hub, and detective controls). The Infrastructure OU holds shared services accounts for networking, DNS, directory services, and Transit Gateway management. The Sandbox OU provides developer experimentation accounts with relaxed SCPs but spending limits. The Workloads OU is divided into sub-OUs for production and non-production workloads, each containing application-specific accounts. The Policy Staging OU tests new SCPs and organization policies before applying them to production OUs. The Suspended OU quarantines accounts that are being decommissioned with restrictive deny-all SCPs. The Deployments OU hosts CI/CD pipeline accounts. Additional OUs may include Transitional for accounts migrated from outside the organization and Individual Business Users for non-technical accounts. This structure separates concerns, applies the principle of least privilege at scale, and enables workload isolation. For the exam, understand how OU hierarchy affects SCP inheritance and how to design OU structures that balance governance with operational flexibility.
What is AWS Control Tower and how does it automate multi-account governance with landing zones?
AWS Control Tower is a managed service that automates the setup and governance of a secure, multi-account AWS environment called a landing zone. It builds on AWS Organizations, AWS IAM Identity Center, AWS CloudTrail, AWS Config, and AWS Service Catalog to provide a pre-configured, best-practice environment. The landing zone includes a management account, a log archive account in a Security OU for centralized CloudTrail and Config logs, and an audit account in the same Security OU for cross-account security auditing. Control Tower provisions these foundational accounts automatically and configures organization-level CloudTrail, Config rules, and SSO. Account Factory is the self-service provisioning mechanism within Control Tower that allows authorized users to create new AWS accounts from pre-approved templates. It integrates with Service Catalog to provide a catalog of account configurations including VPC settings, region selections, and organizational unit placement. Account Factory for Terraform (AFT) extends this capability for organizations using Terraform for infrastructure as code. Control Tower provides a dashboard showing compliance status across all enrolled accounts. It supports account enrollment to bring existing AWS accounts under Control Tower governance. When you enable new AWS regions or add OUs, Control Tower extends its governance automatically. For the exam, understand that Control Tower is the recommended starting point for organizations building multi-account environments, as it automates many manual setup steps. Control Tower manages the lifecycle of controls, detects drift from the desired configuration, and provides remediation guidance. It is distinct from Organizations in that it is an opinionated, automated governance layer built on top of Organizations.
What are AWS Control Tower guardrails (controls) and how do preventive, detective, and proactive controls differ?
AWS Control Tower guardrails, now called controls, are pre-packaged governance rules that enforce policies across your multi-account environment. They are categorized by behavior type into three groups. Preventive controls use Service Control Policies (SCPs) to prevent actions that violate the policy. They are always enforced and cannot be bypassed by any IAM entity in the affected accounts. Examples include disallowing changes to the log archive bucket policy, preventing root user access key creation, and disallowing public read access to S3 buckets. When a preventive control is enabled, the corresponding SCP is automatically attached to the target OU. Detective controls use AWS Config rules to continuously monitor account configurations and report non-compliant resources. They do not prevent non-compliant actions but detect and alert on them. Examples include detecting whether MFA is enabled for the root user, detecting publicly accessible RDS instances, and detecting unencrypted EBS volumes. Detective controls show compliance status in the Control Tower dashboard. Proactive controls use AWS CloudFormation hooks to validate resources before they are provisioned. They examine CloudFormation templates during deployment and block resource creation if the template violates the policy. This is a shift-left approach that catches violations at deployment time rather than after resources exist. Controls are also categorized by guidance level: mandatory controls are always enabled and cannot be disabled (such as disallowing changes to CloudTrail configuration), strongly recommended controls address common security best practices, and elective controls are optional based on organizational needs. For the exam, understand the enforcement mechanism behind each control type and when to use each approach.
How does AWS Control Tower Account Factory work and what is Account Factory for Terraform (AFT)?
Account Factory is the account provisioning component of AWS Control Tower that enables self-service creation of new AWS accounts following pre-approved configurations. It is backed by AWS Service Catalog and provides a catalog product that authorized users can launch to create new accounts. When creating an account through Account Factory, you specify the account email, account name, target OU, and optionally a VPC configuration and IAM Identity Center user. Account Factory applies the landing zone baseline automatically, enrolling the account in Organizations, enabling CloudTrail, deploying Config rules, configuring SSO access, and attaching the appropriate SCPs based on the target OU. Account Factory supports network baselines that configure VPC with predefined CIDR ranges, subnets, and connectivity options, ensuring network consistency across new accounts. You can customize Account Factory blueprints using Service Catalog to add additional resources like default security groups, IAM roles, or tagging configurations. Account Factory for Terraform (AFT) extends Account Factory with a Terraform-based pipeline for account provisioning and customization. AFT deploys a dedicated pipeline infrastructure in a management account that processes account requests defined as Terraform modules. It supports account customizations through a Git-based workflow where Terraform code is stored in repositories and applied automatically when accounts are created. AFT provides global customizations applied to all accounts and account-specific customizations for individual accounts. It integrates with CI/CD pipelines and supports custom Terraform providers and modules. For the exam, understand that Account Factory is for Service Catalog-based provisioning while AFT is for Terraform-based provisioning, and both ensure consistent, governed account creation.
What are the key components of a multi-account strategy and how do you design account structures for workload isolation?
A multi-account strategy uses separate AWS accounts as the primary isolation boundary for workloads, teams, and environments. Each account provides IAM isolation (users in one account cannot access another by default), resource isolation (API throttling and service limits are per-account), billing isolation (costs are tracked per account), and blast radius containment (a security incident in one account does not propagate to others). Key account types include the management account (organization administration only, no workloads), security accounts (log archive for centralized logging, security tooling for detective controls), infrastructure accounts (shared networking, DNS, directory services), sandbox accounts (developer experimentation with guardrails), and workload accounts (one per application per environment). The recommended pattern is to separate production and non-production workloads into different OUs with different SCPs. Each application team should have dedicated accounts for development, staging, and production, providing full environment isolation. Shared services accounts host resources used across multiple workload accounts, such as container registries, artifact repositories, and shared VPCs through RAM. A dedicated networking account manages Transit Gateway, Direct Connect, VPN connections, and centralized egress through NAT Gateways. CI/CD pipeline accounts host deployment tools that assume roles in target workload accounts. For the exam, understand the trade-offs between fewer large accounts (simpler management but weaker isolation) and many small accounts (stronger isolation but more management overhead). The general recommendation is to err on the side of more accounts because Organizations and Control Tower reduce the management burden.
How does cross-account IAM role assumption work and what are the best practices for cross-account access?
Cross-account IAM role assumption enables principals in one AWS account (the trusting account) to temporarily assume a role in another account (the trusted account) using the AWS Security Token Service (STS) AssumeRole API. The process requires two components: a trust policy on the role in the target account that specifies which principals from the source account can assume it, and an IAM policy in the source account that grants sts:AssumeRole permission for the target role ARN. When a principal assumes a cross-account role, STS returns temporary security credentials (access key, secret key, session token) scoped to the role permissions and valid for a configurable duration (15 minutes to 12 hours). The external ID condition is a best practice for third-party cross-account access that prevents the confused deputy problem, where a malicious actor tricks a service into accessing resources in your account. The external ID is a shared secret between the trusting and trusted parties included as a condition in the trust policy. Role chaining allows a role assumed in one account to assume a role in another account, but the maximum session duration is limited to one hour for chained roles. For cross-account access patterns in Organizations, use aws:PrincipalOrgID condition key to restrict trust policies to accounts within your organization without listing every account ID. Use aws:PrincipalOrgPaths to restrict to specific OUs. Best practices include using the principle of least privilege in role permissions, logging all AssumeRole calls in CloudTrail, using session tags for attribute-based access control, and requiring MFA for sensitive cross-account role assumptions.
What are IAM resource-based policies and how do they enable cross-account resource sharing?
IAM resource-based policies are JSON policies attached directly to AWS resources rather than to IAM identities. They specify which principals (including those from other accounts) can perform which actions on the resource. Unlike identity-based policies that require role assumption, resource-based policies grant cross-account access directly without the principal needing to switch roles. This means the principal retains their original identity and permissions while also gaining access to the shared resource. Key AWS services supporting resource-based policies include S3 (bucket policies), SQS (queue policies), SNS (topic policies), Lambda (function policies), KMS (key policies), Secrets Manager (secret policies), ECR (repository policies), and API Gateway (resource policies). S3 bucket policies are the most common example, allowing you to grant read or write access to specific IAM roles or accounts using Principal elements that specify account IDs or ARNs. KMS key policies are unique because they are mandatory; without a key policy granting access, no IAM policy can authorize KMS operations. For cross-account KMS access, the key policy must allow the external account, and the external account must have IAM policies granting KMS usage. Resource-based policies can use condition keys like aws:PrincipalOrgID to restrict access to principals within your AWS Organization, and aws:SourceAccount or aws:SourceArn to restrict which services or resources can invoke the resource. The key difference from role assumption is that resource-based policies do not provide temporary credentials; the calling principal uses their own credentials. For the exam, understand when to use resource-based policies versus cross-account roles, and how they interact with SCPs in Organizations.
What is AWS Resource Access Manager (RAM) and which resources can be shared across accounts?
AWS Resource Access Manager (RAM) enables you to share AWS resources that you own with other AWS accounts, within or outside your organization, without creating duplicate resources. RAM creates resource shares that specify the resources to share, the principals to share with (accounts, OUs, or the entire organization), and the permissions granted. When integrated with AWS Organizations, RAM can share resources with the entire organization or specific OUs without requiring individual account invitations; the sharing is automatic. Key shareable resources include VPC subnets (enabling multiple accounts to launch resources into a shared VPC), Transit Gateway (allowing multiple accounts to attach their VPCs), Route 53 Resolver rules (centralizing DNS resolution), License Manager configurations (enforcing license compliance across accounts), AWS Network Firewall policies, Prefix Lists, and CodeBuild projects. Sharing VPC subnets is a foundational pattern for centralized networking. The network account creates the VPC and subnets, then shares subnets with workload accounts via RAM. Workload accounts can launch EC2 instances, RDS databases, and other resources into the shared subnets, but they cannot modify the VPC, subnets, route tables, or network ACLs. This enables central network management while distributing workloads. Transit Gateway sharing allows workload accounts to create Transit Gateway attachments from their VPCs to a centrally managed Transit Gateway, establishing hub-and-spoke connectivity. RAM permissions define what participants can do with shared resources. Default permissions are pre-defined by AWS, and customer-managed permissions allow you to create custom permission sets. For the exam, understand RAM as the mechanism for resource sharing without duplication, and know which resources support sharing.
Flash Cards
cartes couvrant les concepts clés de 120 SAP-C02
ou inclus avec l'abonnement Mensuel / Pack de Contenu
110 cartes supplémentaires disponibles après déblocage
Langues Disponibles
English
Japanese
Korean
Simplified Chinese
Spanish
French
German
Italian
Portuguese
Sujets de l'Examen
1
20 Q
Design Solutions for Organizational Complexity
Design network connectivity strategies, prescribe security controls, and design multi-account AWS environments.
2
22 Q
Design for New Solutions
Design deployment strategies, determine security strategy, design reliable and performant architectures.
3
19 Q
Continuous Improvement for Existing Solutions
Determine strategy to improve reliability, performance, security, and cost-effectiveness of existing architectures.
4
14 Q
Accelerate Workload Migration and Modernization
Select and design migration strategies, design and implement new architectures for migrated workloads.
SAP-C02 Cheat Sheet
Guide de référence rapide - 6 sections
AWS Certified Solutions Architect - Professional (SAP-C02)
The SAP-C02 exam validates advanced technical skills and experience in designing distributed applications and systems on the AWS platform. This is one of the most challenging AWS certifications, intended for individuals with two or more years of hands-on experience designing and deploying cloud architecture on AWS. The exam tests your ability to design complex, multi-tier applications, migrate enterprise workloads to the cloud, and implement cost-optimized, resilient, and high-performing architectures at scale.
Exam Details
| Exam Code | SAP-C02 |
| Duration | 180 minutes |
| Number of Questions | 75 questions (65 scored + 10 unscored) |
| Passing Score | 750 / 1000 |
| Cost | $300 USD |
| Validity | 3 years |
| Question Types | Multiple choice (single & multiple select), scenario-based |
| Testing Options | Pearson VUE testing center or online proctored |
| Recommended Experience | 2+ years hands-on AWS experience, Solutions Architect Associate preferred |
| Certification Level | Professional (highest tier) |
Domain Weights
| Domain | Weight |
|---|---|
| Domain 1: Design Solutions for Organizational Complexity | 26% |
| Domain 2: Design for New Solutions | 29% |
| Domain 3: Continuous Improvement for Existing Solutions | 25% |
| Domain 4: Accelerate Workload Migration & Modernization | 20% |
Study Tips
- Domain 2 (New Solutions) carries the most weight at 29%, so master architecture design patterns including serverless, containers, and hybrid connectivity
- Understand multi-account strategies using AWS Organizations, Control Tower, and SCPs inside and out since Domain 1 is worth 26%
- Know DR strategies (backup/restore, pilot light, warm standby, multi-site) and their RPO/RTO trade-offs for Domain 3
- Master the 6 Rs of migration (Rehost, Replatform, Refactor, Repurchase, Retain, Retire) and when to use each for Domain 4
- Questions are scenario-heavy and very long; practice reading comprehension under time pressure
- Focus on cost optimization: know when Reserved Instances, Savings Plans, Spot, and On-Demand are appropriate
- Understand networking deeply: Transit Gateway, Direct Connect, VPN, PrivateLink, VPC peering, and Route 53 routing policies
- Study cross-account and cross-Region patterns; many questions involve multi-account or global architectures
Question Strategy Tips
- Questions are long and scenario-based; read the last sentence first to understand what is being asked, then read the full scenario
- Look for keywords like "least operational overhead", "most cost-effective", "minimize downtime", or "maximize availability"
- Eliminate answers that use services inappropriately or add unnecessary complexity
- AWS managed services are almost always preferred over self-managed alternatives
- When two answers seem equally valid, pick the one with the least operational overhead
- Pay attention to Region constraints, compliance requirements, and data residency mentioned in scenarios
- Flag complex questions and return later; do not spend more than 2.5 minutes per question on first pass
- Use the full 180 minutes; this exam rewards careful reading and deliberate elimination of wrong answers
Key Differences from SAA-C03 (Associate)
- Much deeper focus on multi-account strategies, Organizations, and enterprise-grade governance
- Scenarios are more complex with multiple constraints and competing requirements
- Requires understanding of hybrid architectures, migrations, and global deployments
- Cost optimization questions are more nuanced, requiring analysis of multiple pricing models
- Networking questions go deeper into Transit Gateway, Direct Connect, and complex VPC designs
- Expects familiarity with disaster recovery, business continuity, and high availability patterns at enterprise scale
Recommended Preparation Path
- Step 1 - Foundation: Ensure you have a solid understanding of all core AWS services by completing the Solutions Architect Associate (SAA-C03) or equivalent experience before attempting the Professional exam
- Step 2 - Deep Dive: Study each domain in depth using the AWS Well-Architected Framework whitepapers, focusing on operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability pillars
- Step 3 - Hands-On Labs: Build multi-account environments with Organizations, set up Transit Gateway networks, configure Direct Connect simulations, and implement DR strategies in your own AWS account
- Step 4 - Practice Exams: Take multiple full-length practice exams under timed conditions. Review every wrong answer thoroughly and understand why the correct answer is preferred
- Step 5 - Weak Areas: Identify your weakest domains from practice exams and dedicate additional study time to those areas before scheduling the real exam
Well-Architected Framework Pillars
| Pillar | Focus Areas | Key Services |
|---|---|---|
| Operational Excellence | Automation, IaC, observability, incident management | CloudFormation, Systems Manager, CloudWatch, X-Ray |
| Security | Identity, detection, infrastructure protection, data protection | IAM, GuardDuty, WAF, KMS, Shield, Security Hub |
| Reliability | Foundations, change management, failure management | Auto Scaling, Multi-AZ, Route 53, S3, Backup |
| Performance Efficiency | Selection, review, monitoring, trade-offs | CloudFront, ElastiCache, Aurora, Lambda, Global Accelerator |
| Cost Optimization | Expenditure awareness, cost-effective resources, matching supply and demand | Cost Explorer, Budgets, Savings Plans, Spot Instances, S3 Lifecycle |
| Sustainability | Region selection, user behavior patterns, software and architecture patterns | Graviton instances, Serverless, Auto Scaling, S3 Intelligent-Tiering |
Exam Day Checklist
- Arrive 15 minutes early for testing center or start your online proctored check-in 30 minutes before the scheduled time
- Bring two forms of valid identification (one with photo) for testing center; clear your workspace for online proctoring
- You have 180 minutes for 75 questions, which gives you approximately 2 minutes and 24 seconds per question
- Use the "Flag for Review" feature liberally on questions you are unsure about; you can return to them later
- Read every word in the scenario carefully as questions often contain critical constraints in the middle of the text
- Your score is calculated on a scale of 100-1000; you need 750 to pass, which means you need to answer approximately 72-75% correctly
- Results are typically available within 1-5 business days through your AWS Certification account
- If you do not pass, you can retake the exam after 14 days; there is no limit on the number of attempts
- Request accommodations in advance if English is not your first language (extra 30 minutes available for non-native speakers)
Recommended AWS Whitepapers
- AWS Well-Architected Framework: Comprehensive guide to the six pillars; essential reading for understanding trade-offs between different architectural approaches
- Organizing Your AWS Environment: Best practices for multi-account strategy using Organizations and Control Tower; directly relevant to Domain 1
- AWS Migration Whitepaper: Covers the three-phase migration process (Assess, Mobilize, Migrate) and the 6 Rs; essential for Domain 4
- Disaster Recovery of Workloads on AWS: Deep dive into the four DR strategies with architecture patterns; critical for Domain 3
- Building a Scalable and Secure Multi-VPC AWS Network: Transit Gateway, Direct Connect, and hybrid connectivity patterns; frequently tested across all domains
Domain 1: Design Solutions for Organizational Complexity (26%)
This domain focuses on designing architectures that span multiple AWS accounts, Regions, and organizational boundaries. You must understand how to use AWS Organizations, Control Tower, and identity management to govern complex enterprise environments. Multi-account patterns, centralized logging, cross-account access, and policy-based controls are critical topics for this domain.
AWS Organizations
AWS Organizations enables centralized management of multiple AWS accounts. It provides consolidated billing, hierarchical organizational units (OUs), and policy-based controls across your entire AWS environment.
| Feature | Description | Key Use Case |
|---|---|---|
| Management Account | Root account that creates the organization | Billing, organization-wide policies, account creation |
| Organizational Units | Hierarchical grouping of accounts | Separate prod/dev/staging, apply policies by OU |
| Consolidated Billing | Single payer for all accounts | Volume discounts, RI/Savings Plan sharing |
| All Features Mode | Full governance including SCPs | Enterprise governance with policy enforcement |
Service Control Policies (SCPs)
SCPs are organization-level policies that set the maximum permissions for member accounts. SCPs do not grant permissions; they only restrict what actions are allowed. They apply to all IAM users and roles in the affected accounts, including the account root user.
- Deny List Strategy: Start with FullAWSAccess SCP attached, then add explicit deny statements for restricted services. This is the default and most common approach for most organizations
- Allow List Strategy: Remove FullAWSAccess SCP and explicitly allow only needed services. More restrictive but harder to manage at scale
- Inheritance: SCPs cascade down from the root to OUs to accounts. Effective permissions are the intersection of all SCPs in the hierarchy path
- Management Account Exception: SCPs do not affect the management account, even if attached. This is why workloads should never run in the management account
- Common Deny Patterns: Prevent disabling CloudTrail, denying access to specific Regions, preventing root user actions, blocking S3 public access
AWS Control Tower
Control Tower provides an automated way to set up and govern a secure multi-account AWS environment based on AWS best practices. It builds on Organizations, AWS SSO, and other services to create a landing zone.
- Landing Zone: Pre-configured multi-account environment with security and compliance guardrails. Includes Log Archive and Audit accounts by default
- Guardrails (Controls): Preventive guardrails use SCPs to block non-compliant actions. Detective guardrails use AWS Config rules to detect non-compliance. Proactive guardrails use CloudFormation hooks
- Account Factory: Automates provisioning of new accounts with pre-configured settings, VPC designs, and guardrails. Can be customized with Account Factory for Terraform (AFT)
- Dashboard: Centralized view of compliance status across all enrolled accounts and OUs
- Customizations for Control Tower (CfCT): Deploy custom CloudFormation templates and SCPs to accounts managed by Control Tower
Multi-Account Patterns
| Pattern | Description | When to Use |
|---|---|---|
| Security Account | Centralized security tooling (GuardDuty, Security Hub, Detective) | Every enterprise deployment |
| Log Archive Account | Centralized CloudTrail, VPC Flow Logs, Config logs | Compliance, auditing, forensics |
| Shared Services Account | Active Directory, DNS, shared tools, CI/CD | Common infrastructure shared across accounts |
| Network Account | Transit Gateway, Direct Connect, shared VPCs | Centralized networking and connectivity |
| Sandbox Account | Isolated experimentation with budget limits | Developer experimentation, proof of concepts |
Centralized Logging & Monitoring
- CloudTrail Organization Trail: Single trail that logs API activity across all accounts to a centralized S3 bucket in the Log Archive account. Enable log file integrity validation for tamper detection
- AWS Config Aggregator: Collects Config data from multiple accounts and Regions into a single aggregator account. Useful for organization-wide compliance reporting
- GuardDuty Delegated Admin: Designate a security account as delegated administrator. Automatically enables GuardDuty in all org accounts. Findings centralized in the admin account
- Security Hub: Aggregates security findings from GuardDuty, Inspector, Macie, Firewall Manager, and third-party tools. Supports cross-Region aggregation
- CloudWatch Cross-Account Observability: Share CloudWatch metrics, logs, and traces across accounts. Set up monitoring accounts with source accounts sharing data
IAM Identity Center (AWS SSO)
IAM Identity Center is the recommended service for managing workforce access to multiple AWS accounts and business applications. It integrates with external identity providers via SAML 2.0 or SCIM.
- Permission Sets: Define permissions as IAM policies and assign them to users/groups for specific accounts. A permission set creates an IAM role in each assigned account
- Identity Sources: Built-in directory, Active Directory (via AD Connector or AWS Managed Microsoft AD), or external IdP (Okta, Azure AD, etc.)
- Multi-Account Permissions: Assign different permission sets to different accounts from a single location. Users see only the accounts they have access to in the SSO portal
- Application Assignments: Provide SSO access to SAML 2.0 business applications like Salesforce, Office 365, and custom apps
Permission Boundaries & Advanced IAM
- Permission Boundaries: Set the maximum permissions an IAM entity can have. Used to delegate administration safely; even if a developer creates roles, those roles cannot exceed the boundary
- Session Policies: Inline policies passed when assuming a role or federating. Further restrict the effective permissions for that session only
- Cross-Account Roles: Create IAM roles in target accounts that trusted accounts can assume using sts:AssumeRole. Preferred over sharing long-term credentials
- Resource-Based Policies: Policies attached to resources (S3 buckets, SQS queues, KMS keys) that grant cross-account access without needing a role assumption
Resource Access Manager (RAM)
AWS RAM allows you to share resources across accounts within or outside your organization. This avoids resource duplication and reduces costs.
- Shareable Resources: VPC subnets, Transit Gateways, Route 53 Resolver rules, License Manager configs, Aurora DB clusters, CodeBuild projects, and more
- Organization Sharing: When sharing within an organization, no invitation acceptance is needed. Resources appear automatically in member accounts
- VPC Subnet Sharing: Share subnets from a central networking account. Each account can launch resources into shared subnets but manages its own resources independently
- Transit Gateway Sharing: Share a Transit Gateway from the network account so all accounts can attach their VPCs to the centralized hub
Tag Policies & Backup Policies
- Tag Policies: Organization policies that enforce standardized tag keys and allowed values across accounts. Help maintain consistent cost allocation and resource management
- Backup Policies: Organization policies that define AWS Backup plans centrally and apply them across accounts. Ensure compliance with data protection requirements
- AI Services Opt-Out Policies: Control whether AWS AI services can store and use content processed by those services for service improvement
- Policy Inheritance: All organization policies inherit through the OU hierarchy, allowing different policies at different levels with merging behavior
Cross-Account Access Patterns
| Method | How It Works | Best For |
|---|---|---|
| Cross-Account IAM Roles | Target account creates a role with trust policy allowing source account to assume it via sts:AssumeRole | Programmatic and console access, temporary credentials, most common pattern |
| Resource-Based Policies | Attach policies directly to resources (S3, SQS, KMS, Lambda) granting access to other accounts | When the caller does not need to assume a role; simpler for specific resource access |
| AWS RAM Sharing | Share resources (subnets, Transit Gateways, etc.) via Resource Access Manager | Infrastructure sharing within an organization without duplicating resources |
| IAM Identity Center | Centralized SSO with permission sets assigned to users/groups per account | Human access management across multiple accounts via single sign-on portal |
| Organizations Delegated Admin | Designate member accounts as delegated administrators for specific AWS services | Security Hub, GuardDuty, Macie, Config; avoids using management account for service administration |
Compliance & Governance Tools
- AWS Config: Records configuration changes for resources. Config Rules evaluate compliance. Conformance Packs group related rules. Remediation actions auto-fix non-compliant resources via SSM Automation
- AWS Audit Manager: Continuously audit AWS usage for compliance. Pre-built frameworks for GDPR, PCI DSS, SOC 2, HIPAA. Collects evidence automatically from Config, CloudTrail, and Security Hub
- AWS Artifact: On-demand access to AWS compliance reports and agreements. Download SOC reports, PCI attestations, and sign BAAs (Business Associate Addendums) for HIPAA
- AWS CloudTrail Lake: Managed data lake for CloudTrail events. SQL-based queries across organization trails. Retention up to 7 years. Replaces need for custom Athena+S3 analysis pipelines
- Service Catalog: Centralized portfolio of approved CloudFormation products. Administrators define products; end users launch approved resources without needing full CloudFormation access. Enforces standards and tagging
- AWS License Manager: Track and manage software licenses (Oracle, SQL Server, SAP). Set license rules, enforce limits, and track usage across accounts. Integrates with Systems Manager inventory
Networking for Multi-Account
- Centralized Egress: Route all internet-bound traffic through a central networking account using Transit Gateway. Inspect traffic with Network Firewall or third-party appliances before NAT Gateway
- Centralized VPC Endpoints: Create interface VPC endpoints in a shared services VPC and share access via Transit Gateway or PrivateLink. Reduces endpoint costs across accounts
- DNS Resolution: Use Route 53 Resolver with shared rules across accounts via RAM. Forward DNS queries between on-premises and AWS, or between VPCs. Resolver endpoints in the central network account
- Network Firewall: Stateful and stateless inspection of VPC traffic. Deploy in the centralized inspection VPC. Supports Suricata-compatible IPS rules for threat detection
- Firewall Manager: Centrally manage WAF rules, Shield Advanced, security groups, Network Firewall, and Route 53 Resolver DNS Firewall rules across all organization accounts from a single administrator account
Domain 2: Design for New Solutions (29%)
This is the highest-weighted domain on the exam. It covers designing new architectures that meet business and technical requirements including performance, cost, security, reliability, and operational excellence. You must understand compute, storage, database, networking, messaging, and caching options and know when to apply each pattern. Serverless, container, and hybrid designs are heavily tested.
Architecture Patterns
| Pattern | Description | Key Services |
|---|---|---|
| Multi-Tier Web App | Separate presentation, application, and data tiers with load balancing | ALB, EC2/ECS, RDS/Aurora, ElastiCache |
| Serverless | Event-driven, no server management, auto-scaling | API Gateway, Lambda, DynamoDB, S3, Step Functions |
| Microservices | Decoupled services communicating via APIs or events | ECS, EKS, ALB, SQS, SNS, EventBridge |
| Event-Driven | Loosely coupled producers and consumers via event bus | EventBridge, SNS, SQS, Lambda, Kinesis |
| Data Lake | Centralized repository for structured and unstructured data | S3, Glue, Athena, Lake Formation, Redshift Spectrum |
| Hybrid Cloud | On-premises integrated with AWS via connectivity | Direct Connect, VPN, Storage Gateway, Outposts |
Compute Selection Guide
| Service | Best For | Key Considerations |
|---|---|---|
| EC2 | Full OS control, custom AMIs, GPU workloads, licensing | Instance families, placement groups, Spot/RI/Savings Plans |
| Lambda | Short-running event-driven functions (up to 15 min) | Cold starts, 10 GB memory max, 512 MB /tmp (10 GB with EFS), concurrency limits |
| ECS Fargate | Containers without managing EC2 instances | No cluster management, per-second billing, task-level isolation |
| ECS on EC2 | Containers with control over underlying instances | GPU support, Spot instances, custom AMIs, more cost-effective at scale |
| EKS | Kubernetes workloads, multi-cloud portability | Kubernetes ecosystem, complex but portable, Fargate or EC2 data plane |
| App Runner | Simple containerized web apps with minimal config | Source code or container image, auto-scaling, least operational overhead for web apps |
Storage Selection Guide
| Service | Type | Best For |
|---|---|---|
| S3 | Object storage | Data lakes, backups, static websites, any unstructured data. Use Intelligent-Tiering for unknown access patterns |
| EBS | Block storage | EC2 boot volumes, databases. gp3 for general, io2 for high IOPS, st1 for throughput |
| EFS | Network file system (NFS) | Shared file access across EC2/Lambda/ECS, POSIX-compliant, auto-scales |
| FSx for Lustre | High-performance parallel file system | HPC, ML training, can integrate with S3. Sub-millisecond latency |
| FSx for Windows | Windows file server (SMB) | Windows workloads, Active Directory integration, DFS namespaces |
| FSx for NetApp ONTAP | Multi-protocol (NFS, SMB, iSCSI) | Migrating NetApp workloads, multi-protocol access, data deduplication |
Database Selection Guide
| Service | Type | Best For |
|---|---|---|
| Aurora | Relational (MySQL/PostgreSQL) | Production relational workloads, up to 5x MySQL / 3x PostgreSQL performance, Global Database for multi-Region |
| DynamoDB | Key-value / document NoSQL | Single-digit millisecond latency at any scale, Global Tables for multi-Region, DAX for microsecond caching |
| ElastiCache | In-memory cache (Redis/Memcached) | Session stores, leaderboards, real-time analytics. Redis for persistence and replication, Memcached for simple caching |
| Redshift | Data warehouse (columnar) | OLAP, complex SQL analytics, petabyte-scale data. Redshift Spectrum queries S3 directly |
| Neptune | Graph database | Social networks, recommendation engines, fraud detection, knowledge graphs |
| DocumentDB | Document database (MongoDB-compatible) | MongoDB workloads migrated to AWS, content management, catalogs |
Networking & Connectivity
| Service | Description | Key Details |
|---|---|---|
| VPC Peering | Direct connection between two VPCs | Non-transitive, works cross-Region and cross-account, no overlapping CIDRs |
| Transit Gateway | Hub-and-spoke network connectivity | Connects thousands of VPCs, VPNs, Direct Connect. Supports inter-Region peering. Route tables for segmentation |
| Direct Connect | Dedicated private connection to AWS | 1 Gbps or 10 Gbps dedicated, or hosted connections. Lead time of weeks/months. Use VPN as backup |
| Direct Connect Gateway | Connect DX to multiple VPCs across Regions | Single DX connection reaches VPCs in different Regions via DXGW + Transit Gateway |
| AWS PrivateLink | Private connectivity to services without internet | Interface VPC endpoints, expose services to other VPCs/accounts privately. No NAT, no IGW needed |
| Site-to-Site VPN | Encrypted tunnel over the internet | Quick to set up, up to 1.25 Gbps per tunnel, use as Direct Connect backup |
| Global Accelerator | Anycast IPs using AWS global network | Fixed IP addresses, health-check failover, improved performance for global users via AWS backbone |
Serverless Patterns
- API Gateway + Lambda + DynamoDB: Classic serverless API pattern. Use API Gateway caching and DynamoDB DAX to reduce latency and cost. Enable throttling to protect backend
- S3 Event + Lambda: Process file uploads automatically. Use for image resizing, ETL triggers, log processing. S3 Event Notifications or EventBridge for routing
- Step Functions Orchestration: Coordinate multiple Lambda functions, handle retries, error handling, and parallel execution. Standard workflows for long-running, Express for high-volume short-duration
- SQS + Lambda: Decouple producers from consumers. Lambda polls SQS with event source mapping. Configure batch size and visibility timeout. Use DLQ for failed messages
- EventBridge + Lambda: React to events from AWS services, SaaS applications, or custom sources. Rules route events to targets. Supports content-based filtering and transformation
- Kinesis + Lambda: Process real-time streaming data. Use enhanced fan-out for dedicated throughput per consumer. Lambda processes batches from Kinesis shards
Messaging & Integration
- SQS Standard: At-least-once delivery, nearly unlimited throughput, best-effort ordering. Use for decoupling and buffering
- SQS FIFO: Exactly-once processing, strict ordering by message group. 3,000 msg/sec with batching. Use when order matters
- SNS: Pub/sub messaging. Fan-out to multiple subscribers (SQS, Lambda, HTTP, email). Use with SQS for fan-out pattern
- EventBridge: Serverless event bus. Content-based routing, schema registry, archive and replay events. Replaces CloudWatch Events
- Amazon MQ: Managed message broker for ActiveMQ and RabbitMQ. Use when migrating apps that use standard messaging protocols (JMS, AMQP, MQTT, STOMP)
- Kinesis Data Streams: Real-time data streaming. Shard-based throughput (1 MB/s in, 2 MB/s out per shard). Retention up to 365 days
Caching Strategies
- CloudFront: CDN for static and dynamic content. Use Origin Access Control (OAC) with S3, Lambda@Edge for customization, Field-Level Encryption for sensitive data
- ElastiCache Redis: In-memory data store with persistence, replication, and clustering. Use for session management, leaderboards, and real-time analytics
- DynamoDB DAX: Microsecond read latency for DynamoDB. Write-through cache, compatible with DynamoDB API. Drop-in replacement
- API Gateway Caching: Cache API responses at the stage level. TTL configurable, cache key based on request parameters. Reduces backend calls
Domain 3: Continuous Improvement for Existing Solutions (25%)
This domain covers improving the reliability, performance, security, and cost-efficiency of existing AWS workloads. Key topics include disaster recovery strategies, monitoring and observability, CI/CD pipelines, automation, performance tuning, and scaling strategies. Understanding the trade-offs between different DR approaches and their RPO/RTO implications is critical for this domain.
Disaster Recovery Strategies
AWS defines four DR strategies with increasing cost and decreasing recovery time. Choosing the right strategy depends on your RPO (Recovery Point Objective) and RTO (Recovery Time Objective) requirements.
| Strategy | RPO | RTO | Cost | How It Works |
|---|---|---|---|---|
| Backup & Restore | Hours | 24h+ | $ | Regularly back up data to S3/Glacier. Restore infrastructure from backups during disaster. Lowest cost, highest recovery time |
| Pilot Light | Minutes | 10s of min | $$ | Core infrastructure (database) running in DR Region at minimal capacity. Scale up compute on failover. Data is replicated continuously |
| Warm Standby | Seconds | Minutes | $$$ | Scaled-down but fully functional copy running in DR Region. Scale up to production load on failover. Faster than pilot light |
| Multi-Site Active/Active | Near zero | Near zero | $$$$ | Full production in multiple Regions simultaneously. Route 53 distributes traffic. Instant failover, highest cost |
DR Implementation Details
- Aurora Global Database: Cross-Region replication with less than 1 second lag. Promote secondary Region in under 1 minute for RPO of 1 second and RTO of under 1 minute
- DynamoDB Global Tables: Multi-Region, multi-active replication. Automatic conflict resolution with last-writer-wins. Sub-second replication between Regions
- S3 Cross-Region Replication: Asynchronous replication of objects between buckets in different Regions. Use for compliance, latency reduction, and DR. Supports same-account and cross-account
- Route 53 Health Checks: Monitor endpoint health and automatically failover DNS records. Use failover routing policy for active-passive, weighted or latency-based for active-active
- AWS Elastic Disaster Recovery (DRS): Continuous block-level replication of on-premises or cloud servers. Launches recovery instances in minutes. Replaces CloudEndure Disaster Recovery
- AWS Backup: Centralized backup management across services. Cross-Region and cross-account backup copies. Backup plans with lifecycle policies and retention rules
Monitoring & Observability
| Service | Purpose | Key Features |
|---|---|---|
| CloudWatch Metrics | Collect and track resource metrics | Custom metrics, anomaly detection, metric math, composite alarms, cross-account dashboards |
| CloudWatch Logs | Centralized log management | Log Insights for queries, metric filters, subscription filters to Kinesis/Lambda/OpenSearch |
| CloudWatch Alarms | Automated alerting and actions | Threshold and anomaly-based, composite alarms, auto-scaling triggers, SNS notifications |
| X-Ray | Distributed tracing | Trace requests across microservices, identify bottlenecks, service maps, latency analysis |
| CloudTrail | API activity auditing | Management events (free), data events (paid), organization trail, CloudTrail Lake for SQL queries |
| EventBridge | Event-driven automation | React to AWS events in real time, trigger Lambda/SSM/Step Functions automatically |
CI/CD & Automation
- CodePipeline: Orchestrates the end-to-end release process. Source (CodeCommit/GitHub/S3), Build (CodeBuild), Deploy (CodeDeploy/CloudFormation/ECS/Elastic Beanstalk). Supports manual approval gates
- CodeDeploy: Automated deployment to EC2, Lambda, or ECS. Deployment strategies: in-place, blue/green, canary, linear. Automatic rollback on health check failure
- CloudFormation: Infrastructure as Code. Stacks, nested stacks, StackSets for multi-account/multi-Region deployment. Drift detection, change sets for preview. Use conditions for environment-specific resources
- AWS CDK: Define infrastructure using familiar programming languages (TypeScript, Python, Java, etc.). Synthesizes to CloudFormation templates. Higher-level constructs for faster development
- Systems Manager: Operational hub for managing infrastructure. Run Command for remote execution, Patch Manager for patching, Session Manager for secure shell access without SSH keys, Parameter Store for configuration
- SSM Automation: Predefined or custom runbooks for common operational tasks. Approval workflows, multi-account/multi-Region execution, event-driven triggers via EventBridge
Performance Optimization
- CloudFront Optimization: Cache at edge locations, use Origin Shield for additional caching layer, compress content with gzip/Brotli, use Lambda@Edge for dynamic content at edge
- Database Performance: Read replicas for read-heavy workloads, ElastiCache for hot data, Aurora Auto Scaling for read replicas, Redshift concurrency scaling for peak query loads
- S3 Performance: Multipart upload for large objects (required for 5 GB+, recommended for 100 MB+), S3 Transfer Acceleration for global uploads, byte-range fetches for parallel downloads
- EC2 Placement Groups: Cluster for low-latency HPC, Spread for maximum availability (7 instances per AZ), Partition for large distributed workloads like HDFS/Cassandra
- EBS Optimization: Use gp3 to independently set IOPS/throughput, io2 Block Express for sub-millisecond latency, RAID 0 for performance (RAID 1 not recommended; use EBS snapshots)
Scaling Strategies
- EC2 Auto Scaling: Target tracking (simplest, e.g., keep CPU at 50%), step scaling (react in steps), scheduled scaling (predictable patterns), predictive scaling (ML-based forecasting)
- Application Auto Scaling: Scale ECS tasks, DynamoDB tables, Aurora replicas, Lambda provisioned concurrency, Spot Fleet. Uses target tracking, step, or scheduled policies
- DynamoDB Scaling: On-demand mode auto-scales instantly (pay per request). Provisioned mode with auto-scaling adjusts read/write capacity based on utilization target
- Aurora Auto Scaling: Add or remove read replicas based on CloudWatch metrics. Minimum 1, maximum 15 replicas. Combine with Reader endpoint for automatic load distribution
- Lambda Concurrency: Reserved concurrency guarantees capacity for a function. Provisioned concurrency eliminates cold starts by pre-initializing execution environments
Cost Optimization
- Savings Plans: Commit to consistent usage ($/hour) for 1 or 3 years. Compute Savings Plans (most flexible, covers EC2, Lambda, Fargate), EC2 Instance Savings Plans (specific family/Region)
- Reserved Instances: 1 or 3 year commitment for specific instance type. Standard (up to 72% discount, can sell on Marketplace) or Convertible (up to 66%, can change instance family)
- Spot Instances: Up to 90% discount for fault-tolerant, flexible workloads. Use Spot Fleet with diversified allocation, handle interruptions with 2-minute warning. Good for batch, CI/CD, big data
- S3 Lifecycle Policies: Transition objects between storage classes based on age. S3 Standard -> Infrequent Access (30 day min) -> Glacier Instant/Flexible/Deep Archive. Delete incomplete multipart uploads
- Compute Optimizer: ML-based recommendations for right-sizing EC2, EBS, Lambda, and ECS on Fargate. Analyzes utilization patterns and suggests optimal configurations
- Cost Explorer & Budgets: Analyze spending patterns, forecast future costs, create budget alerts. Use Cost Allocation Tags for departmental chargeback
Security Improvement
| Area | Improvement Strategy | Key Services |
|---|---|---|
| Encryption at Rest | Enable default encryption for all data stores; migrate from SSE-S3 to SSE-KMS for auditability | KMS, S3 default encryption, EBS encryption, RDS encryption |
| Encryption in Transit | Enforce TLS everywhere; use ACM for certificate management; redirect HTTP to HTTPS | ACM, ALB HTTPS listeners, CloudFront viewer protocol policy |
| Access Control | Implement least privilege; use IAM Access Analyzer to find unused permissions and refine policies | IAM Access Analyzer, IAM policy simulator, Permission Boundaries |
| Network Security | Replace public endpoints with PrivateLink; implement Network Firewall; enable VPC Flow Logs | PrivateLink, Network Firewall, Security Groups, NACLs |
| Secrets Management | Migrate hardcoded credentials to Secrets Manager or Parameter Store; enable automatic rotation | Secrets Manager, SSM Parameter Store, Lambda rotation functions |
| Vulnerability Management | Continuous scanning of EC2, ECR images, and Lambda functions for vulnerabilities | Inspector, ECR image scanning, Patch Manager |
Deployment Strategies Comparison
| Strategy | Downtime | Rollback Speed | Best For |
|---|---|---|---|
| All-at-Once | Yes (brief) | Redeploy previous version | Dev/test environments, non-critical workloads |
| Rolling | No (reduced capacity) | Redeploy (slow) | Cost-sensitive production with some risk tolerance |
| Blue/Green | No | Instant (switch back) | Production workloads requiring instant rollback capability |
| Canary | No | Instant (shift traffic back) | Risk-averse production, test with small % of traffic first |
| Immutable | No | Terminate new instances | Elastic Beanstalk, ensures clean deployments on fresh instances |
Domain 4: Accelerate Workload Migration & Modernization (20%)
This domain covers selecting and implementing the appropriate migration strategy for workloads moving to AWS. You must understand the 6 Rs of migration, data transfer methods, database migration tools, and modernization approaches including containerization and serverless refactoring. Large-scale migration planning and hybrid connectivity patterns are frequently tested topics.
The 6 Rs of Migration
| Strategy | Also Known As | Description | When to Use |
|---|---|---|---|
| Rehost | Lift and Shift | Move applications to AWS without changes | Large-scale migrations, legacy apps, time-sensitive moves. Use MGN for automated rehosting |
| Replatform | Lift, Tinker, and Shift | Make small optimizations during migration | Move to managed services (e.g., RDS instead of self-managed DB, Elastic Beanstalk for app hosting) |
| Refactor | Re-architect | Redesign application to be cloud-native | When business needs require cloud-native features: microservices, serverless, containers |
| Repurchase | Drop and Shop | Move to a different product (often SaaS) | Replace legacy CRM with Salesforce, self-managed email with SES, on-prem DB with DynamoDB |
| Retain | Revisit | Keep in current environment for now | Apps not ready to migrate, recently upgraded, complex dependencies, compliance constraints |
| Retire | Decommission | Turn off applications no longer needed | Redundant apps, unused environments, consolidation opportunities. Typically 10-20% of portfolio |
Migration Services
| Service | Purpose | Key Details |
|---|---|---|
| AWS MGN (Application Migration Service) | Server migration (rehost) | Continuous block-level replication, automated cutover, non-disruptive testing. Replaces Server Migration Service (SMS) |
| AWS DMS (Database Migration Service) | Database migration | Homogeneous and heterogeneous migrations. Continuous replication (CDC). Source stays operational during migration. Supports on-prem to AWS, AWS to AWS |
| AWS SCT (Schema Conversion Tool) | Schema conversion for heterogeneous migrations | Converts Oracle/SQL Server schemas to Aurora/PostgreSQL/MySQL. Identifies conversion issues and provides recommendations |
| Migration Hub | Central tracking for migrations | Single location to track progress across MGN, DMS, and partner tools. Discovery tools for portfolio assessment |
| Application Discovery Service | Discover on-premises inventory | Agentless discovery (VMware only, basic info) or Agent-based discovery (detailed data including dependencies, network connections) |
DMS & SCT Patterns
- Homogeneous Migration: Same engine to same engine (e.g., MySQL to Aurora MySQL). Use DMS directly without SCT. Simplest migration path
- Heterogeneous Migration: Different engines (e.g., Oracle to Aurora PostgreSQL). Use SCT first to convert schema, then DMS for data migration. More complex, may require code changes
- Continuous Replication (CDC): DMS captures ongoing changes from source and applies to target. Enables near-zero downtime migration. Cut over when target is in sync
- Full Load + CDC: Initial full data copy followed by continuous change capture. Most common pattern for database migrations with minimal downtime
- DMS with S3 as Target: Stream database changes to S3 for data lake ingestion. Use Parquet or CSV format. Useful for analytics pipelines
- Large Table Migration: Use parallel load for tables with millions of rows. Partition-based loading for faster migration of large datasets
Large Data Transfer Options
| Service | Capacity | Best For |
|---|---|---|
| AWS Snowcone | 8 TB usable (HDD) or 14 TB (SSD) | Edge computing, small data transfers, harsh environments, IoT data collection |
| AWS Snowball Edge Storage | 80 TB usable | Large data transfers, local storage and compute. Supports S3-compatible and NFS interfaces |
| AWS Snowball Edge Compute | 42 TB usable + powerful compute | Edge computing workloads, ML inference at edge, disconnected environments |
| AWS Snowmobile | Up to 100 PB | Exabyte-scale data center migrations. Shipping container truck. Use when >10 PB to transfer |
| DataSync | Network-based, up to 10 Gbps | Online data transfer between on-prem and AWS. Supports S3, EFS, FSx. Automatic encryption, integrity validation, scheduling |
| Transfer Family | Network-based | Managed SFTP, FTPS, FTP to S3/EFS. Use when partners require file transfer protocols |
Containerization & Modernization
- App2Container: Analyzes .NET and Java applications running on-premises or on EC2 and generates container artifacts (Dockerfile, task definitions, Kubernetes deployments)
- AWS Microservice Extractor: Tool to decompose monolithic applications into microservices. Analyzes code dependencies and suggests service boundaries
- ECS Anywhere: Run ECS tasks on customer-managed infrastructure (on-premises or other clouds). Register external instances as capacity providers
- EKS Anywhere: Create and manage Kubernetes clusters on your own infrastructure using AWS tooling. Consistent EKS experience on-premises
- Lambda Migration: Break monolith into event-driven functions. Use Strangler Fig pattern to gradually replace components. API Gateway as facade in front of both legacy and new Lambda functions
Serverless Refactoring
- Strangler Fig Pattern: Incrementally replace monolith functionality with microservices/serverless. Route traffic through API Gateway, gradually shifting endpoints from legacy to new. Low risk, reversible
- CQRS Pattern: Separate read and write models. Use DynamoDB/Aurora for writes, ElastiCache/DynamoDB Streams + Lambda for read-optimized views. Improves performance and scalability
- Event Sourcing: Store state changes as events rather than current state. Use Kinesis or DynamoDB Streams. Enables replay, audit, and temporal queries
- Saga Pattern: Manage distributed transactions across microservices using Step Functions. Each step has a compensating transaction for rollback. Choreography vs orchestration approach
VMware Migration
- VMware Cloud on AWS: Run VMware vSphere workloads on dedicated AWS infrastructure. Use vMotion for live migration. Maintain existing VMware tools and skills while accessing AWS services
- Migration Path: Use HCX (Hybrid Cloud Extension) for bulk migration with vMotion. Supports live migration with no downtime. Network extension for IP address preservation
- Integration: VMware Cloud on AWS VPCs connect to native AWS services. Access S3, RDS, Lambda, and other services from VMware workloads via ENI
- Use Cases: Data center evacuation, disaster recovery, burst capacity, modernization staging area. Maintain operational consistency during cloud transition
Hybrid Storage Solutions
- Storage Gateway - S3 File Gateway: NFS/SMB interface to S3. Local cache for low-latency access to frequently used data. Ideal for file shares with cloud backup
- Storage Gateway - FSx File Gateway: Local cache for Amazon FSx for Windows File Server. Extends Windows file shares to on-premises with low-latency access
- Storage Gateway - Volume Gateway: iSCSI block storage backed by S3. Cached volumes (primary data in S3, hot data cached locally) or Stored volumes (primary data on-prem, async backup to S3)
- Storage Gateway - Tape Gateway: Virtual tape library backed by S3 and Glacier. Drop-in replacement for physical tape backup. Integrates with existing backup software (Veeam, Veritas, etc.)
- AWS Outposts: Fully managed AWS infrastructure deployed on-premises. Run EC2, EBS, S3, RDS, ECS, EKS locally. For low-latency, data residency, or local data processing requirements
Migration Planning Framework
| Phase | Activities | Key Tools |
|---|---|---|
| Assess | Discover on-premises inventory, identify dependencies, evaluate migration readiness, define business case | Migration Hub, Application Discovery Service, Migration Evaluator |
| Mobilize | Build landing zone, set up networking, create migration playbooks, train teams, run pilots | Control Tower, Transit Gateway, Direct Connect, CloudFormation |
| Migrate & Modernize | Execute migration waves, validate functionality, optimize performance, decommission source systems | MGN, DMS, DataSync, Snow Family, App2Container |
Key Services Reference
This section provides a comprehensive reference of the most important AWS services tested on the SAP-C02 exam. Services are grouped by category for easy lookup. Understanding when to use each service and how they compare to alternatives is essential for passing the exam.
Compute Services
| Service | Description | Key Exam Points |
|---|---|---|
| EC2 | Virtual servers in the cloud | Instance types, pricing models (On-Demand, RI, Spot, Savings Plans), placement groups, Nitro Enclaves, dedicated hosts for BYOL |
| Lambda | Serverless compute functions | 15 min timeout, 10 GB memory, VPC access, Provisioned Concurrency, SnapStart for Java, container image support |
| ECS | Container orchestration (AWS-native) | Fargate (serverless) vs EC2 launch type, task definitions, service auto-scaling, ALB integration, service mesh with App Mesh |
| EKS | Managed Kubernetes | Kubernetes portability, Fargate or EC2 nodes, EKS Anywhere for on-prem, IRSA for IAM integration with pods |
| Elastic Beanstalk | PaaS for web applications | Supports Docker, Java, .NET, Node.js, Python, Ruby, Go. Rolling, immutable, blue/green deployments. Worker environments for background tasks |
| Batch | Managed batch computing | Job queues, compute environments (Fargate or EC2), array jobs for parallel processing, Spot integration for cost optimization |
Storage Services
| Service | Description | Key Exam Points |
|---|---|---|
| S3 | Object storage | Storage classes, lifecycle policies, versioning, replication (CRR/SRR), encryption (SSE-S3/SSE-KMS/SSE-C), Object Lock, Access Points, S3 Select |
| EBS | Block storage for EC2 | gp3 (3000 IOPS baseline), io2 (64K IOPS), io2 Block Express (256K IOPS), st1 (throughput), sc1 (cold). Snapshots to S3, encryption with KMS |
| EFS | Managed NFS file system | POSIX-compliant, auto-scales, multi-AZ, lifecycle management, Lambda/ECS/EC2 access, Standard and One Zone storage classes |
| FSx | Managed file systems (4 types) | Lustre (HPC), Windows (SMB/AD), NetApp ONTAP (multi-protocol), OpenZFS (Linux). Choose based on protocol and performance needs |
| Storage Gateway | Hybrid cloud storage | S3 File Gateway (NFS/SMB), FSx File Gateway (SMB), Volume Gateway (iSCSI), Tape Gateway. On-prem cache with cloud backend |
Database Services
| Service | Description | Key Exam Points |
|---|---|---|
| Aurora | High-performance relational DB | Global Database (sub-second replication), Serverless v2, Multi-Master, up to 15 read replicas, auto-scaling, cross-Region failover |
| DynamoDB | Serverless NoSQL | Global Tables, DynamoDB Streams, DAX caching, on-demand/provisioned, TTL, PartiQL, export to S3, fine-grained IAM |
| RDS | Managed relational databases | Multi-AZ for HA (sync replication), Read Replicas (async), RDS Proxy for connection pooling, supports MySQL, PostgreSQL, Oracle, SQL Server, MariaDB |
| ElastiCache | In-memory caching | Redis (persistence, replication, pub/sub, Lua scripting, Global Datastore) vs Memcached (multi-threaded, simple). Session stores, leaderboards |
| Redshift | Data warehouse | Columnar storage, Spectrum (query S3), Concurrency Scaling, RA3 nodes (managed storage), data sharing, cross-Region snapshots |
| Neptune | Graph database | Gremlin and SPARQL support, up to 15 read replicas, Streams for change capture, social graphs, fraud detection, knowledge graphs |
Networking Services
| Service | Description | Key Exam Points |
|---|---|---|
| VPC | Virtual private network | Subnets, route tables, NACLs (stateless), security groups (stateful), NAT Gateway, Internet Gateway, VPC Endpoints (Gateway & Interface) |
| Route 53 | DNS and routing | Routing policies: simple, weighted, latency, failover, geolocation, geoproximity, multivalue. Health checks, alias records, private hosted zones |
| CloudFront | CDN | Edge caching, Origin Access Control, Lambda@Edge, CloudFront Functions, signed URLs/cookies, geo-restriction, Origin Shield, field-level encryption |
| Transit Gateway | Hub-and-spoke networking | Connect VPCs, VPNs, Direct Connect via single hub. Route tables for segmentation. Inter-Region peering. Share via RAM. Multicast support |
| Direct Connect | Dedicated private connection | 1/10/100 Gbps, LAG for aggregation, DXGW for multi-Region access, public VIF for AWS public services, private VIF for VPC, transit VIF for TGW |
| ELB | Load balancing | ALB (HTTP/HTTPS, path/host routing), NLB (TCP/UDP, ultra-low latency, static IPs), GWLB (third-party appliances). Cross-zone, sticky sessions |
Security Services
| Service | Description | Key Exam Points |
|---|---|---|
| KMS | Key management | AWS managed keys, customer managed keys (CMK), key policies, grants, cross-account key sharing, automatic rotation, multi-Region keys |
| WAF | Web application firewall | Web ACLs on ALB/CloudFront/API Gateway, rate-based rules, managed rule groups, IP sets, geo-matching, custom rules, Bot Control |
| Shield | DDoS protection | Standard (free, automatic L3/L4 protection), Advanced ($3K/mo, L7 protection, DRT support, cost protection, enhanced detection) |
| GuardDuty | Threat detection | Analyzes CloudTrail, VPC Flow Logs, DNS logs, S3 data events, EKS audit logs. ML-based anomaly detection. Delegated admin for multi-account |
| Secrets Manager | Secret storage and rotation | Automatic rotation via Lambda, cross-Region replication, RDS/Aurora/Redshift native rotation, versioning, resource-based policies |
| ACM | SSL/TLS certificate management | Free public certificates, auto-renewal, CloudFront requires us-east-1, ALB/NLB/API Gateway integration, private CA for internal certificates |
Analytics & Integration Services
| Service | Description | Key Exam Points |
|---|---|---|
| Athena | Serverless SQL on S3 | Presto-based, pay per query (data scanned), supports Parquet/ORC/JSON/CSV, integrates with Glue Data Catalog, federated queries to other data sources |
| Kinesis Data Streams | Real-time data streaming | Shard-based (1 MB/s in, 2 MB/s out per shard), on-demand mode, enhanced fan-out, 1-365 day retention, KCL for consumers |
| Kinesis Data Firehose | Managed delivery to destinations | Near real-time (60s buffer), delivers to S3/Redshift/OpenSearch/Splunk/HTTP, built-in transformation with Lambda, no management needed |
| OpenSearch | Search and log analytics | Full-text search, log analytics, dashboards. Successor to Elasticsearch Service. UltraWarm and cold storage tiers for cost optimization |
| Step Functions | Serverless workflow orchestration | Standard (long-running, exactly-once) vs Express (high-volume, at-least-once), visual workflow, error handling, parallel/map states |
| SQS | Message queuing | Standard (unlimited throughput, at-least-once) vs FIFO (3K msg/s, exactly-once, ordering). DLQ, visibility timeout, long polling, encryption |
Migration Services
| Service | Description | Key Exam Points |
|---|---|---|
| MGN | Application migration (rehost) | Block-level replication, automated cutover, non-disruptive testing, replaces SMS/CloudEndure Migration |
| DMS | Database migration | Homogeneous and heterogeneous, CDC for ongoing replication, use SCT for schema conversion in heterogeneous migrations |
| DataSync | Online data transfer | On-prem NFS/SMB to S3/EFS/FSx, up to 10 Gbps, automatic encryption, integrity verification, scheduling, bandwidth throttling |
| Snow Family | Offline data transfer | Snowcone (8-14 TB), Snowball Edge (42-80 TB), Snowmobile (100 PB). Edge computing with Snowball Edge. Use when network transfer exceeds 1 week |
| Transfer Family | Managed file transfer | SFTP/FTPS/FTP/AS2 to S3/EFS, existing authentication via custom IdP, partner-facing file exchanges |
Common Acronyms & Terms
| Acronym | Full Name | Context |
|---|---|---|
| SCP | Service Control Policy | Organizations guardrails for member accounts |
| RPO | Recovery Point Objective | Maximum acceptable data loss measured in time |
| RTO | Recovery Time Objective | Maximum acceptable downtime after disaster |
| OU | Organizational Unit | Hierarchical grouping in AWS Organizations |
| DXGW | Direct Connect Gateway | Multi-Region access via single DX connection |
| TGW | Transit Gateway | Hub-and-spoke network connectivity service |
| CDC | Change Data Capture | DMS continuous replication of database changes |
| MGN | Application Migration Service | Server rehost migration with block-level replication |
| RAM | Resource Access Manager | Share resources across AWS accounts |
| OAC | Origin Access Control | CloudFront secure access to S3 (replaces OAI) |
| IRSA | IAM Roles for Service Accounts | EKS pod-level IAM permissions via OIDC |
| BYOL | Bring Your Own License | Use existing software licenses on EC2 Dedicated Hosts |