SAA-C03 (SAA-C03) — Questions 676–750

Without versioning, the lifecycle policy cannot protect against accidental overwrites or deletes, and Glacier transition does not provide quick recovery from a full Region outage (RPO ~1 hour).

Without versioning, S3 cross-Region replication cannot protect against accidental overwrites or deletes because replication only copies the current version; deleted or overwritten objects are not recoverable.

EBS snapshots are for EC2 instance volumes, not for S3 data. They cannot protect against accidental overwrites/deletes in S3, nor do they provide cross-Region recovery for S3 objects.

A company needs to archive old data to reduce costs, has a separate backup strategy for disaster recovery, and can tolerate retrieval times of hours for data older than 7 days.

A company needs to replicate objects to another Region for low-latency access or compliance, but does not require protection against accidental deletion or overwrite. Versioning is not needed because the source bucket is append-only or objects are immutable.

This would be correct if the question asked about recovering an EC2 instance's root volume or data volume after a failure, with RPO of 1 hour, and the uploads were temporarily cached on an EBS volume before being moved to S3.

Candidates may think that transitioning to Glacier provides a low-cost backup, but they overlook that versioning is required for recovery from accidental changes and that Glacier retrieval is too slow for a 1-hour RPO.

Candidates may think CRR alone provides disaster recovery, overlooking that versioning is essential for recovering from user errors like overwrites and deletes.

Candidates may confuse EBS snapshots as a general backup mechanism for any data, or think that since uploads pass through a cache, snapshots of that cache can protect the data.

Standard RIs are locked to a specific instance type, size, and region. When the r5 workload migrates to r6i, the r5 RI continues billing but no longer matches the running instances — creating waste and uncovered On-Demand charges.

EC2 Instance Savings Plans lock to a specific instance family (e.g., r5) in a specific region. When the workload migrates to r6i, the Savings Plan no longer covers the new instances — they are charged at On-Demand rates.

Convertible RIs allow exchanging for different families, which could handle the r5→r6i migration. However, the exchange process is manual, requires purchasing new RIs of equal or greater value, and Compute Savings Plans provide the same flexibility automatically.

NLBs do not support security groups; they rely on target group health checks and network ACLs. Additionally, routing through an Internet Gateway would expose the NLB to the public internet, violating the requirement for private connectivity.

S3 Gateway endpoints only provide private access to S3 services, not to NLB-hosted services. They cannot route traffic to a Network Load Balancer or any non-S3 endpoint.

Using a bastion host requires SSH access and does not provide private connectivity via AWS PrivateLink; it introduces a single point of failure, management overhead, and violates the least-privilege principle by granting broad network access.

If the question required public internet access to an Application Load Balancer (ALB) and asked for access restriction, an Internet Gateway with a security group attached to the ALB would be appropriate. For example: 'Allow external clients to access an ALB over the internet, but restrict access to a specific IP range.'

This option would be correct if the question asked for private access to an S3 bucket from a consumer VPC, and the service hostname was stored in SSM Parameter Store for client configuration. For example: 'Your company needs to allow a consumer VPC to access an S3 bucket privately without using the internet.'

A scenario where a consumer needs occasional, interactive access to a provider's internal resources (e.g., database administration) and the provider cannot expose a service via PrivateLink; a bastion host with strict security group rules and SSH key management would be appropriate.

Candidates may mistakenly think security groups can be attached to any load balancer, and that an Internet Gateway is necessary for any cross-VPC communication, overlooking AWS PrivateLink as a private solution.

Candidates may confuse 'Gateway Endpoint' with 'Interface Endpoint' or think that any VPC endpoint can provide private connectivity to any service, not realizing S3 Gateway endpoints are service-specific.

Candidates may think a bastion host is a standard pattern for cross-VPC access and overlook that PrivateLink offers a more secure, managed, and scalable solution without requiring SSH or a jump box.

Weighted routing with a 50/50 split distributes traffic evenly regardless of health, failing to automatically fail over to the secondary region when the primary endpoint is unhealthy.

