SAA-C03 (SAA-C03) — Questions 451–525

A cluster placement group is a hardware-level grouping within a single Availability Zone that places instances on the same high-speed, low-latency network segment. This strategy minimizes round-trip time and packet jitter between nodes, which is critical for tightly coupled workloads that frequently synchronize via message passing or shared state. Only cluster placement groups are specifically engineered to deliver the sub-millisecond, high-bandwidth interconnect (up to 100 Gbps with EFA/ENA) that such distributed applications require.

Step scaling responds to CloudWatch alarms with tiered adjustments, so it can add many instances quickly when a metric breaches an upper threshold. This reacts to actual demand rather than a fixed schedule and scales faster than a single target tracking adjustment, which directly reduces the window where capacity lags behind a sudden surge.

ALB supports authenticate-cognito and authenticate-oidc actions on listener rules. A Cognito user pool can federate a SAML 2.0 IdP, so the ALB can offload the SAML exchange and issue its own session cookie. This meets the requirement without custom sign-in code on the EC2 instances.

A Multi-AZ deployment is the correct RDS feature for availability because Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone within the same Region. The primary DB instance writes data synchronously to the standby before committing, and if the primary fails or its AZ becomes unavailable, RDS automatically performs failover to the standby by updating the DNS endpoint, typically within 60–120 seconds without requiring manual intervention. This eliminates the need for application-level failover logic and provides a clear improvement in availability for an RDS MySQL instance.

STS AssumeRole issues short-lived credentials, eliminating long-lived access keys. Attaching least-privilege IAM policies scoped to the specific Parameter Store parameters and CloudWatch Logs write actions confines the pipeline to exactly the permissions required, satisfying both security constraints.

This approach uses On-Demand capacity to guarantee a reliable baseline and Spot capacity to handle bursts at a lower price. A target tracking policy scales the service based on demand, so during spikes more tasks are added. Since the tasks are stateless and restartable, Spot interruptions are tolerable, and the mix balances cost and availability.

Customer managed KMS keys give the company full control over rotation, and every use is recorded in AWS CloudTrail for auditing. The KMS key policy can grant or deny permissions per principal, so revoking the compromised IAM role is immediate and does not affect other roles that retain access.

ElastiCache for Redis provides an in-memory cache that absorbs repeated catalog reads, cutting database load and returning results in sub-millisecond time. Because catalog data changes only a few times per day, a time-to-live cache with invalidation on update keeps data fresh while dramatically reducing query volume during flash sales.

Point-in-time restore uses the automated backups and transaction logs to rebuild the database to an exact time before the bad change. The exhibit confirms the requested restore time is within the restorable window, and the business wants to validate the restored copy before switching traffic. Restoring to a new instance first is the safest way to recover without risking the current production database.

AWS WAF is a web application firewall that protects against common web exploits such as SQL injection and cross-site scripting. When integrated with an Application Load Balancer, it inspects incoming HTTP/HTTPS requests and applies rules to block malicious traffic. It also provides monitoring and logging of requests, meeting the security team's requirements.

AWS Systems Manager Session Manager provides secure, auditable shell-level access to EC2 instances without requiring inbound SSH/RDP ports. An IAM instance role grants the SSM agent permission to connect outbound to the Systems Manager service, and users authenticate via IAM with the ability to enforce session policies and log sessions to CloudTrail/S3/CloudWatch Logs. This avoids public exposure, enables centralized permissions and auditing, and works for instances in private subnets or without public IPs.

Amazon SQS standard queues provide durable storage across multiple Availability Zones and at-least-once delivery, meaning every message is guaranteed to be delivered eventually, but duplicates can occasionally occur due to the distributed architecture. Consumers must be idempotent so that processing the same event multiple times has the same effect as processing it once, preventing duplicate medical records or actions. This design satisfies the requirement while maintaining the high throughput needed by a patient portal.

A Compute Savings Plan provides discount coverage while preserving flexibility across EC2 families and even other compute services. That makes it ideal for the steady baseline when future family changes are expected. Spot Instances are the lowest-cost choice for the restartable batch tier because interruptions are acceptable and checkpointing is already in place.

