Select Two (Multi-Select) 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.

AWS Elastic Beanstalk

Why it fails: Elastic Beanstalk is a PaaS that provisions and manages application environments, not a declarative IaC tool for defining arbitrary infrastructure. It tempts because it automates provisioning, but that automation is opinionated and imperative from the user's view. CloudFormation and AWS CDK define infrastructure declaratively.

AWS OpsWorks

Why it fails: AWS OpsWorks is a configuration management service using Chef and Puppet stacks; it manages instances and applications but does not provide declarative template-based infrastructure definition. It is tempting as an automation tool, yet CloudFormation and CDK are the services that declare and provision AWS resources from templates.

AWS CodeDeploy

Why it fails: CodeDeploy automates application deployments to EC2, Lambda, or ECS; it does not define infrastructure declaratively. It is tempting because it is an infrastructure-adjacent developer tool, but CloudFormation and CDK are the services that declare and provision resources from templates.

Launch the database instance in a public subnet.

Why it fails: A public subnet exposes the RDS instance to internet routing, contradicting the requirement that the database be unreachable from the internet. Public subnets are tempting because they suit internet-facing load balancers and bastion hosts, but RDS belongs in private subnets reachable only from the web tier's security group.

Store database credentials in AWS Systems Manager Parameter Store.

Why it fails: Parameter Store secures credential storage and rotation, but it neither restricts database access to a specific port nor removes internet reachability, so it fails the stated security objectives. It is tempting because it is a genuine best practise for secrets management, and would be correct if the question asked how to avoid hard-coded credentials.

Amazon Inspector.

Why it fails: Amazon Inspector scans EC2 instances and container images for software vulnerabilities and unintended network exposure; it does not trace packet paths or reachability between instances. It is tempting because it reports network-related findings, and would be correct for vulnerability assessment, not for diagnosing connectivity failures.

AWS CloudTrail.

Why it fails: CloudTrail records API activity and management events in the account; it captures no packet-level or flow-level data between EC2 instances, so it cannot show where connectivity breaks. It is tempting because it is a core monitoring service, and would be correct for auditing who changed security groups or routes, not for tracing live traffic.

AWS Config.

Why it fails: AWS Config records resource configuration changes and evaluates compliance against rules; it does not capture packet-level flow logs or reachability paths between instances. It is tempting because it inventories network resources such as security groups, which is useful for auditing drift, but connectivity troubleshooting requires VPC Flow Logs and Reachability Analyzer.

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.

Use only the rehosting strategy for all applications

Why it fails: Applying rehosting to every application forgoes the risk reduction that replatforming or refactoring provides for workloads unsuited to lift-and-shift, such as those needing managed services or architectural change. Rehosting suits rapid, low-effort migrations of stable legacy applications where minimal modification is acceptable.

Migrate all applications in a single wave to reduce coordination effort

Why it fails: A single wave concentrates change across hundreds of applications simultaneously, amplifying blast radius and making rollback impractical. Waves are deliberately staggered to isolate failures and validate each increment. Batching everything together would only suit a small, tightly coupled set of applications with negligible interdependencies.

Roll back all migrations if any application experiences issues

Why it fails: Rolling back every migration on any single application failure halts the whole programme and discards successful cutovers, multiplying risk rather than reducing it. It is tempting because rollback is a genuine risk control, and it would be correct as a scoped per-application rollback plan.

Use S3 replication to copy logs from member account buckets to the central bucket.

Why it fails: S3 replication copies objects between buckets, but member accounts have no CloudTrail buckets to replicate from — the trail writes straight to the central bucket. Replication is correct for duplicating an existing regional bucket for compliance or latency, not for aggregating trails.

Create an IAM role in each member account that allows CloudTrail to write to the central bucket.

Why it fails: CloudTrail writes to the central bucket directly via the bucket policy and the organisation trail; no per-account IAM role is needed because CloudTrail assumes the service-linked role, not a customer role. Cross-account roles suit delegated administration, not log delivery.

Enable AWS Config in each member account to forward logs to the central bucket.

Why it fails: AWS Config records resource configuration changes, not CloudTrail API activity, and cannot forward CloudTrail logs. It is tempting because Config also aggregates multi-account data, but that aggregation covers configuration items and conformance packs, not the CloudTrail event stream the scenario requires.

Increase the deployment timeout in the CodeDeploy deployment group to allow more time for validation.

