Select Two (Multi-Select) Questions

AWS::EC2::VPNGateway

Why it fails: An AWS::EC2::VPNGateway is incorrect here because its purpose is to create a site-to-site VPN connection between your on-premises network and the VPC. It establishes encrypted IPsec tunnels over the public internet to your corporate network, and it does not provide outbound internet access for private subnet instances.

AWS::EC2::InternetGateway

Why it fails: An AWS::EC2::InternetGateway is incorrect because an internet gateway enables bidirectional communication between a VPC and the internet, but it is only used with public subnets that have route table entries directing 0.0.0.0/0 to the internet gateway. Private subnet instances cannot route directly to an internet gateway; they need a NAT gateway as an intermediary because the internet gateway does not perform NAT for private IP addresses.

AWS::EC2::VPCEndpoint

Why it fails: An AWS::EC2::VPCEndpoint is incorrect because it provides private connectivity between your VPC and specific AWS services, such as S3 or DynamoDB, without traversing the public internet. It uses either gateway or interface endpoints based on PrivateLink, and it is not a general-purpose mechanism for enabling internet access from private subnets; it cannot serve as a route target for 0.0.0.0/0 traffic.

Set a DeletionPolicy on the stack to retain resources when the stack is deleted.

Why it fails: A DeletionPolicy is an attribute applied to individual CloudFormation resources, not to the stack as a whole. It determines what happens to a resource when it is removed from the stack template or when the stack is deleted (e.g., Retain, Snapshot, Delete). It is a lifecycle control, not an access control, so it does nothing to restrict who can modify or delete the stack. To protect a stack from accidental deletion, you would instead use IAM policies or an explicit deny on DeleteStack.

Define a StackSetPolicy to control permissions across accounts.

Why it fails: There is no AWS resource called 'StackSetPolicy' in AWS CloudFormation StackSets. StackSets use IAM roles to perform deployments across accounts—typically an administration role and target-account execution roles—but authorization is managed through standard IAM policies and trust relationships, not a dedicated policy resource attached to the stack set. Attempting to define a StackSetPolicy in a template or API call would result in an error because the resource type does not exist.

DiskReadOps

Why it fails: DiskReadOps tracks the number of read operations completed by a disk volume. A memory leak consumes RAM and, later, possibly swap space, but it does not inherently cause disk reads; disk read activity typically stems from file I/O or application data access. While heavy paging can eventually lead to swap I/O, DiskReadOps specifically measures block device requests, not memory-consumption trends, making it insensitive to a leak.

NetworkIn

Why it fails: NetworkIn measures the number of bytes received on the instance's network interfaces. This metric is driven by incoming traffic, which has no direct relationship with memory allocation or deallocation. A process with a memory leak may continue to use the same network patterns, and the leak itself will not alter NetworkIn unless the leak is triggered by specific network requests—making it an unreliable and indirect indicator.

CPUUtilization

Why it fails: CPUUtilization is a default CloudWatch metric that represents the percentage of allocated compute capacity being used. While a memory leak can cause the OS or garbage collector to compensate over time, the leak itself is a passive failure—the allocated memory simply remains unreferenced, and CPU usage is not necessarily affected until the system starts swapping or becomes OOM-bound. Many other factors, such as active load, thread contention, or inefficient code, can cause high CPU, so this metric lacks specificity for diagnosing a memory leak.

Place all EC2 instances in a single Availability Zone and use a Network Load Balancer.

Why it fails: Placing all EC2 instances in a single Availability Zone and using a Network Load Balancer is problematic because the NLB is regional but its targets are all in one AZ, meaning the whole application goes down when that AZ fails. The NLB itself can operate across multiple AZs, but it does not provide any automatic instance replacement or health-based recovery on its own. This configuration leaves the workload vulnerable to a single failure domain.

Use a single Application Load Balancer in one Availability Zone.

Why it fails: Using a single Application Load Balancer in one Availability Zone is a critical misconfiguration because you are not only placing all targets in one AZ, but the ALB is also only enabled in one subnet, making the load balancer itself a single point of failure. ALBs are regional services, but they must be enabled across multiple AZs to be highly available—specifying just one subnet removes that resilience. Even if the instances were multi-AZ, the ALB's own single-AZ presence would negate the architecture's fault tolerance.