Latency-based routing directs traffic to the region with the lowest latency for each user, not to a primary region with failover to a secondary region when the primary is unhealthy.

Geolocation routing directs traffic based on client location, not health. Without health checks, it cannot automatically fail over when the primary endpoint is unhealthy, which is the core requirement.

When the requirement is to distribute traffic evenly across two healthy endpoints for load balancing, without automatic failover, such as for A/B testing or gradual rollout.

A global application wants to minimize latency for users worldwide and does not require active failover; each user should be routed to the region that provides the fastest response time, with health checks optionally used to exclude unhealthy endpoints.

A question requiring traffic to be routed to specific endpoints based on client geographic origin (e.g., 'Route users from Europe to eu-west-1, and users from North America to us-east-1') without needing automatic failover would make geolocation policy correct.

Candidates may think a 50/50 split provides redundancy, but it lacks health-based failover and does not meet the requirement for automatic failover to a secondary region.

Candidates may confuse latency-based routing with failover because both involve multiple regions, but latency routing optimizes for speed, not for a primary-secondary failover pattern.

Candidates may confuse geolocation with failover, thinking that routing by location inherently provides redundancy, or they overlook the explicit need for health checks to trigger failover.

Security group rules operate at the network/transport layer and cannot inspect application-layer content like SQL injection payloads. They only filter based on IP, port, and protocol, not HTTP request bodies.

Network ACLs operate at the subnet level and cannot inspect application-layer content like SQL statements in request bodies; they only filter based on IP, port, and protocol.

KMS encryption on ALB listener certificates secures data in transit but does not inspect or block SQL injection or malicious HTTP requests; it provides no web attack protection.

If the question asked to block all traffic from a specific IP range at the network level before it reaches the ALB, adding an inbound security group rule denying that IP range would be correct. For example: 'Block all requests from a known malicious IP range at the ALB.'

A question asks to block traffic from a specific IP range at the subnet boundary for a VPC, where application-layer inspection is not required.

A question asks how to enforce encryption for data in transit between the ALB and clients, or to meet compliance requirements for TLS termination using customer-managed keys, where the ALB must use certificates encrypted with KMS.

Candidates may think security groups can block attacks because they are a common security control, but they confuse network-layer filtering with application-layer inspection that WAF provides.

Candidates may confuse network ACLs with WAF, thinking ACLs can perform deep packet inspection, or they overestimate the capabilities of network-layer filtering.

Candidates may confuse encryption with security controls, thinking that encrypting traffic somehow prevents attacks, or they may overestimate the scope of KMS capabilities.

Option A requires the application to call GetParameter on each request or a short refresh interval, which does not meet the requirement for credentials to be rotated without redeploying the task definition. Additionally, Parameter Store SecureString does not support automatic rotation, failing the rotation requirement.

Storing the password in a local file within the container image at build time prevents rotation without redeploying the task definition, violating requirement (2). It also does not use AWS-managed encryption controls for the password at rest, as the image may be stored in Amazon ECR without encryption.

Option D fails because it does not support credential rotation without redeploying the task definition, and the broad IAM policy on the bucket prefix violates least-privilege permissions by allowing all ECS tasks to read the password.

If the requirements did not include automatic rotation and allowed the application to fetch the secret on each request (e.g., for a non-critical config value that changes infrequently), Parameter Store SecureString with IAM least-privilege would be a valid, cost-effective solution.

This option would be correct if the requirement was to avoid any runtime dependency on AWS services for secret retrieval (e.g., offline or air-gapped environment) and rotation was not required, with the password being static and updated only via image rebuild.

This option would be correct if the requirement was to store a large, static configuration file (e.g., a machine learning model) that is encrypted at rest, accessed by multiple tasks, and does not require rotation or strict least-privilege per task.

Candidates may confuse Parameter Store SecureString with Secrets Manager, thinking both support encryption and IAM policies, and overlook the specific rotation requirement. They might also assume that caching the secret is unnecessary or that Parameter Store is sufficient for secrets management.

