DVA-C02 Deployment Practice Question

Exhibit

Refer to the exhibit.

IAM Policy:
```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codecommit:GitPull",
                "codecommit:GitPush"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "codepipeline:StartPipelineExecution"
            ],
            "Resource": "arn:aws:codepipeline:us-east-1:123456789012:MyPipeline"
        }
    ]
}
```

Refer to the exhibit. A developer has the above IAM policy attached. The developer is trying to push code to a CodeCommit repository and trigger a CodePipeline. The push succeeds but the pipeline does not start. What is the most likely reason?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The CloudWatch Events rule that triggers the pipeline on code push does not have the necessary IAM role to invoke the pipeline.

The pipeline is triggered by a CloudWatch Events rule that monitors code push events. For the rule to invoke the pipeline, it must have an IAM role with permission to start the pipeline. If that role is missing or lacks permissions, the pipeline won't start even though the developer has push permissions. Option A is incorrect because the developer's policy allows GitPush, so push succeeds. Option C is incorrect because the developer has StartPipelineExecution permission, but that's not how the pipeline is triggered—it's an event-driven trigger. Option D is incorrect because CodeCommit does not require a trigger to be configured; the CloudWatch Events rule handles the event.

Answer analysis

Option-by-option breakdown

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

✗
The developer does not have permissions to push to the repository.
Why it's wrong here
The developer's IAM policy, as described in the exhibit, explicitly grants the "codecommit:GitPush" action. This specific permission is precisely what allows an IAM principal to successfully push code changes to a CodeCommit repository. Therefore, the developer possesses the necessary authorization to perform the push operation, making this statement incorrect as the root cause of a failure.
✓
The CloudWatch Events rule that triggers the pipeline on code push does not have the necessary IAM role to invoke the pipeline.
Why this is correct
While the developer has permissions to push code, the automated trigger mechanism relies on a CloudWatch Events rule. This rule, when detecting a code push event, attempts to invoke CodePipeline. For this invocation to succeed, the CloudWatch Events rule itself must be associated with an IAM role that possesses "codepipeline:StartPipelineExecution" permissions on the target pipeline. Without this specific service-level permission, the rule cannot initiate the pipeline, even if the developer has their own permissions.
✗
The developer does not have permissions to start the pipeline.
Why it's wrong here
The developer's IAM policy, as indicated, includes the "codepipeline:StartPipelineExecution" action for the specified CodePipeline resource. This permission directly authorizes the developer to manually initiate an execution of the pipeline. The problem is not with the developer's ability to start the pipeline directly, but rather with the automated process that is supposed to trigger it on their behalf after a code push.
✗
The CodeCommit repository does not have a trigger configured.
Why it's wrong here
CodeCommit repositories do not have built-in "trigger" configurations that directly invoke CodePipeline. Instead, the standard AWS practice for automating pipeline starts on code pushes involves using CloudWatch Events (or Amazon EventBridge). A CloudWatch Events rule is configured to monitor specific CodeCommit events (e.g., ReferenceCreated, ReferenceUpdated) and then target a CodePipeline. Therefore, the issue is not a missing direct repository trigger, but rather a potential misconfiguration or permission issue within the CloudWatch Events setup.

Go deeper

DVA-C02 Deployment Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question