S3 Lifecycle Policy practice questions

Use client-side encryption before uploading to S3.

Why it fails: Client-side encryption protects data before upload but places key management entirely on the company, and it does nothing to enforce which users may access objects. It is tempting because it satisfies encryption at rest, yet SSE-KMS with bucket policies and IAM handles both authorisation and encryption natively.

Enable S3 server access logging.

Why it fails: Server access logging records requests made to the bucket for auditing purposes; it neither restricts access to authorised users nor encrypts stored objects. It is tempting because logging sounds security-related, but the requirement is authorisation and encryption at rest, which logging cannot deliver.

Use a bucket ACL to grant access to the data lake.

Why it fails: Bucket ACLs grant coarse read/write permissions to predefined grantee groups and cannot express the fine-grained, identity-based authorisation the scenario needs. They are tempting as a legacy S3 access mechanism, but IAM policies with bucket policies provide the required least-privilege control.

Create an IAM role with a policy that allows only t3.micro, and attach it to users in the dev OU.

Why it fails: IAM policies attached to users cannot restrict instance type by OU, because instance-type conditions such as ec2:InstanceType are evaluated per principal, not per organisational unit, and users could assume other roles. IAM roles suit granting permissions to specific identities or workloads.

Use AWS CloudFormation templates that specify t3.micro.

Why it fails: CloudFormation templates constrain only resources created through those stacks; developers launching instances via the console, CLI or SDK bypass the template entirely, so t3.micro is not enforced. Templates are correct when standardising repeatable, version-controlled infrastructure deployments.

Use AWS Config rules to terminate non-compliant instances.

Why it fails: AWS Config rules detect and report non-compliant instances after launch, and remediation terminates them rather than preventing creation; the requirement is to allow only t3.micro. Config is the right choice for continuous compliance auditing and drift detection across accounts.

Configure each account's CloudTrail to send logs to a central CloudWatch Logs group

Why it fails: CloudWatch Logs is not S3; this delivers log streams to a log group, so the central S3 bucket requirement is unmet. CloudWatch Logs suits real-time metric filters and alarms, not durable centralised log archive in S3.

Create a CloudTrail trail in each account and deliver logs to the same S3 bucket

Why it fails: Per-account trails deliver to S3 but do not automatically cover every member account; each account must be configured individually, and new accounts joining AWS Organizations are missed. An organisation trail created in the management account captures all accounts by default.

Use S3 replication to copy logs from individual account buckets to a central bucket

Why it fails: S3 replication copies objects between buckets after they land, so it cannot deliver CloudTrail events into the central bucket directly; CloudTrail's organisation trail writes to a single bucket using a bucket policy granting the trail service principal PutObject. Replication suits cross-Region or cross-account duplication of existing objects, not centralised log ingestion.

Use Amazon Aurora Serverless to reduce management.

Why it fails: Aurora Serverless is still relational and MySQL- or PostgreSQL-compatible, so it does satisfy the complex-query and minimal-code-change requirements; it fails only because the stem asks for a migration strategy, and serverless capacity scaling is an operational choice rather than a database migration approach. It is tempting because it reduces management overhead.

Store data in Amazon S3 and use Athena for queries.

Why it fails: S3 with Athena is a serverless query service over object storage, not a relational database; it lacks transactions, constraints and low-latency point lookups, so the application's data access code would need substantial rewriting. It is tempting for ad-hoc analytics over large datasets, and would be correct if the workload were analytical reporting rather than transactional application queries.

Migrate to Amazon DynamoDB for scalability.

Why it fails: DynamoDB is a key-value and document store without joins or a SQL engine, so complex relational queries would require rewriting the application's data access layer. It is tempting for microservices needing horizontal scale at single-digit millisecond latency, and would be correct if the workload were access-pattern-driven rather than query-driven.

Deploying the application across multiple Availability Zones.

Why it fails: Multi-AZ deployment addresses high availability within one Region, not disaster recovery across Regions. It is tempting because it protects against a single Availability Zone failure, which is the correct resilience choice for uptime requirements, but a Region-wide disaster still takes the whole application offline.

Using larger instance sizes for better performance.

Why it fails: Instance sizing affects performance and cost, not recovery objectives or failover capability. It is tempting because right-sizing is a genuine design consideration, and larger instances would be the correct answer to a question about handling peak compute load rather than disaster recovery.

AWS Lambda with scheduled scaling

Why it fails: Lambda cannot run or scale the existing EC2 fleet, and scheduled scaling triggers on time, not CPU utilisation. It is tempting because Lambda is serverless and event-driven, and would be correct for scheduled batch jobs or event-triggered functions rather than load-driven EC2 scaling.

