Study guide

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3

AWS Certified DevOps Engineer – Professional Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CI/CD Pipeline Architecture & Source Integration

1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models

2 Chapter 2: Automated Testing, Test Gates & Quality Verification

2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates

3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda

4 Chapter 4: CloudFormation, CDK & Reusable IaC Components

4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance

5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower

5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation

6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration

6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

7 Chapter 7: High Availability & Multi-Region Resiliency

7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR

8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation

8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery

9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation

9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions

10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray

10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps

11 Chapter 11: Automated Observability & Event-Driven Monitoring

11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries

12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines

12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling

13 Chapter 13: Automated Remediation & Deployment Troubleshooting

13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures

14 Chapter 14: Identity, Access Management & Secrets at Scale

14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager

15 Chapter 15: Security Automation, Data Protection & Compliance Auditing

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3

Key Takeaways Explain This Topic AI

AWS CodeArtifact uses Domains as administrative and asset-deduplication boundaries, with Repositories providing polyglot package endpoints for npm, pip, Maven, NuGet, Swift, and RubyGems.

Upstream repositories and external connections allow CodeArtifact to aggregate internal packages and cache external dependencies, insulating enterprise CI/CD pipelines against public registry outages.

Amazon ECR tag immutability prevents image tampering and unintended regressions, while lifecycle policies automate the cleanup of untagged intermediate layers and aged container tags based on rule priority.

ECR cross-region and cross-account replication operates via push-based registry rules, automating distribution with destination KMS key re-encryption.

Amazon S3 artifact storage combines Object Lock in Compliance or Governance mode for immutable WORM deployment archives with noncurrent version lifecycle expiration rules for storage optimization.

Last updated: September 2026

Enterprise Artifact Management Overview

In continuous integration and continuous deployment (CI/CD) pipelines, artifact management forms the operational bridge between source code builds and production runtime environments. For the AWS Certified DevOps Engineer - Professional (DOP-C02) exam, you must master the lifecycle, security, access control, and cross-account distribution patterns across three primary AWS artifact repositories:

AWS CodeArtifact : A fully managed, polyglot package repository service for application software dependencies (npm, PyPI, Maven, NuGet, Swift, and RubyGems).

Amazon Elastic Container Registry (ECR) : A high-performance, managed OCI container image registry supporting private and public repositories, automated image vulnerability scanning, and cross-region replication.

Amazon Simple Storage Service (S3) : An object store utilized for deployable runtime bundles (ZIP, tarballs), CloudFormation nested templates, AWS Lambda code deployment archives, and static application assets.

Securing artifacts requires decoupling build pipelines from public open-source registries, establishing Write-Once-Read-Many (WORM) immutability, and enforcing least-privilege resource policies across multi-account AWS Organizations hierarchies.

AWS CodeArtifact: Architecture, Upstreams & Multi-Account Sharing

AWS CodeArtifact organizes software packages into a two-tier hierarchy: Domains and Repositories .

Domains vs. Repositories

Domain : An administrative boundary that groups repositories together. Physical package assets (the underlying .tgz , .whl , or .jar binaries) are stored and deduplicated at the domain level using SHA-256 content addressing. Even if a specific package version is referenced across twenty different repositories in the same domain, it is stored only once. Domains are encrypted with a single AWS Key Management Service (AWS KMS) Customer Managed Key (CMK) or AWS-managed key.

Repository : A polyglot logical container within a domain where client tools (such as npm , pip , mvn , gradle , nuget ) publish and consume packages. A single CodeArtifact repository natively handles multiple package formats simultaneously. +-------------------------------------------------------------+

  • | AWS CodeArtifact Domain |
  • | - Encryption: KMS CMK |
  • | - De-duplicated Asset Storage (SHA-256) |
  • | |
  • | +-----------------------+ +-------------------------+ |
  • | | Upstream Repository | | Downstream Repository | |
  • | | (e.g., external-cache)|<----+ (e.g., team-repo) | |
  • | +-----------+-----------+ +-------------------------+ |
  • | | |
  • | v |
  • | +-----------------------+ |
  • | | External Connection | |
  • | | (public:npmjs, pypi) | |
  • | +-----------------------+ |
  • +-------------------------------------------------------------+
  • Upstream Repositories and External Connections

A central design pattern in CodeArtifact is upstream repository aggregation . A repository can declare up to 10 direct upstream repositories. When a client requests a package from a downstream repository, CodeArtifact searches the downstream repository first. If the package version is not found, it queries the upstream repositories in the configured priority order.

