AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 151–225

Performance Insights exposes the DBLoad metric, which represents the average number of active sessions and directly reflects query execution workload, and it can be streamed to CloudWatch for alarm creation. Per-query execution time is visible through the top SQL dashboard, allowing you to correlate load spikes with specific queries. The basic retention is included with RDS at no additional cost, making this a cost-effective and fully managed solution for monitoring query performance.

A CodePipeline that deploys CloudFormation stacks can include a manual approval stage, which acts as a preventive control that pauses the pipeline before the stack update executes. The pipeline can detect when a change set modifies IAM resources—for example, by comparing the template or reviewing the change set—and conditionally require an approval step. This ensures a second person reviews the IAM changes before they are applied, satisfying the separation-of-duties requirement. Manual approval is a standard AWS pattern for production governance and is far more effective than post-hoc detection or MFA alone.

IAM is a customer-controlled service: customers define users, groups, roles, policies, and permission boundaries, and they are accountable for the identity and access management decisions they implement. AWS provides the IAM service itself and keeps its control plane available, but it does not create, modify, or assume customer identities or make authorization decisions on the customer's behalf. Correctly scoping least-privilege IAM policies, enabling multi-factor authentication, and rotating credentials are customer responsibilities that directly impact the security of everything deployed in the account.

The `Deploy` stage action stores a literal `DeploymentGroupName` string that must exactly match the name of an existing deployment group in the target CodeDeploy application. This string is case-sensitive and cannot include trailing spaces or a mangled formatted name. When CodeDeploy receives the pipeline's `CreateDeployment` API call, it validates the deployment group against the application in the region; if no exact match exists, it returns the 'Deployment group not found' error. To resolve it, open the pipeline's Deploy stage action and compare the `DeploymentGroupName` value to the deployment group name shown in the CodeDeploy console.

An EventBridge rule can match event patterns against CloudTrail records, for example source 'aws.ec2', detail-type 'AWS API Call via CloudTrail', and eventName 'RunInstances'. When a matching API call occurs, EventBridge invokes an SNS topic in near real time, and the event payload contains instance IDs, user identity, request parameters, and response elements. This is the native AWS event-driven pattern for reacting to EC2 API activity.

Lambda automatically emits a set of standard metrics to CloudWatch, including 'Invocations', 'Errors', and 'ErrorCount' (via enhanced metrics if enabled), so you can directly build an error-rate expression without additional setup. The correct approach is to use a CloudWatch math expression, such as 'm1/m2*100' where m1 is ErrorCount and m2 is Invocations, and then create an alarm on that expression to alert when the error rate exceeds a threshold. This leverages the native, low-latency monitoring pipeline and avoids the overhead of log-based or third-party tooling, making it the simplest and most operationally sound solution.

The net effective policy is that only clients with source IP addresses in 192.0.2.0/24 are permitted to read objects. The Allow statement grants s3:GetObject to Principal "*", but the Deny statement with NotIpAddress of that range blocks all other source IPs; because explicit deny overrides allow, the condition on the deny becomes the controlling factor. This creates a whitelist: any request not coming from 192.0.2.0/24, even an authenticated AWS identity, is denied, while any request from that range, including anonymous users, is allowed.

The bucket policy uses a condition key such as s3:x-amz-acl with a value of bucket-owner-full-control, making that header a mandatory requirement for any successful s3:PutObject call. When the requester omits the x-amz-acl header, the condition evaluates to false, so the allow statement cannot grant the action. With no other applicable allow, the request is implicitly denied and the upload fails. This design ensures the bucket owner can later manage or delete the object by forcing ownership transfer via the canned ACL.

Correct — the policy's Condition uses StringEquals to require the s3:x-amz-acl value of bucket-owner-full-control on every PutObject request. When the user's PutObject request does not specify that exact ACL (either omits the x-amz-acl header or sets it to another value), the condition evaluates false. IAM authorization is deny-by-default: without an explicitly matching allow statement, the request is implicitly denied, producing the denied message. The user must include x-amz-acl: bucket-owner-full-control, or the policy must be adjusted if that enforcement is not desired.

