Practice Test #6

S3 Object Lock is a data protection/compliance feature that prevents deletion or modification of objects for a retention period (WORM). It does not control CloudFront caching or force edge locations to re-fetch updated objects. In fact, Object Lock could hinder overwriting objects depending on retention settings, making it unrelated and potentially harmful for this deployment scenario.

An S3 lifecycle policy to delete previous versions (or noncurrent versions) affects storage management and cost, not CloudFront edge caches. Even if old versions are removed from S3, CloudFront can still serve the previously cached object until its TTL expires or an invalidation occurs. Lifecycle policies also operate on a schedule, not as an immediate post-deploy cache refresh mechanism.

Changing the CloudFront origin bucket after each deployment is an anti-pattern. It adds operational complexity, risks misconfiguration, and does not align with standard CI/CD practices. While it could force CloudFront to fetch from a different origin, it’s unnecessary and disruptive compared to invalidations or versioned asset filenames. It also doesn’t scale well and can break permissions, OAC/OAI settings, and DNS behavior.

Incorrect. AWS X-Ray focuses on distributed tracing (latency breakdowns, service maps, traces/segments) and can provide insights into request paths and downstream calls. It does not collect OS-level metrics like memory utilization, swap usage, filesystem utilization, or disk I/O at 1-minute granularity. X-Ray also is not the standard mechanism for ingesting arbitrary custom metrics such as cacheHitRate and queueDepth into CloudWatch.

Incorrect. Modifying the application to publish metrics via the AWS SDK could work for custom application metrics, but it requires code changes and does not inherently provide OS-level metrics like memory, swap, and filesystem utilization. You would still need an agent or additional host instrumentation to gather those OS metrics. This approach increases development effort and risk compared to using the CloudWatch agent’s built-in capabilities.

Incorrect. AWS CloudTrail records AWS API calls for governance, compliance, and auditing (who did what, when, from where). It does not capture per-instance OS performance metrics or custom application metrics. CloudTrail logs are useful for security investigations and change tracking, not for right-sizing based on CPU/memory/disk utilization or for monitoring application-level KPIs like cacheHitRate and queueDepth.

Rolling deployments update instances in batches, keeping some capacity serving traffic while others are updated. This can reduce downtime, but it does not provide an exact, controlled percentage split (25%/75%) between two versions for a fixed evaluation window. During rolling, traffic goes to a mix of updated and non-updated instances based on batch progression, not a stable canary percentage.

In-place deployments update the existing instances directly (all at once or in a way that can temporarily reduce capacity). This approach can cause brief interruptions or performance degradation, especially for latency-sensitive APIs, and it does not support a controlled 25%/75% traffic split between versions. It’s generally less safe than immutable or traffic-splitting for production releases.

Immutable deployments create a new set of instances with the new version, verify health, and then switch over, which greatly reduces deployment risk and can achieve near-zero downtime. However, immutable is primarily an all-or-nothing cutover model and does not natively provide an exact 25%/75% request routing split for a timed evaluation window. That requirement maps directly to traffic-splitting.

Storing both session data and application data in MySQL on EC2 is a poor fit. Sessions are high-churn and can generate heavy read/write traffic, locking, and connection overhead, which can worsen latency during spikes. Running MySQL on EC2 also increases operational burden (patching, backups, HA design) and does not inherently provide Multi-AZ failover. This option does not address stateless scaling effectively.

Using Memcached for both session data and application data is risky because Memcached is an in-memory cache without persistence and is not a system of record. Cache node failures or evictions can cause data loss. While caching some application reads can help performance, the primary database must remain a durable store (e.g., RDS/Aurora). This option confuses caching with durable storage and is not appropriate for critical exam platform data.

EC2 instance store is local, ephemeral storage that is not shared across instances and is lost when an instance stops or terminates. In an Auto Scaling environment, instances are frequently replaced, so session data would be lost and users could be logged out or see inconsistent behavior unless you also enforce sticky sessions (which reduces scalability). It does not solve cross-instance session sharing and is operationally fragile.

This approach adds an extra API and requires modifying the original Lambda to call another endpoint for updates. It increases coupling, adds latency and failure modes, and does not automatically capture all DynamoDB updates (especially if future partner-specific Lambdas write directly to DynamoDB). It is also more development effort than using DynamoDB Streams, because you must maintain additional API Gateway/Lambda integration logic.

Kinesis Data Streams alone does not directly deliver data to S3; typically you would use Kinesis Data Firehose (or a consumer application) to persist to S3. More importantly, this requires modifying the ingest Lambda(s) to publish to Kinesis, and as new partners are onboarded with dedicated Lambdas, each producer must be updated and managed. This is more work than capturing changes at the DynamoDB layer.

Publishing to SNS from the ingest Lambda requires code changes in the producer(s), and future partner-specific Lambdas would also need to implement the SNS publish logic to ensure complete coverage. SNS is a fanout notification service, not a database change capture mechanism, so it won’t automatically capture updates that occur through other paths. It also introduces message size/format considerations and additional operational complexity.