Monitoring and Logging practice questions

Enable CloudWatch Logs for the ALB and use CloudWatch Logs Insights to query 5xx logs, then create a metric filter and alarm.

Why wrong: Enabling ALB access logs and using CloudWatch Logs Insights with a metric filter is unnecessarily complex and indirect: access logs must first be enabled and delivered to S3, then ingested into CloudWatch Logs, which adds latency. The ALB already publishes the HTTPCode_ELB_5XX_Count metric natively, so parsing logs to create a separate metric filter duplicates existing data and incurs additional cost and operational overhead. Furthermore, CloudWatch Logs Insights is designed for ad-hoc querying, not as a real-time alarm source.

Configure AWS Config rules to check ALB 5xx error counts and trigger alarms.

Why wrong: AWS Config rules are designed to evaluate resource configuration compliance against desired policies, such as ensuring an ALB has a certain security policy or is associated with a WAF, not to monitor transient operational metrics like HTTP 5xx counts. Config does not ingest CloudWatch metrics, and it cannot evaluate time-series data or trigger alarms based on error thresholds. While a custom AWS Config rule could invoke a Lambda function, that function would still need to call CloudWatch GetMetricData, making this a roundabout and unsupported method for real-time monitoring.

Use AWS X-Ray to trace requests and create a CloudWatch alarm based on X-Ray error rate.

Why wrong: AWS X-Ray focuses on distributed tracing of individual requests, providing insights into latency, service dependencies, and errors at the trace level, but it does not aggregate ALB 5xx counts into a CloudWatch metric. To get error rate from X-Ray you would need to create a group and then publish a CloudWatch metric from that group through a custom solution, such as a Lambda function. X-Ray also requires your application to be instrumented with SDKs, making it an unnecessarily heavy and indirect approach for simple 5xx monitoring that native ALB metrics already provide.

Amazon EventBridge

Why wrong: Amazon EventBridge is a serverless event bus designed to route events between AWS services and integrate with event-driven architectures, but it does not evaluate metric thresholds or perform continuous monitoring of numerical values. While you could configure EventBridge to react to a CloudWatch alarm's state change, the alarm itself must still be created in CloudWatch. Therefore, EventBridge is not the service that directly monitors message count for SQS.

AWS X-Ray

Why wrong: AWS X-Ray is a distributed tracing service that helps developers analyze and debug applications by collecting request-level traces, service maps, and performance data, but it does not monitor queue depth or other aggregate CloudWatch metrics. X-Ray focuses on end-to-end request paths, latency, and errors across microservices rather than threshold-based metric alarms. Therefore, it is unsuitable for alerting on SQS message count.

Amazon CloudWatch Logs

Why wrong: Amazon CloudWatch Logs is designed to aggregate, store, and query log data from AWS resources and applications using features like Logs Insights, and it does not directly monitor real-time metric values such as queue depth. Although you could create a metric filter from log events to generate a custom CloudWatch metric, that is not applicable to SQS's built-in per-queue metrics, and it still requires a CloudWatch alarm to react to threshold breaches. Thus, CloudWatch Logs alone cannot serve as the monitoring alarm.

Replicate the canaries to US East (N. Virginia) and run them from there.

Why wrong: Replicating the canaries to US East (N. Virginia) fundamentally changes the measurement perspective: the latency, availability, and success metrics you collect now reflect a Virginia-based vantage point rather than the experience of users in the actual target regions. This introduces a monitoring blind spot for region-specific failures or routing issues and does not preserve the cross-region view you need. It also fails to solve the dashboard problem, because you would still need a mechanism to aggregate and display metrics from the original regions if you want a single pane of glass.

Set up a Lambda function in each region to push canary results to a central S3 bucket, then create a dashboard from S3.

Why wrong: This approach adds unnecessary architectural complexity: you must deploy and maintain Lambda functions in each region, configure IAM roles and cross-region S3 bucket policies, handle eventual consistency and object naming/versioning, and then build a separate dashboard layer (e.g., Athena or QuickSight) to query the centralized S3 data. That entire pipeline simply re-serves data that CloudWatch already exposes as regional metrics via the Synthetics canary integration. It also introduces extra latency, cost, and failure points while providing no benefit over the native cross-region dashboard capability.

