SAA-C03 (SAA-C03) — Questions 301–375

Memory optimized instances are designed for workloads that process large datasets in memory, not for CPU-intensive tasks like image resizing and compression, which primarily require high compute power.

Storage optimized instances are designed for workloads with high sequential I/O access to large datasets on local storage, not for CPU-intensive image processing tasks like resizing and compressing images.

General purpose instances balance compute, memory, and networking, but for CPU-intensive image processing, compute optimized instances offer better price-performance due to higher vCPU count and faster clock speeds.

A question describing a service that processes large in-memory databases or real-time big data analytics, where the primary bottleneck is memory capacity and throughput, would make memory optimized instances the correct choice.

A question asking for an EC2 instance family optimized for workloads that require high, sequential read/write access to very large datasets stored locally on the instance, such as distributed file systems, data warehousing, or log processing.

A question asks for a balanced instance family for a web application with moderate CPU and memory usage, where cost and flexibility are priorities, and no specific resource is a bottleneck.

Candidates may mistakenly think that image processing requires large amounts of memory, or they may confuse memory-intensive workloads with compute-intensive ones.

Candidates may mistakenly think image processing involves heavy disk I/O due to reading/writing many image files, leading them to choose storage optimized instances instead of focusing on the CPU-bound nature of the task.

Candidates may assume 'general purpose' is always a safe starting point, overlooking that CPU-intensive workloads benefit from specialized compute optimized instances for better performance per cost.

Increasing memory size can reduce cold start duration but does not eliminate cold starts entirely; it only shortens the initialization time. The question requires minimizing cold start impact during predictable spikes, which provisioned concurrency achieves by keeping instances pre-warmed.

ALB health checks send requests to a target, but Lambda functions behind an ALB are invoked only when health checks are configured to hit a specific endpoint. However, health checks are typically sent at intervals (e.g., every 30 seconds), which may not keep the function warm during the unpredictable spikes described. Additionally, health checks can cause unnecessary invocations and costs without guaranteeing that all needed concurrent executions are warm.

In a scenario where the goal is to reduce Lambda execution duration for CPU-bound tasks without changing concurrency, and the question asks for a simple configuration change that improves performance without addressing cold starts specifically.

A question where the goal is to ensure a Lambda function remains warm for periodic requests from an ALB, and the traffic pattern is consistent (e.g., steady low traffic with occasional small spikes). In that case, ALB health checks can keep a single instance warm, reducing cold starts for the first request after idle periods.

Candidates often believe that more memory (and thus more CPU) can eliminate cold starts, confusing performance improvement with initialization elimination. They may also think that Lambda's scaling behavior is solely dependent on memory allocation.

Candidates may think that periodic requests (health checks) will keep the Lambda function warm, similar to using a CloudWatch Events rule to ping the function. They overlook that health checks are not designed to handle concurrency spikes and may not prevent cold starts for all concurrent invocations during a spike.

S3 bucket policies control S3 actions like s3:GetObject, but they cannot grant KMS permissions. Decrypting SSE-KMS objects requires explicit kms:Decrypt permission on the CMK, which must be granted via the KMS key policy or an IAM policy that the key policy allows.

The KMS key policy must explicitly grant kms:Decrypt to the IAM role; without it, the role cannot decrypt objects even if it has an IAM policy allowing kms:Decrypt, because KMS key policies control access to the CMK and can override IAM policies.

Enabling S3 default encryption does not automatically grant KMS permissions to IAM roles; you must explicitly grant kms:Decrypt in the key policy or IAM policy for the role to decrypt objects encrypted with a customer managed CMK.

In a scenario where the question asks how to grant access to decrypt objects encrypted with SSE-S3 (not SSE-KMS) or when the question specifies that the CMK's key policy already allows the account root and the role has an IAM policy granting kms:Decrypt, then the answer would focus on S3 bucket policy for s3:GetObject.

