Memory hook: Promote the same verified artifact through increasingly sensitive environments.
Must remember
- Separate source, build, test and deployment responsibilities. A central pipeline can assume deployment roles in workload accounts; scope trust, artifact-bucket permissions and KMS key access. Cross-account artifact access often fails because only the S3 policy was updated.
- Pin dependencies, verify provenance, scan artifacts and record hashes/digests. Sign supported artifacts and enforce verification where required. Store secrets in managed stores and retrieve them at runtime/build time with scoped access; never expose them in logs or intermediate artifacts.
- CodeBuild buildspec phases, environment variables, reports and cache settings affect repeatability. Use ephemeral build environments and avoid giving untrusted pull-request code production credentials. Pipeline approvals should display the exact artifact and evidence being approved.
- Choose in-place, rolling, blue/green, canary or linear deployment using capacity, availability and rollback constraints. Health checks, pre/post hooks and CloudWatch alarms must observe real application outcomes. A deployment that never receives representative traffic cannot validate its behaviour.
- Database changes require expand/migrate/contract sequencing or another compatible strategy. Keep old and new application versions able to work during the transition; delay destructive cleanup until rollback requirements are satisfied.
- Use CloudFormation/SAM/CDK-generated templates with linting, policy checks, change sets and isolated integration tests. StackSets and account provisioning scale baselines; delegated roles and permission boundaries constrain the automation itself.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Same release in staging and production | Promote an immutable artifact, rather than rebuild. |
| Untrusted contributor submits a pull request | Run isolated validation without privileged deployment credentials. |
| Cross-account pipeline cannot decrypt artifacts | Check customer-managed KMS permissions and trust as well as S3. |
Traps
- A passing scanner does not prove a package is harmless.
- Manual approval is weak if reviewers cannot see what they approve.
- Rollback of code does not automatically roll back data.
Active recall
1. Why identify artifacts by digest?
Mutable tags can point to different bytes later.
2. Which controls protect a pipeline across accounts?
Scoped trust, deployment roles, PassRole, artifact/resource policies and encryption-key access.
3. Why are secret build arguments risky?
They can leak into logs, layers or artifacts depending on the tool and process.
4. What makes a canary meaningful?
Representative traffic, measured success/error signals and an enforced decision/rollback rule.
5. Why delay a destructive schema change?
Older application versions may still run or be required for rollback.