Create a CloudWatch Logs Insights query across all regions and visualize results.

Why wrong: CloudWatch Logs Insights queries are scoped to a single region: a query runs against log groups within one Region, so you cannot create a single query that spans all regions. Although you can add a Logs Insights widget to a dashboard, each widget is bound to a specific Region, so you would need a separate widget per region and still could not produce a combined cross-region metric view. Additionally, canary results are primarily published as numeric metrics, and deriving success/failure rates by parsing log text is slower, more complex, and less accurate than directly using the Synthetics metrics that are already available.

Add annotations to the traces for better filtering.

Why wrong: Annotations in X-Ray are user-defined key-value pairs attached to segments or subsegments for the purpose of indexing, searching, and filtering traces; they do not capture or display timing data for the network hops between services. Adding annotations would only help you retrieve traces that meet certain criteria after the fact, but it provides no visibility into where latency is introduced along the service boundary — making it an auxiliary tool for trace organization, not a diagnostic aid for slow inter-service communication.

View the raw segments of the upstream service.

Why wrong: Viewing the raw segments of the upstream service shows the internal work performed within that service (e.g., database queries, local processing, and subsegment timing) but stops at the point where the service sends its response. It does not include the time spent on the wire or the network round-trip between the upstream and downstream services, so it cannot reveal connection-level latency such as packet loss, DNS resolution issues, or load balancer delays that occur outside the service's own execution context.

Adjust the sampling rules to capture more traces.

Why wrong: Adjusting sampling rules changes the proportion of requests that are recorded by X-Ray, which controls trace volume and cost but has no bearing on the analysis of a specific latency problem in an already-captured trace. Even if you increase the sampling rate, you are simply recording more of the same type of trace data; the information needed to diagnose the slow connection (the per-http-edge latency metrics) is still only available through the trace map, and changing sampling rules will not add any dimensions of diagnostic visibility to the existing traces.

Install the CloudWatch agent on the RDS instance.

Why wrong: Amazon RDS is a fully managed database service, and you do not have access to the underlying host or operating system to install the CloudWatch agent. The CloudWatch agent is intended for EC2 instances, on-premises servers, or other resources where you can install software to collect custom metrics and logs. RDS natively publishes CPU utilization and other database metrics to CloudWatch through its built-in service integration, so an agent is neither possible nor needed.

Enable Enhanced Monitoring for the RDS instance.

Why wrong: Enhanced Monitoring is an optional RDS feature that provides OS-level metrics such as individual process CPU usage, memory, and disk I/O at one-second granularity. It runs a lightweight agent within the RDS instance and publishes its own set of metrics to CloudWatch, but it is not required for the default CPU utilization metric. RDS already reports CPUUtilization in the AWS/RDS namespace automatically, so enabling Enhanced Monitoring would only add deeper visibility for troubleshooting.

Enable Performance Insights for the RDS instance.

Why wrong: Performance Insights is a database performance monitoring tool that tracks database load, wait states, and the SQL queries causing that load. Its primary metric, DBLoad, measures the average number of active sessions and is aimed at troubleshooting query performance, not at monitoring host CPU usage. RDS' built-in CloudWatch CPUUtilization metric already covers CPU monitoring, so enabling Performance Insights would be an unnecessary and unrelated action for this requirement.

Have the application call the CloudWatch PutMetricData API directly.

Why wrong: Calling the CloudWatch PutMetricData API directly requires embedding the AWS SDK into the application and adding instrumentation code at every metric emission point. This couples business logic to AWS-specific API calls, forces you to manage credentials, batching, and retries, and is exactly the code change the requirement rules out. It also prevents using a standard agent-based collection layer, making the solution brittle and hard to migrate.

Use the ECS agent's built-in metric collection feature.

Why wrong: The ECS agent (or in Fargate, the underlying managed infrastructure) only exposes container-level telemetry such as CPU utilization, memory usage, and network I/O from Docker runtime stats. It has no mechanism to parse StatsD, StatsD-like UDP payloads, or any application-defined counters and gauges. Custom application metrics, especially those based on application logic or dimensions, are simply outside the scope of what the ECS agent collects, so relying on it leaves the needed metrics unavailable.