Why it fails: Extending the deployment timeout only lets failing validation scripts run longer before the deployment aborts; the scripts still fail. It is tempting because timeouts do cause deployment failures, so raising the value is correct when validation legitimately needs more time than the configured window.

Configure an Auto Scaling lifecycle hook to perform health checks before the instance is placed in service.

Why it fails: A lifecycle hook delays instance termination or launch; it cannot fix validation scripts failing on already-running, in-service instances. It is tempting because lifecycle hooks genuinely gate instance health during scale-in and scale-out events, which is the right control when instances enter service unhealthy.

AWS Lambda functions to process each file.

Why it fails: AWS Lambda caps execution at 15 minutes, so a 2-hour CPU-intensive file cannot complete within a single invocation. It is tempting because Lambda suits short, event-driven S3 processing with no idle capacity, and would be correct for sub-15-minute tasks triggered per object.

Auto Scaling group with scheduled scaling policies.

Why it fails: Scheduled scaling follows a time-based calendar, so it cannot react to unpredictable S3 upload arrivals and leaves capacity idle between batches. It is tempting for predictable traffic patterns, but this workload needs event-driven scaling from queue depth or CloudWatch alarms.

Increase the number of shards in the Kinesis stream to reduce data per Lambda invocation.

Why it fails: This does not address DynamoDB throttling.

Configure reserved concurrency for the Lambda function to limit its maximum concurrency.

Why it fails: Reserved concurrency limits Lambda, not DynamoDB throttling.

Increase the concurrency limit for the Lambda function to allow more parallel executions.

Why it fails: More concurrency may increase throttling.

Shared database schema across services

Why it fails: Shared schema creates tight coupling; changes affect all services.

Synchronous RESTful HTTP calls between services

Why it fails: Synchronous calls create temporal coupling; a change in one service may affect others.

Amazon CloudFront

Why it fails: CloudFront is a content delivery network that caches and serves content from edge locations; it does not load-balance traffic across EC2 instances in an Auto Scaling group. It is tempting because it fronts origins, but the required distribution is handled by Application Load Balancer or Network Load Balancer.

AWS Global Accelerator

Why it fails: Global Accelerator routes traffic over the AWS global network to regional endpoints using static anycast IP addresses; it does not balance requests across EC2 instances in an Auto Scaling group. It is tempting for multi-Region failover, but the required distribution uses Application Load Balancer or Network Load Balancer.

Amazon Route 53

Why it fails: Route 53 is a DNS service that resolves names to endpoints, including weighted and latency routing; it does not distribute traffic across instances within an Auto Scaling group. It is tempting because it can steer traffic between regions, but here the load balancing is done by Application Load Balancer or Network Load Balancer.

Allow each team to create their own VPCs and use VPC Peering to connect them.

Why it fails: Team-created VPCs with peering leave administration distributed and security rules duplicated per VPC, contradicting centralised control. Peering suits connecting a small number of specific VPCs for direct traffic, not enforcing uniform rules across a multi-account estate.

Use AWS CloudFormation StackSets to deploy identical VPCs to each account.

Why it fails: StackSets replicate resources but do not centralise network administration; each account still owns and edits its own VPC and security groups, so common rules drift. StackSets suit deploying identical baseline templates across many accounts, not sharing centrally governed networks.

Use AWS Config to record IAM role changes and stream to CloudWatch Logs.

Why it fails: AWS Config records resource configuration changes, including IAM roles, and can stream them to CloudWatch Logs, but the requirement is logging and alerting on API calls, which CloudTrail captures. Config is tempting because it tracks IAM role state over time, the right choice for compliance auditing of configuration drift.

Create an SCP that denies IAM role creation and modification.

Why it fails: An SCP denying IAM role creation and modification blocks the API calls entirely, so nothing is logged or alerted — it prevents rather than detects. SCPs are tempting because they enforce guardrails across every account in the organisation, which is the right use when the goal is prevention, not monitoring.

Enable IAM Access Analyzer to monitor IAM role usage.

Why it fails: IAM Access Analyzer identifies resources shared with external entities and unused permissions; it does not record or alert on IAM role creation and modification API calls. It is tempting because it analyses IAM policy risk, which suits reviewing existing permissions rather than detecting configuration-change events.

AWS Key Management Service (KMS)