A DLQ with a redrive policy isolates poison messages. After a message is received and fails processing more than the configured maxReceiveCount, SQS moves it to the DLQ, preventing it from continually blocking retries in the source queue.

Target tracking scaling adjusts EC2 capacity automatically in response to a CloudWatch metric such as average CPU utilisation, so the fleet expands before latency degrades. This directly addresses the stem's consistently high peak CPU and rising request latency behind the ALB.

Deploying subnets (and therefore EC2 instances) in at least two Availability Zones removes any single AZ as a point of failure. An Auto Scaling group distributed across those subnets works with a load balancer's health checks to detect unhealthy instances, terminate them, and launch replacement capacity in a healthy AZ. If one AZ fails entirely, the ASG can continue to meet desired capacity in the surviving AZ and the load balancer routes traffic away from unhealthy targets, keeping the dashboard available.

Referencing the application tier's security group as the source means only instances that carry that group can open a connection to port 3306, regardless of their IP addresses. A private subnet has no route to an internet gateway, so the database tier is not reachable from the internet, satisfying both parts of the requirement.

S3 Intelligent-Tiering automatically tracks object access and moves data between frequent and infrequent access tiers, with optional archive tiers, while charging no retrieval fees. It preserves S3 Standard latency and throughput, so analytics files remain immediately available when accessed. Because the tiering is entirely automated and backed by an SLA, it removes the need for human intervention or lifecycle guessing.

With a warm pool, Auto Scaling can launch and keep a set of instances in a pre-initialized state (for example, instances are already booted and have completed parts of startup/initialization as supported by warm pool behavior). When scaling triggers, these instances can transition to service faster and begin registering with the ALB. Because your bottleneck is that instances take ~4 minutes to become truly ready, warming them ahead of time most directly reduces the gap between scale-out and customer-ready capacity (and therefore reduces 5xx occurrences while waiting for targets to pass ALB health checks).

An RDS read replica receives asynchronous copies of the primary's data via its engine's replication mechanism, then serves read-only traffic on its own endpoint. Routing reporting queries there removes that load from the primary, satisfying the requirement to stop reporting queries slowing it down.

Because the assets are public and do not depend on Authorization, excluding Authorization from the cache key allows all users to share the same cached objects. This reduces cache fragmentation and increases cache hit ratio.

IAM database authentication lets the EC2 instance's attached role call RDS's GenerateDBAuthToken API, producing a signed token that the PostgreSQL client presents as the password; the token expires after 15 minutes and the connection uses SSL, so no permanent secret exists in application code, configuration files, or disk. With this design, you create a DB user for IAM authentication in PostgreSQL and grant it privileges while controlling access via IAM policies, making credential rotation unnecessary for the application.

Failover routing is the Route 53 policy intended for this use case. Route 53 returns the primary record while its health check passes, and automatically serves the secondary record when the primary health check fails. That provides DNS-based Regional failover without manual intervention.

IAM database authentication for RDS replaces a static database password with an authentication token generated from the EC2 instance profile using AWS Signature Version 4. The application requests the token via the RDS API (or AWS SDK), and the token is valid for only 15 minutes, so the credential is ephemeral and automatically rotated. This approach avoids long-lived secrets in application code or configuration, enforces least-privilege access because the IAM role governs which database user the instance can connect as, and logs all token generation in CloudTrail. Note that the RDS instance must have IAM DB authentication enabled, and the database user must be created with the `PASSWORD` clause set to `AUTHENTICATED OVER IAM` in PostgreSQL.

Attaching an IAM role to EC2 instances provides temporary credentials that are automatically rotated. The instances can then access S3 without storing long-term credentials. This is the AWS best practice for granting permissions to EC2 instances and meets the requirement to avoid long-term credentials.