Modify the application to send logs using the embedded metric format.

Why wrong: The embedded metric format (EMF) is a powerful pattern that turns structured logs into CloudWatch metrics, but it requires the application to rewrite its logging calls to emit JSON documents with a specific _aws section containing the metric definitions. This is a code change to the application's logging layer and a change to operational behavior, which the requirement explicitly prohibits. Additionally, when running on Fargate you typically need the CloudWatch agent or a separate EMF exporter to decode the logs, so it is not simpler than the sidecar approach.

Enable DynamoDB Accelerator (DAX) to reduce latency.

Why wrong: DAX is a purpose-built in-memory caching service for DynamoDB designed to reduce read latency, not to provide observability. It adds a cache layer that accelerates hot-key reads but emits no metrics or trace data about API errors, Lambda failures, or end-to-end request latency. Deploying DAX would add cost and operational overhead without giving the DevOps team any monitoring or alerting capability, so it does not address the requirement to detect errors and latency.

Enable detailed billing metrics for cost analysis.

Why wrong: Detailed billing metrics in Cost Explorer / AWS Cost and Usage are focused on cost allocation, chargeback, and spend trend analysis by service, region, or tag. They reveal how much money a workload consumes, but they expose no operational signals such as Lambda error counts, API Gateway 5XX responses, or latency percentiles. Even if a spike in spend could indirectly hint at an anomaly, these metrics are not a real-time monitoring tool and cannot be used to set fine-grained alarms on error rates or request performance.

Configure CloudWatch Logs for DynamoDB.

Why wrong: DynamoDB is a managed database service that does natively publish many metrics to CloudWatch (e.g., ConsumedReadCapacityUnits, ThrottledRequests, SystemErrors), but it does not send operational logs such as query text or user activity to CloudWatch Logs. While CloudTrail can capture data plane and control plane API calls, the resulting JSON logs go to S3 or CloudWatch Logs only if explicitly configured, and that tracks API activity rather than latency or errors. Therefore, simply configuring CloudWatch Logs for DynamoDB is a false premise because no such native log stream exists for the database engine itself.

Modify the existing log group to use the KMS key by updating the log group settings.

Why wrong: You cannot modify an existing CloudWatch Logs log group to add or change an AWS KMS key because the kmsKeyId parameter is immutable after the log group is created—the console and API will reject the update. Instead, you must create a new log group with the desired KMS key and then redirect the log source or agent to write to that new group, which makes the existing log group's encryption setting permanently fixed.

Set the log group retention policy to 'Never expire' and use lifecycle policies to transition logs to Amazon S3 Glacier after 30 days.

Why wrong: CloudWatch Logs does not support direct lifecycle policies that transition log events to Amazon S3 Glacier from a log group. A log group retention policy can only expire logs within CloudWatch Logs itself; to use Glacier, you must first export the logs to an S3 bucket and then apply an S3 lifecycle policy with a glacier transition. Therefore, the combination of 'Never expire' and a built-in lifecycle to Glacier is not available in CloudWatch Logs.

AWS X-Ray

Why wrong: Incorrect: X-Ray is for tracing.

AWS Config

Why wrong: Incorrect: Config records configuration changes but not real-time notifications.

Amazon CloudWatch Alarms

Why wrong: Incorrect: Alarms are for metric thresholds, not instance lifecycle events.

Increase the EC2 instance size to handle higher traffic and reduce timeouts.

Why wrong: Increasing the EC2 instance size assumes the errors are due to resource exhaustion, but the described monitoring shows CPU and memory at normal levels, indicating sufficient capacity. ALB 5xx errors can stem from network-level unreachability, such as security group denials or misconfigured network ACLs, which a larger instance would not fix. Moreover, vertical scaling adds cost and does not address the actual cause of connection timeouts or dropped packets, making this a misguided remediation.

Configure a step scaling policy for the Auto Scaling group based on ALB 5XX count.