This would be correct if the question asked about granting permissions to decrypt objects encrypted with SSE-S3 (not SSE-KMS), where S3 manages the encryption keys and no KMS permissions are needed. In that case, only S3 bucket policy or IAM policy granting s3:GetObject is required.

If the question asked about using SSE-S3 (AES-256) with S3 default encryption, then no KMS permissions are needed, and the bucket policy or IAM policy would control access to the objects.

Candidates may mistakenly think that S3 bucket policies are sufficient for all aspects of S3 access, including decryption, and overlook that SSE-KMS requires separate KMS permissions.

Candidates may think that IAM policies alone are sufficient for all AWS services, forgetting that KMS uses a resource-based policy (key policy) that must explicitly allow access, especially when the key is in a different account or when the key policy denies default IAM access.

Candidates may mistakenly think that S3 default encryption automatically handles all permissions for decryption, overlooking that SSE-KMS requires explicit KMS key permissions separate from S3 actions.

Single-AZ RDS with manual backup restoration does not provide automatic failover; it requires manual intervention and incurs significant downtime, failing the requirement for automatic failover within the same Region.

A read replica is not designed for automatic failover; promoting it requires manual intervention or additional scripting, which does not meet the 'automatically fail over' requirement with minimal application changes.

Multi-AZ disabled means no automatic failover; increasing IOPS improves performance but does not provide high availability across AZs, so it fails the requirement of automatic failover during an AZ failure.

If the requirement were to minimize costs and allow for some data loss (RPO of hours) and downtime (RTO of hours), with no need for automatic failover, then a single-AZ instance with periodic backups would be acceptable.

This option would be correct if the requirement was to offload read traffic from the primary database and have a standby for manual failover in a disaster recovery scenario, where some downtime is acceptable and application changes are allowed.

If the requirement were to improve database performance for a read-heavy workload without needing automatic failover, increasing IOPS on a single-AZ instance would be correct.

Candidates may think that restoring from backups is a valid disaster recovery method, but they overlook the requirement for automatic failover with minimal application changes.

Candidates may think a read replica in a different AZ provides automatic failover similar to Multi-AZ, but they overlook that read replicas require manual promotion and do not provide automatic, seamless failover.

Candidates may confuse performance improvements (IOPS) with availability features, thinking that faster storage can compensate for lack of redundancy.

IAM user access keys are long-term credentials and do not solve cross-account access; the app in account A needs to assume a role in account B, not use a user with a policy attached directly.

Option C grants s3:PutObject to all principals in account A, which violates least privilege by not restricting to the specific app role, and it does not address the missing trust relationship needed for cross-account access via role assumption.

The problem is lack of cross-account trust, not an SCP. SCPs deny actions at the OU/account level but don't grant permissions; they would only block access if already allowed, and here no trust exists.

If the question asked for a solution where a single IAM user in account A needs to upload objects to an S3 bucket in account B without using roles, and the bucket policy allows access based on user ARN, then creating access keys for that user and attaching the necessary permissions would be correct.

This option would be correct if the question stated that the app in account A uses an IAM user with programmatic access keys (not a role) and the requirement is to allow that user to write to the bucket without assuming a role, using a bucket policy that grants access to the entire account A.

An SCP denying sts:AssumeRole unless MFA is used would be correct in a question where an organization wants to enforce MFA for all cross-account role assumptions, and the issue is that a role is being assumed without MFA.

Candidates may think that attaching a policy to access keys is a straightforward way to grant permissions, overlooking the cross-account nature of the problem and the need for role assumption.

Candidates may think a bucket policy is the simplest way to grant cross-account S3 access, overlooking that the app's IAM role still needs explicit permission to assume a role in account B, and that a bucket policy alone does not replace the need for a trust relationship.

Candidates may confuse SCPs with IAM policies or think that any denial of access can be fixed by adding a deny statement, not realizing SCPs are a guardrail, not a solution for missing trust relationships.

