AWS Developer Certification Practice Exams

The correct way to attach resource context to custom CloudWatch metrics is to include dimensions. With –dimensions, you add name–value pairs like InstanceId=i-abc123 and AutoScalingGroupName=my-asg to each datapoint so they can be grouped and filtered in dashboards, queries, and alarms. CloudWatch supports up to 10 dimensions per metric, which is ideal for tagging metrics with resource identifiers.

–namespace only defines the logical container for metrics and does not categorize them by resource attributes, so it will not enable per-instance or per-ASG filtering.

–statistic-values is used to publish aggregated statistic sets for a metric and does not provide any labeling or grouping context.

–unit defines the unit of measure for datapoints and similarly does not attach resource identifiers for grouping.

Use dimensions to add resource context (for example, InstanceId, AutoScalingGroupName); namespace groups metrics at a high level, and statistic-values and unit do not provide filtering context.

Persist sessions in Amazon DynamoDB via a session library is correct because DynamoDB provides a durable, multi-AZ replicated, highly available key-value store that all EC2 instances can access. Sessions remain available even if any instance is terminated or replaced, and DynamoDB’s performance and scalability characteristics suit high-concurrency web workloads.

Store session files on Amazon EFS is not ideal because NFS-based session files introduce latency, file-locking, and scaling bottlenecks at high request rates. Although EFS is regional and multi-AZ, it is not the recommended pattern for scalable session state.

Enable stickiness on the ALB target group only keeps a client bound to one instance; it does not replicate or persist session data, so a terminated or failing instance still loses sessions.

Use Amazon ElastiCache for Redis as the session store can work with proper configuration, but it is memory-resident and may risk data loss on failover without persistence settings. Even with AOF/RDB, it is generally less durable than DynamoDB for strict session durability requirements.

For stateful web apps behind load balancers and Auto Scaling, prefer a shared, durable, highly available store for session data. DynamoDB is a common best-practice answer. ALB stickiness addresses routing, not persistence. EFS and Redis can work but have trade-offs in durability, scalability, or operational complexity that make them less optimal for guaranteed session survival.

Amazon S3 Glacier Deep Archive is the most cost-effective S3 storage class for data that is rarely accessed and must be retained for many years, while still meeting high durability and security requirements.

Amazon S3 Standard-Infrequent Access costs more than archival classes and is intended for data that needs millisecond access when retrieved, not the cheapest cold archive.

Amazon S3 One Zone-IA stores objects in a single Availability Zone, which lowers resilience compared to multi-AZ classes and is a poor fit for long-term compliance or critical archives.

Amazon S3 Glacier Flexible Retrieval offers faster retrieval options but at a higher storage price than Deep Archive, making it less optimal for the lowest-cost, rarely accessed data.

When the requirement stresses lowest cost and rarely accessed archival data with strong durability, choose S3 Glacier Deep Archive; if faster restores are needed, consider Glacier Flexible Retrieval instead.

The correct choice is Enable CORS with only allowed origins. CORS is enforced by browsers, and when configured on API Gateway to return Access-Control-Allow-Origin only for approved domains, unapproved web apps will be blocked by the browser from making successful cross-origin calls.

Require API keys with usage plans is incorrect because API keys govern usage tracking and throttling, not origin-based access; any client with a key can call the API regardless of origin.

AWS WAF is incorrect because it does not implement CORS. While you can filter by headers or IPs, it cannot reliably enforce browser-origin restrictions or handle CORS preflight behavior.

API Gateway account-level throttling is incorrect because it only limits request rates and bursts and cannot block based on the caller’s origin.

When a requirement mentions restricting calls from browser-based clients by origin, think CORS. If the goal is to block non-browser clients or enforce real security, consider authorization (IAM, JWT authorizers, Cognito) rather than CORS. Use WAF for IP/pattern filtering and throttling/usage plans for rate control, not origin control.

The requirement is to forward only the state of the item prior to the update into S3. OLD_IMAGE emits the entire item as it existed before the modification, which lets the Lambda function write just the previous values to S3 while the updated values remain in DynamoDB.

NEW_AND_OLD_IMAGES includes both versions, which would deliver the new values as well and is more data than needed.

KEYS_ONLY omits attribute values entirely, making it impossible to reconstruct the previous item.

NEW_IMAGE provides only the post-update state, which does not meet the requirement to capture the old values.

When selecting a DynamoDB Streams view type, align it with exactly what your consumer needs. If you see language like only the previous values, think OLD_IMAGE; for minimizing payload and cost, avoid sending extra images you will not use.

Amazon EventBridge rule for EC2 state change to running with Lambda target is correct because EC2 emits native state-change events that EventBridge can match (state = running) and invoke Lambda directly with low latency and minimal configuration. This provides a simple, scalable, and near real-time trigger path for per-instance launches.

