Free DOP-C02 practice questions

A company runs its AWS CodePipeline in a shared tooling account but deploys the built artifacts into a separate production account using a CloudFormation deploy action. The pipeline currently fails at the deploy stage with an access denied error, even though a cross-account IAM role exists in the production account. The team encrypts the pipeline artifact store with a customer managed AWS KMS key. They want the most reliable way to let the production-account role read the artifacts and deploy them. Which change resolves the failure while keeping access scoped?

• AGrant the production-account deploy role permission to use the customer managed KMS key in the key policy, and allow the tooling-account pipeline role to assume that role, so the role can decrypt and read the artifacts.check_circle Correct
• BReplace the customer managed KMS key on the artifact bucket with the default Amazon S3 managed key, because cross-account CodePipeline actions cannot decrypt artifacts protected by a customer managed key under any configuration.
• CMake the artifact S3 bucket public-read so the production account can fetch the artifacts directly, then attach an administrator policy to the cross-account role so it has enough permissions to deploy.
• DMove the entire pipeline into the production account so no cross-account artifact access is needed, then have developers push source directly into that account to avoid configuring any assume-role trust.

Why A is correct: Cross-account actions fail when the deploy role cannot decrypt the artifacts; adding the role as a key user in the KMS key policy plus the assume-role trust lets it read the encrypted artifact and deploy, with access scoped to that one role.

Why B is wrong: Cross-account decryption with a customer managed key is fully supported once the key policy and bucket grants are correct, so downgrading encryption sacrifices control to fix a problem that is really a missing grant.

Why C is wrong: A public bucket and an administrator policy both breach least privilege and expose build output, and neither addresses the KMS decryption grant that is the actual cause of the access denied error.

Why D is wrong: Collapsing accounts removes the separation the company chose and is a large re-architecture, when the failure is simply a missing KMS key grant on the existing cross-account role.

A team uses AWS CodePipeline to ship a customer-facing service. Builds and automated tests run without human involvement, but the company requires that a release manager sign off in writing before any change reaches the production deploy stage, and the sign-off must be captured as part of the pipeline run. The team wants the most native way to pause the pipeline for that approval and record who approved it, without bolting on an external workflow tool. Which approach meets the requirement?

• AInsert a Lambda invoke action that emails the release manager and then sleeps in a polling loop until a reply arrives, parsing the inbox to decide whether the pipeline should continue to production.
• BAdd a manual approval action as a stage gate before the production deploy stage, so the pipeline pauses until an authorised user approves or rejects, and the decision and approver are recorded in the action history.check_circle Correct
• CConfigure the production deploy stage to start only on a schedule during business hours, on the assumption that the release manager will be watching the pipeline whenever a deployment can run.
• DRequire the release manager to disable the transition into the production stage by default and re-enable it by hand for each release, treating the enable click as the approval record.

Why A is wrong: An email-parsing Lambda is a fragile hand-rolled workflow that risks long-running invocations and weak audit trails, which is exactly the external tooling the team wants to avoid when a native approval action exists.

Why B is correct: A CodePipeline manual approval action pauses the pipeline at that point, requires an authorised user to approve or reject with an optional comment, and records the approver and outcome in the run history, which is exactly the native sign-off control the requirement describes.

Why C is wrong: A schedule controls timing but captures no explicit sign-off and does not pause for a decision, so it cannot satisfy a requirement for a recorded written approval before production.

Why D is wrong: Disabling a stage transition stops automatic flow but logs no approver identity or comment, so it provides weaker auditing than a manual approval action and relies on manual toggling for every run.

A company has one AWS CodePipeline that builds an application in eu-west-1 and must deploy the same artifact to AWS resources in both eu-west-1 and us-east-1 as separate deploy actions. The deploy action in us-east-1 fails because CodePipeline cannot find the build artifact in that Region. The team wants the pipeline to deploy reliably to both Regions while keeping a single pipeline definition. Which configuration is required for the cross-Region deploy action to work?