CloudFormation assumes the IAM permissions of the calling user when provisioning resources from a template. To launch an EC2 instance, ec2:RunInstances is required, and to create an S3 bucket, s3:CreateBucket is required, because those are the specific API calls CloudFormation makes on your behalf. Without these actions, stack creation will fail even if other permissions are present.

Publishing CloudWatch alarms to an SNS topic and applying subscription filter policies is a valid approach because SNS supports content-based filtering on message attributes. When an alarm transitions to ALARM state, it publishes a message with attributes like `state` and `severity`; each subscriber can define filter policies that match only their desired subset (e.g., `state = ALARM` with high severity). This effectively routes critical notifications to the right team while suppressing non-critical messages at the subscription level, without altering the alarm logic itself.

Creating a separate pipeline per allowed branch makes the pipeline definition itself the security boundary. Only branches that have an explicitly defined pipeline can ever proceed through the release stages, so committing to an unauthorized branch simply does not trigger a deployment even if the code is structurally valid. The production pipeline includes a manual approval step, and because that pipeline sources solely from an approved branch (e.g., main), the approval verifies the intended deployable artifact rather than attempting to check a branch name at runtime. This isolation prevents accidental or malicious deployment from unapproved branches without relying on inline validation or easily modified Lambda actions.

Custom Chef recipes associated with lifecycle events are the correct mechanism for configuration management in AWS OpsWorks. OpsWorks defines five lifecycle events—Setup, Configure, Deploy, Undeploy, and Shutdown—and you can assign custom Chef recipes to run at each stage. For example, a Setup recipe can install packages and configure software, while a Deploy recipe can deploy application code. This is the native, fully integrated way to manage configurations in OpsWorks.

The Lambda service enforces a configurable timeout that caps how long a single invocation can run, with a default of 3 seconds. If the function calls a downstream HTTP endpoint that is slower than the remaining execution time, the runtime terminates the invocation and returns a timeout error to the caller. Raising the timeout to 30 seconds grants the HTTP request enough time to return a response, directly resolving the symptom described in the troubleshooting scenario.

An IAM role attached to the CodeBuild project supplies temporary credentials scoped to the required S3 read permissions, avoiding long-lived access keys stored in buildspec or environment variables. This satisfies least-privilege access to the private bucket.

The 'Rate exceeded' error is the exact textual representation of AWS API throttling, meaning the CloudFormation service is rejecting requests because the account's API request rate for that region has exceeded its allowed quota. This often occurs during CodePipeline deployments when multiple stages run large numbers of changeset creation, update, and describe calls concurrently, or when other automation is hammering the same CloudFormation API. The correct fix is to request a service quota increase for the CloudFormation API via Service Quotas or AWS Support, and also implement exponential backoff in the calling code to handle transient throttle responses while the increase is pending.

AWS OpsWorks for Chef Automate instances assume an IAM instance profile, and the chef-client uses those temporary credentials to fetch cookbooks and other artifacts from the configured S3 bucket. Without s3:GetObject (and often s3:ListBucket) permissions scoped to that bucket's path, the cookbook download fails, which prevents the recipe from executing. Granting the instance profile the necessary S3 read permissions directly resolves the issue, making this the correct remediation.

Replicating application data in real time to an Amazon EBS volume gives you a persistent, network-attached copy that survives the EC2 instance's lifecycle. EBS volumes are independently replicated within an Availability Zone, so they remain available if the instance is stopped or terminated. Taking periodic EBS snapshots copies the volume to Amazon S3, providing point-in-time recovery points that can be restored in the same or a different Availability Zone, which protects against both instance failure and EBS volume loss.

