AWS 1: SDLC Automation: 187 practice questions

12 of the 187 1: SDLC Automation questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Use one CodePipeline and CodeBuild: Which design best satisfies these requirements?

1. Create separate CodePipelines in every account, rebuild from the shared repository independently, and use account-local keys without cross-account role assumptions.

   Separate pipelines increase management overhead, independent builds can differ, and the design lacks the required auditable cross-account access model.
2. Use a shared S3 artifact bucket with default encryption, grant deployment accounts broad bucket administration, and deploy from copied artifacts.

   Default encryption and broad bucket administration do not provide the required customer-managed key controls or least-privilege auditable access.
3. Use one CodePipeline and CodeBuild, build once, encrypt artifacts with a customer-managed KMS key, use scoped cross-account roles, and approve production before deployment. ✓

   The centralized pipeline creates one artifact, encrypts it with a customer-managed key, and promotes it through cross-account roles. A manual approval before the production action provides the required control without rebuilding.
4. Store deployment credentials in encrypted repository variables, rebuild the application in each target account, and approve production after deployment starts.

   Repository credentials remain long-lived secret material, independent builds violate identical-artifact promotion, and approval occurs too late.

Centralize CodePipeline and CodeBuild, encrypt one artifact with a customer-managed KMS key, and promote it through approved cross-account roles.

2. Trigger CodePipeline from an immutable commit: Which deployment design is most appropriate?

1. Trigger CodePipeline from a branch head, retrieve tenant settings from Secrets Manager, and rebuild the image separately for each environment.

   A mutable branch head and separate environment builds do not reliably identify the exact staged commit or preserve the validated binary.
2. Trigger CodePipeline from an immutable commit, build once, retrieve tenant settings from Secrets Manager, and promote that artifact. ✓

   This identifies the revision, externalizes tenant configuration, promotes one immutable artifact, and supports rollback by redeploying an earlier artifact.
3. Use Git tags to trigger CodeBuild, embed tenant settings during compilation, and deploy each environment from its own image.

   Embedding tenant settings violates the requirement that configuration not be committed, and environment-specific images prevent identical-artifact promotion.
4. Create one pipeline per tenant, rebuild from the selected commit for every environment, and store deployment credentials in repository configuration.

   Per-environment rebuilds violate identical-artifact promotion, while repository configuration is an inappropriate location for deployment credentials.

Build once from an immutable commit, externalize tenant settings, and promote the same artifact.

3. Use CodeBuild with the release buildspec path: Which configuration best meets these requirements?

1. Build locally, upload the image to ECR, and publish test reports in a later CodePipeline action.

   Local builds reduce reproducibility, and publishing reports later cannot reliably prevent an image from being published after failed tests.
2. Use CodeBuild with a pinned runtime and cache, publish the image during post_build, then upload reports and preserve the test command's failure status.

   Publishing the image before the final test result allows a failed test to occur after publication, so the release gate is not enforced.
3. Keep the root buildspec, select release behavior with variables, and continue after test failures so report collection can finish.

   This does not explicitly select the configuration-directory buildspec and allows failed tests to produce a successful build.
4. Use CodeBuild with the release buildspec path, pinned runtimes, dependency caching, reports, and a test command that fails the build. ✓

   CodeBuild supports an alternate buildspec path, pinned runtime versions, caching, reports, and failure propagation through nonzero test status.

Select the release buildspec explicitly, pin runtimes, cache dependencies, publish reports, and preserve test failures.

4. Store rotating credentials in AWS Secrets Manager: Select TWO actions that best satisfy the requirements.

Select two. More than one option is correct — every correct one is ticked below.

1. Store rotating credentials in AWS Secrets Manager and grant only the relevant build or deployment role access. ✓

   Secrets Manager supports managed secret storage and rotation, while IAM roles restrict access to the required execution context.
2. Reference secrets through CodeBuild buildspec secrets-manager mappings instead of embedding secret values in repository files. ✓

   CodeBuild can retrieve Secrets Manager values at runtime, preventing plaintext repository storage and supporting masked secret handling.
3. Use encrypted environment variables in each CodeBuild project and rotate values by editing project configuration manually.

   Project environment encryption protects storage but manual rotation is operationally weak and does not separate deployment credentials cleanly.
4. Commit encrypted credential files to each repository and decrypt them using the CodeBuild service role.

   Encrypted files still create repository-managed secrets and broaden exposure, while service-role decryption complicates access auditing.