With IAM database authentication, an EC2 instance uses its attached IAM role to generate a temporary authentication token via the RDS generate_db_auth_token API, then supplies that token as the PostgreSQL password. The token is valid for 15 minutes and is cryptographically signed by the IAM role, so RDS can verify it without a stored password. This eliminates embedded secrets, enables rotation by simply refreshing the role credentials, and gives you centralized IAM policies to control which DB users can connect from which identity.

For Interface VPC endpoints, aws:SourceVpce can be used as a condition key so KMS/Secrets Manager API authorization succeeds only when the request originates from the specified endpoint. Restricting the IAM permission to aws:SourceVpce=vpce-... directly matches the requirement that calls must not traverse other network paths (e.g., via NAT/egress).

On-demand capacity mode enables DynamoDB to automatically scale to match your workload's actual traffic, charging per read and write request (pay-per-request) rather than for provisioned capacity. For a batch analytics job with unpredictable traffic, this eliminates manual capacity planning, avoids throttling during sudden spikes, and ensures you only pay for the requests actually processed, making it the most cost-effective and operationally simple choice.

Compliance mode enforces a write-once-read-many model in which no principal, including the root user, can overwrite or delete a locked object version before the retention date expires. Objects stay readable throughout the period, satisfying the availability clause. A 30-day retention directly matches the stated recovery window, and the protection is enforced by S3 itself rather than by policy that could be changed.

Amazon OpenSearch Service is a managed implementation of the OpenSearch engine (fork of Elasticsearch), built on Apache Lucene. It creates inverted indexes from your documents so that every token is mapped to its location, enabling sub-second full-text queries with relevance scoring (e.g., BM25). This is exactly the low-latency, scalable search capability a document portal needs for rapid search across all stored content.

A permission boundary acts as a permissions ceiling for the role. Even if the team attaches an identity-based policy that grants broader permissions, the role’s effective permissions are only those allowed by both the identity policy and the permission boundary. This prevents privilege escalation by role policy changes while still allowing teams to manage which policies are attached, within the boundary.

An S3 lifecycle policy automates object transitions between storage classes based on age, so you can keep recent logs in S3 Standard for fast querying and gradually move them to S3 Standard-IA, Glacier Flexible Retrieval, or Glacier Deep Archive as they age. For example, transition logs older than 30 days to Standard-IA, then to Glacier after 90 days, and finally expire them after a defined retention period. This matches storage cost to actual access patterns without manual intervention, and you retain the ability to query recent data instantly while old data is archived cheaply.

SSE-KMS with a customer managed key lets the company define its own rotation schedule, produces separate AWS CloudTrail entries for the KMS key, and enforces access through the key policy. Restricting the key policy to the designated IAM principals ensures only those identities can perform cryptographic operations, which directly meets the stated compliance requirements.

DAX is an in-memory cache for DynamoDB reads, so repeated lookups for the same keys can be served with much lower latency than direct table reads. It is especially effective for hot-item access patterns like order lookups, product metadata, and profile reads.

An RDS read replica is a separate, read-only MySQL instance that receives asynchronous updates from the primary database. By pointing the analytics dashboard's reporting queries at the replica's endpoint, you move the expensive SELECT and aggregation work off the primary, freeing CPU, memory, and I/O for transactional writes. Multiple replicas can be added to scale read capacity further, making this the correct answer for read-only dashboard traffic.

CloudFront's cache key includes headers and query strings by default, so Authorization headers and irrelevant parameters fragment cached objects. Removing them lets versioned filenames alone key the cache, raising hit ratios without altering origin objects.

Amazon EFS is a fully managed, regional file storage service that provides a standard POSIX file system interface (NFSv4.1) for EC2 instances. By configuring mount targets in multiple Availability Zones, instances across the VPC can concurrently read and write to the same file system with shared file locking and metadata guarantees. This architecture delivers both high availability and elastic scalability, making it the appropriate shared storage layer for a warehouse integration service that must be accessed by multiple compute resources simultaneously.

An AZ outage reduces the number of AZs where the ASG can place instances. With only two AZs, losing one significantly limits capacity and can cause temporary shortages and uneven load distribution, even if existing targets are marked healthy. Expanding the ASG to subnets in three (or more) AZs provides additional placement options so the ASG can maintain the desired number of instances across the remaining AZ(s). The ALB will continue routing only to healthy targets, and the system is more likely to sustain stable response times during the outage.