The option CloudTrail RunInstances metric filter with CloudWatch alarm to Lambda is inferior because it introduces delivery delays and extra plumbing (logs, metric filters, alarms) compared to native state-change events.

The option EC2 Auto Scaling lifecycle hook is scope-limited to Auto Scaling groups only and will not capture launches outside ASGs, so it is not a general solution.

The option AWS Config rule evaluating EC2 instance state is intended for configuration compliance evaluations and is not optimized for immediate event-driven invocation on each launch.

When you see “trigger Lambda on EC2 instance start” or “state change to running,” think EventBridge service events with a rule filtering on the EC2 state and a Lambda target. Avoid designs that rely on CloudTrail + alarms for this use case unless the question explicitly requires API-call auditing-driven triggers.

The most resilient pattern is to externalize session data from the web tier into a managed, distributed store so that scaling out or replacing instances does not disrupt users. This makes the application stateless at the compute layer and maintains availability during failures.

Amazon ElastiCache for Redis fits these requirements by providing an in-memory, highly available store with replica support and clustering for horizontal scale, delivering the low latency and fault tolerance needed for session management.

Amazon S3 is durable but is not designed for frequent, low-latency session mutations and lacks in-memory operations required for efficient session handling.

Enable sticky sessions on the Application Load Balancer binds users to a specific instance, which undermines fault tolerance and elasticity because an instance failure or scale-in event can drop user sessions.

Amazon CloudFront accelerates content delivery but is not a database or cache for session state and cannot maintain per-user session data.

When the requirement emphasizes no lost sessions and seamless scaling, think of externalizing state to a highly available, managed in-memory data store like Redis rather than relying on sticky sessions or object storage.

ApplicationStop → BeforeInstall → ApplicationStart → ValidateService is correct because, in an EC2/On-Premises in-place CodeDeploy deployment, the application is stopped, pre-install tasks run, the application is started, and then the service is validated. This matches the documented hook sequence for in-place deployments.

The option ApplicationStop → BeforeInstall → ValidateService → ApplicationStart is incorrect because validation must occur after the application is started, not before.

The option ApplicationStop → AfterInstall → ApplicationStart → ValidateService is incorrect because it omits the BeforeInstall hook and misorders the early steps.

The option BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic is incorrect because these hooks apply to blue/green traffic-shifting scenarios (such as with load balancers, ECS, or Lambda), not EC2 in-place deployments.

Distinguish in-place hooks from blue/green traffic hooks. For in-place EC2/On-Prem, remember the flow: stop, pre-install, start, then validate. For blue/green, think in terms of Before/AfterAllowTraffic and load balancer cutover.

The Lambda deployment package for ZIP-based functions must contain your function code and any libraries that the runtime does not provide. Packaging dependencies with the code guarantees they are available without network installation at cold start.

Bundle the handler code and every required third-party library into a single ZIP archive is correct because it creates a self-contained artifact so the Lambda execution environment has everything needed at invocation time.

Ship only the source code in a ZIP file along with a script that installs dependencies when the function starts is wrong because installing at runtime increases latency and can fail due to lack of build toolchains or outbound access.

Upload a ZIP that includes an appspec.yml listing libraries, store it in Amazon S3, and roll out with AWS CloudFormation is incorrect since AppSpec is used by CodeDeploy and does not manage Lambda dependency packaging.

Publish the native libraries as a Lambda layer and deploy a ZIP that contains only the function code is a plausible alternative, but the question specifically asks how to build the deployment package; layers are not the deployment package and only apply if you choose to externalize dependencies.

For ZIP-based Lambda functions, place all non-runtime dependencies in the package or use a Lambda layer; avoid installing at invocation due to cold-start impact and reliability risks, and read the question carefully for clues like deployment package versus layer.

Cognito Identity Pools with developer authenticated identities is correct because Identity Pools create a persistent Cognito identity ID that remains the same across sessions and devices when you present the same developer provider and user identifier. It also enables retrieving AWS credentials for accessing resources securely.

The option Amazon Cognito User Pools only is not sufficient because while User Pools issues a stable sub claim for the user, it does not provide the Cognito identity ID or AWS credentials used for federated access via STS.

The option Create an IAM user per app customer is inappropriate for mobile app end users. It adds significant operational burden, scales poorly, and violates best practices.

The option Amazon Pinpoint endpoint IDs is incorrect because endpoint IDs represent individual devices or channels and are not a person-level identifier across multiple devices.

Watch for cues like cross-device identity, persistent user ID, and obtaining AWS credentials. Those terms point to Identity Pools. When the question focuses on sign-up, sign-in, and tokens, think User Pools. Avoid using IAM users for consumer identities.