• ASwitch the pipeline to polling-based source detection so the artifact is re-downloaded in each Region on every run, ensuring the us-east-1 deploy action can always locate a fresh copy of the build output.
• BMove both deploy actions into a single stage with the same runOrder so they execute in parallel, which CodePipeline interprets as a signal to replicate the artifact into every Region automatically.
• CDefine an artifact store in us-east-1 in addition to the home Region, so CodePipeline copies the build artifact into the us-east-1 bucket and the cross-Region deploy action can read it locally.check_circle Correct
• DRecreate the build in us-east-1 as a second source-and-build pipeline, then chain it after the first, because a single CodePipeline cannot perform a deploy action in a Region other than its home Region.

Why A is wrong: Source detection mode governs how new commits trigger the pipeline, not where artifacts live per Region, so changing it does nothing to place the artifact in us-east-1 for the cross-Region deploy.

Why B is wrong: Parallel runOrder only controls execution sequence within a stage and never triggers cross-Region artifact replication, so the us-east-1 action would still fail to find the artifact.

Why C is correct: A cross-Region CodePipeline action requires an artifact store configured in each Region it acts on; CodePipeline then replicates the artifact into the us-east-1 bucket so the deploy action there can read it, fixing the missing-artifact failure within one pipeline.

Why D is wrong: CodePipeline does support cross-Region actions in one pipeline, so splitting into two pipelines is unnecessary duplication that contradicts the goal of a single pipeline definition.

A platform team manages a production VPC stack with "AWS CloudFormation". The stack contains a hand-tuned security group whose rules must never be altered or deleted by a routine template update, while the rest of the stack should still accept ordinary changes through the pipeline. The team wants a guardrail that lives with the stack itself rather than relying on reviewers to spot risky diffs. Which approach BEST protects that one resource while leaving the remainder of the stack updatable?

• AAdd a "DeletionPolicy" of "Retain" to the security group so that the resource is preserved whenever the production stack is updated by the pipeline.
• BAttach a stack policy that denies "Update:Modify" and "Update:Delete" on the security group logical ID while allowing updates to all other resources.check_circle Correct
• CEnable termination protection on the stack so that no resource inside it can be changed during a pipeline-driven update.
• DMove the security group into a separate nested stack and mark that nested stack resource with "Update:Replace" denied in the parent.

Why A is wrong: "DeletionPolicy" only controls what happens when a resource is removed from the template or the stack is deleted; it does not block in-place modification, so it fails the no-alteration requirement here.

Why B is correct: A stack policy is evaluated during every stack update and can deny modify and delete on a specific logical ID while permitting changes elsewhere, giving an in-stack guardrail that needs no human review.

Why C is wrong: Termination protection only blocks deletion of the whole stack; it is tempting as a safety switch but does nothing to prevent updates to an individual resource during a normal update.

Why D is wrong: Splitting the resource out adds structure but still permits modification, and a deny on replace alone does not stop modify or delete, so the protected rule could still be altered.

An engineer must apply a template change to a busy production database stack managed by "AWS CloudFormation". Leadership requires sign-off on exactly which resources will be added, modified or replaced before anything happens, because an unintended replacement of the database would cause downtime. The engineer wants the deployment pipeline to surface that impact for review and only proceed once approved. Which mechanism MOST directly provides this preview-then-approve workflow?

• ARun "cfn-lint" against the template in the pipeline so that static validation reports any resource that would be replaced before the update is applied.
• BEnable drift detection on the stack before the update so that the pipeline reports differences between the template and the deployed resources for review.
• CCreate a change set for the update, have the pipeline pause for approval after the change set lists the affected resources, then execute the change set once approved.check_circle Correct
• DDeploy the change directly with a stack policy that denies replacement on the database, relying on the failed update to reveal whether a replacement was attempted.

Why A is wrong: Linting catches template syntax and best-practice issues but cannot compute the live resource-level difference against the deployed stack, so it cannot tell reviewers which resources will be replaced.