Amazon S3 bucket versioning protects objects within S3 from accidental deletion or overwrite, but it does not back up EBS volumes. EBS volumes are block-level storage attached to EC2 instances, and S3 versioning cannot capture or restore the volume's state.

AWS Security Hub is a security posture management service that aggregates and prioritizes security findings from various AWS services; it does not provide backup or restore capabilities for EBS volumes.

CloudFront invalidations are used to remove cached content from edge locations, not for backing up or restoring EBS volumes.

A question asks for a backup method for files stored in an S3 bucket, where the requirement is to preserve previous versions of objects to recover from accidental deletions or overwrites. In that scenario, S3 bucket versioning is the correct answer.

A question asks: 'Which AWS service should be used to centrally view and manage security alerts and compliance status across multiple AWS accounts?' In that context, Security Hub would be the correct answer.

A company uses CloudFront to distribute a static website and updates the origin content. They need to ensure users see the latest version immediately. CloudFront invalidations would be the correct answer to clear the cache.

Candidates may think S3 versioning is a general-purpose backup feature, or they confuse it with EBS snapshots which are stored in S3, leading them to believe S3 versioning can back up EBS volumes.

Candidates may confuse 'security' with 'backup' or think that Security Hub includes backup features because it is a security-related service, leading them to select it incorrectly.

Candidates may confuse 'invalidations' with 'backups' or think that clearing cache is a form of data protection, but it serves a completely different purpose.

EBS multi-attach does not support attaching a single volume to instances across different Availability Zones; it only works within a single AZ. Therefore, cross-AZ tasks cannot share the same EBS volume.

S3 does not provide a POSIX-compliant shared filesystem with low-latency file locking and immediate consistency needed for streaming intermediate artifacts between tasks; it is an object store, not a filesystem.

Instance store is ephemeral and not shared across tasks, so tasks in different AZs cannot access a common filesystem. SQS message copying adds latency and complexity, failing the low-latency shared filesystem requirement.

If all ECS tasks are running in the same Availability Zone and require a shared block storage with low latency and consistent performance, EBS multi-attach would be the correct choice for a shared filesystem.

A question where the requirement is to store and process large volumes of static artifacts with event-driven workflows, and low-latency shared filesystem access is not needed. For example: 'A data pipeline processes uploaded images and triggers a Lambda function to generate thumbnails.'

A question where tasks need high-speed local scratch storage and can tolerate eventual consistency, such as a batch processing job that processes independent chunks and only needs to aggregate results via a queue.

Candidates may think EBS multi-attach provides cross-AZ sharing similar to EFS, but they overlook the single-AZ limitation of EBS multi-attach.

Candidates may think S3 can serve as a shared filesystem due to its durability and event notifications, overlooking the need for low-latency POSIX semantics and concurrent file access.

Candidates may think instance store offers high performance and SQS can coordinate file transfers, overlooking that instance store is ephemeral and not shared, and that SQS cannot provide a POSIX filesystem.

AWS Config does not generate GetObject logs; it tracks resource configuration changes and compliance, not data plane operations like S3 object access.

VPC Flow Logs capture IP traffic metadata (source/destination IP, ports, protocol) but do not log S3 API operations like GetObject or PutObject; they lack object-level details.

Denial events from a bucket policy that denies GetObject requests do not provide visibility into successful object access or writes; they only log denied attempts, not the actual GetObject or PutObject operations needed for detective controls.

A question asking how to automatically detect and alert on S3 bucket policies that allow public access or are noncompliant with security standards, using AWS Config rules.

A question asking for network-level visibility into traffic to/from an S3 gateway endpoint (e.g., to detect unusual data transfer volumes or IP addresses) would make VPC Flow Logs the correct answer.

If the question asked for a method to enforce encryption in transit for S3 access and log any non-compliant requests for security auditing, then adding a bucket policy that denies GetObject unless TLS is used would be correct, as it generates denial logs for non-TLS requests.