Candidates may think that embedding secrets in the image as a file is more secure than environment variables and avoids network calls, but they overlook the rotation and redeployment constraints.

Candidates may think S3 with SSE provides encryption at rest and is easy to set up, overlooking the lack of rotation support and the overly permissive access policy that violates least-privilege.

Security groups operate at the instance level, not at the edge, and cannot inspect application-layer payloads like SQL injection or XSS. They only filter traffic based on IP addresses, protocols, and ports.

AWS Shield Advanced provides DDoS protection, not application-layer filtering for SQL injection or XSS. It does not inspect HTTP request payloads for these exploits.

Restricting IAM permissions for EC2 instances does not prevent SQL injection or XSS attacks at the edge; it only limits what the application can do after an attack payload reaches the instance. The question specifically asks for mitigation at the edge, which is before traffic reaches the application.

If the question asked for 'restricting inbound traffic to only HTTPS from the internet to an EC2 instance' without mentioning web exploits, then adding inbound rules to the security group for port 443 would be appropriate.

When the question asks for the best service to protect against large-scale DDoS attacks (e.g., volumetric or state-exhaustion attacks) targeting an application behind CloudFront, and the requirement is for enhanced DDoS mitigation with 24/7 support and cost protection.

This option would be correct in a question about limiting the blast radius of a compromised application, such as: 'How can you ensure that an EC2 instance running a web application cannot delete S3 buckets if it is compromised via SQL injection?'

Candidates may confuse network-layer security (security groups) with application-layer protection (WAF), assuming that restricting ports is sufficient to block web exploits.

Candidates may confuse AWS Shield Advanced with AWS WAF, assuming it includes web application firewall capabilities, or overestimate its scope of protection.

Candidates may think that restricting IAM permissions can block the execution of malicious payloads, but IAM controls API actions, not application-level input validation or attack patterns like SQL injection.

Moving each sandbox to its own payer account increases operational overhead and reduces cost visibility, contradicting the goal of lowering cost and overhead while maintaining central purchasing and spend visibility.

Dedicated Hosts increase cost and operational overhead, contradicting the goal of lowering cost and overhead. They are not needed for sandbox workloads and do not provide a lower blended rate compared to Reserved Instances or Savings Plans under consolidated billing.

Disabling AWS Budgets removes spend visibility, which the CTO explicitly wants to maintain. Consolidated billing does not automatically provide visibility; budgets and alerts are still needed.

If the CTO required strict cost isolation between accounts (e.g., for regulatory compliance or chargeback to different departments) and did not need central purchasing or consolidated discounts, then separate payer accounts would be appropriate.

A question requiring dedicated tenancy for licensing or compliance reasons (e.g., Microsoft SQL Server with per-core licensing) where Dedicated Hosts are necessary to meet license terms, and cost is less of a concern.

If the question stated that the CTO wants to reduce operational overhead and budgets are causing excessive alert noise with no value, and the company already has a separate cost monitoring tool that provides visibility, then disabling AWS Budgets could be correct.

Candidates may think separate payer accounts provide clearer cost isolation, but they overlook the increased management overhead and loss of volume discounts from consolidated billing.

Candidates may think Dedicated Hosts offer cost savings through licensing benefits or assume 'dedicated' implies better pricing, not realizing they are more expensive and only beneficial for specific licensing scenarios.

Candidates may incorrectly assume consolidated billing alone provides full visibility and that budgets are redundant, overlooking that budgets are a separate tool for proactive cost monitoring and alerts.

NLB does not support path-based routing or HTTP/2; it operates at Layer 4 and cannot inspect HTTP paths or handle WebSocket upgrades natively.