Why B is wrong: Drift detection compares deployed resources to the last known template, not a proposed new template, so it shows existing drift rather than the impact of the pending update.

Why C is correct: A change set computes the exact resource-level diff including replacements before any change is applied, and execution is a separate step, which is precisely the preview-then-approve flow leadership requires.

Why D is wrong: A stack policy can block a replacement but only at apply time as a failure, which gives no advance preview for human sign-off and risks a disruptive rolled-back update.

A large "AWS CloudFormation" template has grown past 600 resources and repeatedly fails to update because it exceeds template and resource limits, and several teams need to own discrete layers such as networking, security and application tiers independently. The platform team wants reusable, versioned building blocks that a single parent template can compose and update together as one deployment. Which design BEST meets these goals?

• ASplit the layers into separate independent stacks and wire them together at deploy time using exported output values consumed through "Fn::ImportValue".
• BConvert the template into a "StackSet" and deploy each layer as a separate stack instance across the target account so the resource count per stack drops.
• CPublish each layer as a product in "AWS Service Catalog" and let teams launch the products on demand to assemble the overall environment.
• DRefactor the layers into nested stacks referenced by "AWS::CloudFormation::Stack" resources in a parent template, with child templates stored in "Amazon S3".check_circle Correct

Why A is wrong: Cross-stack exports do decouple layers, but exported values become locked and hard to change, and the stacks are deployed separately rather than as one composed unit, missing the single-deployment requirement.

Why B is wrong: StackSets replicate a stack across many accounts or Regions; they solve multi-account roll-out, not composing layered building blocks into one parent deployment in a single account.

Why C is wrong: Service Catalog governs self-service provisioning of approved products, which is tempting for team ownership but does not give a parent template that composes and updates the layers as one coordinated deployment.

Why D is correct: Nested stacks let a parent template compose versioned child templates as reusable building blocks and update them as one deployment, which addresses both the size limits and independent layer ownership.

A company manages around 300 accounts in AWS Organizations grouped into organisational units by environment. Security needs a hard guarantee that no principal in any production account, including account administrators with broad IAM policies, can disable AWS CloudTrail or delete its trails. A previous attempt that relied on attaching an IAM deny policy in each account was bypassed when a team detached the policy. The team wants the most durable control that cannot be removed by account-level administrators. Which approach should they implement?

• AAttach a permission boundary to every IAM role in the production accounts that omits the CloudTrail stop and delete actions, so the boundary caps what those roles can do regardless of their attached policies.
• BDistribute an AWS Config rule to the production accounts that detects when a trail is stopped or deleted and triggers a remediation that recreates it, treating detection and repair as the enforcement mechanism for the requirement.
• CMove all production accounts under a dedicated organisational unit and apply an IAM identity-based deny policy through AWS IAM Identity Center permission sets so every assigned user inherits the CloudTrail restriction centrally.
• DAttach a service control policy to the production organisational unit that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail, so the guardrail applies to every principal in those accounts and cannot be overridden locally.check_circle Correct

Why A is wrong: A permission boundary caps a principal's effective permissions, but it is set within the account and an account administrator can change or remove it, so it does not survive a local admin acting against the control the way an organisation guardrail does.

Why B is wrong: Config with remediation detects and repairs after the fact rather than preventing the action, so there is a window where logging is off, and an account admin can disable the rule, which falls short of a hard preventive guarantee.

Why C is wrong: Identity Center permission sets only constrain principals that sign in through Identity Center, so roles, account root, and locally created users are unaffected, which leaves the very administrators the requirement targets able to stop or delete the trails.

Why D is correct: A service control policy sets the maximum available permissions for every principal in the targeted accounts including account administrators, and it is managed only from the organisation management account, so denying the CloudTrail stop and delete actions there is a preventive guardrail that local admins cannot remove.