Candidates may confuse AWS Config's compliance monitoring with logging capabilities, thinking it can produce object-level access logs when it only evaluates configuration states.

Candidates may confuse network traffic logs with application-level API logs, assuming that all data movement is captured at the network layer, or they may overestimate the granularity of VPC Flow Logs.

Candidates may think that any policy action that generates logs provides visibility, but they overlook that detective controls require logging of successful operations, not just denials.

Spread placement groups are designed to reduce correlated failures by placing instances across distinct hardware, but they do not provide the low-latency, high-bandwidth network performance required for microsecond-level latency. Additionally, placing instances across multiple Availability Zones increases network distance and latency.

Partition placement groups are designed to reduce correlated hardware failures for large distributed workloads like HDFS or Cassandra, not to minimize network latency. They do not provide the low-latency, high-bandwidth network performance required for microsecond-level inter-node communication.

An Application Load Balancer (ALB) operates at Layer 7 and introduces significant latency (milliseconds), which is unacceptable for microsecond-sensitive trading. It also distributes traffic across AZs, increasing latency further.

A question requiring high availability and fault isolation for a small number of critical instances, such as a distributed application that must survive an Availability Zone failure, where low latency is not the primary concern.

A question asks for a fault-tolerant deployment for a large-scale data processing job (e.g., Hadoop or Kafka) that must tolerate rack-level failures while still providing some network isolation. Partition placement groups spread instances across logical partitions, each with its own rack, to reduce the impact of a single rack failure.

For a web application requiring high availability, fault tolerance, and automatic scaling across multiple Availability Zones, with traffic distributed at the application layer (e.g., HTTP/HTTPS).

Candidates may think that spreading instances across multiple Availability Zones improves both fault tolerance and performance, but they overlook that this increases latency, which is unacceptable for latency-sensitive applications.

Candidates may confuse partition placement groups with cluster placement groups, assuming both offer low latency, or they may think that any placement group within one AZ improves network performance, overlooking the specific design goals of each type.

Candidates may think load balancing always improves performance and availability, overlooking the extreme low-latency requirement that makes ALB's overhead unsuitable.

An IAM permissions policy attached to a role used only by the security team cannot enforce a guardrail across all accounts because it only applies to principals assuming that role, not to all IAM users in every account. Local administrators in other accounts can still create access keys unless explicitly denied by a centralized policy like an SCP.

KMS key policies control encryption key usage, not IAM user actions like creating access keys. They cannot enforce a guardrail against IAM operations across accounts.

A permission boundary applies only to a single IAM role, not to all users and roles across multiple accounts, so it cannot enforce the guardrail organization-wide.

This option would be correct in a scenario where the requirement is to restrict access key creation only for users who assume a specific role (e.g., a cross-account role used by security auditors), and the organization does not need to enforce the restriction on all users across all accounts.

A question requiring encryption key management restrictions, such as 'You need to prevent users from disabling or deleting a specific KMS key used for S3 bucket encryption across multiple accounts.' In that case, a KMS key policy with explicit deny statements would be the correct mechanism.

In a scenario where you need to restrict the maximum permissions for a specific IAM role (e.g., a developer role) without affecting other roles or users, a permission boundary would be the correct mechanism.

Candidates may think that attaching a deny policy to a security team role is a simple way to enforce restrictions, but they overlook that it only applies to that role's sessions, not to all IAM users in the organization.

Candidates may confuse 'key' in KMS with 'access key' and think KMS policies can control access key creation, or they may mistakenly believe KMS policies can enforce IAM actions.

Candidates may confuse permission boundaries with service control policies, thinking they can be applied broadly, but permission boundaries are limited to individual IAM entities.

Moving a Lambda function to Amazon S3 is not possible because S3 is a storage service, not a compute service. Lambda functions cannot be hosted or executed on S3.

Changing the function to an ALB target does not improve CPU-heavy JSON transformation performance; it only changes how the function is invoked, not its execution resources.

