SAA-C03 Flashcards — Free SAA-C03 Study Cards

secretsmanager:GetSecretValue on only the secret’s full ARN

Grant the Lambda execution role the least-privilege permission secretsmanager:GetSecretValue scoped to the full ARN of the single secret. This allows the function to retrieve the secret value it needs at startup, while preventing access to any other secrets. Other permissions (such as ListSecrets or UpdateSecret) are either unnecessary for reading or expand the blast radius beyond the stated requirement. Why others are wrong: ListSecrets enables enumeration and is unnecessary when the secret ARN/name is known. UpdateSecret is write access and is outside the requirement to read only. DescribeSecret provides metadata but not the secret value, and using a wildcard resource scope is unnecessarily broad.

Deny PutObject unless s3:x-amz-server-side-encryption equals "aws:kms" and s3:x-amz-server-side-encryption-aws-kms-key-id equals the required CMK ARN

To enforce that uploads use SSE-KMS with a specific customer-managed KMS key, use a bucket policy that denies PutObject unless the client’s request headers indicate (1) server-side encryption type is aws:kms and (2) the specified KMS key ID/ARN matches the required CMK. This checks SSE configuration during the upload request, preventing both unencrypted uploads and uploads encrypted with a different KMS key. Why others are wrong: aws:SecureTransport ensures TLS in transit, not encryption at rest. Content-Type does not affect SSE settings. Checking kms:Decrypt permission is about authorization for decryption operations later and does not enforce the SSE-KMS headers used during PutObject.

Modify the KMS key policy in Account A to allow kms:Decrypt for the Account B role arn:aws:iam::account-b:role/app-read, using the appropriate cross-account conditions (for example, allowing the use via S3 and the expected encryption context for the bucket).

With SSE-KMS, an S3 GetObject request causes S3 to call KMS Decrypt to read the object. Even when the IAM role in Account B has an identity policy that allows kms:Decrypt, KMS still evaluates the KMS key policy in Account A. In cross-account scenarios, AccessDenied for kms:Decrypt typically means the KMS key policy does not allow the external principal (the Account B role) to use the key for decrypt, possibly under the expected S3 encryption context/usage conditions. Updating the KMS key policy to explicitly permit kms:Decrypt for arn:aws:iam::account-b:role/app-read resolves the authorization path that is currently blocked. Why others are wrong: A is not the best fix because it removes a required permission from the caller’s identity policy. Even if the key policy is updated, removing kms:Decrypt from Account B can still block KMS. B is incorrect because S3 GetObject does not grant KMS Decrypt; KMS checks both identity and key policy. D bypasses the failure by changing encryption, but it does not directly address the secure, least-change root cause (KMS key policy authorization) and may not meet compliance requirements.

