AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 901–975

The ALB routes requests only to targets that have successfully passed their configured health checks. If health check failures occur—due to an incorrect health check path, a timeout threshold being too low, or an application dependency failing—the corresponding instances are marked unhealthy and removed from the rotation. When the number of healthy targets drops below the minimum needed (typically zero healthy targets in a target group), the ALB returns HTTP 503 Service Unavailable. This can happen without CPU or memory utilization rising, because health checks validate application-level readiness, not just resource utilization.

The CodeBuild service role must include ecr:GetDownloadUrlForLayer and ecr:BatchGetImage, along with ecr:GetAuthorizationToken, to successfully pull a container image from Amazon ECR. BatchGetImage retrieves the image manifest, while GetDownloadUrlForLayer obtains the URLs for each layer, and both are required after CodeBuild calls GetAuthorizationToken to authenticate. Without these permissions, CodeBuild receives an AccessDenied exception and the security scan cannot start.

Amazon EFS is a regional, elastic, fully managed NFS file system that is accessible from all Availability Zones in the region. It supports the ReadWriteMany access mode, allowing multiple pods across different nodes and AZs to share the same file system simultaneously. EFS integrates with the EKS CSI driver and provides strong consistency and durability, making it an ideal persistent storage solution for stateful applications deployed on EKS.

The 'base-directory' value in the artifacts block points to a path that CodeBuild expects to exist when it attempts to upload artifacts after the build phase completes. If your build commands generate output inside 'dist', for example, then specifying a base-directory like 'build' will cause an 'artifact base-directory does not exist' failure because that directory was never created or populated. CodeBuild does not automatically compile or copy files; it simply packages whatever is present under the specified path at that moment. Therefore this is the correct reason for the error, not an invalid pattern or runtime.

AWS Systems Manager State Manager is the correct choice because it creates State Manager associations that run SSM documents on a schedule to enforce and update configuration files across your managed instances. You can specify the exact content and location of files using SSM documents like AWS-RunShellScript or AWS-ApplyAnsibleModules, and the association will ensure that state stays consistent, remediating drift automatically. It supports targeting by tags, integration with Parameter Store for values, and granular rate controls, making it a native, agent-based configuration management service.

When a pipeline's deploy action references a CodeDeploy deployment group, CodeDeploy resolves that group by name and deployment group ID at execution time. If the group was deleted or renamed after pipeline configuration, the deploy action fails with a DeploymentGroupDoesNotExist or similar error when CodeDeploy attempts the deployment. The pipeline configuration itself stores the name, not a live reference, so the failure occurs at run time, not when the pipeline is edited. This is the classic cause when the error explicitly indicates the deployment group cannot be found.

Aurora Global Database is the correct DR choice because it uses dedicated storage-level replication across regions with a typical RPO of sub-second and an RTO of under 1 minute when you promote a secondary region. The primary and secondary remain fully readable during normal operation, and promotion is a single API call with automatic DNS update, giving the best RTO/RPO among the options.

When the Lambda function's concurrency limit is reached, synchronous invocations from API Gateway are throttled. For proxy integrations, a throttled request is not immediately rejected—the Lambda service may wait for a free concurrency slot while API Gateway's 29-second integration timeout is already counting down; if no slot frees up in time, API Gateway drops the connection and returns a 504. This explains intermittent 504s even though a 5-second function would otherwise succeed, because the delay occurs before the function code ever runs.

Enabling CodeBuild local caching with the cache type LOCAL_DOCKER_LAYER_CACHE stores image layers in the build host's local Docker daemon after the first successful build. On subsequent builds, CodeBuild can reuse those locally cached layers instead of pulling them from Docker Hub, which cuts both external network calls and build time. This is the most direct way to reduce Docker Hub pull frequency for a standard container-image CI pipeline.

The CodeDeploy agent is a daemon installed on EC2 instances that handles deployment instructions, lifecycle events, and reporting instance status to the CodeDeploy service. Without a running agent, the service never receives a heartbeat or a success signal, so the instance is considered unhealthy and the deployment fails with an error like 'No healthy instances found'. This directly matches the symptom described, and verifying agent status with 'sudo service codedeploy-agent status' or checking /var/log/aws/codedeploy-agent/install.log is the first troubleshooting step. Installing or starting the agent on the tagged instances resolves the failure.