`terraform force-unlock <LOCK_ID>` is the designed recovery mechanism for stale or stuck locks, and it directly interacts with the backend's locking system to remove the lock item while preserving the integrity of the state file. This command requires the exact lock ID from the error message and is safe when the previous operation is truly no longer running; it is the recommended alternative to manual DynamoDB edits or destructive state file actions.

Launching the RDS instance in a private subnet that has no route to an internet gateway prevents any direct inbound connection from the public internet, including attempts to exploit database vulnerabilities. Only resources inside the VPC, such as application servers in private subnets or a bastion host, can reach the database, and those connections can be further restricted by security groups and NACLs. This is a core network security control that reduces the attack surface and is a mandatory requirement for many compliance frameworks.

This approach leverages CodePipeline's ability to trigger on all branches and dynamically create CloudFormation stacks per branch using the branch name as part of the stack name. A Lambda function triggered by CodeCommit branch deletion events can delete the corresponding stack. This automates stack lifecycle management with minimal overhead, as the pipeline and Lambda handle creation and deletion. It provides isolation and scalability across branches.

Configure CodeBuild with cache.type set to S3 and specify an S3 bucket as cache.location, then declare the Java dependency directory (e.g., /root/.m2 for Maven) in the buildspec cache.paths. This creates a persistent, shared cache that is uploaded at the end of each build and downloaded at the start of the next, so dependencies are fetched from S3 instead of being downloaded one-by-one from public repositories on every run. By keying the cache appropriately (e.g., including a hash of the buildspec or source), you retain a valid cache while invalidating it when dependencies or build parameters change.

RDS Proxy sits between your application and the database, exposing a fixed writer endpoint that masks the underlying instance DNS changes. When a Multi-AZ failover occurs, RDS Proxy automatically redirects existing connections to the new primary, which eliminates the delay caused by clients waiting for DNS TTL to expire. It also pools and reuses database connections, reducing connection-related errors during failover and lowering CPU/memory pressure on the database. This is exactly why it reduces DNS dependency and delivers failover times typically under one second.

Enabling scan on push only initiates the scan; the pipeline must actively retrieve the results. Calling DescribeImageScanFindings returns the severity counts and individual findings, allowing the pipeline to evaluate them and fail when CRITICAL findings exist. This directly satisfies the requirement to block deployment based on critical vulnerabilities.

Auto Scaling groups have a built-in notification feature that publishes messages to an SNS topic on lifecycle events like ec2-instance-launch and ec2-instance-terminate. This provides immediate, event-driven delivery of the instance ID, the Auto Scaling group name, and the event type to all subscribers (email, SMS, Lambda, HTTP endpoints). It is the simplest native way to receive real-time notifications for the exact scaling actions the company cares about.

Using the NoEcho property on a CloudFormation parameter is a valid best practice because it masks the parameter's value from the AWS Management Console, API responses, and stack outputs, preventing casual exposure during template operations. However, it does not encrypt the value or prevent the resource that receives the parameter from exposing it, so it should be combined with external secret stores. NoEcho is appropriate when a secret must be passed as a stack parameter, but the secret itself should never be embedded in the template or committed to version control.

A Service Control Policy (SCP) applied at the organization root or an organizational unit is the correct mechanism because it acts as a permission boundary that all IAM principals—including the account root user—cannot override. By explicitly denying cloudtrail:DeleteTrail and cloudtrail:StopLogging, the SCP ensures that even a full account administrator cannot disable the trail or stop event delivery. Since member account admins lack permission to modify or detach SCPs, this provides an immutable, centralized control that persists regardless of individual account settings.

RDS Multi-AZ maintains a synchronous standby in a different Availability Zone, so when the primary in us-east-1a fails, the standby in us-east-1b is promoted automatically and the DB instance's CNAME endpoint is repointed to it. This satisfies the stem's automatic failover requirement without manual intervention.