Why wrong: A step scaling policy based on ALB 5XX count would only add or remove instances in response to error rates, but it does not prevent the underlying connectivity issue that causes those errors. If the ALB cannot reach targets due to VPC network configuration or security group rules, newly launched instances will exhibit the same failure, so scaling out cannot resolve the problem. It also risks creating a false sense of resolution while masking the true root cause and could rapidly increase compute costs without benefit.

Enable ALB access logs and analyze the 5xx response patterns.

Why wrong: ALB access logs capture detailed HTTP request/response data, including the 5xx status code, but they do not provide information about network-layer packet drops or connection rejections. If the ALB is experiencing failures connecting to targets because of security group or NACL rules, the access log may show an error code without revealing the underlying network blockage. This limitation makes access logs insufficient for diagnosing the dropped connections, unlike VPC Flow Logs which explicitly record whether traffic was accepted or rejected at the network interface.

The X-Ray SDK cannot send traces to AWS X-Ray from Fargate tasks.

Why wrong: This statement is false because the X-Ray SDK never calls the X-Ray API directly; it always sends trace data to a local daemon via UDP. In Fargate, you run the X-Ray daemon as a sidecar container, and the SDK forwards segments to that daemon, which then batches and asynchronously uploads them to AWS X-Ray over HTTPS. The SDK-to-daemon protocol works identically on Fargate as on EC2, so there is no inherent limitation preventing trace delivery from Fargate tasks.

ServiceLens does not support Amazon ECS with Fargate launch type.

Why wrong: ServiceLens fully supports Amazon ECS, including tasks using the Fargate launch type, as long as you integrate AWS X-Ray with Amazon CloudWatch and configure the required IAM permissions. The trace map and end-to-end service visualization in ServiceLens rely on X-Ray segments, not on the underlying compute launch type. What is required is that the application is instrumented with the X-Ray SDK and that a daemon (or AWS Distro for OpenTelemetry collector) is present in the task to forward traces; the launch type itself does not affect this support.

The application is not sending metrics to CloudWatch Container Insights.

Why wrong: CloudWatch Container Insights collects infrastructure metrics and logs from ECS, but it is entirely independent from X-Ray trace data. ServiceLens shows trace maps and service health based on X-Ray segments and traces, not on the container-level metrics that Container Insights gathers. If Container Insights is disabled, you simply lack those operational dashboards and metrics; traces still appear in ServiceLens because they originate from the X-Ray SDK and daemon, so this is not the reason traces are missing.

Verify that the monitoring account's CloudWatch cross-account observability is enabled.

Why wrong: Cross-account observability being enabled in the monitoring account is a prerequisite for the overall pipeline, but since other source accounts are already ingesting data successfully, this feature is demonstrably active and functioning. If it were disabled, no accounts—including the working ones—would deliver logs, so this check would not isolate why this particular source account stopped sending logs to OpenSearch.

Review the source account's CloudWatch Logs retention policy to confirm logs are not expired.

Why wrong: The retention policy in CloudWatch Logs controls how long log events are kept before they are deleted; it does not trigger, throttle, or otherwise affect the real-time subscription forwarding mechanism. Because the logs are still visible in CloudWatch Logs (as stated in the scenario), they have not expired, and adjusting retention would neither resume forwarding nor explain why OpenSearch stopped receiving them. Expiry would only matter if the logs themselves were already purged, which is not the case here.

Ensure the IAM role in the source account has the correct trust policy for the monitoring account.

Why wrong: Cross-account log delivery via CloudWatch Logs subscriptions does not rely on an IAM role in the source account with a trust policy for the monitoring account. Instead, the source account uses a resource policy attached to the destination (for example, a Kinesis stream or an OpenSearch ingestion endpoint) to grant CloudWatch Logs permission to write data, and the monitoring account consumes that data through its own observability configuration. A misconfigured trust policy would break API calls that assume a role, but this particular data path has no such role assumption, so the issue lies elsewhere.

Create a custom resource in the stack that publishes to Amazon SNS.