Correct. Amazon EventBridge captures Step Functions execution state changes (e.g., 'ExecutionStarted', 'TaskStateEntered', 'ExecutionFailed') in near real-time. These events can be used to build a CloudWatch dashboard that shows the current step, duration per step, and errors, meeting all requirements without custom instrumentation.

The correct approach is to enable the RDS MySQL slow query log by setting slow_query_log=1 and long_query_time in the DB parameter group, then configure RDS to stream those logs to a CloudWatch Logs log group. Once the log events are flowing, you create a CloudWatch Logs metric filter—patterned to match the slow query log format, such as lines containing 'Query_time'—to count matching events as a custom metric, and then set a CloudWatch alarm to trigger when the count exceeds a threshold.

Fluent Bit is a lightweight, high-throughput log processor that runs as a DaemonSet, placing one pod on every cluster node. It automatically discovers and collects container stdout/stderr logs without requiring application-side changes, making it effectively agentless for application teams. It supports multi-line log parsing and its native CloudWatch Logs output plugin streams logs directly to CloudWatch Logs for real-time aggregation. This is the recommended pattern for comprehensive logging on EKS.

This ensures even distribution across all instances in all AZs.

Placing tasks in multiple Availability Zones is a core high-availability strategy because each AZ is an isolated, independent failure domain. The ECS service scheduler spreads tasks across the chosen subnets, so when one AZ is impacted by an outage, the tasks in the other AZs continue serving traffic and the service can still meet its desired count. This addresses resilience by ensuring no single infrastructure failure can take down the entire service.

Instrumenting with the AWS X-Ray SDK is the correct approach because X-Ray traces individual requests as they traverse services, generating a trace ID that propagates across HTTP headers and AWS SDK client calls. The X-Ray console provides a service map and trace timelines, segment and subsegment views that break down latency for each downstream call, letting you pinpoint the exact service or resource causing the slowdown. You can also annotate traces with request metadata and set sampling rules to balance overhead and observability.

AWS CloudTrail records all CloudFormation management-plane API calls as event payloads, including the calling identity, request parameters, and timestamp. Amazon CloudWatch Events (now EventBridge) can consume those CloudTrail events using a rule that matches on source: aws.cloudformation and specific event names like UpdateStack or DeleteStack. That rule can then route the matched event to an SNS topic, producing immediate, precise notifications of who performed the stack operation and what operation occurred. This is the native, event-driven pattern for CloudFormation activity monitoring.

CodeBuild intentionally does not build pull requests from forked repositories unless you explicitly enable the 'Allow pull requests from forked repositories' setting in the project's webhook configuration. Fork PRs are considered untrusted because the entire buildspec, including install commands and environment variable injection, is controlled by the fork author—so CodeBuild requires an opt-in before it will fetch refs such as refs/pull/123/head or refs/pull/123/merge from a fork. When this setting is off, the source client cannot complete the git fetch for the fork PR, producing exactly the kind of git error being troubleshooted.

This is the correct approach because CodeCommit emits CloudWatch Events (EventBridge) on branch pushes, and a Lambda function can use the CodeCommit API to inspect the files changed in that push. The Lambda then maps a changed path prefix (e.g., 'services/order-service/') to the corresponding CodePipeline pipeline and calls StartPipelineExecution with the exact commit ID and branch. This provides path-based, per-service CI/CD while preserving the monorepo, and it only builds the microservice that actually changed, avoiding wasted compute and keeping feedback fast.

Patch Manager automates the entire patching process by using a patch baseline to define which patches are approved, when they are approved (e.g., after a test period expressed in days), and how those rules are applied to tagged instance groups. Maintenance windows schedule when the patching runs on test and production fleets, ensuring production patches are installed only after the baseline's approval delay lets the test fleet validate them. This combination provides automation, a testing gate, and controlled rollout windows, which directly satisfies the requirement.

For an IAM role to decrypt an object using a customer managed key, the KMS key policy must explicitly include the role (or an account principal with delegation) in a statement that allows kms:Decrypt. Even if the IAM role's permissions policy grants kms:Decrypt, KMS requires both the IAM policy and the key policy to authorize the action. If the key policy only allows a different principal or restricts access to specific roles, the decryption fails—this is the most direct cause of the error.