CodeDeploy is the AWS-native service designed for controlled software rollouts, and its canary deployment configuration is fully supported as a CodePipeline deploy action. For example, a configuration like Canary10Percent5Minutes shifts 10% of traffic to the new task set or instance fleet, waits five minutes, then shifts the remaining 90%, while monitoring health via lifecycle hooks. Because CodeDeploy owns the traffic-shifting logic, it automatically detects failures, stops the deployment, and can roll back to the previous version. This directly satisfies the requirement for a built-in canary strategy in the Deploy to Prod stage with no custom scripting.

Enabling AWS KMS encryption for the Lambda function's environment variables with a customer-managed key directly protects the sensitive values at rest. When you configure this, Lambda uses the selected customer master key to encrypt the environment-variable payload before storing it as part of the function configuration. This replaces the default aws/lambda managed key, giving you independent control, rotation, and audit trails through CloudTrail for encryption and decryption operations.

The CloudFormation stack referenced by the CodePipeline deploy action already exists and remains in a failed state (e.g., ROLLBACK_COMPLETE, UPDATE_ROLLBACK_COMPLETE, or CREATE_FAILED). CloudFormation refuses to perform an update on a stack that has not successfully reached a stable state (CREATE_COMPLETE or UPDATE_COMPLETE), so the deploy action fails immediately. A failed stack must be deleted (if resource policy allows) or updated/remediated using a change set to move it back to a stable, updatable state before CodePipeline can retry.

Exporting the VPC and subnet IDs from the network stack via the 'Export' field and importing them into the application stack with Fn::ImportValue establishes a native CloudFormation cross-stack reference within the same account and region. This creates an explicit dependency between the stacks, ensuring the network stack is created before the application stack and that the latest exported values are resolved at stack operation time. It avoids hardcoding by letting CloudFormation manage the wiring, and it supports updates and reuse across multiple dependent stacks. This is the intended, first-class mechanism for sharing outputs between independent CloudFormation stacks.

CloudFormation natively supports an SNS topic as a stack notification option: when you specify an SNS topic ARN in the stack's NotificationARNs property, CloudFormation publishes every stack event—such as CREATE_FAILED and ROLLBACK_COMPLETE—to that topic. Subscribing an email endpoint to the topic delivers these events in near real time, giving operations teams immediate insight into resource limit failures or any other stack error. This is the only answer that directly leverages CloudFormation's built-in notification channel without needing extra services to infer failure.

The appspec.yml file controls the order and content of lifecycle events such as ApplicationStop, BeforeInstall, and AfterInstall. If the file is malformed, references a nonexistent script, or a referenced hook script exits with a non-zero status, CodeDeploy treats that instance as failed and reports 'ScriptFailed' or 'InvalidLifecycleEventName'. Because the deployment reaches the script execution stage and then errors, the appspec definition and its scripts are the most direct cause.

AWS CloudTrail is the primary service that records all API activity in an AWS account, capturing the identity, time, source IP, and request parameters for every call. Enabling CloudTrail across all regions and using events to build a baseline of expected behavior lets security teams flag anomalies such as unusual IAM roles, foreign IP addresses, or credential changes. It is the foundational data source for API-level anomaly detection, and its Insights feature can automatically identify unusual API patterns like mass resource deletion or unusual access timing.

An Amazon SNS topic acts as the delivery channel for CloudWatch alarm actions. By creating a topic, subscribing the team's email address, and confirming the subscription, the alarm can publish messages to that topic whenever it transitions to the ALARM state. This is the standard method to send email notifications and is a required component for the team to be alerted. Without this, the alarm would only change state and not proactively reach the team.

Amazon EventBridge is the native event router for CloudTrail API activity: CloudTrail automatically delivers every call to an event bus, and a rule with a JSON pattern can match the specific API (e.g., an unauthorized or sensitive call). The rule immediately invokes an Amazon SNS topic, which then fans out notifications via email, SMS, or other subscribers. This event-driven flow provides sub-second, real-time alerts with no polling, no custom code, and direct integration, making it the correct architecture.

