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.

• ✓

  Enable encryption for artifacts stored in the pipeline's S3 bucket.

  Why this is correct

  By enabling default encryption on the S3 bucket used as CodePipeline's artifact store—or specifying an AWS KMS customer-managed key in the pipeline settings—all build outputs and source artifacts are encrypted at rest with either SSE-S3 or SSE-KMS. This protects sensitive data from unauthorized direct access to the bucket, even if the bucket policy or ACL is misconfigured. Using KMS adds an additional layer of control by letting you restrict which roles can decrypt artifacts and enabling CloudTrail auditing of all decrypt operations.

• ✓

  Use cross-account actions with appropriate IAM roles to limit access.

  Why this is correct

  Configuring cross-account actions with dedicated IAM roles in each target account limits access by having the pipeline assume a role with a tightly scoped policy rather than relying on shared long-term credentials. The assumed role grants only the exact permissions needed for that action and destination, such as deploying to an ECS service or uploading to a specific S3 bucket. This follows the principle of least privilege and reduces the impact if one role is compromised, because the pipeline cannot directly act in other accounts without assuming the appropriate role.

• ✗

  Configure the source action to poll for changes instead of using webhooks.

  Why it's wrong here

  Switching the source action from webhooks to polling is less secure because the pipeline must repeatedly authenticate to the repository using stored credentials, which remain valid and can be stolen from the pipeline's environment or logs. Webhooks are push-based and can include a shared secret token so the pipeline only accepts verified events from the source provider, eliminating the need for long-lived credentials exposed to the pipeline. Polling also introduces unnecessary risk of unauthorized changes being picked up due to missing webhook validation.

• ✗

  Store secrets in the pipeline environment variables in plain text.

  Why it's wrong here

  Storing secrets directly in pipeline environment variables as plain text makes them visible to anyone with read access to the pipeline definition and risks leaking them in build logs or to third-party actions. Secrets such as API keys, database credentials, or signing tokens should instead be fetched dynamically from AWS Secrets Manager or Systems Manager Parameter Store at runtime, using IAM roles to control access. This approach supports secret rotation, keeps sensitive values out of the pipeline code, and ensures they are never written to storage in a recoverable format.

• ✗

  Use a single IAM role for all pipeline actions to simplify permissions.

  Why it's wrong here

  Assigning a single IAM role to all pipeline actions obliges that role to carry the union of every action's permissions, so any stage that is compromised (e.g., a malicious build script) can abuse broad privileges to access unrelated resources or other accounts. This violates the principle of least privilege because the role is far more powerful than any one action needs. Instead, define granular roles per stage—source, build, and deploy—so that the blast radius of a compromise is limited to the specific resources each action is permitted to touch.

Go deeper

Related to this question