Setting up CloudWatch alarms on the Secrets Manager rotation Lambda function's failure metrics or on the RotationFailed event (via Amazon EventBridge and CloudTrail) is essential because rotation failures can occur silently without directly impacting the application. If a failure goes unnoticed, the secret may remain stale for an extended period; more critically, the Lambda might have created and stored a new version but failed to promote it to AWSCURRENT, leaving the database and Secrets Manager in an inconsistent state. An alarm ensures administrators are notified quickly to prevent both stale credential burnout and potential data-plane outages.

Combining a bucket policy in Account A that grants the IAM user ARN from Account B permissions on the target S3 bucket with an IAM user policy in Account B that approves the same actions is the standard method for cross-account S3 access. The bucket policy acts as the resource-based authorization, defining who can interact with the bucket and its objects; the IAM user policy acts as the identity-based authorization, allowing the user to invoke those S3 APIs. Without both explicit allows, the request is denied by AWS's default deny behavior.

The Execute Recipes feature in AWS OpsWorks Stacks allows you to run a specified recipe on selected instances immediately. This initiates an ad-hoc Chef run that pulls the latest cookbook from your configured source and executes the recipe's logic, directly applying the changes to the existing instances. It is the intended mechanism for manually applying cookbook updates without recreating or redeploying instances.

This design uses CodePipeline stages to gate flow: a stage with parallel unit-test actions runs the per-microservice unit suites concurrently, cutting total test wall-clock time, and the stage only completes when every action succeeds. The subsequent integration-test stage is serial relative to unit tests, so integration testing starts only after all unit suites are green, preserving deterministic dependency ordering while still exploiting parallelism where safe.

The RDS instance's security group must have an inbound rule that allows TCP traffic on the database port (e.g., 3306, 5432) from the security group ID attached to the CodeBuild project's elastic network interface. This is the standard way to permit traffic between AWS resources within a VPC, because security group rules reference other security groups as sources. The CodeBuild project must also be configured with VPC settings (VPC ID, subnets, and security groups) so its ENI is placed in the same network context as the RDS instance, enabling the security group-to-security group allow.

Setting AWS_DEFAULT_REGION in the CodeBuild project's environment configuration is the correct fix because CodeBuild injects all project-level environment variables into every phase of the build, making the value available to the AWS CLI, SDKs, and all build commands without any buildspec changes. This approach is explicit, portable, and aligns with AWS best practices for configuring tooling at the project level rather than relying on phase-scoped shell exports.

Amazon Inspector is a vulnerability management service that scans workloads for software vulnerabilities and unintended network exposure. Its CodePipeline integration uses the Inspector Scan action to automatically inspect container images stored in Amazon ECR during the pipeline, blocking deployment if critical findings are discovered. This catches CVE-level issues in dependencies and OS packages before release, making it a direct preventive control.

To download an object from an S3 bucket, the calling principal must be granted the s3:GetObject action. Without this permission, S3 returns an AccessDenied error even if other S3 actions like ListBucket or PutObject are allowed, so adding s3:GetObject is the minimal and correct fix for a build process that retrieves artifacts.

In a CloudFormation template, the Lambda function's Code property, when referencing an S3 bucket, can include the S3ObjectVersion attribute. Because CloudFormation treats any template property change as a stack update trigger, explicitly specifying the object version creates a new template value whenever the zip file in S3 is modified. Without this version, CloudFormation compares only the bucket and key, both of which stay constant, so it considers the resource unrmodified and skips the Lambda update—even if the S3 object's contents were replaced. Adding the S3ObjectVersion forces a resource replacement or update, making it the simplest and most direct way to ensure the stack updates on code changes.

CloudTrail Insights is the correct choice because it automatically applies machine learning to management events, including IAM AssumeRole, to establish a normal baseline and flag anomalous activity. It requires no manual filter definitions—you simply enable Insights on the trail, and it begins detecting unusual API call rates or error rates, logging them as separate Insights events. This is purpose-built for identifying abnormal role assumption patterns, such as an unexpected spike in AssumeRole calls or a new principal assuming roles outside its normal context.