API Gateway does not natively support WebSocket connections with path-based routing to separate microservices; it would require custom integration logic and cannot directly route to different services based on path patterns like /api/* and /metrics/*.

CloudFront does not natively support WebSocket connections or path-based routing to separate microservices based on URL paths like /api/* and /metrics/*; it is a CDN, not a load balancer with those routing capabilities.

When the requirement is for ultra-high performance with static IP addresses, and routing is based on TCP/UDP traffic (e.g., port-based) without need for HTTP features like path-based routing or WebSocket support.

When the requirement is to expose a RESTful API with features like throttling, caching, and authentication, and the backend is a single service or can be handled via a single integration, with no need for WebSocket support or path-based routing to multiple microservices.

A question requiring global content delivery with low latency, DDoS protection, and caching for static or dynamic content, where the backend is a single origin (e.g., an ALB or S3) and WebSocket support is not needed.

Candidates may think NLB can handle HTTP/2 and path routing because it supports HTTP health checks, but NLB lacks Layer 7 capabilities needed for path-based routing and WebSocket upgrades.

Candidates may think API Gateway is a natural choice for API management and assume it can handle WebSocket and path-based routing, but they overlook its limitations with WebSocket and direct microservice routing without custom workarounds.

Candidates may think CloudFront can handle path-based routing via behaviors and assume it supports WebSocket, but WebSocket support in CloudFront is limited and not designed for microservice path-based routing with TLS termination at the edge.

Latency-based routing directs traffic based on lowest latency, not health status. It cannot automatically fail over to Region B when Region A is unhealthy because it lacks health check integration.

Geolocation routing directs traffic based on the geographic location of the user, not on the health of the endpoint. It cannot automatically failover from Region A to Region B when Region A becomes unhealthy.

Weighted routing with 100/0 weights does not provide automatic failover; it simply sends all traffic to Region A until you manually change weights. It lacks health checks to trigger failover when Region A becomes unhealthy.

You need to route users to the region with the lowest latency for better performance, and you have health checks to exclude unhealthy endpoints. Latency-based routing with health checks would be correct.

A company needs to route users to the nearest regional endpoint based on their country for compliance or content localization, and failover is not required. Geolocation routing would be correct if the requirement is to direct traffic from specific countries to specific regions.

A scenario where you want to gradually shift traffic from one region to another (e.g., for blue/green deployment or load balancing) without automatic failover. For example, you want to send 10% of traffic to a new region and 90% to the old region, adjusting weights manually over time.

Candidates may confuse latency-based routing with failover, thinking that routing to the lowest latency region inherently provides failover, but it does not consider health unless health checks are explicitly used.

Candidates may confuse geolocation routing with failover routing because both involve multiple regions, but geolocation focuses on user location rather than endpoint health.

Candidates may think setting weights to 100/0 is a simple way to direct all traffic to Region A, and assume failover can be achieved by manually changing weights to 0/100 when Region A fails, overlooking the requirement for automatic failover based on health checks.

Enabling automatic key rotation does not grant cross-account permissions; it only rotates the key material periodically. The mount fails due to missing cross-account access in the key policy, not due to key rotation.

In cross-account KMS access, the key policy in account B must explicitly grant permissions to the IAM role in account A; IAM policies in account A alone are insufficient because the key policy is the primary authorization mechanism for the KMS key in account B.

Disabling and re-enabling encryption on an EBS volume is not possible without recreating the volume, and it does not resolve cross-account KMS authorization issues. The root cause is missing key policy permissions in account B.

In a scenario where a customer-managed KMS key is used within the same account and the question asks for a best practice to improve security without changing permissions, enabling automatic key rotation would be correct to meet compliance requirements.

This option would be correct if the KMS key and the EBS volume were in the same account (account A). In that case, the key policy can be attached as an IAM permissions policy to the instance role, and the key policy itself is not evaluated separately for the same account.

In a scenario where an EBS volume is encrypted with a customer-managed KMS key and the instance role lacks kms:Decrypt permissions due to a misconfigured IAM policy, temporarily disabling encryption is not an option. This option would never be correct because EBS encryption cannot be toggled on an existing volume; it must be set at creation.

Candidates may think that key rotation resolves access issues because they confuse key management with access control, or they believe that rotation refreshes permissions.

Candidates may think that IAM policies in the requesting account are sufficient for cross-account access, overlooking that KMS key policies must explicitly allow principals from other accounts.

Candidates may think that disabling encryption bypasses the KMS error temporarily, or they misunderstand that EBS encryption can be changed after volume creation. They might also confuse this with the ability to modify other volume attributes.

Keeping EC2 instances running 24/7 incurs costs for idle time, contradicting the goal of paying primarily for actual runtime when the job completes in under 15 minutes daily.

Running the job as stored procedures in RDS would still require a running database instance 24/7, incurring costs for idle time, and does not align with the goal of paying primarily for actual runtime.

An Auto Scaling group with a fixed minimum size of one instance keeps an EC2 instance running 24/7, which incurs costs for idle time and does not reduce operational overhead or pay-per-use runtime.

If the job required a persistent, stateful environment (e.g., large local storage, specific OS configurations) or needed to run multiple times per day with unpredictable latency demands, EC2 instances running continuously would be appropriate.

If the question required processing large datasets directly within a database (e.g., complex aggregations on terabytes of data) and the team already had a running RDS instance for other purposes, using stored procedures could be efficient without additional compute overhead.

A question where a workload requires a single EC2 instance to always be available (e.g., a legacy application that cannot be containerized or serverless) and must automatically recover from failure, with the goal of high availability rather than cost optimization.

Candidates may default to EC2 for any compute workload without considering serverless alternatives, overlooking the cost and operational overhead of idle instances.

Candidates might think that using RDS stored procedures eliminates the need for separate compute resources, overlooking that the database instance itself must remain running continuously, incurring costs regardless of job execution.

Candidates may think Auto Scaling automatically reduces costs, but a fixed minimum of one instance means the instance never scales in, so it runs continuously, failing to meet the 'pay primarily for actual runtime' requirement.

Increasing the writer instance size does not offload read traffic from the primary node, so CPU remains high from read queries. The question explicitly allows replication lag, making read replicas a more cost-effective and scalable solution.

DynamoDB is a NoSQL database that does not support the same relational query patterns as Aurora MySQL, and the application would require significant refactoring. Additionally, DynamoDB does not inherently eliminate replication lag; it uses eventually consistent reads by default, which can have lag.

Multi-AZ failover provides high availability but does not increase read throughput; the standby replica cannot serve reads, so it does not offload the writer instance's CPU.

If the application cannot tolerate any replication lag and all queries must be strongly consistent, or if the read workload is already low and the bottleneck is write performance, then increasing the writer instance size would be correct.

A question where the application requires a fully managed NoSQL database with single-digit millisecond latency at any scale, and the data model is key-value or document-based, with no need for complex joins or transactions. For example: 'A gaming leaderboard needs to store player scores and retrieve top players with low latency; the data is simple and does not require relational queries.'

A question where the primary concern is database availability during an AZ outage, and read scaling is not required. For example: 'An application needs automatic failover to a standby instance in another AZ with zero data loss. What should be enabled?'

Candidates may think that a larger instance handles more throughput overall, overlooking that read replicas can distribute read load without scaling the writer.

Candidates may think DynamoDB is always faster and has no replication lag, overlooking the fact that it uses eventually consistent reads and requires application changes to adapt to a different data model.

Candidates may confuse Multi-AZ with read replicas, thinking the standby can handle read traffic, or assume that failover automatically improves performance.

The transcoding fleet can handle interruptions, so Spot Instances are cheaper than Reserved Instances. Purchasing All Upfront Reserved Instances for the transcoding fleet would lock in higher costs unnecessarily.

Increasing instance size to keep CPU below 30% wastes compute capacity and increases cost, contradicting the goal of lowest monthly compute cost. The question explicitly states not to change application design, and this action changes the instance type.

Dedicated Hosts increase cost due to per-host billing and do not lower spend; they are used for licensing or compliance, not cost savings. The question asks for lowest compute cost, so this option is counterproductive.

If the question specified that both workloads must run continuously without interruption and the transcoding fleet cannot tolerate any interruptions, then purchasing All Upfront Reserved Instances for the transcoding fleet would provide the lowest cost for steady-state usage.

In a scenario where the application is latency-sensitive and requires consistent low CPU utilization to handle sudden spikes, and cost is not the primary concern, increasing instance size could be correct to ensure performance.

A question where the company has a per-socket or per-core software license (e.g., Windows Server, SQL Server) that requires dedicated physical servers to remain compliant. In that case, Dedicated Hosts can reduce licensing costs despite higher infrastructure spend.

Candidates may think Reserved Instances always provide the lowest cost, overlooking that Spot Instances are even cheaper for fault-tolerant workloads.

Candidates may think that larger instances are more cost-effective per unit of compute, or that keeping CPU low improves reliability, but this overlooks that the startup's goal is to minimize total cost, not optimize utilization.

Candidates may think 'dedicated' implies better performance or security at lower cost, but Dedicated Hosts are actually more expensive and are chosen for licensing or regulatory reasons, not cost optimization.

SSE-S3 uses an AWS-managed key, not a customer-controlled key, so it fails the requirement that the customer controls the encryption key.

Client-side encryption requires managing encryption in application code, which contradicts the requirement that developers do not want to manage encryption in the application. Additionally, storing the encryption key in the same S3 bucket is insecure and violates the principle of separating keys from data.

S3 replication does not provide encryption with a customer-controlled key or the ability to quickly disable access; it only copies objects to another bucket, which may still use the same encryption settings.

A question that requires server-side encryption with minimal management overhead and no need for customer key control or quick key disabling, e.g., 'A company wants to encrypt all S3 objects by default with no additional cost or key management burden.'

This option would be correct if the requirement was that data must be encrypted before it reaches AWS (e.g., for compliance with data sovereignty laws) and the application team is willing to manage encryption logic, but they want to store the key separately (e.g., in AWS Secrets Manager or a different bucket with strict access controls).

A question requiring cross-region disaster recovery or compliance with data residency requirements, where the goal is to automatically replicate objects to a bucket in another region for redundancy, without specific encryption control or access revocation needs.

Candidates may think SSE-S3 provides encryption and is simple to implement, overlooking the specific requirement for customer-controlled keys and the ability to quickly disable access.

Candidates may think client-side encryption gives them full control over the key and avoids AWS-managed services, but they overlook the explicit requirement to avoid managing encryption in application code and the security risk of storing keys with data.

Candidates may think replication adds a layer of security or control, but it does not address encryption key management or rapid access revocation as required.

CloudTrail records API calls but does not perform continuous compliance checks or evaluate resource configurations against rules; it lacks the ability to detect unencrypted EBS volumes or security group misconfigurations in real time.

Amazon GuardDuty is a threat detection service that monitors for malicious activity, not a compliance service that checks resource configurations like EBS encryption or security group rules.

Amazon Macie is a data security service that uses machine learning to discover, classify, and protect sensitive data, not to manage encryption settings or perform compliance checks on resource configurations like EBS encryption or security group rules.

CloudTrail would be correct if the question asked for auditing all API calls made in the account, such as tracking who created or modified resources, or for detecting unauthorized API activity.

If the question asked for a service that automatically detects and alerts on suspicious API calls or network traffic patterns (e.g., compromised EC2 instances or unusual data exfiltration), GuardDuty would be the correct answer.

A scenario where Macie would be correct: 'A company needs to automatically discover and protect sensitive data such as PII or financial records stored in S3 buckets, and receive alerts when such data is exposed.'

Candidates may confuse logging API calls with monitoring resource configurations, assuming that recording changes is sufficient for compliance checks.

Candidates may confuse GuardDuty's security monitoring with compliance checking, or mistakenly think it can enforce encryption policies because of its 'security' label.

Candidates may confuse Macie's focus on data protection with compliance monitoring, or mistakenly think it handles encryption settings due to its 'security' branding.

Option C suggests using bucket website hosting and allowing public GET requests, which violates the requirement to prevent any public access to the bucket. Presigned URLs are needed for authenticated access, not public access.

ACLs cannot enforce HTTPS or restrict access to user-specific prefixes; they only grant coarse permissions. Presigned URLs already provide time-limited access, so extending expiration does not fix the 403 error caused by missing policy conditions.

A question where the requirement is to serve static website content publicly (e.g., a public-facing blog or documentation site) and the bucket policy allows public read access, with no need for presigned URLs or user-specific prefixes.

A question where the requirement is simply to allow bucket owner full control over objects while using presigned URLs for temporary access, with no need for prefix restrictions or HTTPS enforcement. For example: 'An app uses presigned URLs to share files; the bucket must prevent public access but allow the owner to manage all objects.'

Candidates may think website hosting simplifies access and eliminates the need for presigned URLs, but they overlook the strict security requirement of no public access.

Candidates may think ACLs are sufficient for access control and that longer presigned URL expirations solve 403 errors, overlooking that the real issue is a missing policy condition (like aws:PrincipalTag) to restrict access to user-specific prefixes.

AWS CloudTrail records API activity for auditing, not for discovering sensitive data within S3 objects. It cannot inspect object contents for sensitive information like PII or financial data.

AWS Config is designed to evaluate and monitor resource configurations and compliance, not to discover or classify sensitive data within S3 objects. It cannot inspect the content of objects for sensitive information like PII or financial data.

Amazon GuardDuty is a threat detection service that monitors for malicious activity and unauthorized behavior, not for discovering sensitive data within S3 objects. It does not perform content inspection or classification of data stored in S3.

A security team needs to audit all API calls made to S3 buckets, including who accessed objects and when, to meet compliance requirements. CloudTrail would be the correct service to enable for tracking S3 API activity.

A security team needs to continuously monitor and record changes to S3 bucket policies, ACLs, and other resource configurations to ensure compliance with internal security standards. AWS Config would be the correct service to track configuration changes and evaluate rules against desired configurations.

GuardDuty would be correct if the question asked for a service that continuously monitors for suspicious API calls or potential security threats (e.g., compromised credentials, unusual data access patterns) across AWS accounts and workloads, including S3 access patterns.

Candidates may confuse CloudTrail's logging of S3 operations with data discovery, assuming that logging all actions includes scanning object contents, which it does not.

Candidates may confuse AWS Config's ability to monitor S3 bucket configurations with the capability to inspect object content, assuming that 'monitoring' includes data discovery, or they may think Config can scan objects for compliance rules.

Candidates may confuse GuardDuty's threat detection capabilities with data discovery, assuming it can identify sensitive data as part of its monitoring, or they may think it scans S3 objects for anomalies that could indicate sensitive data exposure.

AWS Direct Connect establishes a dedicated network connection from on-premises to AWS, which does not address global latency or repeated requests for static content served from S3.

Amazon Route 53 health checks are used to monitor the health of resources and route traffic away from unhealthy endpoints; they do not cache content or reduce repeated requests to the origin, so they cannot improve page load performance for static assets.

Amazon EFS is a file storage service for EC2 instances, not designed for serving static web content globally or reducing repeated requests. It does not provide edge caching or content delivery acceleration.

A company needs a consistent, low-latency connection between its on-premises data center and AWS for large data transfers or real-time applications, and the question specifies hybrid cloud connectivity requirements.

A company has a multi-region application deployment and wants to automatically route users to healthy endpoints, failing over if an endpoint becomes unhealthy. In that scenario, Route 53 health checks combined with DNS failover would be the correct answer.

A question where a company needs a shared file system accessible by multiple EC2 instances for concurrent read/write operations, such as a web application's shared content or a data processing pipeline, with low-latency access within a region.

Candidates may think a dedicated connection improves speed for all traffic, but Direct Connect does not provide global edge caching or reduce repeated requests to the origin.

Candidates may think that health checks can somehow optimize performance by directing users to faster endpoints, but health checks only verify availability, not speed, and do not address caching or repeated requests.

Candidates may confuse EFS with S3 for static content storage, or think a shared file system can improve performance by centralizing files, but overlook that EFS lacks global caching and edge delivery capabilities.