AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 751–825

A cross-Region read replica in RDS for MySQL, MariaDB, or PostgreSQL uses engine-native asynchronous replication to continuously stream changes from the primary in the source Region to a replica instance in the secondary Region. During a failover, you simply promote the replica, which stops replication and makes it a standalone primary database; promotion typically completes in minutes, giving you an RTO in minutes and an RPO of only seconds (or sub-second in low-write workloads). Because replication is ongoing rather than backup-based, this option gives the lowest RPO and RTO among the choices and is the correct DR strategy for cross-Region recovery.

CodePipeline natively publishes execution-level log events to Amazon CloudWatch Logs, including stage start/end timestamps, action state transitions, and failure diagnostics. This provides a centralized, queryable repository that can be filtered with CloudWatch Logs Insights, used for metric filters and alarms, and retained beyond the console's default history. Because these logs capture the pipeline's own runtime behavior, they are the authoritative source for troubleshooting execution details.

CloudWatch Logs Insights runs a query like `fields @timestamp, @logGroup | filter @message like /ERROR/ | stats count(*) by @logGroup` across all specified log groups in the selected time range, and the exact same query can be added as a dashboard widget using the 'Add to dashboard' option. This gives real-time results without any per-group configuration, and the dashboard automatically reflects the current set of log groups as long as they are included in the query scope. It is the intended native mechanism for interactive multi-group log analysis, making it the correct choice for this scenario.

Enabling detailed CloudWatch metrics on the ALB provides high-frequency measurements such as TargetResponseTime, RequestCount, and TargetConnectionErrorCount, and analyzing ALB access logs offers per-request timestamps, target processing time, request time, client IP, and target status codes. This combination yields a historical, request-level view of latency from the client through the ALB to the target without adding any agents or scripts to the EC2 instances. It also lets you filter for slow requests, group by URL or target, and determine whether delay occurs in the ALB-to-target hop or in the target application itself.

The correct action is to explicitly associate your customer-managed AWS KMS key with the CloudWatch Logs log group, either through the console or by calling the `AssociateKmsKey` API. This association defines the encryption boundary at the log group level and applies to all existing and future log streams within that group. The key-policy prerequisites must already be in place, but the actual enabling step is this association.

NumberOfMessagesPublished is the correct Amazon SNS CloudWatch metric for monitoring message volume. It increments for every successful publish operation to an SNS topic, including individual messages sent via the Publish API and each message within a PublishBatch request. This metric provides the exact count of messages accepted by the topic, making it the appropriate choice for tracking publication activity.

By adding a branchName filter to the event pattern of the CloudWatch Events (EventBridge) rule that invokes the pipeline, the rule only triggers when a push occurs on the main branch. This is the documented and precise way to restrict executions by branch while still capturing all relevant repository state changes. The filter is evaluated in the event pattern, so other branches don't initiate a pipeline run.

To allow the SSM Agent to call Systems Manager APIs, an instance must have an IAM instance profile with the AmazonSSMManagedInstanceCore managed policy. Without this role, the agent cannot authenticate, and the instance will not appear as a managed node in Patch Manager, so no patching can occur.

Amazon CloudWatch is the native monitoring service for AWS, collecting metrics, logs, and events from AWS resources and applications. The CloudWatch Agent, installed on EC2 instances or on-premises servers, can collect memory utilization metrics (such as mem_used_percent) and publish them as custom metrics to CloudWatch, enabling alarms and dashboards. Without the agent, standard EC2 metrics include CPU, disk, and network but not memory, so using CloudWatch with the agent is the appropriate solution.

Attaching an IAM policy that uses a condition such as aws:PrincipalArn to the CodePipeline administrative actions (for example, UpdatePipeline and CreatePipeline) is the correct preventive control. This restricts the set of principals who can modify the pipeline definition no matter how the request is made, and it can be combined with resource-level permissions and least-privilege scoping. It directly addresses unauthorized pipeline modifications at the authorization layer.