AWS Systems Manager Run Command is a capability of AWS Systems Manager that lets you securely push commands to managed EC2 instances and on-premises machines without requiring SSH, RDP, or bastion hosts. The SSM Agent polls for commands, executes them, and can report status back, enabling admins to run scripts, install software, or change system settings across a fleet. Features such as tag-based targets, rate controls, and integration with IAM make it specifically designed for this kind of on-demand configuration activity.

For a private subnet to reach the internet via a NAT gateway, its route table must contain a route with a destination of 0.0.0.0/0 and a target of the NAT gateway's ID. This route tells the instance's traffic to be forwarded to the NAT gateway, which then performs source NAT using its Elastic IP. Without this specific route, the instance's outbound packets have no defined next hop to the internet, causing connectivity to fail.

Running a performance/load test stage (e.g., using AWS CodeBuild with Apache JMeter or Artillery against the deployed API endpoint) validates that the serverless application can sustain expected concurrency and throughput without exceeding Lambda concurrency limits or API Gateway throttling quotas. It catches issues like cold start latency, inadequate memory allocation, or downstream dependency bottlenecks that unit tests miss. In serverless, load tests also confirm that provisioned concurrency or auto-scaling behavior works as intended under spike traffic.

AWS CodeDeploy provides a native ECS deployment mechanism that can shift traffic from the old to the new task definition using blue/green or rolling configurations with an Application Load Balancer. In a CodePipeline-based CI/CD flow, this is the deployment action that makes the newly built image actually run on the ECS service, so it is essential to the pipeline.

The DependsOn attribute explicitly declares a dependency edge from the Lambda function back to the S3 bucket, forcing CloudFormation to wait until the bucket resource has reached CREATE_COMPLETE before it starts provisioning the Lambda function. This is the definitive way to guarantee creation order, especially when the function needs the bucket to exist for side effects such as populating an environment variable, writing to the bucket, or associating permissions, and no implicit dependency exists in the template. Unlike implicit references, DependsOn works even if the bucket is not directly referenced in any property of the Lambda function, making it the correct answer.

Calling PutMetricData with StorageResolution=1 creates a high-resolution custom metric with 1-second granularity, making the data available for CloudWatch alarms in as little as 10 seconds instead of the 60-second standard resolution. This lower storage resolution is the key to detecting critical issues faster because CloudWatch can evaluate alarms at a 10- or 30-second period. Without this parameter, your metrics default to 60-second resolution and alarm latency remains as high as a minute.

Amazon CloudWatch Alarms are the action engine that watches a single CloudWatch metric, a math expression, or an anomaly detection band over a specified time period, then transitions to an ALARM state when the observed value breaches a defined threshold. You can configure the alarm to publish to an SNS topic, trigger Auto Scaling, or execute an EC2 action such as a reboot when the anomaly condition persists. In this solution, the alarm consumes the band produced by CloudWatch Anomaly Detection and calls the monitoring hook when unusual metric behavior is detected.

Configuring the target group for HTTPS forces the ALB to negotiate a TLS session with each EC2 instance, so backend traffic is encrypted as well. Each instance must present a valid certificate that the ALB trusts, typically installed on the instance's web server or TLS terminator, to complete the handshake. This provides encryption in transit across both the client-to-ALB and ALB-to-instance segments.

Amazon EventBridge is a serverless event bus that can natively consume Auto Scaling group state changes such as EC2 instance launch, terminate, and lifecycle hook notifications. Using event patterns that filter on the aws.autoscaling source and detail types like EC2 Instance Launch Successful, EventBridge matches relevant events in near real time and routes them to targets such as SNS topics for email/SMS alerts. It is the correct service because it provides built-in event ingestion, filtering, and routing without requiring custom code or external monitoring agents, making it ideal for health and lifecycle monitoring.

The application reads the secret once at startup and holds it in memory, so after rotation the cached credentials no longer match the new RDS password, producing authentication failures. Refreshing the secret from Secrets Manager on each connection, or handling rotation-aware retrieval, resolves the connection errors.

An ALB returns 503 Service Unavailable when it cannot handle incoming requests due to scaling activity or when all targets are unhealthy. During a traffic surge, the ALB nodes scale up by provisioning additional capacity, and during this scaling activity the ALB may temporarily reject or fail to accept new requests, causing clients to receive 503 responses. This matches the scenario described, making it the correct explanation for the issue.