Use a single large EC2 instance in one Availability Zone.

Why it fails: A single large EC2 instance in one Availability Zone offers no resilience at all: any AZ outage, hardware failure, or maintenance event takes the entire workload offline. While an m5.24xlarge may provide ample compute resources, scale-up does not equate to high availability, and there is no automated recovery or load-balanced redundancy. This design ignores the fundamental requirement of distributing workloads across independent failure domains.

Define a separate 'AWS::RDS::DBSubnetGroup' resource with subnets from at least two Availability Zones.

Why it fails: While a DB subnet group spanning at least two AZs is a prerequisite for RDS Multi-AZ, simply creating the subnet group does not make the DB instance highly available. The instance will remain single-AZ unless the DBInstance's MultiAZ property is set to true (or the engine defaults to Multi-AZ). This option confuses a networking prerequisite with the actual failover configuration.

Deploy the database with multiple read replicas in different Availability Zones.

Why it fails: Read replicas are asynchronous copies used to offload read traffic; they do not provide automatic failover for the primary DB instance. If the primary fails, a read replica must be manually promoted, which incurs downtime and data loss risk. Multi-AZ uses synchronous physical replication to a standby in another AZ, enabling automatic failover without application changes. Thus replicas alone do not satisfy the Multi-AZ requirement.

Configure the database to use a DB subnet group with subnets in a single Availability Zone.

Why it fails: A subnet group confined to a single Availability Zone cannot host a standby in a different AZ, so RDS Multi-AZ cannot be enabled. The DBInstance would be single-AZ and vulnerable to AZ-level failures. Multi-AZ requires a subnet group with subnets in at least two AZs; a single-AZ subnet group is fundamentally incompatible with the failover architecture.

AWS Systems Manager Inventory

Why it fails: AWS Systems Manager Inventory is not designed for configuration drift detection in the sense of comparing resource templates or AWS service configurations. Instead, it collects and stores metadata about the software installed on your managed instances, such as OS versions, application names, and patch levels. While this inventory data can be queried and used to identify software version mismatches, it does not evaluate resource configurations against desired AWS policies or templates, and it does not flag drift in infrastructure-as-code-defined resources.

AWS Trusted Advisor

Why it fails: AWS Trusted Advisor is a guidance service that inspects your AWS account for best-practice recommendations across cost optimization, performance, security, and fault tolerance. It does not track the desired state of your resources or compare current versus expected configurations, so it cannot detect whether your deployed infrastructure has drifted from a CloudFormation template or a configuration baseline. Trusted Advisor provides point-in-time checks (e.g., unused security groups, underutilized instances) but lacks the continuous, rule-based evaluation and detailed compliance history that configuration drift management requires.

AWS CloudTrail

Why it fails: AWS CloudTrail records API activity in your account, providing an audit log of who made what changes and when. While CloudTrail logs are useful for post-incident forensics and can show the sequence of events that led to a configuration change, CloudTrail itself does not evaluate current resource configurations against a desired baseline, nor does it compare the actual state to an expected state. It is a monitoring and auditing tool, not a configuration drift detection mechanism; drift detection requires ongoing state comparison, not just event logging.

Use AWS OpsWorks for Chef Automate to store configuration data in Chef data bags.

Why it fails: AWS OpsWorks for Chef Automate is not a suitable approach for this use case because it is primarily a configuration management service for operating servers, not a centralized store for application configuration data across accounts. Chef data bags are node-specific data structures tied to Chef infrastructure and require a Chef server to manage, which adds operational overhead and does not provide the cross-account, application-facing configuration retrieval and validation features needed here.

Store configuration files in AWS Secrets Manager and retrieve them using the Secrets Manager API.

Why it fails: AWS Secrets Manager is designed to protect and rotate secrets such as database credentials and API keys, not to store general configuration files or application parameters. While it can technically store binary or text values, its API is optimized for infrequent retrieval of highly sensitive data, and it lacks configuration-specific features like schema validation, staged rollouts, and deployment strategies. Additionally, frequent reads would incur unnecessary cost and latency compared to appropriate configuration stores.