The 'Rollback' action in the CloudFormation console is the correct approach because CloudFormation maintains an automatic rollback trigger for failed update operations, and when an update enters a failed state, you can explicitly invoke 'Rollback' from the console to restore the stack to its last known good template and parameter state. This action is specifically designed to undo the partial or failed changes, reverting affected AWS resources to their pre-update configuration, and is the direct rollback mechanism within CloudFormation's lifecycle.

The policy grants 'codepipeline:StartPipelineExecution' with a Resource element of '*', so the service role can trigger a new execution for any pipeline in the AWS account, not just a single named pipeline. In IAM, an action with Resource '*' matches all ARNs for that service; thus, the permission is not scoped to a specific pipeline. This statement is correct because the action is explicitly allowed and the resource constraint is unlimited.

AWS CodePipeline is the correct choice because it is a fully managed continuous delivery service that orchestrates the entire release process, from source code changes to production deployment. It can automatically detect new commits in a repository (e.g., GitHub, CodeCommit, S3) and then trigger a series of sequential or parallel stages, such as build with CodeBuild, test, and deploy via CodeDeploy or a direct Lambda update. By modeling the Lambda deployment as a pipeline action, CodePipeline ensures that each new version is built, tested, and deployed automatically and consistently, with the ability to add manual approvals or rollback steps.

Multi-AZ maintains a synchronous standby in a different Availability Zone and automatically fails over to it when the primary's hardware fails, satisfying the stem's automatic recovery requirement. A single-AZ instance would remain unavailable until AWS or manual intervention restored it.

AWS Organizations provides central management of multiple AWS accounts through hierarchical grouping into organizational units (OUs). It enables the creation and enforcement of service control policies (SCPs), which act as guardrails to restrict the maximum permissions of IAM roles and users across member accounts. SCPs can be attached to the root, OUs, or individual accounts, giving centralized, policy-based control over an entire enterprise environment.

Attaching the policy to every IAM user—or more efficiently, to a group that contains all users—is the only way to make the MFA enforcement policy effective because IAM policies have no effect until they are attached to a principal. Group-based attachment centralizes administration; when a new user is added to the group, the same MFA requirement is automatically inherited. This is the correct deployment step for the policy described in the answer.

Recording processed S3 object keys in a DynamoDB table and checking for existence before processing makes the Lambda function idempotent. Use a conditional write, such as PutItem with ConditionExpression: attribute_not_exists(partition_key), so the first invocation for a given object key proceeds and subsequent duplicates fail the condition and exit without side effects. This is the recommended pattern because it works regardless of how many duplicate events S3 delivers and does not depend on delivery semantics.

Latency routing directs users to the Region with the lowest measured latency, satisfying the nearest-healthy-endpoint requirement. Route 53 latency records support health checks, so unhealthy endpoints are excluded automatically. Unlike geolocation, which maps users by geography, latency uses actual network performance between resolver and endpoint.

The metric filter pattern is the core of the extraction process: it defines exactly which log events should be matched and how the metric value is derived, such as counting occurrences of a 4xx or 5xx status code. For example, a pattern like "[*, _, _, status_code]" or a JSON pattern like "{ $.status_code = 4* }" is needed to parse the relevant field correctly from the log entry. If the pattern is not defined, CloudWatch Logs has no way to know which log lines correspond to an HTTP status code or what value to emit for the CloudWatch metric.

Pod memory utilization directly shows memory usage per pod compared to its configured limit, which is the exact condition that triggers the kernel's out-of-memory killer. When a container's working set (container_memory_working_set_bytes) exceeds its memory limit, the OOM killer terminates it with exit code 137, so plotting this metric against the limit surfaces the specific pod(s) at fault and helps correlate with OOMKilled events in kubectl get pods.

The policy grants s3:PutObject only when the s3:x-amz-server-side-encryption request header is exactly AES256. In S3, that header value maps to SSE-S3, where Amazon S3 manages the encryption keys using AES-256. Consequently, any object uploaded must be encrypted with SSE-S3, and uploads using no encryption or any other encryption method are denied.