A platform team lets application developers create their own IAM roles for Lambda functions through a self-service pipeline. Security requires that no developer-created role can ever grant access outside an approved set of services or escalate its own privileges by attaching administrator policies, yet developers must stay free to add whatever scoped permissions their function needs within that envelope. The team wants the control to travel with each role at creation time and to apply automatically without security reviewing each policy. Which mechanism best enforces this?

• ARequire the pipeline to attach a permission boundary to every developer-created role that allows only the approved services and denies iam:Attach and iam:Put actions, so the boundary caps each role's effective permissions whatever policies developers add.check_circle Correct
• BAttach a service control policy to the developers' account that lists the approved services, relying on the organisation guardrail alone to constrain each role so no per-role control needs to travel with the role itself.
• CHave security review and approve every IAM policy a developer attaches to a role before the pipeline applies it, so a human confirms each grant stays inside the approved services and contains no escalation paths.
• DConfigure an AWS Config rule that flags any developer role whose policies reference services outside the approved set, then notify security so the offending policy can be detached after the role is in use.

Why A is correct: A permission boundary is an advanced policy that sets the maximum permissions an identity-based policy can grant, so attaching one at role creation lets developers add their own scoped policies while the effective permissions can never exceed the approved services or include the privilege-escalation actions the boundary denies.

Why B is wrong: A service control policy caps the whole account uniformly and cannot vary per role, so it cannot let the platform team's own roles keep broad access while constraining only developer-created roles, and it does not block a developer attaching an admin policy within the account's allowed services.

Why C is wrong: A manual review on every policy is exactly the per-policy approval the team wants to avoid, it scales poorly across many developers, and it adds latency without giving the automatic at-creation control the requirement describes.

Why D is wrong: Config detection runs after a role already exists and can act, so it neither prevents an over-broad grant at creation nor stops privilege escalation in the interval before remediation, which fails the requirement for a control that travels with the role from the start.

A central security tooling account runs an automated remediation service that must read configuration and apply fixes in roughly 200 member accounts across AWS Organizations. The team must avoid storing any long-lived credentials, must scope what the tooling can do in each member account, and wants to add new accounts to the programme without redeploying the tooling. They also need every action the tooling takes in a member account to appear in that account's own audit logs. Which design meets these requirements with the least ongoing credential management?

• ACreate one IAM user with programmatic access keys in each member account, share the keys with the tooling account through AWS Secrets Manager, and have the tooling rotate and retrieve a key per account when it needs to act.
• BDeploy a scoped IAM role in every member account that trusts the tooling account, and have the tooling call AWS STS AssumeRole to obtain short-lived credentials for each target account before it reads and remediates.check_circle Correct
• CConfigure the tooling's execution role with a resource-based policy on each member account's resources granting cross-account access directly, so the tooling acts on remote resources without assuming any role in the member accounts.
• DUse AWS IAM Identity Center to assign the tooling a permission set in every member account, then have the tooling sign in through Identity Center to obtain a session in each account before it remediates.

Why A is wrong: Long-lived IAM user access keys are exactly what the requirement forbids, and managing, rotating, and securely distributing a key per account across 200 accounts is heavy credential management that role assumption is designed to remove.

Why B is correct: A cross-account role with a trust policy naming the tooling account lets the tooling call AssumeRole for temporary credentials scoped by the role's permissions, stores no long-lived secrets, and runs the API calls as a principal in the member account so they land in that account's own CloudTrail; new accounts join by deploying the same role, for example through a StackSet, with no change to the tooling.

Why C is wrong: Resource-based cross-account grants do not exist for most services a remediation tool touches, the calls would be attributed to the tooling account rather than the member account's own logs, and maintaining per-resource policies everywhere is far more work than one assumable role per account.

Why D is wrong: Identity Center is built for human workforce sign-in rather than an unattended service calling APIs, so wiring an automated remediation service through an interactive sign-in flow is the wrong tool and adds operational complexity compared with direct STS role assumption.

