Free SAA-C03 practice test

Option E is a common real-world issue: if the bucket policy is updated to remove CloudTrail's write permission, CloudTrail silently fails to deliver logs (it will display delivery errors in the console). Option A (trail stopped or deleted) is the most direct cause — no trail means no log delivery. Option C is incorrect — Block Public Access prevents public ACLs and policies but does not block CloudTrail's service-principal writes, which use a bucket policy grant. Option B is incorrect — CloudTrail logs all API calls regardless of credential type, including temporary credentials. Option F is incorrect — CloudTrail does not automatically change log destinations; the trail configuration is static until manually changed. Option D is incorrect — KMS key rotation replaces the key material for future encryption but does not invalidate existing encrypted objects or prevent new writes; CloudTrail would continue writing logs.

Option D is correct because RDS does not support enabling encryption on an existing unencrypted instance in place. The supported process is: (1) take an unencrypted snapshot, (2) copy that snapshot and enable encryption with a KMS key during the copy operation, and (3) restore a new encrypted RDS instance from the encrypted snapshot. This is the AWS-documented migration path. Option C is incorrect because RDS does not allow you to enable encryption on an existing instance after creation — this setting is immutable and cannot be changed via a modify operation. Option B is incorrect because while DMS is a valid migration tool and could work, the question asks for minimal downtime and the snapshot copy/restore method is simpler, lower-cost, and more straightforward than setting up a DMS task for this specific use case. Additionally, enabling SSL on the source doesn't encrypt data at rest. Option A is incorrect because Amazon Macie is a data discovery and classification service for S3 — it does not support RDS, does not inspect RDS data, and has no capability to encrypt RDS instances.

Option C is correct because AWS Secrets Manager is purpose-built for secrets management with native automatic rotation support. It provides built-in Lambda rotation functions for popular database engines (RDS MySQL, PostgreSQL, etc.), runs rotation automatically on a configurable schedule without application code changes, and the GetSecretValue SDK call retrieves the latest version seamlessly — the application always gets current credentials without modification. Option D is incorrect because Parameter Store (Standard tier) does not have native automatic rotation; the EventBridge + Lambda approach described requires custom rotation code and ongoing maintenance, does not update the parameter atomically with the database credential change, and is more operationally complex than Secrets Manager. Option B is incorrect because KMS is an encryption key management service — it does not store application secrets or credentials, and GenerateDataKey generates data encryption keys for envelope encryption, not a mechanism to retrieve database passwords. Option A is incorrect because storing credentials in S3 objects and rotating them via Lambda is a fragile custom solution that involves race conditions (what if the app reads mid-rotation?), requires application code to fetch and parse objects, and has higher latency than Secrets Manager's regional API endpoint.

When Organizations trusted access is enabled for GuardDuty, Security Hub, and AWS Config, and a delegated administrator account is configured with auto-enable settings, new accounts joining the organization are automatically enrolled in these services without manual opt-in. This is the primary value of using Organizations integration with security services. Manual opt-in via invitation is the legacy account-level invitation model; with Organizations integration and auto-enable, this is not required for new member accounts. Option B partially describes older behavior—modern Organizations integration with auto-enable eliminates the need for per-account invitations for all three listed services. Organizations does not replicate findings from the administrator to members; it aggregates findings from members into the administrator account, not the reverse.

Amazon Macie is a fully managed data security service that uses machine learning to automatically discover, classify, and report sensitive data (including PII such as names, SSNs, credit card numbers) in S3 buckets, without any custom pattern-matching code. Findings are generated natively. Option D (Lambda + Comprehend) also detects PII but requires writing, deploying, and maintaining custom Lambda code — the question specifically says no custom pattern-matching code. Option B (S3 Object Lambda) transforms data on read for consumers; it does not perform discovery or reporting of PII in stored objects. Option A (AWS Config) evaluates bucket-level configuration compliance (e.g., public access settings) and does not inspect object content for sensitive data.