Amazon CloudFront with origin scaling

Why it fails: CloudFront caches and delivers content at edge locations; it has no origin scaling capability and cannot add EC2 capacity from CPU metrics. It is tempting because it fronts web applications, and would be correct for reducing latency and offloading static content, not for scaling compute.

AWS Elastic Beanstalk with environment scaling

Why it fails: Elastic Beanstalk manages its own environment and scaling policies, which conflicts with the requirement to scale the existing EC2 fleet behind an Application Load Balancer directly from CPU metrics. It is tempting as a managed platform, and would be correct for deploying a new application without existing infrastructure.

Increase the instance size to handle more load per instance.

Why it fails: Vertical scaling raises per-instance capacity but cannot respond automatically to sudden spikes; the Auto Scaling group still lacks a scaling policy, so no new instances launch. It suits steady, predictable growth where instance count stays fixed and each node simply needs more CPU or memory.

Manually increase the desired capacity when traffic spikes.

Why it fails: Manual capacity changes require human intervention, directly contradicting the requirement for automatic handling of sudden spikes. It fits planned, one-off events where an operator is present and traffic timing is known in advance, not unpredictable demand.

Use scheduled scaling to add instances at expected peak times.

Why it fails: Scheduled scaling acts on a calendar, so it cannot react to unplanned spikes arriving outside the configured windows. It is the right choice for predictable daily or weekly peaks, such as a batch job or known business-hours load.

Use S3 cross-region replication.

Why it fails: Cross-region replication copies objects into another bucket you own; it cannot grant a partner's account principals access, since authorisation still requires a bucket policy or ACL naming that account. It tempts because replication genuinely serves durability, latency and compliance scenarios across Regions you control.

Create a pre-signed URL for the partner.

Why it fails: A pre-signed URL embeds the issuer's credentials, so the partner accesses objects as the signing identity rather than with their own account credentials, and it expires. It tempts because pre-signed URLs correctly grant temporary access to unauthenticated users or one-off downloads.

Provide the partner with an IAM user in the company's account.

Why it fails: Creating an IAM user inside the company's account gives the partner credentials belonging to that account, not their own, and breaches credential-sharing practice. It tempts because cross-account IAM roles are the standard mechanism, and IAM users are genuinely correct for identities within a single account.

S3 One Zone-Infrequent Access

Why it fails: S3 One Zone-Infrequent Access stores objects in a single Availability Zone, so an AZ failure could destroy logs that must survive seven years. It is tempting because it is the cheapest infrequent-access class, and would be correct for reproducible, non-critical data where durability loss is acceptable.

S3 Intelligent-Tiering

Why it fails: S3 Intelligent-Tiering charges a monthly monitoring and automation fee per object, and its tiers do not extend to the seven-year archival depth required here. It is tempting because it automatically moves objects between access tiers, and would be correct for unpredictable access patterns over shorter retention periods.

S3 Standard

Why it fails: S3 Standard bills at the highest per-gigabyte rate with no retrieval charge, so seven years of daily logs becomes prohibitively expensive. It is tempting because it delivers immediate, low-latency access, and would be correct for frequently accessed, performance-sensitive data rather than archival logs tolerant of a 24-hour retrieval window.

Add Amazon ElastiCache to cache database queries.

Why it fails: ElastiCache offloads database reads, but the stem attributes latency spikes to EC2 CPU utilisation, so caching queries does not relieve the saturated compute. It tempts because ElastiCache genuinely reduces latency when the bottleneck is repeated database access rather than instance CPU.

Use Spot Instances to reduce costs and scale horizontally.

Why it fails: Spot Instances are reclaimed on two-minute interruption notices and do not lower per-request CPU consumption, so latency spikes persist and capacity becomes unreliable. It tempts because Spot genuinely cuts cost for interruption-tolerant, stateless or batch workloads, not latency-sensitive web tiers.

Increase the EC2 instance size to handle peak loads.

Why it fails: Vertical scaling to a larger instance size raises the ceiling but leaves capacity fixed between changes, so peak-hour CPU contention persists and cost scales with idle headroom. It is tempting for steady, predictable workloads, yet the scenario needs elastic horizontal scaling driven by demand.

Amazon S3 Transfer Acceleration and AWS Lambda

Why it fails: Transfer Acceleration only speeds up uploads to S3 over long distances; it does not ingest streaming or IoT data, and Lambda needs an event source to trigger on. Tempting because both are real S3-adjacent services, and Transfer Acceleration would suit accelerating large global uploads, but neither provides near-real-time stream ingestion.