Disabling CloudWatch logging does not improve CPU-bound performance; it only reduces logging overhead, which is negligible for CPU-heavy transformations.

A question asks how to reduce costs for infrequently accessed data that must be stored for compliance. The correct answer would be to move the data to Amazon S3 Glacier or S3 Standard-IA, not the function itself.

When a question asks how to expose a Lambda function over HTTP/HTTPS with path-based routing or to integrate with an existing ALB, and the function is not already behind an API Gateway, then making it an ALB target would be correct.

A Lambda function is experiencing timeouts due to excessive logging (e.g., logging large payloads in a tight loop). Disabling or reducing logging would free up execution time and prevent throttling, making it the correct first step.

Candidates may confuse moving the function's code to S3 (e.g., storing deployment packages) with moving the function itself, or think S3 can execute code like Lambda.

Candidates may think that routing through an ALB can offload processing or improve performance, but ALB is a load balancer for HTTP traffic, not a compute optimizer.

Candidates may think logging consumes significant resources and disabling it will speed up execution, but for CPU-heavy tasks, the bottleneck is compute, not I/O from logging.

Application Load Balancer does not support TCP at the transport layer; it operates at Layer 7 (HTTP/HTTPS) and cannot handle custom TCP protocols. It also does not provide static IP addresses.

Amazon API Gateway does not support custom TCP protocols; it only handles HTTP/HTTPS and WebSocket traffic, and it does not provide static IP addresses at the load-balancing layer.

An Application Load Balancer would be correct for a web application requiring advanced HTTP/HTTPS routing (e.g., path-based or host-based routing) with SSL termination, where static IPs are not needed and clients use HTTP/HTTPS.

A question asking for a fully managed service to expose RESTful APIs or WebSocket endpoints with throttling, caching, and authentication, where the backend is an AWS service like Lambda or HTTP endpoints.

Candidates may assume ALB supports all protocols because it is a common load balancer, or they confuse its Layer 7 capabilities with Layer 4, overlooking the requirement for custom TCP and static IPs.

Candidates may think API Gateway can handle any protocol because it supports WebSocket, or they confuse its throttling and routing features with load balancing capabilities.

Amazon Route 53 alias records are used for DNS routing, not for database backup or point-in-time recovery of RDS instances.

Security groups act as a virtual firewall for controlling inbound and outbound traffic to RDS instances, but they do not provide backup or point-in-time recovery capabilities.

AWS WAF rules are used to filter and monitor HTTP/HTTPS traffic to protect web applications from common web exploits, not for database backup or point-in-time recovery.

A question asks: 'Which AWS service can be used to route traffic to an RDS database with a custom domain name?' In that context, Route 53 alias records would be correct.

A question asks: 'Which AWS feature should be used to restrict network access to an RDS database to only allow traffic from a specific application server?' In that scenario, security groups would be the correct answer.

A question asking how to block SQL injection or cross-site scripting attacks against an Application Load Balancer or CloudFront distribution would make AWS WAF rules the correct answer.

Candidates may confuse 'alias records' with 'backup records' or think Route 53 manages database snapshots due to its broad management capabilities.

Candidates may confuse security groups with database backup features because both are common RDS configuration tasks, leading them to select a familiar option without reading the question carefully.

Candidates might confuse 'rules' for backup policies or think WAF provides some form of data protection, but WAF is a web application firewall, not a backup service.

NACLs are stateless, not stateful; they do not automatically track connections. The issue is missing outbound ephemeral port rules in the NACL, not security group inbound rules for client source ports.

The question describes connection timeouts due to missing outbound NACL rules for ephemeral ports, not health check failures. ALB health checks are not mentioned as failing, and changing the health check port does not address the stateless NACL issue.

The issue is not about internet connectivity; instances are in private subnets but the ALB is in a public subnet and handles internet-facing traffic. A NAT gateway is for outbound internet access from private instances, not for fixing return traffic blocked by a stateless NACL.