Why it fails: KMS manages encryption keys and their access policies; it does not define which AWS API actions an identity may call. It is tempting because KMS is genuinely the right service when the requirement is controlling who can encrypt, decrypt, or rotate specific customer managed keys.

AWS Config

Why it fails: AWS Config evaluates resource configuration against rules and reports drift; it cannot constrain which actions an identity may perform. It is tempting because Config is genuinely the right service when the requirement is detecting and remediating non-compliant resource settings.

AWS CloudTrail

Why it fails: CloudTrail records API activity for auditing and detection; it does not grant or restrict permissions, so it cannot enforce least privilege. It is tempting because CloudTrail is genuinely the right service when the requirement is capturing an immutable audit trail of who invoked which API.

Accounts cannot be moved between OUs once created.

Why it fails: Accounts can be moved between OUs.

Each organizational unit (OU) should contain only one account for security isolation.

Why it fails: OUs can contain multiple accounts; isolation is achieved via SCPs.

SCPs can only be applied to root accounts, not OUs.

Why it fails: SCPs can be applied to OUs and individual accounts.

Grant the Lambda function's IAM role permission to access the RDS database directly.

Why it fails: Granting the Lambda role direct RDS access bypasses Secrets Manager, so credentials would be embedded or fetched manually and never rotated every 30 days. It is tempting because IAM database authentication removes passwords entirely, which would be correct for RDS engines that support it and where rotation is not mandated.

Write custom rotation logic in the Lambda function to change the database password.

Why it fails: Custom rotation logic inside the application Lambda duplicates what Secrets Manager's rotation Lambda already provides, and it cannot update the stored secret atomically. It is tempting because a Lambda can run SQL against PostgreSQL, which would be correct for bespoke credential stores outside Secrets Manager.

Configure an IAM identity provider to use the on-premises Active Directory.

Why it fails: IAM identity providers are for federating AWS API access, not for application-level authentication.

Store AD credentials in AWS Systems Manager Parameter Store and retrieve them at runtime.

Why it fails: Parameter Store is not designed for AD authentication integration.

Deploy AWS Managed Microsoft AD in each account and configure replication.

Why it fails: Deploying AWS Managed Microsoft AD in each account and configuring replication fails to provide a single, centralised identity store for seamless authentication across the AWS Organisation, instead creating isolated directories. This approach does not leverage the directory sharing capabilities of AWS Managed Microsoft AD. It is tempting because AD replication is fundamental for high availability and fault tolerance within a single Active Directory domain. This option would be appropriate if distinct, isolated AD environments were required for separate business units without any cross-account authentication needs from a shared directory.

Transition objects to S3 Glacier Flexible Retrieval after 90 days.

Why it fails: Glacier Flexible Retrieval returns archived objects in minutes to hours, so it cannot maintain millisecond retrieval latency. It is tempting because it dramatically lowers storage cost for cold data, and would be correct if the workload tolerated retrieval delays rather than requiring immediate access.

Use S3 Glacier Deep Archive for data older than 30 days.

Why it fails: Glacier Deep Archive has retrieval times of 12 hours, not milliseconds.

Use S3 One Zone-IA for all data to reduce storage costs.

Why it fails: S3 One Zone-IA stores objects in a single Availability Zone, so it cannot satisfy durability requirements for data needing resilience, and it still bills a retrieval fee per gigabyte. It suits reproducible, non-critical data where cross-AZ redundancy is unnecessary — not general infrequently accessed storage.

Amazon RDS Single-AZ deployment with automated backups

Why it fails: Single-AZ deployment places the database in one Availability Zone, so no automatic failover to a second AZ occurs; automated backups restore data but do not provide multi-AZ high availability. It suits dev/test or cost-sensitive workloads tolerating downtime, not production systems needing minimal-downtime failover.

Amazon DynamoDB with global tables

Why it fails: DynamoDB is a NoSQL key-value store, so it cannot satisfy the stem's relational database requirement; global tables replicate across Regions, not Availability Zones. It would be correct for multi-Region, low-latency NoSQL workloads needing active-active replication, not relational multi-AZ failover.

Amazon RDS Read Replica

Why it fails: A Read Replica serves read scaling and can be promoted manually, but promotion is not automatic failover and introduces downtime; it also uses asynchronous replication. It would suit offloading read-heavy reporting traffic, not the stem's requirement for automatic multi-AZ failover with minimal downtime.