AWS Shield Advanced is the paid tier ($3,000/month) that provides: (1) enhanced DDoS protection for layers 3, 4, and 7; (2) automatic cost protection (DDoS cost credits for scaling charges caused by an attack); and (3) access to the AWS DDoS Response Team (DRT). You associate it with specific resources such as CloudFront distributions, ALBs, and EIPs.

Option D (WAF rate-based rules) can mitigate some HTTP floods but does not provide financial cost protection or DRT access.

Option B is incorrect: AWS Shield Standard is free, automatic, and protects against common network/transport layer attacks only. It does NOT provide cost protection or DRT access — those are exclusive to Shield Advanced.

Option A (Network Firewall) operates at the VPC edge and cannot intercept traffic that has already reached the ALB from CloudFront; it also provides no cost protection or DRT access.

Correct: S3 Cross-Region Replication (CRR) is the purpose-built AWS feature for automatically replicating objects—including metadata, tags, and ACLs—from a source bucket in one Region to a destination bucket in another Region, typically within minutes. It is managed entirely by AWS with no custom code required. Option A is wrong because S3 Lifecycle policies manage object transitions and expirations within or to storage classes (e.g., Glacier)—they cannot copy objects to a bucket in another Region. Option B is wrong because a custom Lambda function would work functionally but introduces significant operational overhead (error handling, retries, IAM permissions management, monitoring) compared to CRR, which is a managed service. Option C is wrong because SRR replicates within the same Region; chaining SRR with CRR adds unnecessary complexity and is not required when CRR alone achieves the goal directly.

Correct: RDS Multi-AZ uses synchronous replication to a standby instance in a different AZ. Because replication is synchronous, every write is committed to both the primary and standby before the transaction is acknowledged, providing near-zero RPO. Failover is automatic and typically completes in 60–120 seconds, with no manual intervention required. Option B is wrong because RDS read replicas use asynchronous replication, meaning there can be replication lag and potential data loss (non-zero RPO), and promotion of a read replica to a standalone instance requires manual action. Option D is wrong because automated snapshots and point-in-time recovery are backup mechanisms; they do not provide automatic failover and restoring a snapshot would result in significant RTO and potentially non-zero RPO (up to 5 minutes for PITR). Option C is wrong because rsync is not a database-native synchronous replication tool—it is a file synchronization utility that would result in data inconsistency, replication lag, and require significant manual operational effort for failover.

Option A is correct: CRR is specifically designed for replicating objects across AWS Regions; it must be enabled on the source bucket and requires versioning on both buckets. Note that versioning is already stated as enabled on the source. Option E is correct: CRR only replicates objects written after replication is configured. To copy existing objects, S3 Batch Operations with a replication job must be used separately. Option C is incorrect because SRR replicates within the same Region, not across Regions. Option B is a prerequisite but is already satisfied (source has versioning enabled), and the destination bucket versioning would be enabled as part of setting up CRR—it is not a separate step the architect must explicitly take beyond enabling CRR. Option D (Glacier lifecycle + restore) is not a replication mechanism and would not satisfy DR requirements.

Option D is correct: by default, Auto Scaling uses only EC2 status checks. Enabling ELB health checks allows Auto Scaling to terminate and replace instances that the ALB has marked as unhealthy (e.g., failing application-level health checks), not just instances with failed EC2 hardware checks. Option C is correct: the ALB must be configured with a valid health check path and appropriate healthy/unhealthy thresholds so it accurately identifies unhealthy instances and stops sending traffic to them. Option B (sticky sessions) routes a user's requests to the same instance, which actually hinders availability. Option E (cooldown of 0) could cause aggressive replacement loops but does not directly control whether traffic is sent to unhealthy instances. Option A (scale-in alarm) is a scaling policy, not a health replacement mechanism.

