What's in this module
TOPIC 1 Deployment methods overview
There are two broad approaches to getting your application onto an EKS cluster: manual deployment via kubectl and automated deployment via a CI/CD pipeline. Manual is fine for learning; production teams use automation to eliminate human error and enforce repeatable deployments.
Manual — kubectl
- Apply YAML manifests directly
- Fast for development / testing
- No pipeline overhead
- Error-prone at scale
- No audit trail / rollback automation
Automated — CI/CD pipeline
- Triggered by code commits
- Build → test → push → deploy
- Repeatable, auditable, consistent
- Integrates with ECR + Helm
- Required for production teams
What are the two main methods for deploying applications to a Kubernetes cluster?
Manual deployment — using
Automated deployment — using a CI/CD pipeline (build → test → push → deploy) that removes human error and enforces consistency.
kubectl to apply manifests directly to the cluster.Automated deployment — using a CI/CD pipeline (build → test → push → deploy) that removes human error and enforces consistency.
Why do production teams prefer automated over manual deployments?
Automated pipelines are repeatable, auditable, and consistent — every deploy follows the same steps. Manual kubectl commands are fast but error-prone at scale and leave no automatic audit trail or rollback mechanism.
TOPIC 2 Scaling deployment workflow — 3 steps
The course defines a three-step framework for scaling your deployment workflow beyond manual kubectl. Each step unlocks a new layer of reliability and automation.
STEP 1
Container image repository
Store, version, and distribute Docker images. Use Amazon ECR for native AWS integration.
STEP 2
Package manager / deployment tools
Use Helm to package Kubernetes manifests into reusable, versioned charts.
STEP 3
Automate your CI/CD pipeline
Connect code commits to automatic build, push, and deploy — no manual kubectl in production.
What are the 3 steps to scaling your deployment workflow?
1. Set up a container image repository (e.g. Amazon ECR)
2. Choose your package manager / deployment tools (e.g. Helm)
3. Automate your CI/CD pipeline (build → push → deploy on every commit)
2. Choose your package manager / deployment tools (e.g. Helm)
3. Automate your CI/CD pipeline (build → push → deploy on every commit)
What role does a container image repository play in the deployment workflow?
It is the central artifact store: your CI pipeline pushes built images there, your cluster pulls images from there. It enforces versioned, immutable artifacts so every environment gets exactly the same binary.
TOPIC 3 Amazon ECR — the container registry
Amazon Elastic Container Registry (ECR) is a fully managed registry for Docker images and OCI artifacts. It is highly available, scalable, encrypted at rest, and tightly integrated with IAM — no separate credential management required when running on AWS.
Animation · ECR push-to-pull workflow
ECR key features
- Fully managed — no servers to operate
- Highly available & scalable
- Encryption at rest (AWS KMS)
- Optional vulnerability scanning
- IAM integration (no extra credentials)
- Image signing support
- Docker & OCI artifact support
ECR registry & repo hierarchy
- Each AWS account → ONE default private registry
- Each AWS account → ONE default public registry
- Multiple repositories within a registry
- Each repository holds multiple image versions (tags)
- URI format:
<account>.dkr.ecr.<region>.amazonaws.com/<repo>
What is Amazon ECR in one sentence?
Amazon ECR is a fully managed registry for Docker images and OCI artifacts — highly available, scalable, encrypted at rest, with native IAM integration.
How many default private registries does an AWS account get in ECR?
One default private registry per AWS account (plus one default public registry). Within that registry you can create many repositories, each holding multiple image versions.
What is the relationship between an ECR registry and an ECR repository?
A registry is the top-level namespace (one per account). A repository is a named bucket inside the registry that stores images for one application. Multiple repositories can exist within a single registry.
Why does ECR not need separate Docker Hub–style credentials on AWS?
ECR uses IAM for authentication and authorization. On an EKS node or Fargate Pod, the attached IAM role grants pull access automatically. You authenticate Docker with a short-lived token:
aws ecr get-login-password | docker login.Does ECR support image signing?
Yes. ECR supports image signing via AWS Signer, which lets you cryptographically sign images so your cluster can verify that only approved, unmodified images are deployed. This integrates with OCI artifact signing standards.
TOPIC 4 ECR image scanning
ECR offers two vulnerability scanning tiers. Basic scanning uses the open-source Clair engine and can run on push or on demand. Enhanced scanning uses Amazon Inspector and covers both OS packages and application language packages, emitting real-time events.
Animation · Basic vs Enhanced scanning
| Feature | Basic scanning | Enhanced scanning |
|---|---|---|
| Engine | Clair (open-source) | Amazon Inspector |
| Trigger | On push OR on demand | Continuous / on push |
| Frequency limit | Max once per 24 hours per image | No 24h limit |
| Coverage | OS packages only | OS + language packages (npm, pip, gem…) |
| EventBridge events | No | Yes — automate remediation |
| Cost | Included | Extra cost (Inspector pricing) |
What engine powers ECR Basic scanning?
Clair — an open-source static analysis tool for container image vulnerabilities. Basic scanning can be invoked on push or on demand, but is limited to once per 24 hours per image.
What additional capability does Enhanced scanning add over Basic?
Enhanced scanning (powered by Amazon Inspector) adds:
• Language package scanning (npm, pip, gem — not just OS packages)
• EventBridge events for automated remediation workflows
• No 24-hour frequency limit
Trade-off: extra cost via Amazon Inspector pricing.
• Language package scanning (npm, pip, gem — not just OS packages)
• EventBridge events for automated remediation workflows
• No 24-hour frequency limit
Trade-off: extra cost via Amazon Inspector pricing.
What is the 24-hour rule for ECR Basic scanning?
Basic scanning can be triggered on push or on demand, but each image can only be scanned once per 24 hours. If you push multiple times within 24 hours, only the first push triggers a new scan. Enhanced scanning has no such limit.
TOPIC 5 ECR workflow — 5 steps end-to-end
Getting a container image from your workstation into ECR and then running in an EKS Pod follows a repeatable five-step workflow. Know this sequence — it is the foundation of every CI/CD pipeline that targets EKS.
1
Create repo
Create an ECR repository in the AWS Console or via CLI.
2
Authenticate
Run
aws ecr get-login-password to get a short-lived token and pass to docker login.3
Build & tag
Build your Docker image and tag it with the full ECR URI.
4
Push
docker push <ecr-uri>:<tag> — layers stream to ECR.5
Consume
EKS Pod spec references the ECR URI. Node (or Fargate) pulls the image using its IAM role.
What command authenticates Docker to Amazon ECR?
aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.comThis exchanges your IAM credentials for a short-lived Docker registry token.
How does an EKS node pull images from ECR without a stored password?
The node's IAM role (or Fargate Pod execution role) includes the
ecr:GetAuthorizationToken and ecr:BatchGetImage permissions. The kubelet uses those permissions to automatically authenticate to ECR — no stored credentials needed.What is the format of an ECR image URI?
<account-id>.dkr.ecr.<region>.amazonaws.com/<repository-name>:<tag>Example:
123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:1.0.0TOPIC 6 Helm — the Kubernetes package manager
Helm is the Kubernetes package manager. It lets you bundle your manifests into a versioned, shareable chart and deploy it with a single command. Helm handles upgrades, rollbacks, and configuration overrides through its templating engine.
Animation · Helm chart anatomy & templating
What is Helm and why do teams use it?
Helm is the Kubernetes package manager. Teams use it to:
• Create standardised, reusable manifest templates
• Eliminate deployment errors (no manual YAML editing per environment)
• Manage app versioning (chart versions + app versions)
• Perform in-place upgrades and rollbacks with a single command
• Create standardised, reusable manifest templates
• Eliminate deployment errors (no manual YAML editing per environment)
• Manage app versioning (chart versions + app versions)
• Perform in-place upgrades and rollbacks with a single command
What are the 4 common tasks Helm helps with?
1. Create standardised reusable templates
2. Eliminate deployment errors (no manual YAML edits)
3. Manage app versioning across environments
4. In-place upgrades (and
2. Eliminate deployment errors (no manual YAML edits)
3. Manage app versioning across environments
4. In-place upgrades (and
helm rollback for quick recovery)
What is a Helm "release"?
A release is a specific deployed instance of a Helm chart in a Kubernetes cluster. The same chart can be installed multiple times (each is a separate release with its own name). Release name is used in templates via
{{ .Release.Name }}.TOPIC 7 Helm chart anatomy & templating
A Helm chart is a directory with a defined structure. The Chart.yaml file is mandatory. Default configuration lives in values.yaml. The templates/ folder contains Go-templated Kubernetes manifests that are rendered at install/upgrade time.
my-chart/
├── Chart.yamlMANDATORY chart name, version, description
├── values.yamlMANDATORY default configuration values
├── templates/MANDATORY
│ ├── pod.yaml Go-templated K8s manifests
│ ├── service.yaml
│ └── deployment.yaml
└── charts/optional chart dependencies
├── Chart.yamlMANDATORY chart name, version, description
├── values.yamlMANDATORY default configuration values
├── templates/MANDATORY
│ ├── pod.yaml Go-templated K8s manifests
│ ├── service.yaml
│ └── deployment.yaml
└── charts/optional chart dependencies
Templating example — values feed into manifests at render time:
templates/pod.yaml
metadata:
name: {{ .Release.Name }}
namespace: {{ .Release.Namespace }}
spec:
containers:
- name: {{ .Values.name }}
image: {{ .Values.image }}:{{ .Values.tag }}
name: {{ .Release.Name }}
namespace: {{ .Release.Namespace }}
spec:
containers:
- name: {{ .Values.name }}
image: {{ .Values.image }}:{{ .Values.tag }}
values.yaml
name: my-app
image: nginx
tag: 0.2
port: 8080
image: nginx
tag: 0.2
port: 8080
KC 2 — Which file in a Helm chart is MANDATORY and contains chart metadata?
A. pod.yaml B. values.yaml C. charts/ D. Chart.yaml
A. pod.yaml B. values.yaml C. charts/ D. Chart.yaml
✓ D — Chart.yaml
Chart.yaml is mandatory. It contains the chart's name, version, and description. values.yaml (B) is also mandatory but holds config values, not chart metadata. charts/ (C) is optional (dependencies).What does Chart.yaml contain?
Chart.yaml is the chart's manifest. Key fields:•
name — chart name•
version — chart version (semver)•
description — human-readable description•
apiVersion — Helm API version (v2)•
appVersion — the app version being deployed
What two special template variables does Helm inject automatically?
{{ .Release.Name }} — the name given at helm install time{{ .Release.Namespace }} — the target namespaceAll user values are under
{{ .Values.* }}. Built-in chart metadata is under {{ .Chart.* }}.What is the purpose of the
charts/ directory?The
charts/ directory holds chart dependencies — other Helm charts that your chart depends on. These are declared in Chart.yaml under dependencies: and downloaded via helm dependency update. It is optional if you have no sub-charts.How do you override values.yaml defaults at install time?
Two ways:
1.
2.
This lets you use one chart across dev/staging/prod by supplying environment-specific values without changing templates.
1.
--set key=value flag on the command line (quick overrides)2.
-f custom-values.yaml to supply an entire override fileThis lets you use one chart across dev/staging/prod by supplying environment-specific values without changing templates.
TOPIC 8 Helm chart sources
Charts can be stored in and distributed from multiple repositories. The course covers three main sources for AWS deployments. Lab 2 specifically uses Amazon S3 as a Helm repository.
SOURCE 1
Artifact Hub
The official public Helm chart registry. Browse thousands of community charts at artifacthub.io.
SOURCE 2
Amazon ECR
ECR supports OCI artifacts — store and distribute Helm charts alongside container images in the same registry.
SOURCE 3
Amazon S3
Use an S3 bucket as a private Helm repository. Lab 2 configures this. Simple, low-cost, IAM-controlled.
What three sources can serve Helm charts according to this course?
1. Artifact Hub — public chart registry (artifacthub.io)
2. Amazon ECR — OCI artifact support; charts alongside images
3. Amazon S3 — private bucket as Helm repo; used in Lab 2
2. Amazon ECR — OCI artifact support; charts alongside images
3. Amazon S3 — private bucket as Helm repo; used in Lab 2
What does Lab 2 require you to do with S3 and Helm?
Lab 2 tasks:
1. Configure an S3 bucket as a Helm chart repository
2. Package and load your chart into S3
3. Deploy your application using
4. Review
1. Configure an S3 bucket as a Helm chart repository
2. Package and load your chart into S3
3. Deploy your application using
helm install from S34. Review
Chart.yaml and values.yaml
Why use ECR as a Helm chart repository instead of Artifact Hub?
Using ECR for Helm charts alongside container images means:
• Single registry for both images and charts
• IAM-controlled access — no separate credentials
• Private by default — not publicly discoverable
• OCI standard — push/pull with standard Docker tooling
• Single registry for both images and charts
• IAM-controlled access — no separate credentials
• Private by default — not publicly discoverable
• OCI standard — push/pull with standard Docker tooling
TOPIC 9 Knowledge checks (from the course)
Official course knowledge-check questions. Try to answer before flipping.
KC 1 — Which two statements about Amazon ECR are true? (Select 2)
A. Each account has one default private AND one default public registry
B. Scanning requires Inspector on all repos
C. Repos must be in the same region as the EKS cluster
D. Multiple repositories can exist within a single registry
A. Each account has one default private AND one default public registry
B. Scanning requires Inspector on all repos
C. Repos must be in the same region as the EKS cluster
D. Multiple repositories can exist within a single registry
✓ A and D
A: Each AWS account gets exactly one default private registry and one default public registry.
D: Multiple repositories (one per app/service) can exist within a single registry.
B is false (Inspector is optional). C is false (cross-region is supported).
A: Each AWS account gets exactly one default private registry and one default public registry.
D: Multiple repositories (one per app/service) can exist within a single registry.
B is false (Inspector is optional). C is false (cross-region is supported).
KC 2 — Which Helm chart file is mandatory and contains chart metadata?
A. pod.yaml B. values.yaml C. charts/ D. Chart.yaml
A. pod.yaml B. values.yaml C. charts/ D. Chart.yaml
✓ D — Chart.yaml
Chart.yaml is the ONLY mandatory file that contains chart metadata (name, version, description). values.yaml is also mandatory but holds configuration values, not chart metadata. charts/ is optional.
Exam trap: What is the difference between ECR Basic and Enhanced scanning triggers?
Basic: triggered on push OR on demand — but limited to once per 24 hours per image.
Enhanced: continuous scanning (can run more than once per 24 hours) + emits EventBridge events for automated workflows. Extra cost.
Enhanced: continuous scanning (can run more than once per 24 hours) + emits EventBridge events for automated workflows. Extra cost.
Exam trap: What Helm template variable holds the name you give at install time?
{{ .Release.Name }} — set when you run helm install <release-name> ./chart.This is distinct from
{{ .Chart.Name }} (the chart name from Chart.yaml) and {{ .Values.name }} (a user-defined value in values.yaml).Which scanning engine scans OS and language packages?
Amazon Inspector (Enhanced scanning). It scans both OS-level packages (like Clair does for Basic) AND application language packages — npm, pip, Ruby gems, etc. This is critical for catching CVEs in application dependencies, not just OS libraries.