Why wrong: Creating a custom resource that publishes to Amazon SNS is an unnecessarily complex workaround: it requires a Lambda-backed custom resource whose lifecycle occurs at a specific point during stack operations, and it only captures events at that single invariant rather than the full stream of stack-level events. Moreover, custom resources depend on Lambda function execution, IAM roles, and error handling, and they add cost and failure points. CloudFormation's built-in notification options already deliver SNS messages for all stack events, so a custom resource is redundant.

Create a CloudWatch alarm on the StackStatus metric.

Why wrong: CloudWatch alarms watch numeric metrics (e.g., CPUUtilization, ErrorCount) emitted by services; CloudFormation does not emit a metric named StackStatus at all. Stack status is returned as a string field via the DescribeStacks API, not exposed as time-series data, so you cannot create an alarm on it. You could use a custom script or EventBridge rule to translate status changes, but a CloudWatch alarm on StackStatus is not a valid, supported configuration.

Use Amazon EventBridge to capture CloudFormation events and publish to SNS.

Why wrong: While EventBridge can capture CloudFormation API events (e.g., via the AWS CloudFormation event source) and route them with a rule to an SNS target, this requires you to design an event pattern, configure a rule, and manage IAM permissions — and it typically captures resource-level CloudFormation events rather than the exact stack-level notification stream that native stack notifications provide. It's a viable automation path, but for the stated need (just get notified on stack events) it is more complex than simply specifying an SNS topic in the stack's notification options. The built-in integration is purpose-built, requires no rules, and is the most efficient choice.

Enable AWS CloudTrail data events for Lambda.

Why wrong: AWS CloudTrail data events for Lambda record the invocation of the function as an API activity, such as Invoke calls or events from AWS services. While this can show that a Lambda was triggered and by whom, it does not include execution timing, subsegment durations, or any trace of the function's internal operations. CloudTrail is for auditing and governance, not performance troubleshooting, so it cannot help identify where time is being spent inside the invocation.

Create a CloudWatch dashboard with function duration metrics.

Why wrong: A CloudWatch dashboard with function duration metrics displays the average, minimum, maximum, or p99 duration across all invocations over a time window. This aggregated view is useful for spotting trends or anomalies, but it hides per-invocation variability and provides no breakdown of how the time is allocated—for example, how long is spent in initialization, external API calls, or database queries. Without a trace that correlates individual requests to their timing, you cannot pinpoint the specific bottleneck causing slow production lambdas.

Add more logging statements to the function code and check CloudWatch Logs.

Why wrong: Adding more logging statements to the function code and checking CloudWatch Logs can reveal where time is spent if you manually record timestamps before and after each external call. However, this approach requires modifying code, estimating granularity, and often lacks the context of the full distributed request across services like DynamoDB or API Gateway. CloudWatch Logs gives you raw output, not a structured trace, so correlating log entries across services and identifying a precise bottleneck becomes tedious and error-prone, especially in a production environment with high concurrency.

Check the Amazon Route 53 health checks for the ALB DNS name.

Why wrong: Route 53 health checks are used for DNS-level failover and routing, such as checking an endpoint's HTTP response or TCP connectivity to decide whether to return a healthy resource's IP address. They do not provide visibility into the ALB's internal target health, connection draining, or per-request 503 responses. While a Route 53 health check on the ALB DNS name might show the ALB itself is reachable, it cannot explain why the ALB is generating 503 errors for specific targets, as DNS health checks only probe the load balancer endpoint, not the backend target group.

Review the EC2 instances' CloudWatch metrics for CPU utilization and network traffic.

Why wrong: EC2 instance CloudWatch metrics like CPU utilization and network traffic are aggregate performance indicators that can suggest resource saturation, but they do not capture the application's HTTP response codes or the ALB's decision to return 503. A sudden CPU spike could correlate with 503 errors, but the metrics lack request-level context such as which URL, which client, or whether the 503 came from the ALB because all targets were unhealthy. Furthermore, 503s frequently occur without high CPU, for example when health checks fail due to a misconfigured health check path or an unresponsive application, so these metrics are too coarse and indirect for diagnosing the root cause.

Inspect AWS CloudTrail logs for the ALB to see if there are any configuration changes.