Use AWS Systems Manager Run Command to push configuration files to EC2 instances on demand.

Why it fails: AWS Systems Manager Run Command is a wrong approach because it is an operational tool for executing commands and scripts on managed instances, not a service for storing or managing configuration files. While you could use Run Command to copy files to EC2 instances, it does not provide a central configuration repository, validation, versioning, or rollout controls, and it would not support cross-account configuration management or runtime retrieval by applications. It solves a different problem—remote command execution—rather than configuration storage and distribution.

CloudFormation can automatically create new AWS accounts using a template.

Why it fails: CloudFormation templates are declarative documents that only manage resources that already exist within a single AWS account. There is no CloudFormation resource type that creates a new AWS account; account creation is performed by AWS Organizations using the CreateAccount API or during AWS Control Tower provisioning. Attempting to place account creation in a template would fail because the template has no valid resource type and no credentials to create the account outside the organization's management path.

Nested stacks can be used to deploy resources in different accounts from a single template.

Why it fails: Nested stacks are stacks declared inside a parent stack, enabling modular and reusable templates. All resources in the parent and nested stacks are provisioned within the same AWS account and AWS region; there is no field or parameter that changes the target account or region for a nested stack. Therefore, nested stacks cannot deploy resources across multiple accounts, and trying to use them for that purpose will either fail or require a different mechanism such as AWS CloudFormation StackSets.

You can use cross-stack references to share resources between accounts.

Why it fails: Cross-stack references allow a stack in the same account and region to export an output (for example, a VPC ID) and another stack to import it using the Fn::ImportValue intrinsic function. The export namespace is per account and per region, so a stack in another account cannot import that exported value; the import would fail because the value does not exist in that account's namespace. For sharing resources across accounts, you should use AWS Resource Access Manager (RAM) or StackSets to provision synchronized resources, not CloudFormation cross-stack references.

Change the source stage to use AWS CodeCommit instead of S3.

Why it fails: Switching to CodeCommit is unnecessary and shifts the architecture rather than fixing the actual defect. CodeCommit also tracks branch tips, and if a commit is force-pushed or a branch is updated, similar consistency concerns can arise. The problem is the external system mutating the S3 object, not the source repository type, so this change does not address the root cause and introduces migration overhead.

Use server-side encryption with AWS KMS (SSE-KMS) on the S3 bucket.

Why it fails: SSE-KMS encrypts object data at rest and for transit, but it does not prevent overwrites or deletions. CodePipeline can decrypt objects if the pipeline role has kms:Decrypt permission, and encryption does not make an object immutable. The failure here is caused by the object being replaced or removed, not by an encryption or access issue, so KMS is unrelated to the root cause.

Increase the timeout for the deploy stage in the pipeline.

Why it fails: Increasing the deploy stage timeout only extends how long CodePipeline waits for deployment actions to complete; it cannot resurrect a missing or overwritten source object. The failure occurs in the source stage when the artifact cannot be fetched, so the deploy stage never receives valid input. This adjustment masks symptoms and wastes pipeline time without addressing the S3 object lifecycle problem.

Require multi-factor authentication (MFA) for pipeline executions.

Why it fails: MFA is an authentication control for human users (IAM users or federated identities) accessing the AWS Management Console, CLI, or APIs. A CodePipeline execution is an automated, event-driven service process that uses a service role’s temporary credentials, not an interactive user session, so MFA cannot be applied to the pipeline run itself. Although you can require MFA for an IAM policy that allows StartPipelineExecution, that only governs who can trigger or manage the pipeline, not the execution's internal security. Therefore, this option does not directly secure the code, build, or deployment artifacts flowing through the pipeline.

Enable AWS CloudTrail to log pipeline executions.

Why it fails: AWS CloudTrail records API activity such as StartPipelineExecution, UpdatePipeline, and PutObject on the artifact bucket, giving you a detailed log of who did what and when. However, logging is a detective control—it tells you about a security incident after it happens, not does anything to prevent one. Enabling CloudTrail does not block unauthorized access, stop a malicious deployment, or constrain who can modify the pipeline; it merely provides an audit trail for post-event investigation. While important for compliance and incident response, CloudTrail alone cannot 'ensure' a secure pipeline, so it does not qualify as one of the correct actions for proactively securing CI/CD.