Spot Instances offer the largest discounts on EC2 compute, often up to 90% off On-Demand, and are ideal for interruptible, stateless, or checkpointed workloads. Since the batch job runs for a short duration nightly and can resume from checkpoints, interruptions are tolerable. Using Spot Instances directly reduces compute costs substantially without requiring upfront commitments or long-term contracts, making it the most cost-effective option.

CloudFront caches static assets at edge locations close to viewers, so requests are served from a nearby point of presence instead of traveling to the single Region. This cuts latency for distant users without any application code changes, and it also reduces load on the origin by absorbing repeated requests for the same assets.

SSE-KMS with a customer managed key gives the company full control over rotation and revocation, and KMS integrates with CloudTrail to log every cryptographic operation. This satisfies encryption at rest, key ownership, and auditability with minimal operational effort because S3 and KMS handle the cryptographic work automatically when objects are written and read.

Block Public Access applies an account- or bucket-level guardrail that overrides bucket policies and ACLs, so any later policy granting public access is refused. This enforces the never-publicly-accessible constraint declaratively, requiring no custom operational scripts.

AWS Secrets Manager natively supports automatic rotation for Amazon RDS databases by using a Lambda rotation function. It eliminates hardcoded credentials and integrates with IAM for access control. Modifying the application to retrieve the secret at startup is a one-time change, and rotation is managed by the service, minimizing operational overhead.

CloudWatch Logs retention policies per log group directly address the cost constraint by automatically expiring debug logs after a defined period, such as seven days. Retention is set at the log-group level, so each workload's logs can be tuned independently, eliminating indefinite storage charges without altering application logging behaviour.

Amazon SQS is a fully managed message queue that decouples the order ingestion service from the backend workers. Producers send order messages to the queue, and consumers poll messages at their own sustainable rate, which naturally absorbs bursts—the queue itself acts as a temporary, durable buffer. The visibility timeout ensures in-flight messages are not processed by multiple workers, and a dead-letter queue captures poison messages after repeated failures. Because SQS retains messages for up to 14 days and integrates with Auto Scaling via the ApproximateNumberOfMessages metric, it is the correct service for handling unpredictable spikes in order volume.

Graviton instances are ARM-based and often deliver better price-performance than comparable x86 instances for CPU-bound workloads. Because the application is already compatible with ARM64, the team can adopt Graviton without rewriting the pipeline. That improves throughput per dollar while keeping the same batch-processing model.

This is the correct approach because the trust policy limits the takeover to exactly the IAM role ARN in Company B, ensuring no other principal in that account can assume RoleInA. The mandatory sts:ExternalId condition ties the request to your specific business engagement and prevents a confused deputy attack; even if Company B is compromised or acting on behalf of another organization, the request must present the unique ExternalId that you generated and shared only with the intended partner. Low-privilege principal and an external condition together meet AWS's recommended pattern for cross-account third-party access.

Secrets Manager is built for storing and rotating credentials such as database passwords. It supports secret versioning, fine-grained access control, and managed rotation workflows, making it the best fit for a 30-day automated rotation requirement. The application can retrieve the current secret at runtime without embedding the password in code or environment variables.

A mixed instances policy allows you to combine On-Demand and Spot Instances, providing cost savings from Spot while maintaining a baseline of On-Demand for reliability. This approach can reduce costs without sacrificing performance, as the Auto Scaling group can maintain a minimum On-Demand capacity and use Spot for additional scalable capacity. It is a best practice for cost optimization in Auto Scaling groups.

Instance store volumes provide locally attached NVMe or SSD storage with higher throughput and lower latency than EBS for temporary data. EMR can be configured to use instance store for shuffle and scratch space, which speeds up spill-heavy operations. This improves performance without adding core nodes or changing the data format, directly addressing the shuffle bottleneck.