CloudWatch Logs cross-account subscription allows a central (destination) account to create a destination policy and use subscription filters in source accounts to forward log events in real time to a central log group or a Kinesis Data Streams/Firehose pipeline. This feature natively supports aggregating logs from multiple AWS accounts into a single location, providing centralized monitoring and analysis. It directly meets the requirement to centralize logs from multiple AWS accounts, making it the correct choice.

The SAM CanaryDeployment property, when paired with a DeploymentPreference such as 'Canary10Percent5Minutes', delegates to AWS CodeDeploy to manage a gradual traffic shift. CodeDeploy publishes a new Lambda version, then adjusts the alias's routing configuration to send only 10% of live invocations to the new version for a 5-minute observation period, and finally shifts the remaining 90% after the interval succeeds. It also supports CloudWatch alarm-based automatic rollback, making it the only option here that provides a managed, gradual, and rollback-capable canary release on Lambda.

ApproximateNumberOfMessagesVisible is the correct CloudWatch metric for monitoring queue depth because it reports the number of messages available in the SQS queue for immediate retrieval by consumers. This value directly reflects the backlog of work waiting to be processed, making it the standard metric used for autoscaling consumers or triggering alarms. It is approximate due to SQS's distributed architecture, but it is polled frequently enough to provide a reliable real-time indicator of queue pressure.

Amazon S3 is a supported CodePipeline Source action that detects new uploads when versioning is enabled, either through CloudWatch Events or periodic polling. When a new object version is written to the designated bucket and key, CodePipeline starts a pipeline execution and downloads that object as the input artifact for downstream stages. This makes S3 a common choice for external tooling or third-party providers to drop build artifacts.

A dead-letter queue (DLQ) captures messages that remain unprocessed after multiple attempts, preserving them for later analysis or manual intervention, while Auto Scaling based on SQS queue depth dynamically adjusts the number of consumers to match incoming load. This combination ensures that spikes in traffic are handled by adding more processing capacity, and messages that cannot be processed are not permanently lost, providing both reliability and scalability.

CodePipeline is the orchestration service whose own pipeline definition can be declared as code, letting the team version and recreate the pipeline itself. It satisfies the requirement by acting as the managed resource that CloudFormation templates provision and update.

MemoryUtilized and MemoryReserved are the correct CloudWatch ECS metrics for Fargate tasks, as they directly measure the task's memory consumption against the memory limit configured in the task definition. When MemoryUtilized consistently approaches or equals MemoryReserved, the container runtime may start swapping memory pages to disk, which degrades performance. Monitoring these two metrics together provides the earliest signal of memory pressure that leads to swapping.

For a NAT Gateway to provide internet access, its public subnet must have a route to an Internet Gateway. If the public subnet's route table does not have a route to the Internet Gateway, the NAT Gateway cannot forward traffic to the internet. This is a common misconfiguration in CloudFormation templates.

A CloudWatch alarm on CPUUtilization with a five-minute period and 80% threshold, notifying via Amazon SNS, directly matches the stated requirement to alert when utilisation exceeds 80% for more than five minutes, enabling investigation of the daily 10:00 AM spike.

For a deployment to an Auto Scaling group, CodeDeploy must be able to adjust the group's desired capacity and update its configuration. autoscaling:UpdateAutoScalingGroup lets CodeDeploy modify min/max/desired values, while autoscaling:SetDesiredCapacity forces the group to scale to the exact instance count required for the deployment. Without these permissions, CodeDeploy cannot perform instance replacement or blue/green transitions, causing the deployment to fail.

AWS Config Conformance Packs are collections of AWS Config rules and remediation actions that can be deployed across an entire AWS Organization. They enforce compliance by evaluating resource configurations against predefined templates and automatically remediating noncompliant resources. This enables centralized governance of security and operational best practices across all accounts, making them a correct answer for centrally managing compliance.

S3 Server-Side Encryption (SSE-S3 or SSE-KMS) transparently encrypts object data before it is written to disk and decrypts it when the object is read, using either S3-managed AES-256 keys or AWS KMS-managed customer keys. This ensures that objects stored in the bucket are unreadable without the appropriate decryption key, directly protecting data at rest. For SSE-KMS, the service also provides envelope encryption, key rotation, and fine-grained access control through IAM policies.