The correct remediation is to first raise the Lambda timeout to a value that comfortably covers the actual processing duration for a batch, then set the SQS visibility timeout to at least that same timeout so the queue does not redeliver a message while the function is still processing it. Adding a dead-letter queue to the source SQS provides a safety net: after the configured retries (maxReceiveCount), messages that still fail are diverted to the DLQ, preserving them for analysis instead of silently expiring. This combination directly resolves the timeout issue and handles residual failures cleanly.

CloudFormation is an infrastructure-as-code service that declares the entire serverless application stack, including the Lambda function, IAM role, event source mappings, and environment variables. Updating the stack applies code and configuration changes in a deterministic order and supports rollback on failure, making it a valid CI/CD deployment step. It treats the Lambda function as a managed resource, and can be invoked via CodePipeline or directly. This is a correct approach because it ensures drift-free, auditable releases.

Amazon EC2 Auto Scaling is the service that continuously monitors the health of EC2 instances using EC2 status checks and, when configured, Elastic Load Balancing health checks. If an instance fails these checks, Auto Scaling automatically terminates it and launches a replacement instance to maintain the desired or minimum fleet size. This health-based replacement is an inherent capability of an Auto Scaling group, making it the correct answer for automatically replacing unhealthy instances.

Configuring the source action with CodeCommit as the source provider and specifying the 'develop' branch is exactly how CodePipeline implements automatic change detection for a CodeCommit repository. The action references the repository and branch; on each update to that branch, CodePipeline uses an automatically managed CloudWatch Events rule (or event polling) to trigger a new pipeline execution. This is the recommended native integration, and it ensures every commit to the 'develop' branch starts the pipeline without custom webhooks or manual steps.

Using a dynamic stack name parameter, such as inserting the branch name into the stack name (e.g., `MyApp-${Branch}`), lets each branch deploy to a unique CloudFormation stack. This isolation prevents resource name collisions when multiple branches are deployed concurrently, supports per-branch rollback and lifecycle management, and eliminates the need to manually reconfigure the pipeline when a new branch is created.