Allow s3:ListBucket on arn:aws:s3:::customer-data only when s3:prefix equals "exports/acme/" (for example, using a StringEquals condition on s3:prefix). Also allow s3:GetObject only on arn:aws:s3:::customer-data/exports/acme/*.

For S3 tenant isolation with least privilege, you need two distinct controls: 1) Listing: Allow s3:ListBucket on the bucket ARN, but use a Condition that restricts the request to only the required listing prefix (the app’s Prefix value). 2) Reading: Allow s3:GetObject only for the specific object ARN pattern under exports/acme/. This ensures both enumeration (ListBucket) and data access (GetObject) cannot escape the approved prefix. Why others are wrong: A restricts reads but not enumeration; the role can still list other tenants’ object keys. C mis-scopes ListBucket (bucket ARN required) and makes GetObject too broad. D may prevent reads outside the prefix but still leaks other tenants’ keys via ListBucket.

Signed URLs or signed cookies with an expiration time of 1 hour

Signed URLs or signed cookies are the correct CloudFront pattern for private content that requires authenticated-only access with a short expiration. By generating signatures with a 1-hour expiry, you ensure CloudFront validates the signature at the edge and only serves the requested objects to users who have received valid signed credentials. WAF may supplement security, but it does not replace CloudFront’s native signed authorization model for time-limited access to specific resources. Why others are wrong: Option B focuses on WAF/JWT blocking, which is not the most appropriate native feature for time-limited, resource-scoped access via CloudFront. Option C only affects direct S3 access; it does not enforce authenticated user access or a 1-hour expiry for requests through CloudFront. Option D enforces location-based restrictions rather than authentication-based, expiring access.

Configure a dead-letter queue (DLQ) with a redrive policy that moves messages after maxReceiveCount, and implement idempotent processing in the consumer using an idempotency key.

Because SQS Standard provides at-least-once delivery, timeouts can cause redelivery. To prevent poison messages from blocking progress indefinitely, configure a DLQ with a redrive policy (maxReceiveCount) so failing messages are quarantined. To avoid duplicate side effects from legitimate retries, make the consumer idempotent using an idempotency key so repeated deliveries do not re-apply side effects. Why others are wrong: Deleting or simply increasing visibility does not quarantine poison messages for investigation and does not reliably prevent infinite retry behavior. Relying on SNS for exactly-once delivery is incorrect. Switching to FIFO with deduplication alone does not address poison-message handling and does not replace idempotency for safe retry behavior.

Change the application to use the Aurora cluster writer endpoint and retry transient connections.

The best way to reduce Aurora failover impact is to connect through the Aurora cluster writer endpoint rather than a specific instance endpoint, and to retry transient connection failures. A fixed instance endpoint can become stale after failover, especially when the application uses a connection pool that holds on to old connections. The writer endpoint always points to the current writer, so the application recovers much more quickly. Why others are wrong: Adding a read replica does not help writer failover or stale endpoints. Increasing EC2 size does not change how the database endpoint resolves. Switching to single-AZ would make availability worse, not better.

Implement idempotent processing (for example, store processed payment IDs in DynamoDB) and configure an SQS dead-letter queue (DLQ) using a redrive policy with an appropriate maxReceiveCount.

Because SQS Standard is at-least-once, duplicate deliveries are expected when processing exceeds the visibility timeout or when consumers fail mid-processing. Idempotent processing prevents duplicates from causing duplicate side effects by ensuring each payment ID is applied only once. Separately, configuring an SQS DLQ via a redrive policy with maxReceiveCount prevents poison messages from continuously reappearing and consuming worker time by quarantining messages that repeatedly fail. Why others are wrong: Visibility timeout tuning alone cannot guarantee correctness; duplicates can still occur and poison messages can still loop. Deleting immediately upon receipt breaks reliability because failures after delete cannot be recovered. Moving to a synchronous HTTP retry model does not inherently provide safe handling of duplicates nor DLQ-based quarantine for poison messages in the same way as an SQS DLQ combined with idempotency.

Update the ASG to use subnet IDs that span at least two Availability Zones so it can launch replacement instances after an AZ outage.

To recover from an Availability Zone outage, Auto Scaling must be able to create replacement capacity in the remaining Availability Zones. Because the ASG is currently attached only to subnets in one AZ, it cannot launch new instances after that AZ fails. Updating the ASG to span at least two Availability Zones allows Auto Scaling to restore desired capacity automatically. Why others are wrong: ALB health check timing and connection draining affect how quickly requests are marked unhealthy or how in-flight requests complete, but they do not change the ASG’s ability to launch instances in other AZs. Increasing desired capacity only scales within the AZs already configured for the ASG, so it cannot restore capacity after the sole AZ fails.

Create Aurora read replicas and direct reporting read-only connections to the cluster reader endpoint.

To reduce write latency caused by reporting reads, the architect should offload reporting workloads to read replicas. Aurora read replicas handle read-only queries, preserving writer resources for OLTP writes. Directing reporting to the cluster reader endpoint (or the replica endpoints) ensures that read traffic goes to replicas instead of the writer. Options that resize the writer or keep reporting on the writer do not achieve workload isolation, and cross-region replication may be overkill for the specific performance problem described. Why others are wrong: Resizing the writer treats symptoms and can keep mixed workload contention on the same endpoint, which may still impact write latency. Disabling replicas and relying only on application caching doesn’t guarantee performance during reporting runs when many queries are not cache hits. Cross-region replication addresses resilience/geography but is not the most targeted solution for business-hour read/write contention within a single Region.

Add Amazon DAX as a caching layer in front of DynamoDB and route repeated read operations through DAX.

Because the partitioning model is already healthy, the latency issue is driven by repeated reads for the same items. Amazon DAX is specifically designed to cache DynamoDB read results in memory, which dramatically reduces latency for hot read patterns without requiring a change to partition keys or the data model. Routing those repeated “latest status” reads through DAX improves read latency while preserving the existing partitioning strategy. Why others are wrong: Randomizing the partition key attacks the wrong symptom and undermines the ability to access items by deviceId. Increasing write capacity does not address read-path latency caused by repeated reads. Adding a GSI may improve certain query patterns, but it does not inherently reduce latency for repeated point reads the way an in-memory caching layer does.

Publish a version of the function and configure provisioned concurrency on an alias, using autoscaling for the alias.

Use provisioned concurrency on a published version attached to an alias. Provisioned concurrency keeps a specified number of execution environments initialized and ready to handle ALB-invoked requests, which directly reduces cold-start latency. Using the alias model allows the team to manage and autoscale warm capacity for those predictable hourly spikes rather than relying on default on-demand initialization behavior. Why others are wrong: Increasing memory or adjusting reserved concurrency can change performance and limits, but they do not ensure pre-initialized execution environments are available during bursts. Event source mapping configuration is not applicable for ALB-triggered synchronous invocation in a way that would reliably prevent cold starts.

Enable Lambda provisioned concurrency on a published function alias and set the minimum provisioned instances to the baseline expected during spikes.

Provisioned concurrency is designed specifically to reduce or avoid cold start latency by keeping a specified number of Lambda execution environments initialized. The best approach is to publish a version and attach provisioned concurrency to an alias, then set the minimum provisioned instances to cover the expected traffic baseline during predictable spikes. Increasing memory helps compute speed but doesn’t pre-initialize environments. ALB health checks might reduce some cold starts but cannot guarantee consistent low latency for bursty traffic. Monitoring with CloudTrail improves observability, not performance. Why others are wrong: Increasing memory can reduce function duration, but cold start delays still occur when there are no initialized environments. ALB health checks may create artificial warm-up behavior but are not equivalent to Lambda’s deterministic initialization and can fail under sudden bursts or changing traffic patterns. CloudTrail data events provide metrics for troubleshooting, but they do not alter Lambda’s initialization behavior, so they won’t reliably reduce p95 latency during spikes.

Create an S3 lifecycle rule to transition older objects to a colder storage class after 30 days, then expire after 1 year

The best approach is an S3 lifecycle policy because it matches the retention pattern: logs must be kept for 1 year, but they become infrequently accessed after 30 days. A lifecycle rule can transition objects to a cheaper storage class once they age past 30 days, and an expiration rule can delete them only after 1 year. The other choices either keep data in the most expensive storage class, use an inappropriate storage primitive (EBS snapshots) for log retention, or use replication, which does not address storage-class pricing and can increase cost. Why others are wrong: Keeping logs in S3 Standard ignores the main cost lever: storage class selection. EBS snapshots are not designed for general application log retention. Replication does not reduce storage cost for the original objects and can increase costs by storing/copying data in another region.

Right-size the instances to a smaller size that matches the observed utilization

Right sizing is the most direct cost-optimization step because persistent low utilization indicates the instances are larger than required. When average CPU is around 10% for weeks and the application remains stable, downsizing reduces the hourly compute cost while keeping performance within acceptable limits for normal fluctuations. The other options increase capacity cost (higher desired capacity), introduce operational risk unrelated to the metric evidence (Spot interruptions), or optimize a smaller secondary cost (monitoring) without fixing the overprovisioned compute spend. Why others are wrong: Increasing Auto Scaling desired capacity increases spend despite low CPU utilization. Spot is a separate decision that trades lower price for interruption risk and does not inherently solve overprovisioning. Disabling detailed monitoring reduces some monitoring costs, but it does not meaningfully address the dominant EC2 cost created by oversized instances.

Set appropriate Cache-Control headers (or origin cache settings) so CloudFront caches responses longer

CloudFront origin requests are reduced primarily by increasing the cache hit ratio. The most direct way to do that for static content is to configure correct caching behavior—such as appropriate Cache-Control headers/TTL—so edge locations can reuse the cached objects for longer periods. When objects remain in cache, repeated viewer requests are served from edge caches instead of triggering new origin fetches, lowering origin bandwidth and request-related costs. Why others are wrong: Disabling caching forces an origin fetch for every request, increasing origin traffic. Forwarding additional headers and query strings expands cache-key variability and reduces cache hits. Moving the origin bucket region does not, by itself, change caching policy/TTL, so it is not the most direct lever to stop unnecessary origin fetches.