A company runs an application on EC2 instances that needs to read objects from a private S3 bucket. Security policy prohibits storing long-lived AWS credentials on any instance. What is the best way to grant this access?
Create an IAM user with an access key and secret key, and store the credentials in the application config file
Attach an IAM role with a policy granting read access to the bucket, and assign the role to the EC2 instances
Store the access key and secret key as environment variables on each instance
Make the S3 bucket public and restrict access using a bucket policy based on the instances' public IP addresses
Explanation
An IAM role attached to the instances provides temporary, automatically-rotated credentials via the instance metadata service, with no long-lived keys stored anywhere — exactly what the policy requires. Options A and C both persist long-lived credentials on the instance, which is explicitly prohibited and also a real security risk (credentials can leak through logs, backups, or a compromised instance). Option D introduces public exposure and IP-based access control, which is both less secure and operationally fragile since EC2 public IPs can change.
A company must ensure that data stored in an S3 bucket is encrypted at rest, and requires that they retain full control over the encryption key, including the ability to disable it immediately in a security incident. Which solution meets these requirements?
Server-side encryption with Amazon S3-managed keys (SSE-S3)
Server-side encryption with AWS KMS customer managed keys (SSE-KMS) using a key the company creates and manages
Server-side encryption with AWS managed keys (SSE-KMS with an AWS managed key)
Client-side encryption with a key stored in the application source code
Explanation
A KMS customer managed key gives the company direct control over the key's policy, rotation, and — critically — the ability to disable or schedule deletion of the key immediately, which revokes access to all data encrypted under it. SSE-S3 (A) and SSE-KMS with an AWS managed key (C) both use keys the company does not control and cannot disable on demand. Client-side encryption with a key in source code (D) is a serious security anti-pattern regardless of the stated requirement.
An application uses a single Multi-AZ RDS MySQL database. The company wants to offload read-heavy reporting queries from the primary database without affecting write performance, and needs the reporting queries to reflect data that is at most a few seconds old. What should a solutions architect recommend?
Create an RDS read replica and direct reporting queries to it
Enable Multi-AZ standby access and direct reporting queries to the standby instance
Take a daily manual snapshot and restore it to a separate instance for reporting
Increase the primary instance size to handle both workloads
Explanation
A read replica is built exactly for this pattern: it asynchronously replicates from the primary (typically within seconds) and can serve read-only queries without touching the primary's write capacity. Option B is not how Multi-AZ works — the standby in a Multi-AZ deployment is for failover only and is not accessible for read queries. Option C introduces data that could be up to a day stale, failing the "few seconds old" requirement. Option D does not solve the underlying problem of contention between write and read workloads on the same instance.
A company needs its application to automatically recover from the failure of an entire Availability Zone with minimal manual intervention, while keeping infrastructure costs as low as possible. Which disaster recovery strategy best fits this requirement?
Multi-site active-active across two AWS Regions
Warm standby with a scaled-down but running copy of the environment in a second Availability Zone
Backup and restore from S3 to a new environment provisioned only after a failure occurs
Pilot light with only the database replicated to a second Availability Zone
Explanation
Warm standby keeps a running, if scaled-down, environment ready in a second AZ, allowing traffic to shift with minimal manual work while costing less than a full active-active deployment. Multi-site active-active (A) satisfies the resilience requirement but fails the "low cost" constraint — it is the most expensive option listed. Backup and restore (C) requires substantial manual provisioning after a failure, violating "minimal manual intervention." Pilot light (D) with only the database replicated still requires standing up compute resources during a failure, which is slower and more manual than warm standby.
A global media company serves large video files to users worldwide and wants to reduce latency for users far from its origin S3 bucket, while minimizing the load on the origin. What should a solutions architect recommend?
Enable S3 Transfer Acceleration on the bucket
Deploy an Amazon CloudFront distribution with the S3 bucket as the origin
Replicate the S3 bucket to every AWS Region using cross-region replication
Increase the S3 bucket's request rate limits through a support ticket
Explanation
CloudFront caches content at edge locations close to users worldwide, reducing both latency and the number of requests that reach the origin bucket directly — solving both stated problems in one solution. Transfer Acceleration (A) speeds up uploads to S3 over long distances, not content delivery to end users, so it does not address this scenario. Cross-region replication (C) is costly, does not reduce latency the way an edge cache does, and does not reduce origin load for reads happening within a region. Option D is not a real, recommendable mechanism for this problem.
An application experiences unpredictable traffic spikes throughout the day. The company wants compute capacity to scale automatically based on real-time demand, without over-provisioning for peak traffic that occurs only briefly. What should a solutions architect implement?
A fixed number of EC2 instances sized for peak expected traffic
An Auto Scaling group with a target tracking scaling policy based on average CPU utilization
A single, larger EC2 instance to absorb traffic spikes through vertical capacity
Manually launch additional instances whenever an operations engineer notices increased load
Explanation
A target tracking scaling policy automatically adds or removes instances to maintain a target metric (like CPU utilization), matching capacity to real-time demand without manual intervention or standing over-provisioning. Option A wastes money running peak-sized capacity around the clock. Option C provides no redundancy and has an upper ceiling on a single instance's capacity. Option D is not automatic and will always lag behind an actual spike, defeating the purpose of handling unpredictable traffic.
A company runs a batch-processing workload that can tolerate interruptions and can be restarted from the last checkpoint. The workload runs for several hours each night. Which EC2 purchasing option minimizes cost for this workload?
On-Demand Instances
Spot Instances
Reserved Instances with a 3-year commitment
A Savings Plan covering 100% of expected usage
Explanation
Spot Instances offer the deepest discount of any EC2 purchasing option — commonly 70-90% off On-Demand pricing — and are ideal specifically for interruption-tolerant, checkpoint-able workloads like this one, since AWS can reclaim Spot capacity with short notice. On-Demand (A) is the most expensive option for a workload with no urgent availability requirement. Reserved Instances (C) and Savings Plans (D) both require a steady, predictable usage commitment, which fits an always-on workload far better than a nightly batch job that could be interrupted without harm.
A company stores application logs in S3 that are accessed frequently for the first 30 days, occasionally for the next 60 days, and almost never after that, but must be retained for 7 years for compliance. What is the most cost-effective storage configuration?
Store all logs in S3 Standard for the full 7-year retention period
An S3 Lifecycle policy that transitions objects to S3 Standard-IA after 30 days, then to S3 Glacier Deep Archive after 90 days
Store all logs in S3 Glacier Deep Archive from the moment they are created
Manually move objects between storage classes using a script run once a year
Explanation
A lifecycle policy automatically matches storage cost to the access pattern described: Standard for the frequent-access period, Standard-IA for the occasional-access period, then Glacier Deep Archive for long-term compliance retention at the lowest per-GB cost. Option A pays Standard-tier prices for data nobody is reading after 90 days, wasting money for years. Option C makes the first 30 days of frequently-accessed logs expensive and slow to retrieve, since Glacier Deep Archive retrieval takes hours, not seconds. Option D works technically but reintroduces manual operational overhead a lifecycle policy eliminates for free.
How you did is less useful than knowing why
If you scored 12 out of 12, that is a reasonable sign but not a complete one — twelve questions cannot cover four domains deeply enough to be a real readiness test on their own. If you missed a few, look at whether you missed them by picking a technically-valid-but-wrong answer (the actual failure mode SAA-C03 is designed to test) versus a genuine knowledge gap. Those two situations call for different fixes: the first needs more scenario practice under time pressure, the second needs more hands-on time with the specific service.
CertSharp's full SAA-C03 bank has 500 questions built the same way — enough to practice at full exam length repeatedly without seeing the same scenarios twice, with a domain-by-domain score breakdown after every attempt so you know exactly where to focus next.
Get the Full 500-Question Bank
These 12 are a sample. The full SAA-C03 bank has 500 questions across all four domains, each with a full explanation. Try 30 free, no credit card.