This option would be correct if the question stated that NACLs are stateful and the security group was blocking return traffic. For example: 'An application uses a stateful firewall (like a security group) and clients see timeouts; what is the fix?'

In a scenario where an ALB target group health check is failing because the health check path or port is not configured correctly (e.g., the application listens on port 8080 but health check targets port 80), updating the health check to the correct port would resolve the issue.

In a scenario where EC2 instances in private subnets need to download updates from the internet, and the outbound NACL blocks ephemeral ports, adding a NAT gateway would be correct to allow outbound traffic and its return traffic.

Candidates may confuse NACLs with security groups, assuming NACLs are stateful like security groups, and think the fix involves adding inbound rules to the security group for client ports.

Candidates may confuse connectivity issues with health check misconfigurations, especially when ALB is involved, and assume that adjusting health check settings can fix general traffic flow problems.

Candidates may confuse network connectivity issues with internet access requirements, assuming private subnets always need a NAT gateway for any traffic flow, even when the traffic is internal to the VPC via an ALB.

S3 Transfer Acceleration speeds up uploads over long distances but does not protect against accidental deletion or overwrite, nor does it create a cross-region copy for disaster recovery.

Lifecycle policies to move objects to Glacier provide cost optimization for long-term storage, but do not protect against accidental overwrite/deletion or provide cross-region recovery.

Block Public Access prevents public access to S3 objects but does not protect against accidental overwrite or deletion by authorized users, nor does it provide cross-region replication for disaster recovery.

A company needs to upload large files from multiple global locations to a central S3 bucket and requires faster upload speeds. Enabling Transfer Acceleration would be the correct action to reduce upload latency.

An architect needs to reduce storage costs for infrequently accessed data that must be retained for compliance, with no requirement for immediate retrieval or cross-region redundancy.

An exam question where the requirement is to prevent public access to sensitive data stored in S3, such as financial records or personal information, and no other access controls are specified.

Candidates may confuse 'acceleration' with 'protection' or think it helps with replication, not realizing it only optimizes data transfer speed, not durability or availability.

Candidates may confuse lifecycle policies with data protection mechanisms, assuming moving to Glacier inherently secures data, or they may think Glacier's durability alone addresses the requirements.

Candidates may mistakenly think Block Public Access provides general data protection, confusing it with versioning or replication features that actually prevent overwrites and enable recovery.

A larger NAT Gateway increases outbound bandwidth but does not decouple the frontend from workers; it does not help the frontend stay responsive when workers are overloaded.

Scaling vertically to a single bigger EC2 instance does not address traffic spikes that overwhelm workers; it creates a single point of failure and does not provide elasticity or decoupling. The frontend would still block if the single worker is overloaded.

Route 53 health checks monitor endpoint availability and trigger DNS failover, but they do not decouple the frontend from downstream workers or absorb traffic spikes. The frontend would still directly invoke workers, causing overload and slowdowns.

In a scenario where the application experiences high outbound traffic from private subnets to the internet and is hitting NAT Gateway bandwidth limits, a larger NAT Gateway would be the correct answer to increase throughput.

A question where the bottleneck is CPU or memory on a single worker instance, and the goal is to handle increased load without redesigning the architecture (e.g., a legacy monolithic application that cannot be distributed).

A Route 53 health check on the frontend would be correct in a scenario where the application needs to detect frontend failure and route traffic to a standby frontend in a different region for high availability.

Candidates may think that scaling network capacity (NAT Gateway) will resolve performance issues, confusing network bandwidth with application-level decoupling needed to handle worker overload.

Candidates may think that a larger instance can handle more load, ignoring that spikes require horizontal scaling and decoupling to keep the frontend responsive.

Candidates may think health checks can detect worker overload and redirect traffic, but health checks only assess endpoint health (e.g., HTTP 200), not load or queue depth, and cannot buffer requests.