Attach an Internet Gateway to the VPC and route the private subnet to it.

Why it fails: Attaching an Internet Gateway to the VPC and routing the private subnet to it directly violates the definition of a private subnet. Such a route makes the subnet effectively public, giving every instance a publicly reachable IP and allowing inbound traffic to bypass the ALB entirely. This defeats the security architecture's principle of a single controlled entry point and exposes instances to direct scanning and attacks.

Configure a network ACL on the private subnet to allow inbound traffic on all ephemeral ports.

Why it fails: Configuring a network ACL (NACL) to allow inbound traffic on ephemeral ports is unnecessary and ineffective here because the ALB typically communicates with instances on a fixed port (e.g., 80 or 443) defined in the security group, not on ephemeral ports. NACLs are stateless, so you would also need symmetric outbound rules, and they apply at the subnet boundary rather than per-instance. Most importantly, the real control should be the instance security group referencing the ALB's security group, which provides stateful, identity-aware filtering that NACLs cannot offer.

Set up an AWS Direct Connect connection for the instances to access the internet.

Why it fails: Setting up AWS Direct Connect does not provide internet access for the instances; it provides a dedicated private network connection from your on-premises data center to your VPC, bypassing the public internet. For inbound web traffic, you still need an internet-facing endpoint such as an ALB with an IGW, and for outbound internet from private instances you would use a NAT gateway. Direct Connect is irrelevant to the ALB-to-EC2 traffic flow inside the VPC and introduces unnecessary cost and complexity without addressing the security requirement.

Use AWS Config rules to detect non-compliance.

Why it fails: AWS Config rules are detective, not corrective: they continuously evaluate resources against compliance policies and report whether a resource is non-compliant, but they do not modify the instance. To actually enforce a firewall rule, you would need to pair Config with remediation actions or Systems Manager automation, which is indirect and not the primary desired-state enforcement tool. Therefore, Config alone is insufficient for the stated requirement of ensuring the firewall rule stays applied.

Use Run Command to execute the configuration once.

Why it fails: Run Command executes a document or command once on target instances, making it ideal for immediate, one-off tasks like rebooting or ad-hoc patching. After the execution finishes, Systems Manager keeps no ongoing state guarantee, so if the firewall rule is later disabled or altered, nothing will reapply it. Even scheduling Run Command through CloudWatch Events or Maintenance Windows still results in independent fire-and-forget executions rather than a stateful association that tracks and enforces desired state.

Enable AWS CloudTrail to log DynamoDB read requests.

Why it fails: AWS CloudTrail records API activity in DynamoDB, such as GetItem, Query, or Scan requests, but it is not designed to emit operational capacity metrics. CloudTrail is an auditing service that helps with security and compliance, not a real-time monitoring tool for read capacity utilization. Enabling CloudTrail data events would not give you the consumed versus provisioned units that indicate scaling needs.

Set up an AWS Lambda function to monitor the DynamoDB ReadThrottleEvents metric.

Why it fails: ReadThrottleEvents is a nonzero CloudWatch metric that DynamoDB emits only when requests are already being throttled due to insufficient provisioned capacity. A Lambda function that monitors this metric is fundamentally reactive: it fires after users have experienced throttled reads, meaning the alarm is too late to prevent service degradation. Proactive monitoring requires observing the consumption trend before it reaches the provisioned limit, which is why you need the ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits metrics instead.

Configure DynamoDB to stream all read events to CloudWatch Logs.

Why it fails: DynamoDB does not have any built-in feature to stream read events to CloudWatch Logs; it only integrates with CloudWatch for metrics and with DynamoDB Streams for item-level changes. CloudWatch Logs can receive application-level logs, but the database service itself does not export every read request as a log entry. This option confuses CloudWatch Logs with the metric-based monitoring that DynamoDB actually supports, so it is not a valid approach.

AWS CloudFormation

