AWS Certified Developer – Associate 1-10

sam sync –watch enables AWS SAM Accelerate, detecting local changes and quickly applying only the differing resources.
The –watch flag automatically monitors source code changes, and only changed resources such as the Lambda function are synced to the cloud, avoiding a full rebuild and complete redeployment of all artifacts.
sam deploy –force-upload (A) forcibly uploads all artifacts, which is counterproductive.
sam deploy –no-execute-changeset (B) only creates a change set without executing it.
sam package (C) only packages the artifacts and performs neither deployment nor incremental sync.
sam sync is the best fit for speeding up iterative updates during development.
AWS SAM CLI sam sync command reference

S3 event notifications invoke the Lambda function immediately after object creation, achieving the lowest latency.
Because the application runs only about 10 times a day for about a minute each, Lambda—which is billed only for execution time—is far cheaper than EC2, which incurs charges even while idle.
A CloudWatch alarm (A) is intended for monitoring metric thresholds and is not suited to instantly triggering on object uploads.
A scheduled event (C) only fires at fixed intervals, so a delay occurs between data arrival and execution.
EC2 polling (D) is disadvantageous on both fronts: the cost of always-on operation and the delay caused by the polling interval.
Using AWS Lambda with Amazon S3

In a configuration where a Lambda function calls a downstream database (DocumentDB), distributed tracing is the best way to pinpoint where time is being spent with minimal effort.
AWS X-Ray provides end-to-end request tracing and a timing breakdown, making it possible to see whether the latency originates in Lambda initialization, a downstream call, or a database query.
Adding custom subsegments around DocumentDB operations lets you measure the exact time taken for each query execution or connection acquisition, so you can quickly identify slow queries.
B is centered on errors and generic metrics and cannot precisely isolate the cause of the added 20-plus seconds.
C is a performance-improvement measure applied before confirming the root cause, which does not meet the requirement of identifying the bottleneck first.
D requires detailed logging implementation and queries, increasing overhead in both development effort and log cost.
Using AWS X-Ray with AWS Lambda

This is the classic cross-account access pattern using AWS STS AssumeRole.
Account A permits Account B through the trust policy on the role side, but that alone is not enough; the caller—the EC2 role in Account B—also needs permission to perform sts:AssumeRole (A).
In addition, to actually obtain the temporary credentials, the application must call the AssumeRole API within its code (D).
B is incorrect because granting permissions directly on the Account A-owned table from the Account B side has no effect.
C is wrong because merely obtaining the EC2 role’s credentials does not grant Account A’s permissions; assuming the cross-account role is mandatory.
E’s GetSessionToken is for MFA sessions of IAM users and is not used for assuming a cross-account role.
AWS STS AssumeRole API reference

A DynamoDB table with a composite key using the location ID as the partition key and the timestamp as the sort key can write and retrieve time-series usage data with low latency and high throughput, and it scales seamlessly as demand grows.
DynamoDB is serverless with no downtime during writes, making it well suited to combining high-frequency writes with per-location range queries.
RDS (A) has an upper limit on write scaling and increases operational burden and cost.
ElastiCache for Redis (C) is in-memory, so it is not suited to durable storage and is costly for long-term historical retention.
S3 + Athena (D) is inexpensive but scans on every query, making it unsuitable for low-latency, on-demand access to current usage.
Working with queries in DynamoDB

When using HTTP/HTTPS listeners, an Application Load Balancer operating at Layer 7 adds the original client IP to the X-Forwarded-For header and forwards it, so the application can obtain the client IP from this header.
The ALB terminates HTTP/HTTPS traffic and inserts headers such as X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port by default.
The NLB’s Proxy Protocol (B) is a mechanism for Layer 4 TCP connections and does not match the requirement of obtaining the client IP via HTTP/HTTPS headers.
Instance ID registration in C concerns the target registration method and is unrelated to obtaining the client IP.
An NLB does not add the X-Forwarded-For header (D), so it is incorrect.
X-Forwarded-For header on Application Load Balancers

API Gateway’s edge-optimized endpoint automatically uses Amazon CloudFront’s global edge network, minimizing latency for users distributed around the world.
By associating the TLS certificate imported into ACM with the custom domain name, you can provide secure connections on any domain.
Disabling the default endpoint enforces access only through the custom domain.
Approaches like A and D, which separately build CloudFront and process requests with Lambda@Edge or CloudFront Functions, merely duplicate capabilities that an edge-optimized API Gateway provides out of the box and are unnecessary.
The private endpoint in B is intended for use from within a VPC and does not meet the requirement of global, low-latency access.
Custom domain names for Amazon API Gateway

Configuring an S3 event notification to invoke a Lambda function lets you insert a record into DynamoDB the moment a new file is added to the bucket, with no server management required.
Because an S3 object-creation event serves as the trigger, processing runs almost simultaneously with the addition.
EventBridge (A) can also achieve this, but the option’s description is vague about the specific processing mechanism, and S3 event → Lambda is the most direct and standard method.
Polling with Lambda (C) incurs continuous polling cost and delay.
A cron job (D) runs on a schedule and does not meet the immediacy requirement of “as soon as it is added.”
Tutorial: Using an Amazon S3 trigger to invoke a Lambda function

The requirements are two-fold: in-transit encryption and at-rest encryption with a KMS key that can be rotated on demand.
At-rest encryption can be satisfied by encrypting objects with an AWS KMS customer managed key (C). Customer managed keys can be rotated on demand.
In-transit encryption can be enforced by using the aws:SecureTransport condition in a bucket policy to allow only HTTPS connections (D). This is the standard method recommended by AWS.
The permissions boundary in A is for controlling IAM policies and cannot be used to enforce transport encryption in a bucket policy.
B is incorrect because an S3 bucket policy cannot enforce client-side encryption.
Block Public Access in E is a feature for preventing public exposure and is unrelated to enforcing encryption.
Using server-side encryption with AWS KMS keys

AWS Secrets Manager encrypts credentials at rest with AWS KMS and achieves schedule-based automatic rotation using rotation templates (SecretsManagerRotationTemplate) that support RDS, DocumentDB, and Aurora.
This meets the requirements of encryption and rotation in the most secure and managed way.
IAM database authentication in A is not necessarily available for all engines and has a different purpose than the required credential rotation.
Parameter Store (SecureString) in B can encrypt at rest but does not natively provide automatic secret rotation.
S3 storage in C rotates the encryption key rather than the credentials themselves, and access management becomes cumbersome.
Rotating AWS Secrets Manager secrets