Increasing Lambda timeout does not address database throttling or duplicate records; it only allows the function to wait longer, but the database will still throttle under load, and retries will still create duplicates.

SNS pushes messages to all subscribers immediately without buffering or throttling, so it does not help with database throttling or retry management; it would still overwhelm the database and cause duplicate processing.

Disabling retries entirely would cause order writes to fail permanently during throttling, losing data and increasing timeouts, which contradicts the need for safe retry behavior.

If the question were about handling a slow database that occasionally takes longer than the default Lambda timeout (e.g., 3 seconds) but never throttles, and idempotency is already handled, increasing the timeout would prevent timeouts.

A question where the goal is to fan out a single event to multiple downstream services (e.g., order placed triggers email, SMS, and analytics) and immediate delivery is acceptable, with no need for buffering or retry control.

In a scenario where duplicate processing is unacceptable and the system can tolerate occasional data loss (e.g., non-critical logging), and retries are handled externally (e.g., by a queue with DLQ), disabling Lambda retries prevents duplicate records.

Candidates think that giving Lambda more time will solve the throttling issue, but they overlook that the root cause is database capacity, not Lambda execution time.

Candidates may confuse SNS with SQS, thinking any messaging service provides buffering, or they may overvalue 'immediate delivery' without considering the need for decoupling and retry safety.

Candidates may think that disabling retries directly solves the duplication problem without considering that it also eliminates the ability to recover from transient failures, leading to data loss.