Why it fails: AWS CloudFormation is an infrastructure-as-code service that declaratively provisions AWS resources; it cannot run the arbitrary bash scripts or Packer commands required to build a custom Elastic Beanstalk platform AMI. Even if you model the environment as a stack, CloudFormation would only create or update resources after an AMI already exists, leaving the actual image-building step outside its capability.

AWS CodeDeploy

Why it fails: AWS CodeDeploy is an application-deployment service that pushes your application code to running EC2 instances (or Lambda/ECS) and manages lifecycle hooks during a deployment. It has no concept of building a base machine image or platform AMI, and it cannot be used to package an Elastic Beanstalk platform. Custom platform creation happens before instances exist, so CodeDeploy, which operates on already-provisioned infrastructure, is not applicable here.

Remove the approval step and rely on post-deployment monitoring.

Why it fails: Removing the approval stage eliminates the human verification control that the company requires before a critical application is deployed. Post-deployment monitoring, such as Amazon CloudWatch alarms, can only detect failures and anomalies after the release has already shipped, meaning a faulty build can affect end users and trigger rollbacks or incident response. This does not provide the pre-production authorization gate that a manual approval enforces, so it violates the stated control objective.

Replace the manual approval with an automated approval based on test results.

Why it fails: An automated approval driven by test results replaces the required human judgment with a predetermined rule, so it does not meet the explicit 'manual approval' requirement. Even if tests pass, a human approver may need to consider deployment windows, rollback readiness, incident status, or other context that automated gates ignore. Thus it changes the nature of the control rather than enhancing its auditability or accountability.

Use a shared IAM user for all approvers to simplify management.

Why it fails: Using a shared IAM user for all approvers prevents CloudTrail or IAM Access Analyzer from attributing an approval event to a specific individual, breaking non-repudiation and making post-incident reviews impossible. It also violates the principle of least privilege because any approver who knows the credentials can perform any future approval, and it increases the blast radius if those credentials are compromised. Individual IAM users or federated identities with MFA should be used so that each approval decision is uniquely attributable.

Store secrets in a parameter file in the source repository.

Why it fails: Storing secrets in a parameter file checked into the source repository violates the core tenet of keeping credentials out of version control. Every user or CI tool with repository access can read the file, and even after deleting it, the secret remains in Git history and in any forks, caches, or mirror copies. This creates a permanent credential exposure that automated scanners may detect, and there is no central way to rotate or audit usage.

Hardcode secrets in CloudFormation template parameters.

Why it fails: Hardcoding secrets as CloudFormation template parameters embeds sensitive data directly in the infrastructure-as-code artifact and any change set or stack template history. Although the NoEcho property can mask parameter values from console output, it does not encrypt them at rest or prevent them from appearing in API calls or logs, and the plaintext secret remains in the template body. This tightly couples credential management to stack deployment, making rotation and least-privilege controls difficult.

Use S3 bucket policies to restrict access to secret files.

Why it fails: An S3 bucket policy only defines who can perform actions against the bucket; it is an authorization control, not an encryption mechanism. If secret files are stored in S3, the object data at rest is protected only if you separately configure server-side encryption, and requests to the bucket are still subject to transport-level risks unless you enforce HTTPS. Additionally, using S3 as a secrets repository requires you to build rotation and access auditing yourself, whereas purpose-built services handle those controls natively.

Amazon CloudWatch Logs

Why it fails: CloudWatch Logs is a service for centrally aggregating, storing, and monitoring log files from applications and AWS resources. It does not have native event-driven triggers to start a CI/CD pipeline or build job based on a CodeCommit push; its primary integration is through Log Groups, metric filters, and subscriptions, which are not designed to respond to repository events. While CodeBuild or CodePipeline can send logs to CloudWatch Logs, the service itself cannot initiate test execution on a commit.

AWS CodeDeploy

Why it fails: AWS CodeDeploy is specifically designed to automate application deployments to EC2, Lambda, or on-premises instances. It does not support source control events or pre-test triggering; it is an execution phase that typically comes after a build and test phase. CodeDeploy relies on a deployment group and AppSpec file to deploy an already-built artifact, so it cannot listen for CodeCommit pushes and invoke a test suite.