The health check interval (30 seconds) and failure threshold (2) mean it takes up to 60 seconds to mark a task unhealthy. During deployments, the rolling update may temporarily have only 1 healthy task (minimum 50% of 2 = 1), and if that task becomes unhealthy, HealthyHostCount drops to 0.

Upload the cookbook containing the recipe to a repository (S3, Git, or HTTP), then in the OpsWorks stack settings enable 'Use custom Chef cookbooks' and add the recipe name to the Configure lifecycle event. The OpsWorks agent then executes that recipe on every Configure event, which fires when any instance enters the online state or when instances are added to or removed from the stack. This is the documented, supported method for attaching custom configuration logic to OpsWorks lifecycle events.

AWS DRS provides continuous block-level replication from source servers to a low-cost staging area in the AWS target Region, capturing every data change and maintaining a nearly synchronous copy. On failover, DRS automatically launches EC2 instances from the most recent consistent recovery point, achieving an RPO of seconds (well under the required 1 minute) and an RTO that can be measured in minutes. This directly meets the stated DR requirements, making it the correct choice.

For IAM database authentication, the application must first assume the IAM role 'DatabaseAccessRole' to obtain credentials authorized to generate the RDS token; the trust policy on 'DatabaseAccessRole' must explicitly list 'EC2-AppRole' as a trusted principal. When this trust policy does not allow the EC2 instance's role to assume it, the STS AssumeRole call returns 'AccessDenied', so the application cannot acquire the token required for authentication to RDS. This exactly matches the observed error, confirming the trust policy of 'DatabaseAccessRole' is the root cause.

S3 Versioning must be enabled on both the source and destination buckets because S3 Cross-Region Replication (CRR) requires versioned buckets to function. Versioning allows every object version, including overwrites and delete markers, to be captured and replicated, ensuring a complete and recoverable history in the DR Region. Without versioning, CRR cannot replicate updates or track deletes consistently, and the RPO guarantee would be unattainable.

This is the correct approach because it guarantees the 'latest' tag is only ever applied to an image that has successfully passed the defined security gate. In the post_build phase of CodeBuild, you can run a local container scanner (e.g., Trivy, Snyk, or Anchore) and only when the exit code indicates a pass do you execute `docker tag` to relabel the built image as `latest` followed by `docker push`. This ensures the 'latest' tag remains immutable and clean, with no vulnerable image ever being exposed under that tag during the build or scan window.

Change Sets in AWS CloudFormation generate a read-only summary of the exact resource-level actions (Update, Add, Remove) that would result from submitting a new template or parameters. They act as a dry-run, allowing the team to inspect the proposed modifications, identify resources that will be replaced, and evaluate potential downtime before executing the stack update. This review-and-approve capability makes Change Sets the ideal tool for implementing infrastructure as code with controlled change management.

A single StackSet with a common template and per-account parameter overrides is the intended pattern for account-specific values like CIDR blocks. You can attach overrides to individual stack instances via CreateStackInstances or UpdateStackInstances, so each account receives the same standard security and network rules but with the exact CIDR range it needs, all through one API call. This approach centralizes updates and drift management—changing a rule once updates every account—while preserving per-account flexibility, and it integrates natively with Organizations' delegated administrator and automatic deployment for new accounts.

CloudWatch Logs Insights lets you run SQL-like queries against application logs stored in CloudWatch Logs, allowing you to filter for specific error codes, exception stack traces, or deployment markers that align with the exact timestamp of the metric spike. By correlating log timestamps with the scaling activity, you can identify events like a failed code release, a dependency outage, or a traffic surge that pushed the metric above the alarm threshold. This is the only option that gives access to application-level evidence needed to diagnose the upstream cause of the spike.