5. Place all credentials in Systems Manager Parameter Store Standard parameters and grant every project role read access.

   Broad read access violates least privilege, and Standard parameters do not provide the requested secret rotation capability by themselves.

Use Secrets Manager with scoped IAM access and CodeBuild runtime mappings, keeping rotating secrets outside repositories.

5. Use CodeDeploy ECS blue/green with canary shifting: Which deployment strategy should the team implement?

1. Use CodeDeploy EC2 in-place deployment configuration for the ECS container instances, then monitor alarms during replacement.

   EC2 deployment configurations manage instances, not ECS task-set traffic shifting through the load balancer.
2. Use CodeDeploy ECS blue/green with canary shifting, alarms, approval, and the same image. ✓

   The ECS compute platform supports replacement task sets, canary traffic shifting, alarm-based stopping or rollback, approval before the deployment action, and reuse of the tested image.
3. Use an ECS rolling update, pause for approval, and inspect application logs after shifting a small percentage of traffic.

   An ECS rolling update does not provide the required CodeDeploy canary task-set traffic shifting or equivalent alarm-controlled exposure.
4. Use an all-at-once ECS deployment, require approval afterward, and rebuild the prior image if rollback becomes necessary.

   All-at-once exposure violates the limited-initial-traffic requirement, approval occurs too late, and rebuilding violates immutable artifact reuse.

Use CodeDeploy ECS blue/green canary deployment with alarms and approval before traffic shifting.

6. Run PR unit tests with failure propagation and reports: Which design should be selected?

1. Run PR unit tests with failure propagation and reports; after merge, build one candidate, run integration tests against it, and promote that unchanged artifact. ✓

   The design tests pull requests quickly, runs integration tests against the post-merge candidate, publishes reports, propagates test failures, and promotes the exact tested artifact.
2. Run PR unit tests and publish reports, then build after merge, run integration tests, and rebuild the image before production deployment.

   The final rebuild means production receives an artifact different from the one tested by integration tests.
3. Run PR and post-merge tests with failure propagation, publish reports, and build a fresh production image from the approved source after testing.

   A fresh production build is not the artifact tested before production.
4. Run PR unit tests, configure CodeBuild report groups, and let the final report-upload command determine whether the build succeeds after post-merge integration testing.

   A successful upload command can mask a failed test unless the test command's nonzero status reaches CodeBuild.

Propagate failures, publish reports, run integration tests against the release candidate, and promote that same artifact.

7. Load-test an isolated representative environment: Which approach is most appropriate?

1. Use a small staging sample, manually compare results, and promote the tested image after developer review.

   A small sample may not reproduce peak arrival behavior, and manual review does not automatically enforce the stated thresholds.
2. Test production during low traffic and inspect dashboards afterward.

   Production testing can affect customer payments and does not provide an isolated automated release gate.
3. Load-test an isolated representative environment, automatically gate on throughput and latency, and deploy the exact tested image. ✓

   This protects production, exercises queues and dependencies at representative scale, enforces measurable thresholds, and preserves artifact identity.
4. Benchmark handlers with synthetic calls, then promote after reviewing average duration.

   Handler benchmarks omit queue behavior, downstream interactions, duplicate handling, throughput, and end-to-end latency.

Load-test an isolated representative environment with automated throughput and latency gates, then deploy the tested image.

8. Configure an ECS CodeDeploy Lambda validation hook: Select TWO actions.

Select two. More than one option is correct — every correct one is ticked below.

1. Increase the canary interval and retain the existing command so the worker has more time to recover.

   A longer interval does not correct the masked exit status or guarantee detection of a stopped worker.
2. Configure an ECS CodeDeploy Lambda validation hook to return failure when the worker check fails. ✓

   ECS CodeDeploy lifecycle validation uses supported Lambda hooks; a failed hook prevents the deployment from progressing.
3. Change the command to `run_checks.sh && echo validation-complete` so the check's nonzero status reaches the hook. ✓

   Conditional execution prevents the final echo from replacing the failed command's exit status.
4. Run the checks in CodeBuild and publish only the resulting report to the pipeline artifact.

   A report preserves evidence but does not by itself provide CodeDeploy with a failed validation result before traffic promotion.
5. Keep the command unchanged and rely on the load balancer health check to detect the stopped worker.

   The final successful echo masks the failure, and an HTTP health check does not necessarily measure worker consumption.

Preserve the nonzero exit status and connect it to a supported ECS CodeDeploy validation hook.

9. Connect both repositories' PR checks to CodeBuild: Which design is most appropriate?