AWS CodeBuild

Why it fails: AWS CodeBuild is a fully managed build and test service that runs a build project when invoked, but it does not subscribe to CodeCommit repository events on its own. CodeBuild must be triggered explicitly by a parent orchestrator (like CodePipeline) or an external caller (e.g., Lambda or a CLI command), or via periodic schedule. Therefore, while CodeBuild is the tool that actually executes the tests, it lacks the native event-listener capability to start on a push without an intermediate service.

Reduce read capacity units to limit concurrent reads

Why it fails: Reducing read capacity units controls only read throughput; it has no effect on write conflicts. Global tables replicate writes asynchronously, and concurrent updates to the same item in different regions are prevented only by write-time checks or reconciliation logic. Read throttling would merely limit how often clients can fetch data, not how their updates interact, so it leaves the original conflict problem untouched.

Enable DynamoDB Streams with last writer wins

Why it fails: DynamoDB Streams capture a time-ordered sequence of item changes, but merely enabling them does not change the default last-writer-wins (LWW) conflict resolution used by global tables. In LWW, the write with the latest timestamp silently overwrites the other, regardless of application semantics, which can lose meaningful updates. Streams can trigger processes to detect conflicts after the fact, yet they are not a resolution mechanism themselves—you must still decide how to reconcile conflicting values.

Increase write capacity units on the table

Why it fails: Increasing write capacity units grants more provisioned write throughput, but conflicts are not a capacity issue—they arise from business logic colliding on the same item. Higher WCU may even exacerbate the problem by allowing more concurrent writers to attempt updates simultaneously. The table can absorb more writes, yet every conflicting write still faces the same overwrite risk unless conditional expressions or reconciliation logic are used.

Use Amazon Kinesis Data Analytics to analyze logs in real-time and send alerts

Why it fails: Amazon Kinesis Data Analytics would require you to set up a Kinesis Data Stream or Firehose to feed logs, then write SQL or Flink applications to extract error codes, and finally publish results to a destination for alerts. This introduces provisioning, buffering, and operational overhead that is unnecessary when CloudWatch Logs metric filters already perform pattern matching directly on the log stream. For simple error-count thresholds, the cost and complexity of a streaming analytics pipeline cannot be justified.

Enable AWS CloudTrail to log the application's API calls

Why it fails: AWS CloudTrail records management events and data events for AWS API calls made by principals against AWS services; it does not capture stdout, stderr, or json logs emitted by an application running inside an ECS container. Application-level logs are typically shipped to CloudWatch Logs using the awslogs log driver in the ECS task definition, so CloudTrail would neither see nor analyze the error codes the application writes. Enabling CloudTrail would not satisfy the alerting requirement and would only produce unrelated API activity records.

Stream logs to Amazon S3 via Amazon Kinesis Data Firehose and use S3 event notifications to trigger alerts

Why it fails: Streaming logs with Amazon Kinesis Data Firehose to Amazon S3 introduces an inherent buffer interval (for example, 60 seconds or up to 128 MB per object) before objects are delivered, and S3 event notifications fire only after that object lands, making alerts significantly less immediate than a native metric filter. Additionally, you would need an S3 event notification to trigger an AWS Lambda function that reads the object, scans for error codes, and publishes an alarm, creating extra components and potential failure points. For near-real-time error alerting, a CloudWatch Logs metric filter is both simpler and faster.

Deletion protection must be disabled on the DB instance.

Why it fails: RDS deletion protection is a lifecycle control that only blocks the DeleteDBInstance action, not the ModifyDBInstance action used when CloudFormation changes a DBInstanceClass. Reconfiguring an instance to a larger or smaller class is a modification, not a deletion, so the presence of deletion protection does not hinder the CloudFormation stack update.

A change set must be created and executed for the update.

Why it fails: Change sets are a planning feature that lets you preview the changes CloudFormation will make; they are not a prerequisite for updating a stack. A stack update can be executed directly by calling UpdateStack with a modified template or parameter values, so omitting a change set will not prevent the RDS instance class modification from taking effect.