The ApproximateNumberOfMessagesVisible metric of the dead-letter queue is a native SQS metric that reports the number of messages available for retrieval. When the redrive policy moves messages from the source queue to the DLQ after the maximum receive count is exceeded, this metric immediately increases. Creating a CloudWatch alarm on this metric provides a direct, near-real-time signal that messages are failing processing, and you can trigger an SNS notification or other action from the alarm.

Custom metrics are not emitted by default by EC2; they require an explicit mechanism such as the CloudWatch agent or direct PutMetricData calls from the application. If the agent is not installed or its configuration file (common for statsd or collectd) is missing/invalid, no metric data will be sent even though the application is running. This is the most common root cause when an application expects to send custom metrics but nothing appears in CloudWatch, because without the agent’s collection loop, nothing triggers the metric submission.

CloudTrail natively supports SSE-KMS: you configure the trail by specifying a KMS key ID (e.g., arn:aws:kms:region:account:key/key-id) and you must also grant CloudTrail the required permissions via the KMS key policy—specifically kms:GenerateDataKey and kms:Decrypt on the key. This lets CloudTrail encrypt each log file with a customer-managed AWS KMS key, giving you full lifecycle control, auditability, and the ability to disable or rotate the key as needed. Unlike SSE-S3 or SSE-C, this is the only option that both supports automated delivery and uses a customer-managed key.

Assigning recipes to lifecycle events is the native OpsWorks Stacks mechanism for ordered configuration. Each layer exposes five lifecycle events (Setup, Configure, Deploy, Undeploy, Shutdown), and recipes attached to an event execute in the order listed within that event's configuration. This provides a predictable, sequential run across all instances in the layer, ensuring that prerequisites and dependencies are satisfied. Because OpsWorks orchestrates these events centrally, this is the only option that reliably enforces both per-instance ordering and layer-wide sequencing.

CloudFormation performs template validation before any update action is taken, checking for well-formed JSON/YAML, resolving intrinsic functions, validating resource types and required properties. An invalid template will cause the UpdateStack API call to fail immediately with a ValidationError, leaving the stack's current status unchanged. This is a hard precondition that every direct update must satisfy.

AWS Systems Manager Parameter Store with a SecureString parameter encrypts the secret under a KMS customer managed key and lets CodePipeline or CodeBuild retrieve it directly as an environment variable at build time, without the secret ever appearing in the source repository or build artifact. Because access is controlled via IAM, you can scope which pipelines see which secrets, and you can rely on Parameter Store’s native versioning to rotate values without triggering a pipeline rebuild.

Enabling S3 bucket versioning on the bucket that stores CodePipeline build artifacts preserves every object version, including each build output. When a deployment needs to roll back, you can retrieve a previous artifact version directly from S3 or point the pipeline stage to that exact version. Versioning is a prerequisite for using S3 as CodePipeline's default artifact store in a way that supports safe, reproducible rollbacks without losing prior builds.

After a Multi-AZ failover, the RDS DNS record for the writer endpoint is updated to point to the new primary instance, but an application that caches DNS resolutions continues sending write connections to the old IP. That old IP belongs to the former primary, which is now promoted to standby (or replaced) and will not accept write connections, so all new database requests fail until the TTL expires or the application is restarted. This directly causes the five-minute outage because the application never re-resolves the endpoint until the cached entry times out.

A CodeCommit trigger can be set up to invoke an AWS Lambda function whenever a push event occurs, and the event payload includes the full commit list with metadata such as the commit message and author. The Lambda function can programmatically validate each commit message against a required format or regex, and then take action such as sending an alert or invoking a rollback if validation fails. This is a serverless, centrally managed approach that runs on every push and cannot be bypassed by developers, making it the correct solution.

Because the web application stores its session state locally—either in memory (e.g., a servlet HttpSession) or on the instance's ephemeral disk—any instance replacement destroys active sessions. During a rolling update, the Auto Scaling group terminates old instances after launching new ones, forcing users who had sessions on those instances to be logged out. Moving session data to a shared external store such as ElastiCache for Redis, DynamoDB, or a central database makes sessions independent of instance lifecycle and prevents this behavior.

