DOP-C02 SDLC Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use a Lambda function as a source action instead of GitHub.

  Why it's wrong here

  Using a custom Lambda function as the source action instead of a GitHub source action is unnecessarily complex. CodePipeline natively supports GitHub sources with automatic webhook integration and branch filtering, so a Lambda would have to duplicate that logic—fetching commit metadata, invoking StartPipelineExecution, and handling errors—without adding value. It also introduces extra Lambda invocation costs and additional failure points, and it loses the built-in change metadata visible in the pipeline console.

• ✗

  Create a GitHub webhook manually and point it to a Lambda function that starts the pipeline only for main branch pushes.

  Why it's wrong here

  Creating a manual GitHub webhook and pointing it at a Lambda function to start the pipeline only for main-branch pushes is an anti-pattern because CodePipeline already manages that webhook automatically when you configure a GitHub source action with source code change detection enabled. A manual webhook requires you to validate GitHub signatures, filter push events, and ensure idempotent StartPipelineExecution calls, which is fragile and redundant. Any misconfiguration could cause missed or duplicate pipeline runs, whereas the managed webhook enforces the branch filter at the platform level.

• ✓

  Configure the source action's 'Branch' field to 'main' and set 'PollForSourceChanges' to false, and use a webhook with filters.

  Why this is correct

  This is the correct approach. Setting the source action's Branch field to 'main' and disabling PollForSourceChanges ensures that the pipeline uses the CodePipeline-managed GitHub webhook instead of legacy polling, preventing duplicate executions. The webhook is configured with event filters that only forward push events for refs/heads/main, so the pipeline starts only when the default/main branch is updated. This gives you native, real-time triggering without custom code and without starting pipelines for other branches.

• ✗

  Add a condition in the pipeline's first stage to check the branch name.

  Why it's wrong here

  Adding a condition in the first stage is not a valid mechanism to prevent the pipeline from being triggered by commits to non-main branches. A pipeline execution is already created and the source action runs before any stage condition evaluates, so a condition will only cause the stage to fail after the fact—it does not stop the trigger. Conditions are designed to gate stage transitions based on criteria like variables or manual approvals, not to act as a branch filter for incoming source events.

Go deeper

Related to this question