Amazon EFS replication continuously replicates data from a source EFS file system to a destination file system in another Region, with a typical RPO measured in minutes—meeting the 15-minute requirement with minimal operational overhead. Option C (AWS DataSync every 15 minutes) could theoretically meet the requirement, but scheduling a DataSync task every 15 minutes is operationally complex, the task itself takes time to run, and there is a risk that new files written just after a task completes won't be replicated for nearly 15 minutes. Option B (Lambda + EventBridge + S3 CRR) introduces multiple services, adds latency from S3 CRR, and does not guarantee delivery to EFS in eu-central-1—the destination would be S3, not EFS. Option D (S3 Transfer Acceleration) is for accelerating uploads to S3 buckets, not for moving EFS data, and requires additional steps to read from EFS.

Option B is correct. Reserved Instances provide the lowest per-hour cost for predictable baseline capacity, while Spot Instances are up to 90% cheaper than On-Demand and are well-suited for stateless, fault-tolerant workloads that can tolerate interruptions. Because the app is stateless, Spot interruptions don't cause data loss. Option A uses On-Demand for spikes, which is significantly more expensive than Spot for short, bursty periods. Option D ignores cost optimization and creates a single point of failure without elasticity. Option C using Spot-only is risky: if Spot capacity is unavailable during a spike, the application could become unavailable with no stable baseline.

A cluster placement group packs instances physically close together within a single AZ, enabling high-bandwidth, low-latency network connections (up to 10 Gbps between instances for supported types, and eligible for enhanced networking / ENA). This is the optimal choice for tightly coupled, latency-sensitive inter-node communication. — Partition placement groups are designed for distributed, fault-tolerant workloads (e.g., Hadoop, Cassandra) where isolation between partitions matters more than raw latency between nodes. — Spread placement groups place each instance on distinct hardware to maximize fault isolation, but they sacrifice network proximity and are limited to 7 instances per AZ. — Distributing across multiple AZs with no placement group increases inter-instance network latency and does not exploit high-bandwidth intra-rack networking.

Option D (Transfer Acceleration) routes uploads through CloudFront edge locations over AWS's optimized backbone network, dramatically reducing latency and improving reliability for global uploads. Option A (multipart upload) is recommended by AWS for objects over 100 MB—it allows parallel uploads of individual parts, automatic retry of failed parts, and the ability to resume interrupted uploads. Option F (changing bucket region) only helps users near one office and doesn't help global users. Option E (Intelligent-Tiering) is a cost-optimization storage class and has no effect on upload performance. Option C is incorrect—S3 bucket policies cannot configure part sizes; multipart upload part sizes are set by the client. Option B (S3 Replication) copies data after a successful upload and does nothing to improve the reliability of the initial upload.

Origin Access Control (OAC) is the current AWS-recommended mechanism (replacing the legacy Origin Access Identity) that allows CloudFront to authenticate to S3 using IAM SigV4 signing. The S3 bucket policy must explicitly allow s3:GetObject from the OAC's service principal (cloudfront.amazonaws.com) conditioned on the specific distribution ARN. Together, these two settings ensure S3 content is served only through CloudFront while the bucket itself remains private. — Using bucket ACLs to allow CloudFront IP ranges is not recommended: CloudFront has a large, dynamic IP range that cannot be reliably maintained in ACLs, and ACLs are a legacy S3 access control mechanism. Block Public Access should be enabled but granting access via IP-based ACLs is incorrect. — Signed URLs with IP restrictions limit which end users can access content via CloudFront, but they don't prevent direct S3 endpoint access; this solves a different problem. — Making the S3 bucket public exposes the bucket directly to the internet; geo-restriction in CloudFront only applies to CloudFront requests and cannot block direct S3 URL access.