To consume public open-source software securely, you attach an External Connection to a repository. Supported external connections include:

  • public:npmjs (npm Registry)
  • public:pypi (Python Package Index)
  • public:maven-central , public:maven-google , public:maven-gradle-plugins
  • public:nuget-org (NuGet Gallery)
  • public:ruby-gems-org (RubyGems)

Exam Watch : When an external package is requested for the first time through a repository with an external connection, CodeArtifact fetches the asset, ingests it into the domain, and retains it permanently as an internal package version. This caching protects pipelines against external registry downtime, upstream package deletion (the "left-pad" incident), and unauthorized remote tampering.

Cross-Account Package Distribution Pattern

In enterprise AWS Organizations setups, organizations adopt a hub-and-spoke artifact architecture :

Shared Services Account (Hub) : Hosts the CodeArtifact Domain, the external-connection cache repository, and the central enterprise release repository.

Development & Production Accounts (Spokes) : Contain build agents and deployment runtimes that read from and publish to the central repositories.

  • To enable cross-account access, both Domain Policies and Repository Policies are applied: {
  • "Version": "2012-10-17",
  • "Statement": [
  • {
  • "Sid": "AllowCrossAccountRead",
  • "Effect": "Allow",
  • "Principal": {
  • "AWS": "arn:aws:iam::111122223333:root"
  • },
  • "Action": [
  • "codeartifact:GetAuthorizationToken",
  • "codeartifact:GetRepositoryEndpoint",
  • "codeartifact:ReadFromRepository"
  • ],
  • "Resource": "*"
  • }
  • ]
  • }

Authentication requires generating a temporary authorization token using aws codeartifact get-authorization-token (or aws codeartifact login ), which provides a 12-hour STS-backed credential for CLI package managers.

Package Retention, Immutability & Package Statuses

CodeArtifact enforces immutability: once a specific package version (e.g., lib-auth@1.2.0 ) is published, it cannot be overwritten. To manage the package lifecycle, CodeArtifact provides distinct package version statuses:

Published : Fully available for consumption.

Unfinished : Package assets are in the process of uploading.

Archived : Package can be read by existing consumers but cannot be resolved as the latest dependency for new builds.

Disposed : Assets are purged from the repository; package version metadata remains to prevent republishing the same version string.

Deleted : Completely erased from the repository.

Amazon ECR: Registry Governance, Immutability & Lifecycle Automation

Amazon ECR provides managed container registries for Docker and OCI images, Helm charts, and deployment manifests.

Private vs. Public Repositories & Authentication

Private Repositories : Scoped to individual AWS accounts and regions. Authentication uses the aws ecr get-login-password command, which generates an authorization token valid for 12 hours via the AWS STS ecr:GetAuthorizationToken API. Runtimes authenticate against aws_account_id.dkr.ecr.region.amazonaws.com .

Public Repositories : Registered under Amazon ECR Public Gallery ( public.ecr.aws ) with global public read access and optional AWS Marketplace monetization.

Image Tag Immutability

By default, ECR repositories allow tag mutability, meaning pushing an image with an existing tag (such as :latest or :release-v1 ) silently overwrites the previous image manifest. In production CI/CD pipelines, you must enable Image Tag Immutability :

Prevents tag overwriting: Any docker push attempting to push a pre-existing tag fails with an ImageTagAlreadyExistsException .

Guarantees deterministic deployments: Assures that task definitions referencing :v2.4.1 always pull the exact digest evaluated during staging testing.

Blocks rogue tampering: Untrusted actors cannot overwrite a trusted image tag with malicious code.

ECR Lifecycle Policies

ECR lifecycle policies automate repository hygiene, preventing unchecked storage cost growth caused by untagged intermediate layer builds and stale feature branch containers. Lifecycle policies are JSON documents containing ordered rules: {

  • "rules": [
  • {
  • "rulePriority": 1,
  • "description": "Purge untagged images older than 7 days",
  • "selection": {
  • "tagStatus": "untagged",
  • "countType": "sinceImagePushed",
  • "countUnit": "days",
  • "countNumber": 7
  • },
  • "action": {
  • "type": "expire"
  • }
  • },
  • {
  • "rulePriority": 2,
  • "description": "Retain only the last 30 release images",
  • "selection": {
  • "tagStatus": "tagged",
  • "tagPatternList": ["release-*"],
  • "countType": "imageCountMoreThan",
  • "countNumber": 30
  • },
  • "action": {
  • "type": "expire"
  • }
  • }
  • ]
  • }
  • Lifecycle Policy Evaluation Mechanics