Option B allows s3:PutObject on all objects under ci-artifacts (not just uploads/), violating the least privilege requirement to restrict uploads to uploads/*. Additionally, it grants s3:ListBucket without a prefix condition, allowing listing of all objects in the bucket, which is broader than needed.

The pipeline needs to upload artifacts (PutObject) and list objects (ListBucket) to verify uploads, not download them. GetObject is for reading object content, which is not required for verification.

Option D includes s3:DeleteObject, which is not required for the pipeline's tasks of uploading and listing artifacts. Granting unnecessary permissions violates the principle of least privilege.

This option would be correct if the requirement was to allow the pipeline to upload artifacts to any location under the bucket and list all objects (e.g., for general bucket management). For example, a CI pipeline that needs to upload build outputs to various folders and verify the entire bucket contents.

A scenario where the pipeline needs to download or read the content of uploaded artifacts (e.g., for validation or processing) would require s3:GetObject on the upload path.

This option would be correct if the pipeline also needed to delete old or failed uploads from the uploads/ prefix to manage storage or clean up after a failed build.

Candidates may think that allowing PutObject on the entire bucket is simpler and still meets the upload requirement, overlooking the need to restrict to uploads/. They may also underestimate the risk of granting ListBucket without a prefix condition.

Candidates may confuse 'verifying upload succeeded' with needing to read the object, or think that listing requires GetObject permission.

Candidates may think that including DeleteObject is harmless or might be needed for cleanup, overlooking that the question explicitly requires only upload and list capabilities.

On-Demand instances with future Spot capacity do not guarantee cost reduction for steady 24/7 usage, as Spot instances can be interrupted and are not suitable for continuous workloads. Compute Savings Plans provide a consistent discount for steady usage while allowing instance family changes.

Reserved Instances lock you into a specific instance type and region, which contradicts the requirement to change instance families/sizes during performance tuning.

Spot Instances can be interrupted with little notice, making them unsuitable for a continuously running 24/7 web service that requires high availability and reliability.

If the workload is fault-tolerant, flexible, and can handle interruptions (e.g., batch processing, stateless applications), and the question asks for the lowest cost option without requiring steady 24/7 operation, then using Spot Instances with On-Demand fallback would be correct.

A question where the workload has predictable, steady usage and the instance family and size are fixed and known for the entire term, with no need for future changes.

For a fault-tolerant, stateless, or batch processing workload that can handle interruptions and is not required to run continuously, Spot Instances offer significant cost savings.

Candidates may think that combining On-Demand with Spot offers flexibility and cost savings, but overlook that Spot instances are not reliable for steady, continuous workloads due to potential interruptions.

Candidates may think Reserved Instances always offer the best discount for steady usage, overlooking the flexibility trade-off required by the scenario.

Candidates see 'reduce cost' and know Spot Instances are cheaper, but overlook the requirement for continuous, steady compute usage that cannot tolerate interruptions.

RDS cross-region read replicas do NOT automatically failover. Only RDS Multi-AZ provides automatic same-region failover. Manual promotion is required for cross-region replicas.

Restoring from a snapshot creates a new instance from an older state. The read replica contains more recent data (continuously synchronized). Promotion is faster and yields less data loss than snapshot restoration when the replica is available.

Creating an empty new instance and manually re-entering data is not a valid DR procedure. The read replica already contains synchronized production data. Never manually re-enter data as part of a DR plan.

Changing to SSE-S3 removes customer-managed KMS controls, violating the requirement to keep encryption at rest with customer-managed KMS.

Moving the EC2 instance into the same Availability Zone as the S3 bucket does not resolve encryption errors related to KMS permissions, as S3 is a regional service and Availability Zone placement does not affect KMS authorization.

Attaching AmazonS3FullAccess does not bypass KMS authorization; S3 still requires KMS permissions to decrypt objects encrypted with customer-managed KMS keys, so the application would still fail.

If the question required removing dependency on KMS permissions and allowed using AWS-managed keys, switching to SSE-S3 would simplify access without encryption errors.

This option would be correct in a scenario where the application is experiencing high latency or data transfer costs due to cross-AZ data retrieval from S3, and the question asks for a change to reduce latency or cost while maintaining encryption at rest.

This option would be correct if the question stated that the application needs full S3 access and encryption is not a concern (e.g., using SSE-S3 or no encryption), and the issue is a missing S3 permission rather than a KMS permission.

Candidates may think SSE-S3 eliminates KMS permission issues, overlooking the explicit requirement for customer-managed KMS controls.

Candidates may mistakenly believe that S3 operations are affected by network proximity at the AZ level, or confuse S3 with services like EC2 or EBS where AZ placement impacts performance and errors.

Candidates may think that granting full S3 access overrides all other permissions, not realizing that KMS has its own authorization layer that must be satisfied separately.

Keeping the bucket public allows anyone with the S3 URL to access thumbnails directly, bypassing CloudFront. Signed cookies control access via CloudFront but do not prevent direct S3 access, so this fails to meet the requirement.

Enabling S3 static website hosting exposes the S3 bucket via its website endpoint, allowing users to bypass CloudFront and access thumbnails directly, which violates the requirement to prevent direct access.

WAF rules at CloudFront can block certain requests but do not prevent direct access to the S3 bucket; users could still bypass CloudFront and access the bucket directly if the bucket policy allows it.

If the requirement were to restrict access to thumbnails while allowing both CloudFront and direct S3 access for authorized users, signed cookies (or signed URLs) could be used with a public bucket to control access at the CloudFront level, but the bucket itself would remain accessible.

This option would be correct if the requirement was to serve static content (e.g., a single-page application) directly from S3 without CloudFront, and the question asked for the simplest way to host a static website with public access.

In a scenario where the S3 bucket is already configured to allow only CloudFront access (e.g., via OAI/OAC) and the goal is to add an additional layer of security to block specific request patterns (e.g., SQL injection) at the CloudFront edge, a WAF rule would be appropriate.

Candidates may think signed cookies provide comprehensive access control, but they overlook that the bucket policy must also restrict direct access. The option seems to address user authentication without considering the need to block direct S3 access.

Candidates may confuse 'static website hosting' with a security feature, thinking it restricts access, or they may mistakenly believe it integrates with CloudFront to block direct access.

Candidates may think that a WAF rule at CloudFront can enforce access control globally, misunderstanding that WAF operates at the application layer and does not restrict network-level access to the S3 bucket.