Although CodePipeline updates the S3 origin with the new static files, CloudFront edge locations continue to serve stale content until the cache TTL expires or an explicit invalidation is submitted. A CloudFront distribution does not automatically detect origin content changes; it caches objects based on the Cache-Control/Expires headers. Without creating an invalidation for '/*' (or for the changed paths) after the deployment, users will still see the previous version of the website, which matches the reported symptom. This is the only option that explains outdated content being served while the pipeline itself succeeds.

A CodeCommit trigger configured for push events can launch a Lambda function that inspects the incoming commits's metadata and calculates the size of each file. While native triggers are asynchronous, the Lambda can quickly delete the offending branch reference or tag, effectively rejecting the large-file push from a server-side governance perspective. This is the only option that applies custom validation logic that actually sees file content and can act to block the push, unlike IAM conditions, which cannot inspect Git payloads, or pre-receive hooks, which CodeCommit does not support.

Spreading instances across two or more Availability Zones ensures the application survives an AZ outage, since the Application Load Balancer routes to healthy targets in remaining zones. This directly satisfies the resilience requirement for the stateless workload.

`npm install` reads the `dependencies` and `devDependencies` fields in `package.json` and installs exactly the packages listed there. If lodash is not specified in that file, it will not be installed, and any subsequent `require('lodash')` or `import ... from 'lodash'` will throw `MODULE_NOT_FOUND`. A missing `package.json` would cause `npm install` to fail outright, but either way, the root cause is that lodash was not properly declared as a dependency.

The correct approach is to leverage CodeDeploy's rollback capability: configure the deployment group to automatically roll back on deployment failure (or on a CloudWatch alarm), which causes CodeDeploy to track the last known good revision. Triggering the rollback—either through the console's rollback action or by redeploying the previous successful revision—makes CodeDeploy deploy that good revision to the green fleet and shift traffic back to the original blue environment, restoring the known-good service. This is the only option that actively reverses the faulty deployment and restores live traffic, rather than merely affecting future instances or repeating the defect.

CloudFormation modules are reusable building blocks that encapsulate resource definitions and can be included in templates via the AWS::CloudFormation::Module resource type. They support parameters and can be versioned and shared across teams, exactly matching the requirement. Modules simplify template maintenance by abstracting complexity and promoting consistency.

With the AllAtOnce deployment configuration, CodeDeploy targets every instance in the deployment group simultaneously, but if a failure occurs partway through, the deployment stops without rolling back unless you explicitly enabled automatic rollback. Instances that already received and ran the new revision keep it, while instances that were not yet updated remain on the old revision, yielding a mixed state across the fleet. This is exactly the situation that would leave some instances running the previous version and others running the new version.

Amazon Managed Service for Prometheus is a scalable, fully managed service compatible with Prometheus query language (PromQL) and remote write. It eliminates the operational overhead of running Prometheus at scale, provides durable storage, and integrates with Amazon Managed Grafana for dashboards. This is the recommended AWS-native approach for long-term metrics retention on EKS.

S3 Standard is the default storage class and is engineered to deliver 99.999999999% object durability and 99.99% availability by synchronously storing each object across a minimum of three Availability Zones (AZs) within the same AWS Region. When an AZ becomes unavailable, S3 automatically serves requests from the remaining copies, so the bucket stays accessible without manual intervention. Because the data exists in at least three independent AZs, a single AZ failure does not cause data loss or downtime, making it the appropriate choice for resilience against an AZ disruption.

Attaching an IAM execution role with a least-privilege policy that allows secretsmanager:GetSecretValue on the specific secret ARN is the recommended pattern because it keeps the secret out of the function configuration and gives you native rotation, versioning, and CloudTrail audit events. If the secret is encrypted with a customer-managed KMS key, you must also grant kms:Decrypt on that key, but the default AWS-managed key used by Secrets Manager requires no additional KMS action. This lets the function call GetSecretValue at runtime and parse the returned JSON string without exposing the raw secret in environment variables or source code.