AWS CloudFormation StackSets require a trust relationship between the IAM role used to administer the StackSet (in the management account) and an execution role in each target account. If the execution role’s trust policy does not include the StackSet IAM role (or the appropriate account) as a trusted principal, the sts:AssumeRole call fails with an access-denied error. This trust policy is what authorizes the management account’s role to assume the target execution role, so its absence directly produces the reported failure.

In the buildspec.yaml, the artifacts section can set 'encryptionDisabled: false' and specify the desired KMS key ID via the 'kmsKeyId' setting (or similarly named property). This explicitly instructs CodeBuild to encrypt the output artifact using the specified customer-managed KMS key, ensuring server-side encryption at rest. This is the direct and reliable way to enforce SSE-KMS for build artifacts.

Amazon RDS Performance Insights is the correct choice because it is a dedicated database performance tuning feature that visualizes database load and provides granular, per-query metrics. It breaks down DB load by wait events, SQL statements, and hosts, directly surfacing the exact query text and execution statistics (e.g., rows returned, latency) causing high load. This allows a DevOps engineer to identify problematic queries quickly, unlike network or API-level logs.

The describe-stack-events AWS CLI command is the correct programmatic way to inspect the full event history of a stack, including each resource's CREATE_FAILED event followed by the overall stack rollback event. Each event object contains a ResourceStatusReason property with the detailed error thrown by the failed resource, along with the logical resource ID, physical resource ID, and timestamps. This command is ideal for automation because it returns the exact same failure information you would see in the CloudFormation console, allowing you to log or alert on the root cause.

RDS Performance Insights is the correct approach because it provides a database-load dashboard that correlates wait events, SQL statements, and hosts in real time, allowing you to pinpoint the exact queries causing bottlenecks. Enhanced Monitoring complements this by delivering OS-level metrics—including CPU, memory, file I/O, and process lists—from the underlying hypervisor, which helps identify resource saturation that affects query performance. Together, these services give both the query-level and system-level telemetry required to diagnose slow PostgreSQL performance.

EventBridge rules match CloudTrail management events by API name, so a rule filtering StopLogging and UpdateTrail invokes a target such as SNS within seconds of the call. This delivers the real-time detection of tampering with CloudTrail's own configuration that the scenario requires.

The deploy stage of CodePipeline assumes the CodePipeline service role when it interacts with S3, so that role must have an IAM policy allowing s3:PutObject on the target bucket. This permission enables the pipeline to upload the artifact archive and any extracted files to the bucket that hosts the static website. Without it, the deploy action fails with a permissions error even if other roles, such as CodeBuild's, happen to have access to the same bucket.

AWS CodePipeline is a fully managed continuous delivery service that automates the entire release process, from source through build, test, and deployment. It orchestrates the pipeline by connecting multiple stages, such as pulling code from CodeCommit, invoking CodeBuild, and triggering CodeDeploy, along with integrations for third-party tools like Jenkins or GitHub. This end-to-end automation makes it the central CI/CD service in AWS.

AWS Secrets Manager is designed for storing and rotating secrets. It supports automatic rotation via Lambda functions, and it integrates with AWS KMS for encryption and AWS CloudTrail for auditing. This solution meets all requirements: encryption at rest, auditing, and automatic 30-day rotation.

AWS CodePipeline integrates with AWS CodeDeploy to provide blue/green deployments for ECS. By setting the ECS deploy action to use the 'CODE_DEPLOY' deployment controller, you can specify a CodeDeploy application and deployment group configured for blue/green. CodeDeploy manages the traffic shift and can automatically roll back if health checks fail. This is the standard way to achieve blue/green with automatic rollback in CodePipeline.

This is the correct non-interactive deployment sequence for an AWS SAM application in an automated pipeline. `sam build` prepares the application by installing dependencies, compiling code, and creating the deployment artifacts required for Lambda functions and layers. `sam deploy` then packages these artifacts, uploads them to S3, and uses AWS CloudFormation to create or update the stack, all without requiring manual intervention.

