Professional-level AWS certification for designing and automating delivery pipelines, infrastructure as code, resilience, observability and security at scale on AWS, with a worked explanation on every practice question.
Free sample questions
No account needed. Every question has a worked explanation, just like the full bank.
lock_openFree sampleSDLC Automationmedium
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.
For cross-account CodePipeline deploys with a customer managed KMS key, the target role needs both assume-role trust and key-usage rights to decrypt artifacts. When a CodePipeline artifact store uses a customer managed AWS KMS key, any cross-account role that reads those artifacts must be listed as a key user in the key policy in addition to having S3 read access and assume-role trust; without the KMS grant the deploy action gets access denied even though the IAM role exists.
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.
lock_openFree sampleSDLC Automationmedium
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.
Use a CodePipeline manual approval action to pause a pipeline for a recorded human sign-off before a sensitive deploy stage. CodePipeline supports a manual approval action that halts the pipeline until an authorised principal approves or rejects, optionally with a comment and an SNS notification; the approver identity and decision are kept in the action execution history, giving a native, auditable sign-off gate before production.
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.
lock_openFree sampleSDLC Automationmedium
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.
Cross-Region CodePipeline actions require an artifact store defined in every Region the pipeline acts on so artifacts are replicated locally. When a CodePipeline has actions in more than one Region, an artifact store must be configured for each of those Regions; CodePipeline copies the input artifact into the bucket of the Region where the action runs, so a us-east-1 deploy action can read the replicated artifact rather than failing to find it.
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.
Examworthy is not affiliated with or endorsed by Amazon Web Services. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. DOP-C02 and related marks belong to their respective owners.