Amazon Athena and Amazon S3

Why it fails: Athena queries data already in S3 using SQL; it cannot ingest IoT or streaming data, and it is not a processing engine for arriving records. Tempting because it is a genuine S3 analytics service, and would be correct for ad-hoc or scheduled queries over a static data lake, but the stem demands near-real-time ingestion and processing.

AWS Glue and Amazon Redshift

Why it fails: Glue is a batch-oriented ETL service and Redshift is a warehouse, so neither processes records as they arrive. Tempting because both are legitimate data-lake components, and Glue with Redshift would be correct for scheduled batch transformation into a warehouse, but the stem requires near-real-time streaming ingestion and processing.

Store session state in Amazon DynamoDB

Why it fails: DynamoDB is a key-value store, not a session cache; it adds per-request latency and cost compared with ElastiCache, and the ALB cannot route by session ID. It is tempting because DynamoDB offers durable, highly available storage, and would suit persistent user profile or order data rather than ephemeral session state.

Store session state on the local instance store of each EC2 instance

Why it fails: Instance store is ephemeral and tied to one EC2 instance, so sessions vanish on stop or replacement and are invisible to other instances behind the ALB. It is tempting for its low latency and zero cost, and would be correct for scratch data or temporary caches that can be regenerated.

Store session state in Amazon S3

Why it fails: S3 offers no low-latency atomic read-modify-write for concurrent session updates, and the ALB cannot route requests by session ID. It is tempting because S3 is durable, highly available and cheap, and would be correct for storing static assets, logs or backups rather than live session state.

Use client-side encryption with the AWS SDK.

Why it fails: Client-side encryption with the AWS SDK leaves key management and rotation entirely to the company; it provides no automatic annual rotation and no AWS-managed key store. It is tempting because it gives full control over plaintext and keys before upload, which suits scenarios demanding end-to-end encryption where AWS must never hold the key.

Use S3 server-side encryption with customer-provided keys (SSE-C).

Why it fails: SSE-C requires the company to supply and rotate the encryption key on every request; S3 stores no key and performs no automatic rotation, so the annual rotation mandate fails. It is tempting when you must retain sole custody of keys while still letting S3 perform the cryptographic operations.

Use S3 server-side encryption with S3 managed keys (SSE-S3).

Why it fails: SSE-S3 uses keys owned and rotated by AWS, not by the company, so the requirement for a company-managed key with automatic annual rotation is unmet. It is tempting as the zero-configuration default for basic encryption-at-rest needs where no customer key control is mandated.

Deploy EC2 instances in multiple AWS Regions and use Route 53 latency-based routing.

Why it fails: Multi-Region EC2 with latency-based routing duplicates the entire application stack, requiring data replication, deployment pipelines and failover management across Regions — far from least operational effort. It is tempting because latency routing genuinely directs users to the closest healthy endpoint, and would be correct when full regional isolation or disaster recovery is also required.

Move the dynamic content to Lambda@Edge functions running at CloudFront edge locations.

Why it fails: Lambda@Edge cannot serve the origin EC2 dynamic content; it only runs JavaScript or Python at edge locations in response to CloudFront events, so the single-Region origin remains the bottleneck. It is tempting because Lambda@Edge genuinely reduces latency for request and response manipulation, and would be correct for header rewriting or lightweight personalisation at the edge.

Add an Amazon ElastiCache cluster in front of the EC2 instances to cache dynamic responses.

Why it fails: ElastiCache caches repeated reads but does not move content closer to distant users; each uncached request still traverses the globe to the single-Region EC2 origin, so latency for distant users persists. It is tempting because ElastiCache genuinely reduces database load and response times, and would be correct for read-heavy workloads with repeated queries from a concentrated user base.

Use Amazon S3 with server-side encryption and enforce HTTPS.

Why it fails: S3 server-side encryption and HTTPS secure objects stored in S3, not data on the EC2 instances' EBS volumes, leaving the at-rest requirement unmet. It is tempting because S3 is the usual store for sensitive data, and this pairing would be correct for an application persisting files to S3.

Use AWS Key Management Service (KMS) to generate keys and enable encryption on EBS volumes.

Why it fails: KMS-encrypted EBS volumes cover data at rest, but the option configures no TLS listener or certificate, so data in transit between clients and the instances remains unencrypted. It is tempting because KMS and EBS encryption are the standard at-rest answer, and would suffice if the stem required only encryption at rest.

Use AWS Certificate Manager (ACM) to issue TLS certificates and configure the application to use HTTPS.