CodeBuild first calls sts:AssumeRole to obtain temporary credentials for the service role, and this requires the role's trust policy to include codebuild.amazonaws.com as a trusted service principal. The permissions policy may be correct, but if the trust policy is missing or misconfigured, CodeBuild is not authorized to assume the role and the build fails before any repository action occurs. This is the classic cause when CLI output verifies the repository and the permissions policy, yet the build cannot start.

In AWS KMS, a customer master key is always governed by a resource-based key policy in the account that owns the key. To allow principals in separate member accounts to use the CMK, the key policy must include a statement whose Principal element contains the ARN of the IAM role (or the member account root) and grants the required cryptographic actions, such as kms:Decrypt. This acts as the cross-account authorization; additionally, the member account's IAM policy must delegate those same actions to the role, because KMS requires that both the key policy allow the principal and the principal's IAM policy allow the action.

AWS CloudTrail records all API calls made by IAM users as events, and CloudWatch Events (now Amazon EventBridge) can be configured with event patterns to match specific actions. This integration enables real-time notifications by routing matched events to an SNS topic or Lambda function. Thus, CloudTrail provides the audit log while CloudWatch Events performs the filtering and alerting.

The instance OS runs its own packet-filtering firewall—typically iptables or firewalld on Linux—which operates independently of AWS's security groups and network ACLs. Even with a permissive security group and a correct public IP, an iptables rule (e.g., default INPUT policy DROP or a REJECT rule) will drop inbound HTTP packets before they reach the web server. This is a classic scenario where all AWS-side checks pass but the instance remains unreachable, hence the CLI 'running state' does not reflect host-level firewall state.

AWS CodePipeline is the fully managed continuous delivery service that models the entire release process as sequential stages (source, build, deploy) and manages transitions, artifacts, and approvals. For a SAM application, CodePipeline pulls source from a repository, invokes CodeBuild to run SAM CLI commands, and triggers a CloudFormation deployment through a deploy action. Its stage-based orchestration is exactly what the question's 'pipeline stages' refers to, making it the correct service to orchestrate the pipeline.

In CodePipeline, a source stage with a CodeCommit action automatically subscribes to repository events on the specified branch (e.g., main) and triggers a new pipeline execution whenever a commit is pushed. This is the standard, fully managed integration: CodePipeline creates the necessary event rule to detect the branch update and passes the commit ID and repository name as inputs to subsequent stages. By specifying the branch in the action configuration, you also get filtering on that branch only, making this the simplest and most reliable way to achieve continuous delivery from CodeCommit.

The event name "CreateKey" maps directly to the AWS KMS CreateKey API call, which is used to provision a new customer master key (CMK). In the CloudTrail log, the resources array contains the ARN of the newly created key (e.g., arn:aws:kms:region:account:key/key-id), confirming that a new symmetric or asymmetric KMS key was successfully created. This is the only action listed whose event name and resource type align with the observed log entry.

Lambda allocates CPU proportionally to the configured memory, so increasing memory to 256 MB from a lower value (e.g., 128 MB) roughly doubles the available vCPU fraction, speeding up CPU-bound tasks. This directly targets the performance bottleneck and is a standard first step in Lambda performance tuning. For the stated issue, this change is more likely to reduce execution time than the other options.

AWS Systems Manager Run Command is the correct choice because it uses the SSM Agent already installed on the EC2 instance to execute a script as a one-shot, non-interactive command. It does not require SSH, opening port 22, or managing SSH keys, and it works across multiple instances concurrently with rate control and output logging. Run Command is purpose-built for exactly this ad-hoc script execution scenario, and it leverages the instance's IAM role for permissions, avoiding any need for bastion hosts or direct network access.

Amazon EventBridge is the correct service because it is a serverless event bus that natively captures AWS service events, including CloudFormation stack lifecycle changes (CREATE, UPDATE, DELETE), and delivers them to targets like SNS, Lambda, or SQS for immediate action. EventBridge rules filter on resource type, event detail type, and other JSON fields, allowing you to build precise event-driven workflows without custom polling. This makes it the standard, low-latency solution for reacting to CloudFormation events in real time.