This is correct because it matches storage cost to actual access frequency: logs are typically accessed heavily in the first 30 days, so S3 Standard is appropriate, after which Standard-IA reduces storage cost while still allowing rapid access. At 180 days, the logs are unlikely to be needed for active operations, so Glacier Deep Archive provides the lowest-cost storage while still satisfying the 18-month retention requirement. The lifecycle transitions honor S3's minimum storage duration constraints (30 days and 180 days), so no early-deletion fees are incurred.

RequestCountPerTarget directly reflects how many requests each instance is serving, which matches the symptom in the exhibit. It scales the fleet based on actual per-target demand instead of CPU, so the group can add capacity before queueing and latency grow.

CloudFront caches responses at edge locations close to European users and forwards cache misses to the API Gateway endpoint in us-east-1. For cacheable API responses, this cuts the transatlantic round trip and reduces load on the backend, while the Lambda function and database stay in us-east-1, satisfying data residency and cost constraints.

CloudWatch Logs retention policies are applied per log group and define the exact number of days that log events are kept before they are automatically deleted. By default, logs are set to 'Never Expire,' so configuring a retention period, such as 30 or 90 days, directly reduces log storage costs and helps meet compliance guidelines. This is the correct approach because it specifically automates the deletion of older logs without any external processes.

DynamoDB Global Tables is the correct solution because it provides fully managed, multi-region, multi-active replication with submeter-second propagation between the three chosen replica tables. With Global Tables, writes to any replica are accepted and automatically propagated to all others, and built-in conflict resolution using last-writer-wins resolves concurrent updates without any custom code or operational overhead. This gives you active-active reads and writes in all three regions, which exactly matches the requirement for low-latency multi-region access.

The reader endpoint is a load-balancing DNS name that distributes each new connection across all available Aurora Replicas in the cluster. By explicitly routing read-only queries to this endpoint, the application offloads its SELECT-heavy workload from the primary to the idle replica, directly reducing CPU strain on the writer and increasing the cluster's aggregate read capacity. This is the intended scaling pattern for Aurora MySQL and resolves the described bottleneck.

Using an Amazon SQS standard queue meets the at-least-once requirement: SQS stores messages durably across multiple Availability Zones and redelivers any message that is not deleted before the visibility timeout expires, so every event is processed at least once. Because standard queues can occasionally deliver duplicate copies, your consumer design must be idempotent—e.g., by tracking a unique event ID or a deterministic processing key—so that repeated handling of the same event does not corrupt patient data. This combination gives you high throughput, operational simplicity, and no single point of failure, which is why it is the correct choice.

RDS read replicas are separate DB instances that receive asynchronous replication from the primary and can serve read traffic. Directing the tracking-history queries to the replica endpoint removes that load from the primary, freeing CPU for writes. The asynchronous replication lag is typically seconds, which the workload tolerates, and no engine change is required.

A gateway VPC endpoint for S3 keeps S3 traffic within the AWS network. After you add the S3 gateway endpoint and update the private subnet route tables for the S3 prefix list to target the endpoint, S3 API calls from the private subnets no longer traverse the NAT Gateway. This directly reduces both NAT Gateway per-hour charges and NAT data-processing charges associated with S3 traffic. If the application truly only needs S3, you can remove the NAT route for those S3 destinations and rely on the endpoint for S3 connectivity.

NLB is a Layer 4 load balancer that supports TCP and UDP. When the traffic is routed to targets (for example, instance or IP targets), the backend connection maintains the original source IP/port at the networking layer, which supports IP-based auditing without requiring HTTP headers.

AWS WAF attached to the Application Load Balancer inspects incoming HTTP requests and blocks SQL injection and cross-site scripting using managed rule groups, satisfying the minimum-operational-overhead constraint without custom scripts. Rules are evaluated at the load balancer before traffic reaches the application, providing managed protection with no code changes.

A bucket policy with a Deny on s3:PutObject using the s3:x-amz-server-side-encryption-aws-kms-key-id condition blocks unapproved encryption at the API layer. CloudTrail data events and an EventBridge rule on the PutBucketPolicy management event provide near-real-time detection and an automated response, requiring no servers to maintain.