1. Connect both repositories' PR checks to CodeBuild; publish coverage, fail required checks on test errors, and promote one built artifact. ✓

   This explicitly runs both repositories' pull-request tests, publishes coverage, propagates failures to merge checks, and promotes one artifact across Regions.
2. Use CodeBuild reports after deploying each regional build, compare coverage, and block production when reviewers reject the results.

   Testing after deployment is too late for the merge gate, manual rejection is not the required automated enforcement, and regional builds need not be identical.
3. Run required tests for both repositories after merge, build independently in every Region, and select the fastest successful build for production.

   This omits pull-request checks and can produce different regional artifacts, contrary to the single-artifact requirement.
4. Store coverage files and ask reviewers to inspect them before merging, then deploy the approved source to each Region.

   Manual inspection does not enforce pull-request execution or block merges when required tests fail, and regional source deployments can rebuild different artifacts.

Run both repositories' PR checks in CodeBuild, publish coverage, fail required checks on errors, and promote one artifact.

10. Use CodeBuild to create the stack: Which design should the team implement?

1. Use CodeBuild to create the stack, run tests, clean up in `finally`, publish logs, and return failure. ✓

   A CodeBuild buildspec can invoke CloudFormation and tests, use finally commands for cleanup, publish reports, and return a nonzero result to stop the pipeline.
2. Use CodeBuild to run the tests with scoped service permissions and upload reports.

   This supports testing and reporting but does not specify creation and guaranteed cleanup of the temporary environment.
3. Use a manual approval for testers to create and remove the environment.

   Manual approval does not reliably automate provisioning, cleanup on failure, reporting, or failure propagation.
4. Use Lambda to provision and test the stack with administrator permissions, then delete it after success.

   Administrator access violates least privilege, and cleanup only after success leaks resources when tests fail.

Use a scoped CodeBuild action with guaranteed cleanup, reports, and nonzero failure propagation.

11. Store packages in CodeArtifact: Which design best satisfies these requirements?

1. Store packages in CodeArtifact, images in ECR, promote image digests and package versions, and gate releases on scan findings. ✓

   CodeArtifact and ECR provide appropriate repositories; immutable identifiers, lifecycle retention, and explicit scan gating satisfy promotion requirements.
2. Use ECR image tags and CodeArtifact package names without versions, allowing each environment to resolve the latest published content.

   ECR tags and package names can identify content, but mutable latest resolution cannot guarantee reproducible rollback or promotion.
3. Store packages and images in an S3 bucket, then promote environment-specific archives after rebuilding them in each account.

   S3 can store pipeline artifacts, but rebuilding per environment violates identical-artifact promotion and weakens repository semantics.
4. Build separate images in each account, scan only production images, and configure short repository retention because older releases are rarely used.

   Separate builds create divergent artifacts, production-only scanning delays security decisions, and short retention breaks six-month rollback.

Use service-specific repositories, immutable identifiers, explicit scan gates, and retention policies supporting rollback.

12. Sign and verify the digest: The approved build must be promoted without rebuilding; package-token issuance per

Select two. More than one option is correct — every correct one is ticked below.

1. Place the CodeArtifact authorization token in the source repository so every build can retrieve dependencies consistently.

   A CodeArtifact token expires and is a credential. Committing it creates exposure and expiry failures rather than using runtime role-based authentication.
2. Sign and verify the digest, then push through an authorized workload-account role without rebuilding. ✓

   The trusted role and scoped ECR permissions support artifact promotion; signing and verification bind the promoted digest to the approved build.
3. Trust the tooling pipeline action role in security and grant the build role scoped CodeArtifact reads. ✓

   The pipeline must be authorized to invoke the cross-account build, while the security-account build role needs local dependency-read permissions.
4. Rebuild the container image in the workload account after promotion so its local role owns the final artifact.

   Rebuilding changes the tested artifact and contradicts promotion of the same image.
5. Grant the pipeline service role administrator access in both accounts to avoid configuring separate resource and trust policies.

   Administrator access violates least privilege and does not correctly establish the build role's dependency or image-access path.

Use temporary cross-account access for CodeArtifact and sign, verify, and promote the same image digest through scoped workload-account permissions.

Other AWS domains

• 2: Configuration Management and IaC — 144 questions →
• 6: Security and Compliance — 144 questions →
• 3: Resilient Cloud Solutions — 128 questions →
• 4: Monitoring and Logging — 127 questions →
• 5: Incident and Event Response — 119 questions →
• All 849 AWS questions →
• AWS certification: requirements, cost and exam format →