Option A is correct. AWS Global Accelerator provides static anycast IP addresses and routes user traffic to the nearest AWS edge location, then carries it over the congestion-free AWS global backbone to the origin in us-east-1. This significantly reduces latency for dynamic, non-cacheable content compared to traversing the unpredictable public internet. Option B (CloudFront) is designed for caching and content delivery. For dynamic, uncacheable API responses, CloudFront provides no caching benefit and essentially proxies traffic without the same TCP/network optimization that Global Accelerator offers for dynamic workloads. Option C (multi-region replication) would work but is extremely complex, expensive, and operationally heavy—it is not the most effective single solution given that Global Accelerator achieves significant improvement without full replication. Option D (increasing bandwidth) does not address the fundamental issue, which is network latency caused by geographic distance and public internet routing, not server throughput.

Correct – C: EFS supports lifecycle management policies that automatically transition files unused for a configurable period (including 90 days) to the EFS Infrequent Access (IA) storage class. EFS IA costs approximately 85% less than EFS Standard. When a file is accessed, EFS transparently retrieves it back — no application changes are required, which meets the requirement. Wrong – A: This describes 'EFS Intelligent-Tiering,' which is indeed a valid EFS feature, but the description is slightly off — EFS Intelligent-Tiering transitions to IA after the configured inactivity period (not a fixed 30 days; the policy is configurable). More importantly, answer C is more precise and directly names the correct mechanism (lifecycle policy with 90-day threshold), matching the scenario's finding. Both A and C are close, but C is the more accurate and specific answer that aligns with configuring the threshold to match the 90-day access pattern identified. Wrong – B: Copying files to S3 and deleting from EFS would break the NFS-based mount that EC2 instances use. The application would lose access to files via the file system path, violating the 'no application changes' requirement. Wrong – D: Migrating to S3 and using the AWS SDK would require significant application changes to replace POSIX file system calls with S3 API calls, violating the 'no application changes' requirement.

Athena charges $5 per TB of data scanned. Converting CSV files to Parquet reduces data scanned because Parquet is a columnar format — Athena only reads the columns referenced in the query and compression ratios are much higher than CSV, typically reducing scanned data by 60–90%. Partitioning the data by date and filtering on the partition key allows Athena to skip entire S3 prefixes that don't match the query's date range, dramatically reducing the amount of data scanned. Together, these two changes are the standard AWS-recommended approach to minimizing Athena costs. S3 Transfer Acceleration speeds up uploads to S3 from the internet; it has no effect on Athena query performance or cost. S3 Versioning maintains multiple versions of objects; it does not reduce query costs and would actually increase storage costs. Moving data to Glacier Instant Retrieval is incompatible with direct Athena queries — Athena requires data in S3 standard storage classes and cannot query Glacier-archived objects directly.

Purchasing 1-year All Upfront Reserved Instances for the two baseline instances is correct because they run year-round and Reserved Instances offer up to 72% savings over On-Demand for predictable, steady-state usage. Using On-Demand Instances for peak holiday capacity is correct because peak demand is temporary and seasonal; On-Demand avoids committing to capacity needed for only 3 months. Using a 3-year Reserved Instance for all peak instances is incorrect because committing 3 years for capacity needed only 3 months per year wastes money on unused reservation time. Using Spot Instances for peak is a common suggestion but is incorrect here because order processing is a critical application that cannot tolerate interruptions during peak revenue season. Purchasing a 1-year Partial Upfront RI for all peak instances is incorrect because it creates unnecessary commitments for temporary capacity and is less cost-effective than On-Demand for short bursts.

Aurora Serverless v2 with a minimum of 0.5 ACUs is the most cost-effective because it scales capacity down to near-zero during idle periods and scales up automatically to handle bursts, charging only for consumed capacity in ACU-hours. This directly addresses the requirement to avoid paying for idle capacity. RDS MySQL with Multi-AZ and a Reserved Instance is cost-effective for steady-state workloads but has a fixed instance size running continuously—you pay for capacity even during idle periods. Aurora MySQL with provisioned instances and Read Replicas also runs continuously at fixed capacity, incurring costs during the long idle periods. DynamoDB with provisioned capacity and Auto Scaling is a NoSQL solution; the question specifies a relational database requirement, making this architecturally inappropriate regardless of cost.