A team runs a stateless web service in a single Amazon EC2 Auto Scaling group fronted by an Application Load Balancer, but every instance and both load balancer nodes currently sit in one Availability Zone. An architecture review flags that the loss of that Availability Zone would take the whole service offline, and the business now requires the tier to keep serving if any single Availability Zone fails. The team wants the most direct configuration changes to make the existing tier survive a zonal failure. Which TWO actions together meet this requirement? (Select TWO.)

• AExtend the Auto Scaling group to span subnets in at least two more Availability Zones so it launches and balances instances across multiple zones.check_circle Correct
• BAdd the subnets of the additional Availability Zones to the Application Load Balancer so it provisions nodes and routes to targets in every chosen zone.check_circle Correct
• CReplace the Application Load Balancer with a Gateway Load Balancer so that traffic is inspected by appliances before it reaches the web instances in the zone.
• DEnable termination protection on the running instances so the Auto Scaling group cannot remove them when an Availability Zone becomes impaired.

Why A is correct: Spreading the Auto Scaling group across multiple Availability Zone subnets means a zonal failure removes only part of the fleet, and the group relaunches the lost capacity in the surviving zones.

Why B is correct: Enabling extra Availability Zone subnets on the load balancer gives it nodes in each zone, so the public endpoint stays reachable and can route to healthy targets even when one zone is lost.

Why C is wrong: A Gateway Load Balancer fronts third-party inspection appliances rather than balancing web traffic, so it is tempting as a load balancer swap but does nothing to spread the web tier across Availability Zones.

Why D is wrong: Termination protection looks like a way to keep capacity, but it only blocks manual termination and cannot keep instances alive when their Availability Zone fails, leaving the single-zone exposure in place.

A team runs a stateful relational database for a payments service on a single Amazon RDS instance in one Availability Zone. A recent zonal hardware event took the database offline for over an hour, and the business now requires that an Availability Zone failure trigger an automatic failover with no application code changes and minimal recovery time. The team wants the lowest operational overhead while meeting this requirement. Which approach should they choose?

• ACreate a cross-Region read replica of the RDS instance in a second AWS Region and promote that replica to a standalone primary manually whenever the original Availability Zone becomes unavailable.
• BSchedule automated RDS snapshots every fifteen minutes and write a runbook so an operator can restore the latest snapshot into a healthy Availability Zone after an outage is detected.
• CConvert the RDS instance to a Multi-AZ deployment so AWS maintains a synchronous standby in a second Availability Zone and automatically fails over to it when the primary Availability Zone is impaired.check_circle Correct
• DAdd an in-Region RDS read replica in a second Availability Zone and point the application at the replica endpoint so reads continue if the primary Availability Zone fails.

Why A is wrong: A cross-Region read replica protects against Regional loss but promotion is a manual step that adds recovery time, and it addresses a different blast radius than the single-AZ failure the requirement actually targets.

Why B is wrong: Frequent snapshots reduce data loss but restoring one is a manual, slow operation that misses the automatic-failover and minimal-recovery-time requirement, leaving the service down while the restore runs.

Why C is correct: Multi-AZ keeps a synchronous standby in another Availability Zone and performs an automatic DNS-based failover on a zonal fault, meeting the requirement with no code change and the least operational overhead.

Why D is wrong: A read replica serves reads only and cannot accept writes without manual promotion, so a payments database that needs writes after an AZ loss is not protected by this design.

An order-processing web tier runs behind an Application Load Balancer across three Availability Zones in an Amazon EC2 Auto Scaling group. During a deployment, several instances passed the load balancer health check on the TCP port but were returning HTTP 500 errors because a downstream dependency was misconfigured, so the load balancer kept sending them traffic. The team wants the load balancer to stop routing to an instance whenever the application itself reports unhealthy. Which change should they make?