The SCP only denies the iam:CreateUser action, which means it does not restrict the engineer's ability to create IAM roles. IAM role creation is governed by the iam:CreateRole permission, which is not covered by the SCP's deny statement. As a result, the engineer can create a new administrative role, attach a permissive policy to it, and assume that role to bypass the intended restrictions and achieve privilege escalation.

The aws:ViaAWSService global condition key is true when an AWS service, such as Systems Manager, makes the API call on the principal's behalf rather than the principal making a direct call. The policy's condition requires this key to be false, so when the tool is invoked via Systems Manager the actual value is true and the Allow statement does not match. With no other matching Allow, the request is implicitly denied, which is exactly the error observed.

AWS Config rules evaluate the recorded configuration of AWS resources against the desired policy logic you define in a rule. A rule can be AWS-managed (e.g., requiring S3 buckets to be encrypted) or custom (via Lambda), and it runs on a change-triggered or periodic schedule to identify noncompliant resources. When a resource deviates from the policy, AWS Config flags it as noncompliant and can trigger remediation actions, making it a continuous drift-detection and compliance-audit service.

CodeDeploy deployment logs capture lifecycle event hook failures, invalid scripts, and resource timing issues during deployment (e.g., BeforeInstall/AfterInstall failures) that can leave instances in a degraded state causing performance hits. Any failed or aborted deployment step may cause new instances to be registered with incomplete configuration, leading to CPU/memory pressure or misrouted traffic. Scrutinizing these logs pinpoints whether the performance spike correlates with deployment execution timeouts, file overwrite errors, or instance registration failures.

Implementing DynamoDB Accelerator (DAX) is correct because it puts a write-through, in-memory cache directly in front of your DynamoDB table. DAX intercepts repeated read requests—such as product details, pricing, or inventory views during a sale—and serves them in microseconds, dramatically reducing the read capacity units consumed by the table. This offloading lowers the chance of throttling your primary table while keeping latency low for read-heavy traffic.

When CloudFormation returns an error that an account limit has been reached, it means the AWS resource API rejected the creation request due to service quota exhaustion for that resource type in the current region. You should use the Service Quotas console or AWS Support to check the current limit and request an increase, then wait for approval before retrying the stack creation. This directly resolves the root cause without modifying the template or IAM role.

Enabling access logs on the Application Load Balancer is the foundational step; it delivers a raw, per-request log file containing the client IP, request URI, User-Agent, and HTTP status code for every request handled by the ALB. These logs are written in gzip-compressed files to an S3 bucket you specify, and S3 provides durable, queryable storage. Without this first step, no HTTP-level transaction data exists in S3, making any subsequent log analysis or querying impossible. This is why enabling ALB access logs is the correct primary action.

Container Insights automatically collects CPU, memory, network, and log data from EKS nodes and pods without installing custom agents beyond the CloudWatch agent DaemonSet. CloudWatch alarms evaluate the CPUUtilization metric over 5-minute periods, and CloudWatch dashboards can display both metrics and log insights queries together, satisfying the monitoring and alerting needs with minimal operational effort.

An instance profile supplies temporary AWS credentials to the EC2 instance via the instance metadata service, and the attached IAM role's policy can be scoped to the exact bucket and the required actions. This provides least-privilege access, ensuring the instances can read and write only that bucket without long-lived keys or additional service permissions. Because IAM policies explicitly identify the resource (the bucket ARN) and the actions, no other AWS service or bucket is accessible unless separately allowed.

AWS CloudFormation is the correct choice because it is a declarative Infrastructure as Code (IaC) service that can directly model and provision AWS resources, including AWS CodeCommit repositories. You define a repository in a CloudFormation template using the AWS::CodeCommit::Repository resource type, specifying properties such as RepositoryName and Code, and CloudFormation will create, update, and delete the repository as part of stack lifecycle management, making it ideal for automating resource creation.