Why wrong: AWS CloudTrail records API calls made to the AWS control plane, such as CreateLoadBalancer, ModifyLoadBalancerAttributes, or changes to target group configurations, but it does not capture the data-plane HTTP requests or responses handled by the ALB. Since the web application's 503 responses are generated at the request routing layer, CloudTrail logs would only show if someone changed ALB settings (e.g., security groups, listener rules) around the time errors occurred, which is not the actual cause of the 503. Even if configuration changes exist, you still need request-level data or health check metrics to correlate those changes with the specific 503 responses, making CloudTrail insufficient and irrelevant for this diagnosis.

Stream logs to Amazon Kinesis Data Firehose for transformation before landing in CloudWatch Logs.

Why wrong: Kinesis Data Firehose is optimized for delivering streaming data to destinations like S3, Redshift, or Splunk, and can invoke Lambda for transformation. However, using it solely to route EKS logs to CloudWatch Logs inserts an unnecessary intermediary that adds per-GB cost, provisioning overhead, and replication lag while CloudWatch Logs already supports direct ingestion from Fluent Bit and native subscription filters for post-processing. For simple log retention and analysis, direct streaming to CloudWatch Logs is the recommended, simpler path.

Enable CloudWatch Container Insights for the EKS cluster.

Why wrong: CloudWatch Container Insights delivers prebuilt dashboards and aggregated metrics for cluster, node, pod, and container resource utilization (CPU, memory, disk, network) from EKS, but it does not expose custom application-level metrics such as request counts, error rates, or service-specific latency. Those require instrumenting your code with a metrics SDK or deploying the CloudWatch agent in Prometheus scrape mode to collect from application endpoints. Container Insights is complementary to application metric monitoring and log-based alerting, not a substitute for either.

Enable AWS CloudTrail data events for the EC2 instances to capture log file modifications.

Why wrong: AWS CloudTrail records API activity across AWS services, not operating system level file modifications on EC2 instances or Amazon EFS filesystems. The application writes ASCII log lines directly to an EFS mount, and CloudTrail data events are not supported for EC2 instance storage or EFS file content changes. Even if enabled, CloudTrail would only show PutObject-style calls to S3, not the file writes performed by the web application, so it cannot extract 5xx error patterns.

Configure an Amazon EventBridge scheduled rule to invoke an AWS Lambda function that reads new log lines from EFS and publishes them to Amazon CloudWatch Logs.

Why wrong: This pattern uses a scheduled EventBridge rule to trigger a Lambda function at fixed intervals, but the Lambda would need the EFS filesystem mounted and must track a file offset across invocations to find only new log lines. Polling every minute (or longer) is not near-real-time, and the state management for 'new lines' is error-prone if log rotation occurs. The CloudWatch agent's tailing mechanism handles file rotation and sends data as it is written, eliminating the need for custom state.

Stream the log files to Amazon Kinesis Data Streams using a custom producer, then use a Lambda function to analyze and alert on 5xx errors.

Why wrong: Injecting a Kinesis custom producer onto each EC2 instance requires writing, packaging, and maintaining an agent to read the EFS log file, serialize records, and put them into a stream, and then a Lambda consumer must emit metrics. This replicates the functionality of the CloudWatch Logs agent while adding shard provisioning, data retention tuning, and an extra event-driven pipeline to debug. The operational burden is higher for the same outcome: near-real-time ingestion and alerting on 5xx errors.

Disable log file validation to reduce overhead.

Why wrong: While disabling log file validation reduces the small CPU/memory overhead of hash computation, it completely removes your ability to detect if a log file has been altered after delivery. For any security-conscious environment, the integrity guarantee of validation far outweighs the negligible performance gain. Furthermore, without validation, you have no way to prove to auditors that the logs were not tampered with.

Store CloudTrail logs in a CloudWatch Logs log group with a retention policy.

Why wrong: CloudTrail can be configured to send events to CloudWatch Logs, but CloudWatch Logs is a monitoring and log aggregation service, not an immutable archive. Log events in a log group can be manually deleted by users with `logs:DeleteLogGroup` or `logs:DeleteLogStream` permissions, and they expire automatically according to the retention policy. This makes it unsuitable for tamper-proof storage of CloudTrail logs; S3 with Object Lock is the appropriate destination for an immutable audit trail.

