Security And Resilience Mixed Drills

Concepts Covered

• Mixed SAA-C03 scenario reading
• IAM and resource policy layering
• KMS access failures
• Private service access
• Multi-account logging
• Multi-AZ resilience
• Backup, replication, RTO, and RPO
• SCP guardrails
• Audit log protection
• Secure failover traps

1. Domain Mental Model

Real architecture decisions rarely test one pillar at a time. A secure design that cannot recover is not enough. A highly available design that exposes data publicly is not enough.

The SAA-C03 exam separates secure and resilient architectures into different domains, but scenario wording often blends them. A question might mention encrypted data, private subnets, cross-account access, and Availability Zone failure in one paragraph. The exam move is not to panic and pick the first familiar service. The move is to split the question into layers:

identity -> resource boundary -> network path -> encryption key -> failure boundary -> recovery objective

If you cannot name the layer, every answer choice feels plausible.

2. Official Task Map

This drill set sits across SAA-C03 Domain 1 and Domain 2.

Domain 1 asks for secure access, secure workloads, and data security controls. Domain 2 asks for scalable, loosely coupled, highly available, and fault-tolerant architectures.

When the two domains combine, the question usually sounds like:

keep the workload available, but do not weaken the trust boundary

That is why private access, KMS authorization, cross-account logging, SCP guardrails, Multi-AZ failover, backups, replication, RTO, and RPO often appear together.

3. What AWS Is Testing

For every mixed scenario, ask four questions.

First, who is the principal? Human user, application role, AWS service, external partner, or another AWS account?

Second, where is the resource boundary? Same account, cross-account, public internet, private VPC, centralized logging account, or organization-wide guardrail?

Third, what failure is being tolerated? Instance failure, Availability Zone failure, Region failure, accidental deletion, corrupted data, credential compromise, or audit tampering?

Fourth, what is the recovery target? High availability, durability, RTO, RPO, backup retention, point-in-time recovery, or immutable audit evidence?

This prevents the common mistake of solving the security half while ignoring the resilience half.

4. Service And Concept Clusters

Use these clusters while drilling:

• Identity and policy: IAM Policy Types And Evaluation Traps, Cross-Account Access Patterns, Service Control Policies
• Private access: VPC Endpoints And PrivateLink, NAT Gateway vs VPC Endpoints, Gateway vs Interface VPC Endpoints
• Data protection: AWS Key Management Service, KMS Key Policies vs IAM Policies, S3 Encryption And KMS Key Policy Traps
• Resilience: RDS Multi-AZ vs Read Replicas, RDS And Aurora Recovery Choices, AWS Backup
• Auditability: AWS CloudTrail, CloudTrail vs Config vs CloudWatch vs Trusted Advisor

5. Architecture Reasoning Patterns

Use the drills below to practice the combined trace:

principal -> resource owner -> private path -> key access -> failure mode -> recovery target

Drill 1: Private S3 Access With Encrypted Data

Scenario: EC2 instances in private subnets need to read encrypted S3 objects. The security team does not want traffic to leave the AWS network through NAT, and access must be restricted to this VPC path.

Best answer: create an S3 gateway VPC endpoint, associate it with the private route tables, scope the bucket policy to the endpoint where required, and make sure the instance role has S3 permissions plus the required KMS decrypt permission.

Why: the network requirement points to private S3 access without NAT. The data security requirement adds KMS authorization. S3 access alone is not sufficient when SSE-KMS protects the object.

Distractors:

• NAT Gateway solves outbound internet-style egress, not the lowest-cost private S3 path.
• A security group rule does not grant S3 object access.
• Bucket permission alone does not grant KMS decrypt.
• Public bucket access violates the security requirement.

Drill 2: RDS App Must Survive AZ Failure

Scenario: A web application stores transactional data in RDS. The business wants automatic failover if an Availability Zone fails. Developers also ask whether read replicas satisfy the requirement.

Best answer: use RDS Multi-AZ for high availability and failover. Use read replicas only when the requirement is read scaling or read offload, not automatic synchronous standby failover for the primary database.

Why: Multi-AZ is a resilience control. Read replicas are primarily a performance and scaling control, and their replication characteristics and promotion behavior do not replace the normal Multi-AZ answer for managed database failover.

Distractors:

• Read replicas may help read-heavy workloads but are not the first answer for automatic AZ failover.
• Backups help recovery after data loss but do not keep the app highly available during an AZ failure.
• A larger DB instance improves capacity, not fault tolerance.
• Auto Scaling web servers do not protect the database tier.

Drill 3: Centralized CloudTrail Logs Across Accounts

Scenario: A company uses multiple AWS accounts. Security wants centralized CloudTrail logs, protection from modification, and prevention of member-account administrators disabling logging.

Best answer: send organization or account trails to a centralized logging bucket, use tightly scoped bucket and KMS key policies, enable log file validation where useful, and apply SCP guardrails to prevent member accounts from disabling or tampering with logging controls.

Why: this scenario blends auditability, account governance, and data protection. CloudTrail records activity, but organizational prevention needs a guardrail. The logging bucket and encryption key also need resource-side controls.

Distractors:

• Giving the security team administrator access in every account does not prevent local administrators from making changes.
• CloudWatch alarms can notify after a problem but do not create immutable log governance.
• S3 versioning helps accidental overwrite recovery but is not the whole design.
• An IAM allow policy in one account cannot constrain every member account.

Drill 4: Cross-Account Encrypted Backup Recovery

Scenario: Production data is backed up and copied to a separate recovery account. During a test restore, the recovery role can see the backup metadata but cannot restore encrypted resources.

Best answer: check the KMS key policy and backup copy encryption design. The recovery account role must be authorized to use the relevant key or the copy must be encrypted under a key controlled by the recovery account.

Why: cross-account recovery has both backup permissions and key permissions. Metadata visibility does not prove decrypt or restore authorization.

Distractors:

• Increasing IAM permission in only the recovery account may still fail if the key policy in the source or copied-key context does not trust it.
• Recreating the VPC does not fix key access.
• Read replicas do not replace backup recovery for this requirement.
• Disabling encryption to simplify restore violates the security requirement.

6. High-Yield Comparisons

Private S3 access versus internet egress: gateway endpoint for supported private S3 traffic; NAT Gateway for broader outbound internet access.

KMS permission versus storage permission: the storage service can allow the request while KMS still denies decrypt.

SCP versus IAM policy: SCPs constrain accounts; IAM policies grant or deny permissions to principals inside those boundaries.

Multi-AZ versus read replica: Multi-AZ is the managed high-availability answer; read replicas are mainly read scaling and replication design.

Backup versus replication: backups support point-in-time or retained recovery; replication can reduce RPO or support regional recovery but can also replicate bad data.

Detection versus prevention: CloudTrail, GuardDuty, and Config give visibility; SCPs, policies, network controls, and key policies shape what can happen.

7. Scenario Triggers

Use this checklist when answer choices mix security and resilience:

• If the wording says "private access to S3 or DynamoDB from a VPC," think gateway endpoint before NAT.
• If encrypted data is denied, check KMS in addition to the service policy.
• If an organization-wide prevention requirement appears, think SCPs.
• If the requirement says automatic database failover across AZs, think Multi-AZ before read replicas.
• If the wording says RTO and RPO, choose the recovery pattern that matches time and data-loss tolerance.
• If log tamper resistance appears, protect the destination bucket, key, and account boundary.

8. Common Traps

Do not treat read replicas as the default answer for database high availability.

Do not forget KMS key policy when data is encrypted across accounts.

Do not use NAT Gateway for private S3 access when a gateway endpoint satisfies the requirement.

Do not expect an SCP to grant access.

Do not centralize CloudTrail logs without protecting the log bucket, key, and account boundary.

Do not choose backup-only recovery when the scenario requires low RTO.

Do not solve data durability while ignoring who can restore the data.

9. Study Path

Study in this order:

1. Design Secure Architectures
2. Design Resilient Architectures
3. Secure Architecture Trap Drills
4. Resilient Architecture Trap Drills
5. Private App Access To S3
6. Secure Cross-Account CloudTrail Logging
7. Backup vs Replication Recovery Design

10. Related Topics

Review Secure Architecture Trap Drills, Resilient Architecture Trap Drills, Private App Access To S3, and Backup vs Replication Recovery Design.

Official AWS references:

• SAA-C03 exam guide
• Content Domain 1: Design Secure Architectures
• Content Domain 2: Design Resilient Architectures
• Gateway endpoints for Amazon S3
• Disaster Recovery of Workloads on AWS