Priority Ordering : Rules are evaluated strictly in ascending numerical order ( rulePriority: 1 executes before rulePriority: 2 ).

Single Match Rule : Once an image matches an active rule, it is subject to that rule's action and is excluded from evaluation by subsequent rules.

Tag Status Options : tagged (requires tagPrefixList or tagPatternList ), untagged (matches images whose tags were removed or overwritten), or any .

Cross-Region and Cross-Account Replication

ECR provides registry-level, push-triggered replication. When enabled, pushing an image to a repository in us-east-1 automatically replicates the image layers and manifests to specified destination accounts and regions (e.g., eu-west-1 , ap-southeast-1 ).

Encryption in Transit & at Rest : Destination repositories can re-encrypt replicated layers using region-specific KMS Customer Managed Keys.

Repository Creation Templates : Automatically apply repository policies, tag immutability, and lifecycle rules to newly auto-created destination repositories.

Cross-Account Pulls : If replication is not used, cross-account pulling requires an ECR Repository Policy granting ecr:BatchGetImage , ecr:GetDownloadUrlForLayer , and ecr:BatchCheckLayerAvailability to external IAM principals.

Amazon S3: Immutable Deployment Bundles, Object Lock & Lifecycle Rules

Amazon S3 serves as the backbone for raw application deployment archives (AWS Lambda .zip artifacts, Elastic Beanstalk source bundles, and CodeDeploy application revisions).

S3 Versioning and MFA Delete

Enabling S3 Versioning ensures that every PUT , POST , or DELETE creates a distinct version ID rather than overwriting existing objects. When an object is deleted without a version ID, S3 applies a Delete Marker . To prevent malicious or accidental permanent deletion of release binaries, enable MFA Delete on the release bucket, requiring hardware or virtual multi-factor authentication tokens to purge specific object versions.

S3 Object Lock: Compliance vs. Governance Modes

For regulated workloads requiring absolute Write-Once-Read-Many (WORM) storage, S3 Object Lock prevents object deletion or overwriting for a fixed retention period:

Feature Compliance Mode Governance Mode

Root Account Override No (Cannot be deleted or bypassed by any identity, including the AWS account root user) Yes (Identities with s3:BypassGovernanceRetention permission can delete or bypass retention)

Shortening Retention Prohibited under all circumstances Allowed with governance bypass permission

Use Case Regulatory and legal compliance (SEC Rule 17a-4, FINRA, HIPAA audit trails) Operational protection against accidental deletion while allowing administrative lifecycle maintenance

S3 Object Lock also supports Legal Holds , which place an indefinite retention lock on an artifact independent of retention dates until explicitly cleared by an authorized identity.

S3 Lifecycle Rules for Build Artifacts

Build pipelines generate thousands of transient artifacts. A production S3 artifact lifecycle policy manages costs by:

Transitioning current versions from S3 Standard to S3 Standard-Infrequent Access (Standard-IA) after 30 days.

Moving historical noncurrent versions to S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive after 60 days.

Expiring and permanently deleting noncurrent versions after 180 days.

Aborting incomplete multipart uploads via AbortIncompleteMultipartUpload after 7 days to eliminate orphaned upload segments.

Architectural Comparison: CodeArtifact vs. ECR vs. S3

Capability AWS CodeArtifact Amazon ECR Amazon S3

Primary Artifact Types Language packages ( .tgz , .whl , .jar , .nupkg ) OCI/Docker container images, Helm charts Raw archives ( .zip , .tar.gz ), CloudFormation templates

Protocols & Clients npm, pip, twine, mvn, nuget, swift, gem Docker CLI, containerd, Podman, Helm S3 API, AWS SDKs, AWS CLI, cURL (Presigned URLs)

Immutability Controls Package version immutability, Package status management Image Tag Immutability flag S3 Object Lock (Compliance / Governance Mode)

Purge / Lifecycle Domain-level package deletion / package disposal APIs Lifecycle Policies ( rulePriority , untagged , count) S3 Lifecycle Rules (Transitions, Noncurrent expiration)

Caching & Upstream Native Upstream Repositories + External Connections Pull-Through Cache rules (for public registries) Cross-Region Replication (CRR), S3 Multi-Region Access Points

Auth Mechanism 12-hour STS authorization token ( codeartifact login ) 12-hour STS authorization token ( ecr get-login-password ) IAM SigV4, Bucket Policies, S3 Presigned URLs

Loading diagram... Centralized Multi-Account Artifact Distribution Architecture