RDS Multi-AZ only synchronously replicates to a standby in the same Region, so it cannot protect against a regional outage. Amazon Aurora Global Database replicates data to up to five secondary Regions using storage-level replication, typically with an RPO of 1 second or less, while still providing a familiar MySQL/PostgreSQL-compatible endpoint. Promoting a secondary Region during failover is a fast, deliberate action that preserves the database's durability and availability in a disaster recovery scenario.

Amazon Route 53 health checks monitor the primary endpoint (e.g., an Application Load Balancer or an IP address) and automatically detect when it becomes unhealthy. With failover routing, Route 53 stops returning the primary resource's DNS answer and instead returns the DR region's endpoint, effectively steering user traffic within minutes. This directly supports the RTO by eliminating the need for manual DNS changes, and it works with any application architecture as long as the endpoint can be health-checked. However, Route 53 only handles traffic redirection—it does not replicate data or pre-warm compute, so it must be paired with a data replication strategy to also meet the RPO.

A change set is a read-only summary of the exact modifications CloudFormation will make to the stack when you execute it, including resource type add/remove/replace and whether the change is dynamically applied or requires no interruption. You can create and inspect multiple change sets from different template versions without touching live infrastructure, then deliberately execute the approved one—only execution applies the update. This gives you the review-before-apply gate that the requirement asks for, as the change set is the proposed changes themselves rather than a policy or detection signal.

Amazon CloudWatch natively ingests Amazon RDS performance metrics—including CPU utilization, freeable memory, database connections, read/write IOPS, and replica lag—through the AWS/RDS metric namespace. These metrics are published automatically and can be visualized in CloudWatch dashboards or used to trigger alarms for proactive alerting and auto scaling actions. CloudWatch also supports publishing custom metrics and streaming RDS logs, making it the comprehensive monitoring service for RDS PostgreSQL.

Pre-installing the CodeDeploy agent in a custom AMI (or bootstrapping it via user-data at instance launch) ensures the agent is running before the instance ever joins a deployment group. Because the agent is already present, CodeDeploy's deployment workflow can immediately begin pulling the AppSpec file and application revision from Amazon S3 or GitHub without waiting for an installation step. This proactive approach also avoids the time-of-installation risk where a deployment starts before a scripted agent installation completes, and it minimizes the chance of an instance being skipped or failing due to a missing agent.

The access denied error indicates the build's AWS credentials lack permission for ECR push operations. Granting ecr:InitiateLayerUpload along with the related push actions such as ecr:PutImage and ecr:UploadLayerPart on the specific repository authorizes the docker push and directly resolves the failure.

Enabling ALB access logs to be delivered to Amazon S3 creates immutable, row-based log files that are ideal for large-scale retrospective analysis. Amazon Athena lets you run standard SQL directly on that S3 data using a serverless engine that charges only for the bytes scanned, and you can further optimize costs and performance by partitioning S3 objects by date or using compression. This combination is the industry-standard cost-effective approach when the goal is to perform flexible SQL queries over historical ALB logs without pre-provisioning infrastructure or paying for continuous ingestion.

Amazon CloudWatch Alarms are the correct choice because they continuously monitor a specified CloudWatch metric—such as ApproximateNumberOfMessagesVisible for an SQS queue—against a defined threshold over a configured period. When the metric crosses the threshold, the alarm changes state (OK, ALARM, or INSUFFICIENT_DATA) and can trigger an action like an SNS notification, EC2 Auto Scaling, or an arbitrary EC2 stop/terminate action. This provides the exact metric-threshold monitoring required.