• AReduce the target group deregistration delay to zero seconds so failing instances are removed from the load balancer immediately once the deployment marks them as outdated.
• BSwitch the load balancer from an Application Load Balancer to a Network Load Balancer so faster Layer 4 health checks can detect the failing instances and remove them from the target group.
• CAttach a CloudWatch alarm on the HTTPCode_Target_5XX_Count metric and have it terminate the Auto Scaling group when the error count crosses a threshold during the deployment.
• DConfigure the target group health check to use the HTTP protocol against an application health endpoint that returns a non-200 status when a downstream dependency is unavailable, so unhealthy targets are removed from rotation.check_circle Correct

Why A is wrong: Deregistration delay only controls connection draining when a target is deliberately removed; it does nothing to detect an instance that is silently returning errors while still passing the port check.

Why B is wrong: A Network Load Balancer operates at Layer 4 and cannot inspect HTTP status codes, so it would still treat an instance returning 500 errors as healthy as long as the port accepts connections.

Why C is wrong: An aggregate error alarm reacts after the fact and cannot identify which individual targets are unhealthy, and terminating the whole group removes good instances rather than draining the specific failing ones.

Why D is correct: An HTTP health check against a dependency-aware endpoint lets the application signal its true state, so the load balancer drains targets returning errors rather than trusting a shallow port check that ignores application failures.

A DevOps team runs a fleet of Amazon EC2 instances behind an Auto Scaling group and needs to alarm when an instance is short of available memory or when its root disk passes 85 percent used. The default Amazon EC2 metrics that Amazon CloudWatch publishes do not expose either value, and the team wants these metrics in CloudWatch with the least ongoing maintenance so existing CloudWatch alarms can act on them. Which approach should they implement?

• AWrite a cron job on each instance that reads memory and disk usage from the operating system and calls the CloudWatch PutMetricData API with custom metric values on a fixed schedule for every host.
• BInstall the Amazon CloudWatch agent on the instances and bake a unified agent configuration into the launch template so memory and disk metrics are published to CloudWatch as the group scales.check_circle Correct
• CEnable detailed monitoring on the Auto Scaling group so Amazon CloudWatch collects memory and disk metrics from each instance at one-minute resolution without any additional software on the hosts.
• DEnable AWS Compute Optimizer on the account so it analyses the Auto Scaling group and publishes the memory and disk utilisation of each instance into Amazon CloudWatch for alarming.

Why A is wrong: A hand-rolled cron and PutMetricData script does surface the values, but it is bespoke code the team must patch, secure, and maintain on every host, which is the high-maintenance path the requirement explicitly rules out.

Why B is correct: The CloudWatch agent is the managed way to collect guest-level memory and disk metrics, and shipping its configuration in the launch template means every scaled instance self-configures with no per-host code to maintain.

Why C is wrong: Detailed monitoring only raises the publishing frequency of the existing hypervisor-level EC2 metrics to one minute; it never adds guest memory or disk-usage metrics, which the hypervisor cannot observe.

Why D is wrong: Compute Optimizer produces right-sizing recommendations from historical data and does not stream live memory or disk metrics into CloudWatch, so no CloudWatch alarm could fire from its output.

A DevOps team runs a fleet of around 300 Amazon EC2 instances in an Auto Scaling group, all managed by AWS Systems Manager. Operations need to alarm on available memory and on root-disk used percentage, but the default Amazon EC2 metrics that Amazon CloudWatch publishes expose neither value. The configuration must apply identically to instances the Auto Scaling group launches later, and the team wants the lowest ongoing maintenance so that existing CloudWatch alarms can act on the metrics. Which TWO actions together meet this requirement? (Select TWO.)

• AInstall and run the Amazon CloudWatch agent on the instances so it collects the memory and disk metrics that the hypervisor cannot see and publishes them to Amazon CloudWatch.check_circle Correct
• BEnable detailed monitoring on the Auto Scaling group launch template so Amazon CloudWatch reports the instance metrics at one-minute granularity instead of five.
• CStore the agent configuration in Systems Manager Parameter Store and push it to the fleet with a State Manager association so new instances receive the same collection settings automatically.check_circle Correct
• DSchedule a per-instance cron job that reads memory and disk usage and calls the PutMetricData API to send the values into Amazon CloudWatch as custom metrics.