Pipe the output of aws ecr get-login-password to docker login for the registry, then run docker pull REPOSITORY_URI:TAG is correct because Docker must first be authenticated against the private Amazon ECR registry using the CLI v2 password, after which the image can be pulled successfully.

Run docker pull REPOSITORY_URI:TAG is incorrect because a private ECR repository requires prior authentication and a direct pull will fail with an authorization error.

Execute aws ecr get-login-password and afterward run docker pull REPOSITORY_URI:TAG is incorrect since merely running the command prints a password; you must pass that output to docker login to establish a session.

Use aws ecr-public get-login-password, then run docker pull REPOSITORY_URI:TAG is incorrect because this authenticates to ECR Public, not the private ECR registry described in the scenario.

For private ECR pulls, first authenticate Docker: aws ecr get-login-password | docker login –username AWS –password-stdin .dkr.ecr..amazonaws.com, then run docker pull registry/repository:tag.

CloudTrail is correct because it captures and stores AWS API events (management and data events), including the caller identity, timestamp, and source IP, providing a verifiable audit trail across AWS accounts and services. It supports organization trails, event history, and CloudTrail Lake for deeper analysis, which aligns directly with audit requirements.

The option AWS X-Ray is incorrect because it traces application requests within distributed systems and services for performance troubleshooting, not AWS API control-plane activity.

The option Amazon CloudWatch is incorrect because it handles metrics, alarms, and log ingestion but does not natively record a complete history of AWS API calls.

The option AWS Config is incorrect because it records resource configuration changes and compliance states, not the full set of API events across services and principals.

When you see keywords like audit trail, API activity, who/when/source IP, and across services, think CloudTrail. Map similar distractors quickly: resource configuration timeline → AWS Config, metrics/alarms → CloudWatch, request traces → X-Ray.

The safest way to avoid downtime while enabling the fastest rollback in a single Elastic Beanstalk environment is Immutable. It launches a new set of instances in a separate Auto Scaling group with the new version, verifies health, then switches traffic, and rollback is simply swapping back.

All at once updates every instance at the same time, which risks an outage and makes rollback a full redeploy.

Rolling replaces instances in batches and can temporarily reduce capacity, and rollback requires redeploying the previous version across multiple batches.

Rolling with additional batch preserves capacity but still performs phased replacements and does not provide the near-instant, safe cutover and rollback that Immutable offers.

If a question emphasizes zero downtime and fast rollback within a single Elastic Beanstalk environment, pick Immutable. If it explicitly mentions two environments and a CNAME swap, think blue green.

The correct choice is vendorId (partition), purchaseTimestamp (sort). Using vendorId as the partition key groups all a vendor’s orders together, and using purchaseTimestamp as the sort key allows efficient time-ordered queries within that vendor partition. The composite key vendorId plus purchaseTimestamp provides per-vendor uniqueness and supports range queries by time. If exact timestamp collisions are possible, a common pattern is to append a tiebreaker such as an increment or UUID to the sort key, while still anchoring the design on vendorId and purchaseTimestamp.

The option vendorId (partition), productName (sort) is incorrect because products repeat, so it neither guarantees uniqueness nor provides chronological ordering.

The option purchaseTimestamp (partition), vendorId (sort) is incorrect because partitioning by time causes write hot spots and prevents efficient per-vendor queries, since Query requires the partition key.

The option vendorId (partition), pricePerUnit (sort) is incorrect because prices are reused and provide no reliable ordering or uniqueness.

When a question asks for time-ordered queries within an entity group, pick the entity identifier as the partition key and the time attribute as the sort key. Use Query with KeyConditionExpression on the partition key and a time range on the sort key. Avoid using time as the partition key due to hot partitions and poor query ergonomics. If uniqueness within a timestamp could collide, compose the sort key as timestamp plus a tiebreaker while preserving time-based ordering.

The most efficient solution is to use cross account roles. Create IAM roles in the Production and QA accounts with the necessary permissions and a trust policy that allows the Sandbox account to assume them. The developer then uses STS AssumeRole to obtain temporary credentials and launch resources. That is why Define IAM roles with required permissions in the Production and QA accounts and allow the Sandbox user to assume those roles is correct.

Create a unique IAM user in each account and have the developer sign in to each account separately increases operational overhead and credential sprawl, and it does not leverage temporary credentials.

Create IAM groups in the Production and QA accounts and add the Sandbox IAM user to those groups is not possible because IAM users from another account cannot be members of local IAM groups.

Use AWS Organizations service control policies to grant the Sandbox user permissions in the other accounts is incorrect because SCPs only define permission boundaries and do not grant permissions to principals, so they cannot authorize cross account actions by a specific user.