Amazon CloudWatch Alarms are the correct service because they directly evaluate CloudWatch metrics, and CPUUtilization is a built-in metric emitted by EC2 instances. You can configure an alarm to transition to an ALARM state when the average CPU utilization exceeds a threshold, and then trigger actions like Auto Scaling, Amazon SNS notifications, or EC2 actions (reboot, stop, terminate). Alarm evaluation periods and statistic types (e.g., average, maximum) allow precise control over when an alarm fires, making it the natural choice for CPU monitoring.

The correct approach is to declare the Elastic Beanstalk environment directly in your CloudFormation template with the AWS::ElasticBeanstalk::Environment resource. This native resource supports properties such as ApplicationName, SolutionStackName or PlatformArn, OptionSettings, and Tags, allowing CloudFormation to create and manage the environment as part of the stack. It integrates cleanly with other stack resources and avoids custom code or workarounds.

Amazon S3 is a fully supported source action in AWS CodePipeline. You can store a single zip file or a set of files in an S3 bucket, and CodePipeline detects changes when the object version changes or via Amazon CloudWatch Events. The bucket must have versioning enabled so that each upload creates a new source artifact, which is then downloaded and extracted in the Source stage for subsequent build and deploy actions.

A service control policy (SCP) attached at the Organizations root is a preventive guardrail that applies to every account in the organization, including accounts created later. By using the s3:x-amz-server-side-encryption condition key with values AES256 or aws:kms, you can deny any PutBucketEncryption call that attempts to use a different encryption type, such as SSE-C or no encryption. This works because SCPs filter permitted API actions before they reach IAM, and they cannot be overridden by account administrators, making them the correct way to enforce encryption settings organization-wide.

CloudFormation stack tags are specified on the stack and automatically propagated to every resource in the stack that supports tagging. Because CloudFormation applies these tags to resources during the CREATE or UPDATE operation, resources are born with the required tags, eliminating the need for a post-creation remediation step. This provides a native, preventive control that works without requiring any custom Lambda functions or additional configuration.

SAM is the only option that natively pairs with CodePipeline for serverless deployments: the pipeline can run `sam build` and `sam package` in a CodeBuild stage, then use a CloudFormation change set via the `CreateReplaceChangeSet` action. By specifying a `ParameterOverrides` JSON file (e.g., `stageName`, `environment`, `vpcConfig`) on that action, each environment (dev, test, prod) reuses the same pipeline definition yet receives its own configuration without duplicating stages or using manual scripts. SAM also generates the Lambda function, event sources, and permissions as a CloudFormation template, so environment-specific values propagate consistently through `AWS::Serverless::Function` properties and `!Ref` parameters.

DependsOn is the correct CloudFormation mechanism to explicitly control resource creation order when there is no implicit dependency. Even though CloudFormation automatically creates a dependency when you use Ref or GetAtt in a resource property, there are cases where the Lambda function's IAM role ARN is substituted indirectly (e.g., via a parameter or a Fn::Sub in a string), so CloudFormation cannot infer the ordering. Adding DependsOn: IamRole to the Lambda function resource guarantees that the IAM role is fully created before the Lambda function is provisioned, preventing the deployment failure that occurs when Lambda tries to use a role that does not yet exist.

The SSM Agent is the software component that executes Systems Manager requests on the instance, and the instance must also have an instance profile with IAM permissions to call Systems Manager APIs and download patch content. Without the agent or a role such as AmazonSSMManagedInstanceCore, the instance will not show up as a managed node and the automation cannot even target or initiate patching. This is the definitive prerequisite that is missing in this scenario.

While the scenario describes a transition to Glacier (not expiration), the lifecycle policy is still the cause: the digest file is moved to Glacier and becomes inaccessible, appearing missing. This is the most likely cause among the options.

Monitoring the 'InitDuration' metric is the direct, built-in approach because CloudWatch automatically receives this metric for every Lambda invocation that experiences a cold start. This metric reports the time the runtime spends initializing the execution environment (downloading the code, starting the runtime, and running initialization code) before the handler is invoked. It requires no custom instrumentation or querying, making it the simplest and most authoritative source for cold start duration.