Why A is correct: The CloudWatch agent reads in-guest counters such as available memory and disk used percentage, which the default EC2 metrics omit, and emits them to CloudWatch where alarms can evaluate them.

Why B is wrong: Detailed monitoring only raises the reporting frequency of the existing EC2 metrics and is tempting for finer alarms, but it never adds memory or disk metrics because those are not collected from inside the guest.

Why C is correct: A Parameter Store agent config applied through a State Manager association installs and configures the agent consistently on current and newly launched instances with no per-host manual step.

Why D is wrong: A cron job with PutMetricData can emit the values and looks workable, but it is bespoke code to maintain on every host and is not reapplied to new Auto Scaling instances, raising overhead rather than lowering it.

An application writes its logs to Amazon CloudWatch Logs, and each authentication failure produces a log line containing the token "AuthFailure". The security team wants an alarm to notify them through Amazon SNS when more than fifty such lines appear within five minutes, and they want to reuse the log data already in CloudWatch Logs rather than introduce a separate pipeline. What is the most appropriate way to achieve this?

• AStream the log group to Amazon OpenSearch Service through a subscription filter, then schedule an OpenSearch alert that counts "AuthFailure" documents over five minutes and publishes to the Amazon SNS topic.
• BRun a CloudWatch Logs Insights query on a five-minute schedule with Amazon EventBridge to count "AuthFailure" entries and invoke a Lambda function that publishes to the Amazon SNS topic when the count is high.
• CCreate a metric filter on the log group that matches "AuthFailure", emit a custom metric, and attach a CloudWatch alarm that notifies the Amazon SNS topic when the metric exceeds fifty over five minutes.check_circle Correct
• DConfigure a CloudWatch Logs subscription filter that matches "AuthFailure" and delivers each matching event straight to the Amazon SNS topic so the team is notified on every authentication failure.

Why A is wrong: Streaming to OpenSearch and running an alerting query works, but it stands up and maintains a separate search cluster and pipeline, which is more operational overhead than the in-place CloudWatch capability the requirement points to.

Why B is wrong: A scheduled Insights query plus a Lambda function is plausible, but it adds custom polling and code to maintain when a metric filter and alarm deliver the same alerting natively without writing or operating any function.

Why C is correct: A metric filter turns matching log events into a CloudWatch metric directly inside CloudWatch Logs, and a standard alarm on that metric with an SNS action meets the threshold requirement with no extra pipeline.

Why D is wrong: Subscription filters cannot target SNS and would page on every single event rather than on a count, so they neither support the destination nor honour the more-than-fifty-in-five-minutes threshold.

A security team wants every change to an Amazon S3 bucket policy across the account to trigger an automated response. The team has confirmed that AWS CloudTrail management events are delivered to the default event bus. They need an Amazon EventBridge rule that runs only when a PutBucketPolicy API call occurs, and they want the matched event passed to an AWS Lambda function that evaluates the new policy. With the least custom code, how should the rule be built?

• ACreate an EventBridge rule with an event pattern that matches the aws.s3 event source and the PutBucketPolicy event name, then add the Lambda function as a target so the function receives the matched CloudTrail event directly.check_circle Correct
• BCreate an EventBridge rule with a schedule expression that fires every five minutes and targets a Lambda function that scans CloudTrail logs for any recent PutBucketPolicy call before evaluating the bucket policy.
• CConfigure an Amazon S3 event notification on each bucket for the s3:ObjectCreated event type and route it to the Lambda function, which then reads the current bucket policy and evaluates it.
• DCreate an EventBridge rule that matches all events from the aws.s3 source, then have the Lambda target inspect each event and discard anything that is not a PutBucketPolicy call before evaluating the policy.

Why A is correct: An event pattern keyed on the source and the specific eventName matches only the PutBucketPolicy call, and naming the function as a target delivers the matched event as the payload, so EventBridge does the filtering and invocation with no extra code.

