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

AWS Systems Manager Run Command is part of AWS Systems Manager and lets you remotely and securely execute shell commands or PowerShell scripts on EC2 instances (and on-premises machines) via the SSM Agent. You can run a command like `ps aux` or `Get-Process` to enumerate running processes, capture output, and store it in S3 or CloudWatch Logs. Because the SSM Agent runs inside the instance as a guest process, it has direct access to OS-level state, making it the appropriate service for collecting process-level data. It also supports rate control and error handling for fleet-wide execution.

Raising the Lambda function's reserved concurrency to 500 is correct because it directly increases the maximum number of simultaneous executions, allowing the SQS event source mapping to scale out beyond the previous limit and process more messages in parallel. With a higher concurrency ceiling, incoming SQS messages are consumed faster, preventing the burst of throttling attempts that occur when the function is already running at its current cap. This aligns with Lambda's SQS scaling model, where the number of active pollers grows with the message volume until the reserved concurrency is exhausted.

The `SecurityGroupIds` property of an EC2 instance is typed as a list of security group IDs. When you use `!Ref` on a security group resource, CloudFormation resolves it to the security group's physical ID as a single string, not an array. Because the property requires a `List<AWS::EC2::SecurityGroup::Id>`, passing a bare `!Ref` causes a type-validation failure. To fix it, you must wrap the reference in a list literal, e.g., `SecurityGroupIds: [!Ref MySecurityGroup]`, or use `Fn::Split` if composing from a string.

The bucket policy contains an explicit deny statement for the principal or action being attempted, and AWS IAM policy evaluation gives explicit deny statements absolute precedence over any allow statements from identity-based policies, resource-based policies, or permission boundaries. Even though the IAM role allows the s3:GetObject call, the explicit deny in the bucket policy forces the final decision to AccessDenied. This precedence is a deterministic, non-configurable part of AWS's authorization engine.

