A CodePipeline pipeline triggers from changes to the main branch in CodeCommit, uses CodeBuild for build/test stages, and uses CodeDeploy for deployment. After a recent source change, CodeDeploy did not deploy the updated application. Which two explanations are possible? (Choose two.)

The code change not being committed to the repository's main branch is a direct cause for the pipeline not triggering. CodePipeline is configured to trigger on changes to the main branch; if the changes are in a different branch or not committed at all, the pipeline won't start, and thus CodeDeploy won't run. An earlier pipeline stage failing would also prevent CodeDeploy from executing. CodePipeline stages execute sequentially, and a failure in an upstream stage (like CodeBuild's build or test stage) will halt the pipeline's execution, preventing it from reaching subsequent stages, including the CodeDeploy stage. An inactive EC2 instance in the CodePipeline cluster is incorrect because CodePipeline itself doesn't run on an EC2 cluster; it orchestrates services. CodeDeploy might use EC2 instances for deployment targets, but an inactive instance wouldn't prevent CodeDeploy from being invoked by CodePipeline, only from successfully deploying to that specific instance. An incorrect pipeline configuration where CodeDeploy is not invoked would prevent deployment, but the question implies the pipeline should include CodeDeploy, making this less likely than a failure or missing trigger. CodePipeline not having permissions to read from CodeCommit would prevent the pipeline from starting at all, which is a different scenario than CodeDeploy not deploying after a source change.