When you see cross account access for an existing IAM user, look for assume role with a trust policy that names the external account, and avoid solutions that create duplicate users or rely on SCPs, which do not grant permissions.

The most likely cause is an EC2 Auto Scaling group with desired capacity. Auto Scaling groups continuously enforce their desired capacity. When an instance in the group is terminated, the group automatically launches a replacement instance using its launch template or configuration.

The EC2 Auto Recovery option is incorrect because it restarts the same instance after certain failures and does not create a new instance when a user terminates one. The Application Load Balancer option is incorrect because load balancers only route traffic and do not create instances. The EC2 Spot Fleet with maintain target capacity option is an advanced distractor; while Spot Fleets do replace terminated Spot instances to maintain capacity, the default and more general mechanism for automatic instance replacement after termination in typical AWS setups is an Auto Scaling group.

When you see automatic replacement of instances after termination, think Auto Scaling group and the phrase maintain desired capacity. Load balancers do not launch instances, and Auto Recovery restarts the same instance rather than creating a new one. Spot-specific constructs apply only when Spot capacity is explicitly in use.

The stream shows shard-level saturation and the consumers are CPU bound, so the correct remediation is to increase capacity on both sides. Upgrade the EC2 instance types and add more shards by resharding raises consumer processing power and increases Kinesis stream throughput and parallelism, which together reduce iterator age and backlog.

Increase only the shard count in the Kinesis stream addresses producer and read bandwidth limits but leaves the EC2 consumers CPU constrained, so lag would remain.

Scale out the EC2 Auto Scaling group until the instance count matches the shard count is not required because one host can run multiple KCL workers and it does not increase stream capacity.

Use larger EC2 instances only ignores the shard bottleneck, so the stream would still throttle or fall behind.

For Kinesis pipelines, scale along two dimensions: shard count for stream throughput and consumer compute for processing capacity. Watch metrics such as IncomingBytes, WriteProvisionedThroughputExceeded, and GetRecords.IteratorAgeMilliseconds to decide whether to scale shards, consumers, or both.

Amazon ElastiCache for Redis is the best fit for storing session state at massive concurrency because it is an in-memory data store that delivers sub-millisecond latency, very high throughput, built-in TTLs for expiring sessions, horizontal scaling via sharding, and Multi-AZ replication with automatic failover for resilience to an Availability Zone outage.

ALB session stickiness is not a session store; it only keeps clients routed to the same target. If the instance or AZ fails or the target group scales in, sessions are lost because there is no shared state.

Amazon S3 is durable object storage with much higher latency and request patterns unsuitable for high-frequency session reads and writes. It is not designed as a session store.

Amazon DynamoDB with TTL can scale and expire items, but it is not in-memory and typically has higher latency than Redis for per-request session access. Hot keys and very high request rates for session reads and writes make ElastiCache a better choice for this use case.

For ephemeral, high-throughput session state, choose an in-memory cache like ElastiCache for Redis with Multi-AZ. Avoid confusing load balancer stickiness with state storage. Use TTLs to auto-expire sessions. Be cautious with durable stores like S3 or DynamoDB when ultra-low latency and extremely high RPS are required.

The right choice for nonproduction when speed matters and brief outages are acceptable is All-at-once deployment. This policy updates all instances in the environment simultaneously, which is the fastest method and intentionally allows a short period of unavailability.

Immutable update provisions a parallel Auto Scaling group and shifts traffic only after health checks pass, which is safer but slower and unnecessary when downtime is acceptable.

Blue/green environment swap is a zero-downtime strategy that requires a second environment and a CNAME swap, adding complexity and time and is not a Beanstalk deployment policy option inside a single environment.

Rolling deployment updates instances in batches to maintain service availability, which reduces risk but is slower than all-at-once and not aligned with the goal of fastest possible pushes.

When you see keywords like fastest deployment and downtime is acceptable, think All-at-once. If the requirement emphasizes no downtime or safe rollback, prefer Rolling, Rolling with additional batches, Immutable, or a Blue/green approach.

The correct choice is /tmp in the Lambda environment. This is the only writable, ephemeral directory available to a Lambda function. Files written here are tied to the execution environment and do not persist across new cold environments.

The option Amazon S3 is incorrect because S3 is durable storage; objects persist until explicitly deleted.

The option Amazon EFS is incorrect because EFS is a persistent network file system shared across invocations and functions.

The option /opt in Lambda runtime is incorrect because it is generally used for Lambda layers and is read-only during execution.

Remember that Lambda has a single writable path: /tmp. Paths tied to the code package or layers are read-only, and external services like S3 or EFS persist data. If you see “temporary” or “scratch” in a Lambda question, think /tmp.