Why it fails: ACM certificates and HTTPS encrypt traffic in transit, but no EBS or other at-rest encryption is configured, so stored financial data remains plaintext on disk. It is tempting because ACM is the standard TLS solution, and this would be correct if only in-transit encryption were required.

Create IAM users in target accounts with AdministratorAccess.

Why it fails: StackSets do not use IAM users.

Use a CloudFormation service role in the management account.

Why it fails: Service role is for stack operations in one account.

Apply an SCP to allow CloudFormation actions across accounts.

Why it fails: SCPs only restrict, they don't grant permissions.

Enable AWS Config in the management account and use an aggregator for all accounts.

Why it fails: A Config aggregator only centralises configuration and compliance data from source accounts; it does not enable the Config rule in each account. Aggregators are tempting for cross-account compliance visibility, and would be correct when the requirement is a consolidated dashboard rather than automatic rule deployment in new accounts.

Use an SCP to automatically enable the AWS Config rule in all accounts.

Why it fails: SCPs are IAM policy guardrails that allow or deny API actions; they cannot enable AWS Config rules or create configuration resources. SCPs are tempting because they enforce policy across every account in an organisation, which is the correct approach when the goal is blocking specific API calls rather than provisioning Config.

Use an SCP to deny the s3:PutBucketPublicAccessBlock action if a specific tag is not present.

Why it fails: SCPs cannot evaluate tag presence to conditionally deny s3:PutBucketPublicAccessBlock, and denying that action prevents blocking public access rather than enabling a Config rule. Tag-conditioned SCPs are tempting for attribute-based guardrails, and would fit when the requirement is denying actions on untagged resources.

Use a bucket policy to deny uploads that do not include the x-amz-server-side-encryption header.

Why it fails: This option fails because a bucket policy denying uploads without the `x-amz-server-side-encryption` header only enforces that clients *specify* encryption, not that S3 automatically *applies* it. If a client omits the header, the upload is denied, but the objective is to ensure *all successful uploads* are encrypted. This approach is tempting as it can prevent unencrypted uploads if default encryption is not configured, or enforce a specific encryption method. It would be appropriate for scenarios where you need to mandate that clients explicitly declare their desired server-side encryption method.

Create an AWS Lambda function that encrypts objects after they are uploaded.

Why it fails: Post-upload Lambda encryption leaves a window where objects sit unencrypted, and it does not enforce encryption as a bucket policy condition on the PUT itself. Default bucket encryption (SSE-S3 or SSE-KMS) encrypts objects at write time. Lambda remediation suits transforming or scanning existing objects, not enforcing at-rest encryption.

Configure an S3 Access Point with a policy that requires encryption.

Why it fails: This is possible but adds unnecessary complexity. An S3 Access Point with a policy can enforce encryption, but it is an additional component to manage. Default encryption achieves the same goal more directly at the bucket level.

AWS Key Management Service (KMS)

Why it fails: KMS manages encryption keys, not application secrets; it stores no database passwords or API keys and performs no rotation. KMS is tempting because it is a security service, but Secrets Manager is purpose-built for centralised secret storage with automatic rotation.

AWS CloudHSM

Why it fails: CloudHSM provides dedicated hardware security modules for cryptographic key operations, not a managed secret store with rotation. It is tempting for key custody, but Secrets Manager centralises credentials and rotates them natively; CloudHSM would require custom rotation logic.

AWS Systems Manager Parameter Store

Why it fails: AWS Systems Manager Parameter Store securely centralises the storage of configuration data and secrets, such as database passwords and API keys, aligning with the need for secure and centralised secret management. However, it does not offer native automatic secret rotation, a crucial requirement for this scenario. While Parameter Store is excellent for managing non-rotating parameters or secrets where rotation is handled by custom scripts, it fails to meet the explicit demand for *automatic* rotation.

AWS Data Pipeline

Why it fails: AWS Data Pipeline is a legacy orchestration service scheduled for end-of-support, and it lacks native support for the complex conditional transformation logic required here. It suits simple scheduled data movement between AWS services. Step Functions provides the branching and state management this pipeline needs.

AWS Lambda functions

Why it fails: Lambda functions run individual transformation snippets, but they impose a 15-minute timeout and no native workflow state, so complex conditional pipelines spanning many steps cannot be coordinated. Lambda is right for short event-driven tasks, not multi-stage orchestration with branching logic.

AWS Glue ETL jobs

Why it fails: AWS Glue ETL jobs execute the transformation logic itself, but the question asks which service orchestrates the pipeline, including conditional branching across multiple steps. Glue is the correct choice when you need serverless Spark-based transformation code, not workflow coordination with dependencies and triggers.