Enabling S3 caching in a CodeBuild project stores the dependency cache (e.g., Maven's .m2, npm's node_modules, or Python's pip cache) in an Amazon S3 bucket between builds, so the build only downloads changed or missing packages instead of re-fetching the full dependency set each time. This directly reduces the time spent on network I/O, which is often the dominant cost for builds with many third-party libraries. By setting the 'cache' type to S3 and specifying a bucket, subsequent builds restore the cache at the start, making the compilation faster. This is the recommended approach because it targets the common bottleneck of dependency resolution.

A manual approval action in CodePipeline is a first-class, natively integrated gate that pauses the pipeline execution at a defined stage boundary (e.g., after build, before deploy). When the action runs, CodePipeline sends an SNS notification to the designated approver topic, and the execution remains in a Waiting state until an authorized user explicitly approves or rejects it via the console, CLI, or SDK. This is the intended AWS pattern for a human review gate because it is fully managed, has no custom polling logic, and automatically resumes the pipeline only upon approval — making it superior to any ad-hoc script or external approval mechanism.

Disabling sticky sessions on the ALB is a necessary precondition for a horizontally scalable, fault-tolerant design. With stickiness off, the ALB can route any request to any healthy target, so if an instance fails, the next request can be served by a different instance — assuming the session state is stored externally (for example, in ElastiCache or DynamoDB). This makes the application effectively stateless at the instance level, which also allows Auto Scaling to add or remove instances without worrying about breaking client sessions on a particular host.

The ECS task definition's memory limit is a hard limit enforced by Docker; when the container's memory utilization consistently exceeds 80%, it is likely approaching or hitting that ceiling, leading to OOM kills or severe performance degradation. Increasing the memory limit lets the container allocate more heap or working set, directly relieving the memory bottleneck. This is a vertical scaling action, and you must also ensure the EC2 instance has enough free memory to support the increased limit.

When a CloudFormation stack that contains an AWS::S3::Bucket with DeletionPolicy: Retain is deleted, the template's deletion intent is to leave that bucket in place. The bucket, including any objects and versions, remains in your AWS account and is no longer under CloudFormation's management. The stack itself shows DELETE_COMPLETE because CloudFormation treats the Retain policy as a successful completion of the resource deletion step, even though no physical deletion occurred.

The error message in the build log explicitly returns AccessDenied for the CreateInvalidation action, which means the IAM role assumed by CodeBuild does not include a statement allowing cloudfront:CreateInvalidation on the target distribution. Even though the role is correctly associated and used, it lacks this specific identity-based permission, so the aws cloudfront create-invalidation API call fails. This is an IAM policy gap, not a misconfiguration of the project or the distribution.

The ECS deployment circuit breaker is a native ECS feature that continuously monitors the health of a service deployment by watching for failed health checks, crashes, or task startup failures. If it detects that the new version is unhealthy, it automatically cancels the deployment and rolls back the service to the previous stable revision, without manual intervention. This makes it the only option that directly addresses deployment failures as part of the ECS service update path.

Automated integration tests that exercise real interactions between services (for example, using contract tests or a dedicated test environment) catch API mismatches, schema changes, and network configuration errors before production. By running these tests early in the CI/CD pipeline, you shift left defect detection, reduce the cost of fixes, and increase confidence that independently deployed services will interoperate correctly.

Modifying the RDS instance to a larger instance class is the correct immediate response because it directly adds vCPU, memory, and often dedicated EBS bandwidth to handle the current workload. Amazon RDS supports scaling instance classes with minimal downtime, especially for Multi-AZ deployments where a failover masks the restart. This scale-up action provides the compute headroom needed to bring CPU utilization back to acceptable levels and is the standard first step when a CPU alarm indicates that the instance is simply undersized for the traffic.

Enabling S3 Versioning is the correct first-line protection because it retains every version of an object, including the original, whenever an overwrite (PUT) or delete (DELETE) occurs. With versioning, an overwritten object's previous version is preserved as a non-current version, and a DELETE action only inserts a deletemarker, leaving all prior versions intact. You can recover accidental changes by simply fetching a previous version, making it the foundational mechanism that enables other features like lifecycle rules, MFA Delete, and point-in-time restores.

Change sets provide an itemized, read-only prediction of the exact modifications CloudFormation will apply to a stack when an updated template or parameter set is executed, listing each resource as being added, removed, or replaced without actually altering the stack. They are generated by calling CreateChangeSet, allowing the team to inspect the impact in a CI/CD pipeline and then explicitly execute the change set only after human approval. This makes change sets the correct mechanism for implementing a controlled pre-update review and approval workflow.

With a 5-minute period, 3 evaluation periods, and 3 datapoints to alarm, the alarm enters ALARM state only when every one of the three most recent 5-minute data points breaches the threshold. This means the metric must be continuously in breach for 15 minutes, filtering out transient spikes and providing a reliable signal of a sustained problem. It is the appropriate setting for production alarms that should page responders only after a consistent degradation.

A 503 response from the ALB health check means the target instance accepted the TCP connection and returned an HTTP response, but the response status code was not a success (2xx/3xx). If the health check path is '/health' and the application does not define that route, the web server returns a 503 error because no handler matches the request. To resolve this, the health check path must be changed to an existing endpoint or the application must implement an endpoint that returns 200 OK on '/health'.

KMS key policies are resource-based policies attached directly to the customer master key, and they are evaluated for every KMS API action against that key. The policy can include a Condition block that references SAML-derived session attributes, such as a session tag mapped from an attribute in the SAML assertion, to allow kms:Decrypt only when the expected attribute value is present. This is the correct approach because it centralizes the decryption restriction at the key resource itself, ensuring that any principal attempting to use the key must satisfy the condition regardless of their IAM permissions.

A service role is an IAM role that CloudFormation assumes to make API calls on your behalf when creating, updating, or deleting stacks. By specifying a service role with least privilege, you ensure CloudFormation only has the permissions required to provision the intended resources, limiting the impact if a resource definition is malicious or misconfigured. This also enables separation of duties because users can create stacks without holding direct resource permissions, and all actions are attributed to the service role.

Increasing the rate-based rule's threshold is the appropriate response because the rule currently flags legitimate traffic when it should only block genuinely anomalous request floods. AWS WAF rate-based rules count requests that match a rule's conditions from a single source IP over a 1- or 5-minute evaluation window; if your legitimate users share an office IP or traverse a NAT gateway, their aggregate requests can exceed a threshold set too close to peak traffic. By raising the threshold above your historical maximum legitimate request volume per IP, you preserve protection against distributed or bot-driven floods while eliminating false positives from normal usage spikes.

ALB access logs record per-request target status, target IP and timing, so filtering 503s reveals whether targets returned errors or the load balancer itself failed. This directly correlates the ELB 5XX spike with backend latency, satisfying the stem's need to identify the failing tier first.

AWS CodeCommit is a fully managed source-control service that hosts private Git repositories, supporting branches, commits, pull requests, and merge operations with IAM-based access control. It matches the description of a source-control service because it is the central repository where developers store, version, and collaborate on code. Its native Git compatibility and tight AWS integration enable seamless use with other DevOps services, but its core identity is version control, not building or deploying.

Latency-based routing policy uses AWS-measured round-trip time data to direct each user to the endpoint that offers the fastest response, and it supports health checks on each record. When the primary endpoint fails its health check, Route 53 automatically selects the next lowest-latency healthy endpoint, providing seamless active-passive failover without manual intervention. This combination of performance optimization and health-aware failover makes it the correct choice for an application with multiple regional endpoints.

AWS CloudTrail is the principal service that logs all management, data, and insight API calls across an AWS account, capturing identity, request context, and response details. It is correct for this scenario because you need API-call logging, but to make the resulting log files truly tamper-proof you must configure CloudTrail to deliver them to an S3 bucket with Object Lock enabled. CloudTrail also supports log file integrity validation, yet that only detects tampering, whereas Object Lock prevents it.

Using a customer-managed KMS key with a cross-account key policy is correct because CodePipeline stores build artifacts in S3, which must be encrypted. By default, AWS-managed keys are scoped to a single account, so to share artifacts with a target account you must use a customer-managed key and explicitly grant the target account's principals decrypt permission via a cross-account key policy. This provides secure, auditable cross-account artifact transfer without exposing the key material, and it lets you enforce encryption at rest with full control over key rotation and access.

Conditional writes enable optimistic concurrency by allowing the application to assert a precondition—such as an item version or updated timestamp—before the write commits. If the condition evaluates to false because another concurrent write modified the item, DynamoDB rejects the request without overwriting, forcing the application to re-read and retry. This prevents silent data loss from last-writer-wins and is the appropriate DynamoDB-native way to enforce a safe update workflow in a multi-region setup.

The correct approach uses a parameterized AWS CloudFormation template that defines a complete CodePipeline (source, build, deploy) for a given repository, and combines it with an EventBridge rule that detects the `CreateRepository` API call from CodeCommit (via CloudTrail) and triggers a Lambda function. That Lambda function validates the input and invokes `CreateStack` (or `UpdateStack`) with the repository name as a parameter, automatically provisioning a dedicated pipeline for each new microservice as soon as the repo is created. This delivers event-driven, infrastructure-as-code automation, ensuring every pipeline is identical, versioned, and created without human interaction, thereby meeting the scalability and consistency goals of the team.

The CloudWatch Embedded Metric Format encodes custom metric values inside a structured JSON log event; when the Fargate task's awslogs driver sends that log to CloudWatch Logs, CloudWatch automatically extracts the declared metrics into the specified namespace for graphing and alarms. This requires no separate daemon, sidecar, or SDK call—developers only add a serialization layer to application logging, making it the minimal-code path you asked for.

This is correct because an HTTP request sets the aws:SecureTransport context key to false, and the Deny statement is scoped to exactly that condition. The policy likely contains an Allow for the S3 action on the folder, but the explicit Deny for non-secure transport takes precedence under AWS's evaluation logic. As a result, the user's GET request over HTTP is denied, while the same request sent over HTTPS would be allowed if the other permissions match.

Fargate task-level CPU and memory metrics in CloudWatch reveal resource exhaustion causing task stops; raising the task definition's CPU and memory values gives tasks sufficient headroom, directly addressing the suspected exhaustion constraint and preventing recurrence.