If the ZIP file is exceptionally large (approaching Lambda's 50 MB compressed limit), the time CloudFormation takes to download it from S3 and create the Lambda resource can exceed the stack resource creation timeout. This manifests as a 'Resource creation timed out' error in the stack event, even though the function is valid. In contrast, a small package deploys quickly regardless of the Lambda function's configured timeout or role permissions.

Allows recovery from backups in another Region.

The approver needs permissions to submit the approval result.

The CodeBuild service role is the IAM role that the build service assumes at runtime to perform actions on your behalf, including fetching source code from Amazon S3. If the role's attached policy lacks an s3:GetObject action on the source bucket, the build start fails with an AccessDenied error that names the role. This is the correct diagnosis because CodeBuild's access to source objects is governed entirely by the service role, not by the caller's user-level S3 permissions.

This is the correct solution because CloudWatch natively supports creating dashboards that display multiple operational metrics, and alarms on DynamoDB consumed capacity can be configured to trigger SNS notifications (e.g., email) when thresholds are exceeded. The dashboard can be shared as a public read-only dashboard using the CloudWatch console's 'Share' feature, which generates a URL that grants view-only access without requiring IAM credentials or Cognito. This directly addresses both the need for at-a-glance monitoring and threshold-based alerting on DynamoDB capacity, making it the most operationally sound and low-overhead option.

This statement uses 'Deny' with the condition 'aws:SecureTransport': 'false', meaning that any time S3 sees a request to this bucket that did not use TLS/SSL, the condition is satisfied and the explicit deny applies, causing the request to be rejected. HTTPS requests have SecureTransport set to true, so they are not affected by this particular statement and may be allowed or denied based on other applicable policies. This is a standard pattern to enforce HTTPS-only access to S3 buckets.

The correct issue is that this Lambda execution role lacks any inline or managed policy granting the required CloudWatch Logs permissions. Without a policy allowing logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents, Lambda cannot write execution logs to CloudWatch, even though the trust policy is valid. This will cause runtime failures or missing log output, and is a common misconfiguration.

Enabling S3 default encryption with SSE-S3 on the CodePipeline artifact bucket automatically encrypts every object with 256-bit AES keys managed by Amazon S3. This is the simplest native approach: once enabled, you need no key management, no pipeline role changes, and no application code modifications. CodePipeline writes artifacts as normal S3 PUTs, so the bucket-level default encryption covers all stages and runs with zero overhead.

IAM Access Analyzer's ‘Unused access' findings are purpose-built for this exact scenario: it continuously analyzes IAM roles, users, and access keys, and when a resource has not been used for a configurable period (e.g., 90 days), it generates a detailed finding containing the resource ARN, the last-accessed timestamp, and the action. You can configure Amazon EventBridge to capture these findings as they are emitted and invoke an AWS Lambda function that automatically deletes or disables the IAM user, providing a fully automated, scalable, and auditable lifecycle policy. Access Analyzer relies on IAM's internal service-last-accessed data, which includes console logins, API calls, and programmatic access, making it more comprehensive than the credential report. This approach also supports multiple accounts when combined with AWS Organizations delegated administration, enabling centralized unused-access management.

AWS Config is the correct choice because it provides a continuous, account-wide compliance evaluation of resource configurations. You can use the managed AWS Config rule 'required-tags' (or a custom Lambda-backed rule) to check that every EC2 instance has the mandatory tags, and the rule can be paired with an auto-remediation action, such as an SSM Automation document, to automatically add missing tags. Since AWS Config records every EC2 instance as a configuration item and re-evaluates on configuration changes, it can both detect and enforce tag compliance for all existing and newly launched instances, regardless of how they were created.

A single pipeline in the management account leverages CodePipeline's native cross-account support by assuming an IAM role in the target account for the deployment action. The pipeline uses KMS customer-managed keys to encrypt artifacts, and each target account's role restricts the pipeline to deploy only the intended stack. This centralizes visibility and approval while keeping every account's permissions scoped, making it the recommended pattern for multi-account infrastructure delivery.

Enabling S3 Object Lock on the destination S3 bucket is the correct way to make CloudTrail logs immutable. In governance mode, you can set a retention period and object lock protects objects from being deleted or overwritten by any user—including the AWS account root user—unless they have the `s3:BypassGovernanceRetention` permission. This ensures that the audit log remains intact for the duration of the retention period, satisfying compliance mandates that require unauditable log preservation.

S3 Object Lock with Governance mode applies a Write-Once-Read-Many (WORM) policy that guarantees the backup objects cannot be modified or deleted by any ordinary user—even an account administrator with full S3 access—until the 365-day retention period expires. Governance mode does allow users with the s3:BypassGovernanceRetention permission to override the lock if needed, but a typical backup scenario doesn't grant that to regular IAM roles, so the data remains immutable for the entire year. Pairing this with a lifecycle rule that transitions the objects to S3 Glacier Deep Archive after 30 days satisfies both the need for protection and cost efficiency: the transition preserves Object Lock metadata and the object stays protected through the transition, after which Storage Costs drop to the lowest tier while retention still applies for the remaining 335 days.

This is the correct cause. When an application writes log events to CloudWatch Logs, it must have an existing log stream; if the stream does not exist, the client (such as the AWS SDK or CloudWatch agent) first calls logs:CreateLogStream. The IAM policy grants only logs:PutLogEvents, so the implicit or explicit CreateLogStream call is denied, causing the overall write operation to fail. To resolve it, the policy must additionally allow logs:CreateLogStream, and possibly logs:DescribeLogStreams, on the same log group and stream resources.

An IAM role attached as an instance profile is the AWS-recommended mechanism because the EC2 instance automatically assumes the role through the instance metadata service (IMDS), receiving temporary credentials from AWS STS that are valid for a limited duration and refreshed automatically by the SDK or CLI. This eliminates the need to store or manage long-lived access keys while letting you scope the role with a narrowly defined read-only policy, such as allowing only s3:GetObject or ec2:DescribeActions. The instance profile acts as the container for the role, and the per-instance trust policy ensures only instances with that profile can use the role, giving centralized control, easy revocation, and cross-account access when needed.

Change Sets allow you to review proposed changes before applying them.

The CodeBuild project must be explicitly configured to use the CodeCommit repository as its source and to specify the main branch as the source version. This ensures the build fetches the latest code from that branch whenever a build is initiated, whether manually or via an event. Without this configuration, CodeBuild would have no source to use, so this is a prerequisite that makes the other correct answers functional.

FreeableMemory from Enhanced Monitoring directly reflects memory availability from the DB instance OS perspective. When this value remains consistently low, the database may be forced to use swap or evict cache, causing increased read latency and degraded throughput. It is a correct metric because memory pressure is a common root cause of performance degradation, and Enhanced Monitoring reports this OS-level counter with per-second granularity.

The 'Update stack instances' operation is the correct remediation because it targets only the specific stack instance that failed inside the target account/region. CloudFormation StackSets treats a failed stack instance as an operation that can be retried without affecting other stack instances or the stack set definition. This operation re-invokes the deployment logic for that single instance, allowing transient issues such as permission timeouts or resource contention to resolve while preserving the centralized management model.

CodePipeline and CodeDeploy are regional services. When a pipeline deploys to a CodeDeploy deployment group, the pipeline's deploy action resolves that group by name within the same AWS Region where the pipeline is running. If the deployment group exists only in a different region, the action cannot find it and fails with a 'deployment group not found' error. This is a common cause, especially when copying pipeline templates across regions without recreating the deployment stack. You must either create the deployment group in the same region as the pipeline or configure a cross-region action with a corresponding artifact bucket in the target region.

AWS WAF rate-based rules track the number of requests from each client IP over a rolling evaluation window (typically 5 minutes) and, when a configured threshold is exceeded, automatically block that IP for a specified duration. This provides immediate, in-place mitigation on the existing ALB without DNS changes, making it the fastest L7 DDoS countermeasure. You can tune the rate limit and scope (e.g., by URI or session) to allow legitimate bursts while dropping attack traffic.

CodePipeline’s custom-action framework lets you define a stage gate backed by a Lambda function that calls your third-party scanner; the Lambda uses the job worker API (e.g., PutJobSuccessResult/PutJobFailureResult) to report the scan outcome, failing the stage if vulnerabilities are found. This approach is ideal when the scanning vendor doesn't have a built-in action provider and you need the scan to happen at a specific point in the pipeline before deployment.

Amazon GuardDuty is a continuous threat detection service that ingests and analyzes AWS CloudTrail management and data events, VPC Flow Logs, and DNS query logs. Using machine learning, anomaly detection, and integrated threat intelligence, it identifies reconnaissance, credential compromise, crypto-mining, and other unauthorized behavior. GuardDuty generates prioritized findings in the console and can trigger automated responses via Amazon EventBridge. Because it actively correlates across logs, it directly fulfills the 'monitor and detect unauthorized access' requirement.

Amazon EventBridge is the native event-delivery service for AWS and CodeCommit automatically publishes repository events—such as referenceCreated, referenceUpdated, and referenceDeleted—as event objects to the default EventBridge bus. You can define a rule with an event pattern matching the specific CodeCommit repository and event type, then set the rule's target to a CodeBuild project, which EventBridge invokes directly and asynchronously. This is the simplest and most direct integration because no intermediate processing or custom code is required, and you can even configure an input transformer to pass the commit ID as the sourceVersion to the CodeBuild build so the build uses the exact revision that triggered it.

Self-managed permissions require an execution role in each target account.

Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service that delivers messages to subscribers such as email, SMS, Lambda, or HTTP endpoints. When a CloudWatch alarm transitions to the ALARM state for the StatusCheckFailed metric, it publishes a message to an SNS topic, which then fans out the notification to all subscribed endpoints. This makes SNS the essential delivery mechanism for alerting the DevOps engineer promptly without requiring polling or custom integration code, and it integrates seamlessly with CloudWatch Alarms.

This is the correct first step because CloudWatch provides two directly relevant metrics for an RDS for MySQL instance: DatabaseConnections shows the number of client sessions currently established, and CPUUtilization reflects aggregate CPU consumption. If DatabaseConnections spikes while CPUUtilization remains normal, the problem is connection exhaustion or a connection leak; if CPUUtilization also rises, it likely indicates heavy query load. These metrics give you a high-level, time-aligned picture of whether the symptom is connection-bound or compute-bound, which drives the next diagnostic step (e.g., enabling Performance Insights).

AWS IAM Identity Center (formerly AWS SSO) is the correct service because it is purpose-built to centrally manage workforce user access and single sign-on across multiple AWS accounts, business applications, and SAML 2.0-enabled apps. It lets you define permission sets that map users or groups to IAM roles in different accounts, and it integrates with identity providers like Active Directory or Okta. This directly addresses the requirement to centrally manage user access to multiple AWS accounts with SSO.

CodePipeline polls CodeCommit for changes at a fixed interval (e.g., every 5 minutes) when no webhook is configured. If the repository receives numerous pushes in a short period, the polling calls to CodeCommit's API may be throttled by their respective rate limits, causing a poll to fail silently. Even if the poll succeeds, changes are aggregated, so a single push may not generate a distinct execution if superseded by later commits. This throttling—not any missing configuration—results in no pipeline trigger being created.

By default, a CodeBuild project that is associated with your Amazon VPC runs in one of your private subnets and has no outbound internet connection unless your route table directs traffic through a NAT gateway. Without that route, `npm install` cannot reach the npm registry and fails with network timeouts. Placing the NAT gateway in a public subnet, updating the private route table to `0.0.0.0/0 -> nat-gateway-id`, and associating the CodeBuild project with that VPC gives the build deterministic, reliable egress to the internet while still allowing it to access any VPC-only resources.

Customer managed keys allow you to enable automatic rotation with a customizable period (default 365 days).

In the RDS DB parameter group for MySQL, set slow_query_log to 1 or ON and define long_query_time with the desired threshold (for example, 2 seconds) — these parameters control which queries are written to the slow query log. This log records the exact SQL text, query execution time, and timestamp for every query exceeding the threshold, giving you the raw data needed to calculate SLO metrics like the ratio of slow queries to total queries. Because slow_query_log is a dynamic parameter for MySQL in RDS, you can apply the change immediately without rebooting the database instance.

AWS CloudTrail is the authoritative audit service that records management events as API calls, including the CreateUser action that IAM user creation invokes. By enabling CloudTrail, your security team gains a detailed, tamper-evident log of who created which IAM user, from which source IP, and with what permissions. This event data can then be delivered to Amazon CloudWatch Logs for further processing and alerting, making CloudTrail the essential first step in a real-time monitoring pipeline.

Correct. A logic error in the Lambda function can cause false NON_COMPLIANT results despite the tag being present.

Multi-AZ availability is not universally available across all RDS database engines; for example, Microsoft SQL Server supports Multi-AZ only on Enterprise or Standard editions (and not on Express/Web), while Oracle requires Enterprise Edition. If an engine/edition lacks Multi-AZ support, setting MultiAZ=true in CloudFormation will fail validation or be ignored. Therefore, confirming engine support is a necessary prerequisite before enabling Multi-AZ in the template.

Patch Manager is correct because it automates the process of patching managed nodes with security updates and other types of updates, directly replacing OpsWorks Chef's ability to manage package updates and system patches via cookbooks. It provides a centralized, policy-based approach to patch compliance without requiring custom Chef recipes.

A custom build image with the required Java version already installed, stored in Amazon ECR, is the correct architecture because CodeBuild can be configured to pull that image at build time. Baking the JDK, build tool, and dependency caches into Docker layers means the runtime is available immediately, eliminating per-build installation overhead and making versioning deterministic. This approach is the intended pattern for non-standard language versions.

A metric filter on the CloudWatch Logs group can count occurrences of the pattern 'ERROR', creating a custom metric. A CloudWatch alarm on that metric with a threshold of 100 and a 5-minute period will trigger when the error count exceeds 100.

Checking the CloudFormation stack events is the most direct and authoritative diagnostic step because every resource action logs a status reason that mirrors the exact API error returned by the RDS service. For a DBInstance failure, the event's status message will contain the precise reason—such as an invalid DB instance class, insufficient subnet coverage, or a parameter group mismatch—saving you from guesswork. The events tab also shows the sequence of resource creation, so you can determine whether the failure is isolated to the database or caused by a dependency like a VPC or subnet group that failed earlier.

CodePipeline's manual approval action generates a PutApprovalResult API call when an approver clicks to approve or reject. CloudTrail automatically captures that call, and the event includes the IAM principal ARN (user or role), the timestamp, source IP, and session context. This satisfies the audit requirement without any additional configuration.

Manually deleting the RDS DB instance from the RDS console removes the physical database object from the account, circumventing CloudFormation's inability to delete it automatically. This is a valid operational workaround when the stack is stuck in DELETE_FAILED because the DB instance is protected by RDS deletion protection or has a DeletionPolicy of Retain. Once the resource is gone, a subsequent stack delete operation will succeed because CloudFormation no longer attempts to delete that DB instance.

During a CodeDeploy blue/green deployment, the new instances (green) are launched and then a health check grace period is applied before traffic is shifted. If the application fails to become healthy within that window, CodeDeploy considers the deployment failed and automatically rolls back to the original blue fleet. This is the only condition that directly results in a rollback after the new instances are provisioned, making it the correct answer.

A cross-Region read replica uses asynchronous replication with lag typically under 5 minutes and can be promoted quickly, meeting both RPO and RTO cost-effectively.

By returning a meaningful error object (e.g., throwing an exception) within the Lambda handler, the error details and stack trace are automatically written to CloudWatch Logs. This gives the most comprehensive information for debugging application errors.

Enabling local caching in the buildspec.yml stores resolved dependencies (e.g., Maven ~/.m2 or Gradle caches) in a local cache directory on the build host, which persists across builds for the same project. This avoids re-downloading artifacts from repositories like Maven Central on every build, which is typically the most significant variable in Java build time. The correct configuration uses the 'cache' section with 'paths' pointing to the dependency directories and a 'local' cache type; unlike S3 caching, local caching has zero network latency and is ideal for short-lived, high-frequency builds.

This option is correct because the CloudFormation error explicitly states that the imageId is invalid, which is the EC2 API's validation response for an AMI ID that is malformed, deregistered, or not present in the account/region. During a stack update, CloudFormation passes the AMI ID from the template to the EC2 RunInstances API, and EC2 rejects it with an error like 'InvalidAMIID.NotFound' or 'InvalidAMIID.Malformed', causing the stack update to roll back. This commonly happens when a template references a hard-coded AMI that was deregistered or copied from a different region.

EC2Rescue can run diagnostics at startup; extending the grace period gives time for the tool to collect data before termination.

This is correct because CodeDeploy deployment groups support automatic rollback for trigger events such as DEPLOYMENT_FAILURE, DEPLOYMENT_STOP_REQUEST, and ALARM_ACTIVE. When any of these events occurs, CodeDeploy automatically initiates a new deployment of the last known-good revision to the same deployment group, with no custom code required. This native mechanism is the standard and recommended way to recover from a failed deployment while preserving deployment-group settings such as traffic routing and alarm monitoring.

A service control policy (SCP) attached at the organization root or to all accounts is the only option that gives central, preventive enforcement across every member account. By explicitly denying s3:PutBucketEncryption and s3:PutObject when encryption is not specified (using conditions like s3:x-amz-server-side-encryption), the SCP blocks the API actions themselves before any resource policy or IAM evaluation, so no account or workload can bypass the requirement. This works even if a member account administrator has full administrative permissions, because SCPs act as a permission boundary for all IAM principals in the account.

This is the correct root cause because when CodeBuild runs in your VPC, it attaches the security group you specified to its ENI. For the build container to successfully connect to RDS, the database's security group must have an inbound rule that permits traffic on the database port from the source being the CodeBuild security group ID. If that rule is missing, all connection attempts will time out or be refused, regardless of other network configurations, making this the definitive security group misconfiguration to resolve.

Elastic Beanstalk's native Environment Properties are key-value pairs defined at the environment level and injected directly into the operating system as environment variables on each EC2 instance, or as container environment variables for ECS-based platforms. This allows platform-managed settings to be consumed by your application with no extra code, and they are automatically updated on configuration changes without requiring a new deployment. They also support encrypted values when set through the AWS CLI or saved configurations with KMS, making them the standard, service-supported approach.

Amazon OpenSearch Service ingests CloudWatch Logs via a subscription filter and Lambda, indexing them for real-time full-text search, aggregations, and Kibana visualization. This makes it purpose-built for interactive log analytics and operational dashboards, directly querying the live stream without S3 export latency. It also scales to handle massive log volumes with open-source Elasticsearch-compatible APIs.

The `yum` command is specific to RPM-based distributions that use YUM as the package manager, such as older Amazon Linux (AL1/AL2) or CentOS 7. If the AMI is based on Amazon Linux 2023, which uses `dnf`, or on Ubuntu/Debian, which uses `apt`, the `yum` binary will not be present. When the UserData script runs `yum` on such an AMI, the shell returns a 'command not found' error, preventing the installation and causing the deployment to fail.

AWS CloudTrail is the primary service for recording API activity in an AWS account, capturing every management and data event with details like the caller's identity, the action, the resource, and the timestamp. By enabling CloudTrail in all regions and with appropriate event types, you can inspect logs to identify unauthorized attempts, such as failed authentication or IAM policy denials. CloudTrail provides the raw evidence needed for security analysis and is the foundational data source for services like GuardDuty.

AWS::CodeStar::Project is the CloudFormation resource that directly provisions a CodeStar project, bundling the project's underlying CI/CD infrastructure (typically CodePipeline, CodeBuild, an S3 bucket, and IAM roles) into a managed unit. It also creates the CodeStar project entry that appears in the developer dashboard and supports team member management. This is the only resource among the options that represents the CodeStar project itself, rather than a single constituent service.

Reviewing the instance's CPU credit balance is the correct first step because a T-series instance that exhausts its earned credits will be throttled to the baseline CPU, causing slowdowns even when the alarm threshold is breached. The network utilization metric is also essential since high network throughput can drive CPU overhead from interrupt handling and packet processing, which may be the actual root cause. Together, these metrics reveal whether the alarm reflects genuine resource contention or a misconfigured alarm threshold.

Sending VPC Flow Logs from each account to a centralized Amazon S3 bucket is correct because it creates a single, durable, cost-effective data lake that scales to petabytes. You configure each account's VPC Flow Logs to deliver to the same S3 bucket (with a bucket policy allowing cross-account delivery, ideally scoped to your AWS Organization ID). Then Amazon Athena can query these logs directly using standard SQL, with per-query pricing and no server to manage; using partition projection on account, region, and date drastically reduces scan costs and speeds up investigations.

This policy grants the root principal s3:GetObject and s3:PutObject actions on the arn:aws:s3:::bucket/* resource. s3:GetObject allows downloading an object's data and metadata, while s3:PutObject allows uploading a new object or overwriting an existing one. Together, these actions explicitly authorize reading and writing objects inside the bucket, which is exactly what the question asks — making this the correct option.

Secrets Manager natively supports rotation for RDS credentials through a managed Lambda function. The rotation function updates the password in the RDS database and then stores the new value in the secret, using staging labels like AWSCURRENT and AWSPENDING to ensure applications can always retrieve valid credentials. The application retrieves the current secret via the Secrets Manager API (for example, GetSecretValue), and effective caching keeps this cost-efficient. This exactly meets the requirement of rotating the database every 30 days while keeping the application functional.

Cross-zone load balancing on the ALB ensures that incoming traffic is distributed evenly across all registered targets in every Availability Zone, preventing any single AZ from being overloaded and allowing the ALB to continue serving requests even if one AZ is impaired. Connection draining gives in-flight requests a grace period to complete before an instance is deregistered or replaced, avoiding request interruption during rolling updates or failed health checks. Together, these features support seamless instance replacement without dropping active requests, though they do not on their own preserve stored session data — they protect the connection lifecycle while the application layer (e.g., ElastiCache) handles state.

AWS CloudFormation is the core service that declaratively provisions and updates the stack by processing the template. It manages the resource lifecycle, applies change sets, and handles rollbacks in a controlled manner, making it the essential target of the infrastructure-as-code pipeline.

AWS CloudTrail records all IAM user and role API activity as events, including the source IP address, user agent, event name, and whether the call was authorized. Analyzing CloudTrail logs with querying or visualization tools helps you identify which unauthorized or anomalous calls occurred, when they occurred, and what resources were accessed, so you can scope the impact and determine whether other remediation steps are needed. It is the first responder's forensic tool for understanding the security incident.

AWS X-Ray provides distributed tracing by propagating a trace ID across instrumented services and recording segments and subsegments for each component. Enabling X-Ray on API Gateway and Lambda functions (e.g., via active tracing on the API Gateway stage and the Lambda execution role with X-Ray permissions) captures the full lifecycle of a request, including the API Gateway frontend, Lambda invocation, and any downstream SDK calls or HTTP requests. This allows you to follow a specific request through the entire architecture, view a service map, and drill into per-service latency, errors, and annotations, making it the correct solution for end-to-end tracing.

Configuring the deployment group to roll back when a CloudWatch alarm is triggered is the correct action because CodeDeploy natively supports this as a rollback trigger. An alarm can monitor any custom metric—including a health check endpoint—and when it transitions to ALARM, CodeDeploy automatically rolls back the deployment to the last known-good revision. This mechanism directly ties the health check's failure signals to the deployment lifecycle, enabling the desired rollback behavior.

Amazon EventBridge natively captures CodeCommit events, including the 'CodeCommit Pull Request State Change' detail type, and invokes Lambda via an event rule. This event-driven pattern eliminates polling and reacts the moment a pull request transitions to a state such as Approved or Merged. The Lambda function can run unit tests and then post results back to the pull request, and you can optionally route results to other services like SNS for notifications.

ElastiCache provides a resilient, high-performance session store.

MapPublicIpOnLaunch is a subnet-level attribute that, when set to true, automatically assigns a public IPv4 address to every instance's primary network interface upon launch. This is the correct control for achieving subnet-wide public IP assignment, as it directly applies at the subnet boundary and affects all instances regardless of individual launch configuration. Changing this attribute is the standard CloudFormation approach to provision instances in a public subnet with reachable IP addresses.

The listener receives incoming traffic on a specific port.

Customer managed keys are the only KMS key type that supports manual rotation, allowing you to create a new key and update aliases as needed at any time. By manually rotating every 90 days, the company can enforce its required rotation policy while keeping the same alias or key ID for applications. This gives full control over rotation frequency, unlike automatic rotation which is fixed at yearly.

Distributing instances across AZs provides high availability for the web tier.

The default EC2 monitoring only exposes hypervisor-level metrics like CPU, network, and disk I/O; memory utilization is a guest-OS metric that AWS cannot see without an in-guest component. Installing the unified CloudWatch agent (with the `mem_used_percent` and similar metrics in the agent's JSON config) and starting the `amazon-cloudwatch-agent` service enables the agent to publish memory metrics to CloudWatch, making them available for alarms and dashboards. This is required because no amount of instance-level monitoring settings can surface guest-OS memory.