Why B is wrong: A scheduled rule polling CloudTrail can find the call eventually, but it adds latency and log-scanning code, whereas the requirement is an event-driven match on the API call with the least custom logic.

Why C is wrong: S3 event notifications report object-level activity such as ObjectCreated, not bucket policy changes, so this never fires on PutBucketPolicy and fails to detect the management action in scope.

Why D is wrong: Matching every S3 event then filtering inside the function works but invokes Lambda needlessly on unrelated calls and pushes filtering into code, when an event pattern can match only PutBucketPolicy at the rule.

A platform team routes Amazon GuardDuty findings through an Amazon EventBridge rule on the default event bus to an AWS Lambda target that runs containment logic. During a recent incident the Lambda target was throttled and several finding events were silently lost, and the team also wants to be paged when delivery to the target keeps failing. They need both durable retention of any event the target cannot accept and a signal that deliveries are failing, with the least custom code. Which TWO actions together meet this requirement? (Select TWO.)

• AConfigure a dead-letter queue on the EventBridge rule's target so events that exhaust the delivery retries are stored in an Amazon SQS queue for later inspection and reprocessing.check_circle Correct
• BCreate an Amazon CloudWatch alarm on the rule target's FailedInvocations metric that publishes to an Amazon SNS topic the on-call responders are subscribed to.check_circle Correct
• CIncrease the Lambda function's reserved concurrency to a very high value and disable the EventBridge retry policy so events are delivered in a single immediate attempt.
• DEnable archive and replay on the event bus so every finding event is stored, and rely on a manual replay each time the team notices that the target dropped an event.

Why A is correct: A target-level dead-letter queue captures any event EventBridge cannot deliver after its retry policy is exhausted, which is the native way to stop losing finding events when the Lambda target fails.

Why B is correct: EventBridge emits a FailedInvocations metric per rule, so an alarm on it publishing to an SNS topic pages responders the moment delivery to the target keeps failing, with no polling code.

Why C is wrong: Raising concurrency may reduce throttling, but disabling retries removes the safety net entirely, so any transient target failure still loses the event rather than retaining it durably.

Why D is wrong: Archive and replay retains events for replay, but it stores all matching traffic rather than only undeliverable events and depends on a human noticing the drop, which is slower than a dead-letter queue and an alarm.

An EventBridge rule invokes an AWS Lambda function whenever Amazon GuardDuty raises a finding. During an incident the function began failing because a downstream dependency was unavailable, and the team discovered that several finding events were lost with no record of them. They want any event that the target cannot process successfully to be retained for later inspection and reprocessing, configured with the least operational overhead. What should they do?

• AIncrease the Lambda function timeout and reserved concurrency so the function has more time and capacity to retry the downstream dependency before EventBridge gives up on delivering each finding event.
• BConfigure a dead-letter queue on the EventBridge rule target so that events EventBridge cannot deliver to the Lambda function after its retry attempts are written to an Amazon SQS queue for later inspection and reprocessing.check_circle Correct
• CAdd an Amazon SNS topic as a second target on the rule so that every finding event is also published to subscribers, giving the team a copy of each event regardless of whether the Lambda target succeeds.
• DEnable EventBridge archive on the event bus and set a long retention period, then replay the entire archive whenever the team needs to recover events that the Lambda function failed to process.

Why A is wrong: More timeout and concurrency may reduce some failures, but it does nothing to retain an event once delivery is finally exhausted, so findings can still be lost without any record for inspection.

Why B is correct: A dead-letter queue on the target captures any event EventBridge fails to deliver after retries, writing it to an SQS queue where the team can inspect and replay it, which is the managed way to stop losing finding events.

Why C is wrong: A parallel SNS target copies every event whether or not Lambda succeeds, but SNS does not retain undelivered messages for replay, so it neither isolates failures nor supports reprocessing the lost events.

Why D is wrong: An archive retains all matched events, not just failures, so recovering only the failed findings means replaying and re-filtering everything, which is far more overhead than a target dead-letter queue.