Enable CloudTrail Insights to detect configuration changes.

Why wrong: CloudTrail Insights captures anomalous API activity such as resource changes and high-volume events, using machine learning to detect patterns outside normal behavior. It produces a separate Insights event source and stores those events alongside regular events, but it does not add any protection to the log files themselves. Enabling Insights improves visibility, not security of the log integrity, so it cannot substitute for Object Lock or log file validation.

Auto Scaling group, then launch template, then configure network, then set capacities, then add scaling policy

Why wrong: An Auto Scaling group cannot be created without an existing launch template (or legacy launch configuration) because the group is only a wrapper that references the template to know which AMI, instance type, security groups, and user data to use when launching instances. The CreateAutoScalingGroup API call normally requires a LaunchTemplate or LaunchConfigurationName parameter, so attempting to create the group first will produce a validation error. Additionally, the network configuration, such as VPC and subnets, is selected during the group creation flow after the template is chosen, so reversing the order breaks every subsequent dependency.

Configure network, then launch template, then Auto Scaling group, then set capacities, then add scaling policy

Why wrong: Configuring the network is not a discrete pre-step; VPC, subnets, and Availability Zones are selected as part of the Auto Scaling group creation flow, after the launch template is chosen. A launch template itself may contain network interface settings, but the ASG still requires you to specify VPC subnet or AZ placement when you create the group, and that placement can override or complement the template. Doing network configuration before a launch template or ASG exists has no target object to attach to, and the AWS console/API will not let you define a standalone 'network' for a future group. The correct order is template, then group, with network as a step inside that group creation process.

Create launch template, then Auto Scaling group, then configure network, then add scaling policy, then set capacities

Why wrong: Adding a scaling policy before setting the group's capacity limits is invalid because every scaling policy, whether target tracking, step, or simple, operates by adjusting the DesiredCapacity within the currently configured MinSize and MaxSize boundaries. If MinSize and MaxSize are not already defined, the policy has no allowed range for its adjustments, and target tracking policies cannot compute the number of instances needed to maintain a metric target without existing capacity values. For example, when you attach a target tracking policy, EC2 Auto Scaling requires the group to have healthy capacity, otherwise scaling activity will fail. Therefore, capacities must be finalized, or at least initialized, before the scaling policy is added, even though these values can be later modified.

Create CodeBuild project, then Create ECR repository, then Write buildspec.yml, then Start build

Why wrong: This sequence is invalid because a CodeBuild build run cannot push to an ECR repository that has not yet been created, and if the repository does not exist at build time, the push fails. Additionally, creating the CodeBuild project before writing buildspec.yml risks the source repository at build start not containing that build instructions file, causing a 'buildspec file not found' error. The binding of a buildspec to a project can be declared upfront, but the file must exist in the source before the build is triggered; therefore the project-first ordering breaks the dependency chain.

Write buildspec.yml, then Create ECR repository, then Create CodeBuild project without privileged mode, then Start build

Why wrong: The fatal flaw here is omitting privileged mode: when a buildspec runs `docker build`, `docker tag`, or `docker push`, the build container must have access to the Docker daemon, which CodeBuild only exposes when the environment's `privileged` flag is set to true. Without that flag, the build fails with 'Cannot connect to the Docker daemon' even though the ECR repository already exists. While writing buildspec.yml before project creation is acceptable, creating the project without privileged mode makes Docker-based image builds impossible, and privileged mode cannot be toggled at build time—it must be configured on the project.

Create ECR repository, then Start build, then Create CodeBuild project, then Write buildspec.yml

Why wrong: This ordering is nonsensical because `start build` requires an existing CodeBuild project as a prerequisite; the AWS API call `StartBuild` takes a project name that must reference a previously created project, so a build cannot be initiated before the project exists. Moreover, even after the project is created later, the buildspec.yml file must already be present in the source repository or S3 input at the time the build runs, so writing it after starting the build would yield a missing-file error. The ECR repository also needs to be provisioned before the build pushes to it, making this entire tail-end ordering unworkable.