Deletion protection is a DynamoDB table attribute that blocks DeleteTable operations until explicitly disabled, while tightly scoped IAM policies that deny dynamodb:DeleteTable reduce the risk of a single misissued CLI command or console action taking down a payments table. Without this guard, an accidental deletion is immediate and permanent, taking all data, indexes, and backup history with it. It is therefore a required complement to backup features.

A cluster placement group launches a group of instances into a single Availability Zone using the same underlying infrastructure segments, which lets them communicate over a low-latency, high-bandwidth, non-blocking network path. For a trading analytics workload that needs consistent inter-instance latency and minimal jitter, this placement strategy provides the closest possible physical proximity and dedicated interconnect performance. Because all instances share the same logical and physical network segment, packet round-trip times become both shorter and more predictable.

This SCP is a preventive guardrail at the AWS Organizations level. By applying a Deny statement for ec2:CreateVolume with a StringEquals condition on ec2:Encrypted set to false, the policy blocks any attempt to provision an unencrypted EBS volume in every account in the organization. Because SCPs act as a permission boundary above IAM, even an administrator with full IAM permissions cannot create a noncompliant volume.

Route 53 failover routing is designed specifically for active-passive failover: you create two alias records pointing to the two ALBs, one marked PRIMARY and the other SECONDARY, each with an associated health check. Under normal conditions, Route 53 returns the PRIMARY record, but if that record's health check fails, Route 53 automatically stops returning it and returns the SECONDARY record instead. This gives the company an automated, DNS-level failover that does not depend on client latency, manual weight changes, or client-side load balancing.

A customer managed KMS key's access is governed by its key policy, which must explicitly grant the partner account or role permission to use the key. Without this cross-account grant, the partner's IAM policy alone cannot authorise any cryptographic operation on the CMK.

Updating the CMK key policy in Account A is the correct approach because KMS key policies are the authoritative resource-based policies that govern access to the key, especially for cross-account scenarios. By explicitly adding the Account B role's ARN as a `Principal` and granting `kms:Decrypt` (and `kms:DescribeKey` for context) within the key policy, Account A explicitly authorizes the external principal to use its CMK, satisfying the two-layer authorization model.

AWS WAF integrates directly with Application Load Balancers and supports managed rule groups that detect SQL injection and cross-site scripting patterns, along with rate-based rules that count requests per originating IP over a rolling window. Attaching a web ACL to the ALB inspects incoming HTTP requests before they reach the instances, satisfying both the exploit filtering and rate-limiting requirements in a single service.

MediaLive performs the real-time encoding/transcoding of the live input, MediaPackage origins the just-in-time HLS/DASH packaging, and CloudFront caches at edge locations for massive concurrent scale. This is fully managed with no streaming servers to operate, and the combination delivers low latency to a geographically dispersed audience.

Aurora Replicas are independent database instances in the same Aurora cluster that share the underlying storage volume, allowing them to serve read traffic without replicating data changes at the instance level. You can add up to 15 replicas, which adds CPU, memory, and connection capacity for concurrent SELECT queries, effectively scaling out the database layer horizontally. Because the storage is shared, replicas also offer near-zero replication lag, making them suitable for read-heavy workloads that need fresh data.

SCPs apply to all principals in all member accounts and cannot be overridden by account-level IAM. Attached to the Organization root, this SCP covers every member account. The Deny with StringNotEquals condition on aws:RequestedRegion blocks all other regions.

Because SQS Standard is at-least-once, the consumer must assume duplicates are possible. Persisting a record keyed by paymentInstructionId (or using a database unique constraint) lets the consumer detect that a given instruction was already processed successfully and safely skip the charge or merge results deterministically.

A NAT gateway in a public subnet allows instances in private subnets to initiate outbound connections for patching while remaining unreachable from the internet. It is a managed, highly available service, so operational overhead is minimal. This satisfies the outbound-only requirement without exposing the instances, matching the security policy and simplicity goal.