Module 07 · Multi-Cloud Security Curriculum

DevSecOps & Container Security

~60 minutes of structured interview prep, MCQs and hands-on simulations covering CI/CD pipeline security, container hardening, Kubernetes RBAC, and IaC scanning.

Interview Q&As

MCQ Questions

Simulations

Curriculum Hours

Topics Covered

Area	Key Concepts
DevSecOps Principles	Shift Left, shared responsibility, security gates
CI/CD Pipeline Security	SAST, DAST, IAST, SCA, secrets scanning, IaC scanning
Container Security	Docker hardening, image scanning, Trivy, Falco, container escape
Kubernetes Security	RBAC, Network Policies, Pod Security Standards, admission controllers
IaC Security	Terraform, Checkov, tfsec, state file security
Supply Chain	Image signing (Sigstore/Cosign), SBOM (SPDX, CycloneDX)

💡 DevSecOps is one of the most sought-after skills in cloud security roles. Focus on knowing the difference between SAST/DAST/SCA and being able to place tools at the correct pipeline stage.

Core Concepts · ~10 min

DevSecOps & Container Security Fundamentals

CI/CD Pipeline Security Stages

Stage	Security Activity	Key Tools
Pre-commit	Secrets scanning, SAST in IDE	TruffleHog, GitGuardian, git-secrets, SonarLint
Build	SAST, SCA, container image scanning	SonarQube, Semgrep, Checkmarx, Snyk, Trivy, Dependabot
Test	DAST, IAST, integration security tests	OWASP ZAP, Burp Suite Enterprise, Contrast Security
Deploy	IaC scanning, policy-as-code gates	Checkov, tfsec, KICS, OPA/Conftest
Runtime	Workload protection, syscall monitoring	Falco, Aqua Security, Prisma Cloud Defender

Testing Types Comparison

Type	Full Name	When	What it Finds
SAST	Static Application Security Testing	Build (source code)	Injection flaws, hardcoded secrets, insecure patterns in code
DAST	Dynamic Application Security Testing	Test (running app)	XSS, SQLi, auth flaws found by attacking live app
IAST	Interactive Application Security Testing	Runtime (with agent)	Real-time analysis during test execution, low false positives
SCA	Software Composition Analysis	Build	Known CVEs in open-source dependencies

Container Security Best Practices

Practice	Why	How
Use non-root user	Limits blast radius if container is compromised	`USER nonroot` in Dockerfile
Minimal base image	Smaller attack surface	Use distroless or Alpine; avoid ubuntu:latest
Read-only filesystem	Prevents runtime modification	`readOnlyRootFilesystem: true` in K8s spec
No privileged containers	Prevents host escape	Avoid `--privileged`; use drop capabilities
No docker.sock mount	Prevents container escape to host Docker	Never mount `/var/run/docker.sock`
Multi-stage builds	Excludes build tools from final image	Separate builder and runtime stages
Image scanning	Detect CVEs before deployment	Trivy, Snyk, AWS ECR scanning

Kubernetes Security Components

Component	Purpose	Key Points
RBAC	Control who can do what in the cluster	Roles + RoleBindings (namespace); ClusterRoles + ClusterRoleBindings (global). Least privilege for service accounts.
Network Policies	Control pod-to-pod traffic	Default: allow all. Apply NetworkPolicy with default-deny, then explicit allows.
Pod Security Standards	Restrict dangerous pod configurations	Restricted (most secure) > Baseline > Privileged. Enforced via labels on namespaces.
Admission Controllers	Intercept API requests before object creation	OPA/Gatekeeper, Kyverno — enforce custom policies at admission time.
Secrets	Store sensitive data	K8s Secrets are base64 encoded, NOT encrypted by default. Use Vault or Sealed Secrets for true encryption.

Common IaC Security Mistakes (Terraform)

Mistake	Risk	Fix
Public S3 bucket (`acl = "public-read"`)	Data exposure	Remove ACL, use bucket policies + Block Public Access
SSH open to 0.0.0.0/0	Brute force / RCE	Restrict to specific CIDR or use SSM Session Manager
Hardcoded passwords in .tf files	Credential exposure in version control	Use Secrets Manager / Key Vault references
Logging disabled	No audit trail	Enable CloudTrail, S3 logging, VPC Flow Logs in Terraform
Unencrypted RDS	Data at rest exposure	`storage_encrypted = true`

🎯 Interview Tip: Know the difference between SAST (static, code) vs DAST (dynamic, running app) vs SCA (dependencies). Know that K8s Secrets are NOT encrypted by default. Know that Falco uses eBPF to monitor syscalls at runtime.

Interview Q&A · ~20 min · 20 Questions

Interview Questions & Model Answers

Click a question to reveal the model answer.

1What is DevSecOps and how does it differ from traditional DevOps?Easy▼

DevSecOps integrates security practices into every phase of the DevOps lifecycle rather than treating security as a final gate before release. In traditional DevOps, security is often bolted on at the end (penetration testing before go-live). In DevSecOps:

Developers run SAST tools in their IDEs as they write code
Security tests run automatically in CI/CD pipelines
Infrastructure is scanned for misconfigurations before deployment
Security is everyone's responsibility (Dev, Sec, Ops)

The key cultural shift: security is not a blocker but an enabler baked into the delivery process.

💡 Mention the "Shift Left" principle — finding and fixing issues earlier in the SDLC is 10–100× cheaper than fixing in production.

2What does "shift left" mean in DevSecOps?Easy▼

"Shift left" means moving security activities earlier in the software development lifecycle — to the left on a traditional timeline (Requirements → Design → Code → Test → Deploy → Operate). Instead of security testing only at the Test or Deploy stages, shift left means:

Running SAST in the IDE as code is written (Pre-commit)
Scanning dependencies for CVEs at Build time
Checking IaC templates before deployment
Threat modeling during Design

The business benefit: bugs found in code are far cheaper to fix than bugs found in production. IBM estimates the cost ratio is 1:15:30 (dev:test:production).

💡 Contrast with "shift right" — testing in production (chaos engineering, feature flags, A/B testing). Both can coexist in mature DevSecOps.

3What is the difference between SAST, DAST, and IAST?Medium▼

SAST (Static): Analyzes source code without executing it. Runs at build time. Finds injection flaws, hardcoded secrets, insecure patterns. Tools: SonarQube, Semgrep, Checkmarx, Veracode.
DAST (Dynamic): Attacks a running application from the outside (black-box). Finds XSS, SQLi, auth flaws, misconfigurations. Runs in test environment. Tools: OWASP ZAP, Burp Suite Enterprise.
IAST (Interactive): Agent inside the running application monitors code paths during test execution. Combines benefits of SAST and DAST. Low false positives. Tools: Contrast Security, Seeker.

Key difference: SAST has no runtime = no false positives from runtime context; DAST has no source access = can miss business logic flaws; IAST is the most accurate but requires agent instrumentation.

💡 SCA (Software Composition Analysis) is a fourth type — scans third-party library dependencies for known CVEs. Tools: Snyk, Dependabot, OWASP Dependency-Check.

4What is SCA and why is it important?Easy▼

Software Composition Analysis (SCA) scans the open-source and third-party libraries used in a project against known vulnerability databases (NVD, OSV, GitHub Advisory Database) to identify CVEs, license risks, and outdated dependencies.

Why important:

Modern applications are 70–90% open-source code by volume
A single vulnerable dependency can compromise the entire app (e.g., Log4Shell via Log4j)
Provides visibility into your Software Bill of Materials (SBOM)
Enables automated PR comments and blocking builds on critical CVEs

Tools: Snyk, Dependabot (GitHub), OWASP Dependency-Check, Grype, Trivy (for containers).

💡 SCA is now mandated by US Executive Order 14028 for federal software supply chains — SBOM generation is required.

5How do you prevent secrets from being committed to source control?Medium▼

Multi-layered approach:

Pre-commit hooks: TruffleHog, git-secrets, detect-secrets — scan staged files before commit. Developer gets immediate feedback.
CI/CD scanning: GitGuardian, GitHub Secret Scanning — scan entire git history and new commits in pipelines.
Secrets management: Store secrets in AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, GCP Secret Manager. Fetch at runtime via IAM-authenticated calls.
Environment variables: Inject secrets as env vars at runtime from a secrets manager — never bake into images or code.
NEVER: Hardcode API keys, passwords, certificates in source code, .env files committed to git, Docker layers, or CI/CD config files.

If a secret is accidentally exposed: revoke it immediately, rotate all affected credentials, audit usage logs for unauthorized access.

💡 GitHub now has secret push protection built in — it blocks pushes containing known secret patterns (AWS keys, GitHub tokens, etc.).

6What is IaC security scanning and which tools are used?Medium▼

IaC (Infrastructure as Code) security scanning analyzes Terraform, CloudFormation, ARM templates, Kubernetes manifests, and Helm charts for security misconfigurations before they are deployed to cloud environments.

Key tools:

Checkov: Open-source; supports Terraform, CloudFormation, K8s, Helm, ARM, Dockerfile; 1000+ built-in checks; integrates into CI/CD.
tfsec: Terraform-focused; fast; integrates with GitHub Actions.
KICS (Keeping Infrastructure as Code Secure): Checkmarx; multi-platform.
Terrascan: Multi-cloud IaC scanner; OPA-based policies.
Snyk IaC: Commercial; developer-friendly with fix suggestions.

What they detect: public S3 buckets, open security groups, disabled logging, unencrypted storage, missing tags, overprivileged IAM.

💡 Terraform Sentinel (HashiCorp) adds policy enforcement at the Terraform Cloud/Enterprise level — policy-as-code that blocks non-compliant plans.

7What are common Terraform security mistakes?Medium▼

Public S3 buckets: acl = "public-read" exposes data to the internet
Unrestricted security groups: cidr_blocks = ["0.0.0.0/0"] on port 22/3389 opens SSH/RDP to the world
Hardcoded credentials: Passwords or API keys in .tf files committed to version control
Disabled logging: No CloudTrail, VPC Flow Logs, or S3 access logging = no audit trail
Unencrypted databases: Missing storage_encrypted = true on RDS
State file in insecure location: Terraform state contains sensitive data — should be in encrypted S3 with DynamoDB locking, not local or unencrypted
Using latest image tags: Non-deterministic deployments; use specific image digests

💡 Run checkov -d . in your Terraform directory to get a full security report with pass/fail for each resource.

8What is container image scanning and which tools perform it?Easy▼

Container image scanning analyzes Docker/OCI images for known CVEs in OS packages and application libraries before they are pushed to a registry or deployed to production.

Key tools:

Trivy (Aqua): Open-source, fast, scans images, filesystems, git repos, K8s clusters; integrates easily with CI/CD
Grype (Anchore): Open-source; pairs with Syft for SBOM generation
Snyk Container: Developer-friendly; fix recommendations; IDE integration
AWS ECR Image Scanning: Native; basic (Clair-based) or Enhanced (Inspector-powered)
Azure Container Registry: Integrated vulnerability assessment via Defender for Containers
Clair: Open-source static analyser maintained by CoreOS/Red Hat

Best practice: scan at build, block critical CVEs from reaching registry, rescan periodically as new CVEs are published.

💡 An image passing today may fail tomorrow — new CVEs are published daily. Set up scheduled rescans of your image registry.

9What is Falco and how does it work?Hard▼

Falco is an open-source cloud-native runtime security tool (CNCF graduated project) that detects anomalous and potentially malicious behavior in containers, Kubernetes, and Linux systems at runtime.

How it works:

Uses eBPF (extended Berkeley Packet Filter) or kernel module to intercept Linux system calls (syscalls) at the kernel level — extremely low overhead
Evaluates syscalls against a set of YAML rules (e.g., "alert if a shell is spawned inside a container")
Generates real-time alerts sent to stdout, syslog, Slack, SIEM (Splunk, Elastic)

Example detections:

Shell spawned in a container (exec /bin/bash)
Sensitive file read (/etc/shadow, /etc/kubernetes/admin.conf)
Network connection from unexpected container
Privilege escalation attempt
Container namespace escape attempt

💡 Falco is post-exploit detection — it doesn't prevent attacks but detects them in real time. Pair with OPA/Gatekeeper (admission-time prevention) + Falco (runtime detection) for defense in depth.

10What is a privileged container and why is it dangerous?Medium▼

A privileged container runs with nearly all Linux capabilities enabled and has access to the host's devices — essentially equivalent to root on the host machine. Specified with --privileged in Docker or privileged: true in Kubernetes pod spec.

Why dangerous:

Can mount the host filesystem and read/modify any file
Can load kernel modules
Can access and manipulate host network namespaces
Can escape the container and compromise the underlying host node
In Kubernetes: can access the node's kubelet, steal credentials, and compromise the entire cluster

Alternatives:

Use specific Linux capabilities only (cap_add/cap_drop) — principle of least privilege
Use securityContext with allowPrivilegeEscalation: false
Use readOnlyRootFilesystem: true

💡 Pod Security Standards (Restricted profile) explicitly deny privileged containers — use it on all production namespaces.

11What is a container escape and how can it be prevented?Hard▼

A container escape is when a process inside a container breaks out of its isolation boundary and gains access to the host system or other containers.

Common escape vectors:

Privileged containers: Near-full host access by design
docker.sock mount: Mounting /var/run/docker.sock allows container to control the Docker daemon and create privileged containers
Host path mounts: Mounting sensitive host paths (e.g., /etc, /proc) into containers
Kernel vulnerabilities: CVEs in Linux kernel exploited from within container (e.g., Dirty COW, runc CVE-2019-5736)
Misconfigured seccomp/AppArmor: Missing syscall restrictions allow dangerous calls

Prevention:

Never run privileged containers in production
Never mount docker.sock
Use Pod Security Standards (Restricted)
Apply Seccomp profiles (RuntimeDefault or custom)
Apply AppArmor profiles
Keep container runtime (containerd, runc) patched

12How does Kubernetes RBAC work?Medium▼

Kubernetes RBAC (Role-Based Access Control) controls which users and service accounts can perform which actions on which Kubernetes resources.

Key objects:

Role: Defines permissions (verbs: get, list, create, delete) on resources (pods, secrets) within a namespace
ClusterRole: Same as Role but cluster-wide (or for non-namespaced resources like nodes)
RoleBinding: Grants a Role to a user/service account within a namespace
ClusterRoleBinding: Grants a ClusterRole cluster-wide

Best practices:

Avoid cluster-admin for application service accounts
Create specific roles per application with minimal verbs/resources
Audit RBAC with kubectl auth can-i --list --as=system:serviceaccount:namespace:sa-name
Use tools like rbac-police, RBAC Lookup, Starboard

💡 A common mistake: granting get/list/watch on Secrets at cluster level — this allows reading ALL secrets including other apps' credentials.

13What is a Kubernetes NetworkPolicy?Medium▼

A NetworkPolicy is a Kubernetes resource that controls network traffic (ingress/egress) between pods using label selectors — essentially a firewall for pod-to-pod communication.

Key facts:

By default, Kubernetes allows all pod-to-pod traffic (no isolation) — a pod can talk to any other pod in the cluster
NetworkPolicies require a CNI plugin that supports them (Calico, Cilium, Weave — NOT Flannel by default)
Applying a NetworkPolicy with an empty podSelector creates a default-deny for selected pods

Common pattern:

Apply a default-deny-all ingress NetworkPolicy to a namespace
Apply explicit allow policies only for required communication paths

This implements microsegmentation — even if an attacker compromises one pod, they cannot reach other pods or namespaces.

💡 NetworkPolicies are L3/L4 (IP/port). For L7 (HTTP-aware) policies, use a service mesh like Istio or Linkerd.

14What are Pod Security Standards in Kubernetes?Hard▼

Pod Security Standards (PSS) are a built-in Kubernetes framework (GA in 1.25, replacing deprecated PodSecurityPolicies) that defines three security profiles applied at the namespace level:

Privileged: No restrictions — for system/infrastructure workloads (kube-system)
Baseline: Prevents known privilege escalations (no privileged containers, no host namespaces, limited volume types)
Restricted: Heavily restricted, following security best practices (requires non-root, no privilege escalation, seccomp RuntimeDefault, drops ALL capabilities)

Applied via labels on namespaces:
pod-security.kubernetes.io/enforce: restricted

Three modes: enforce (reject violating pods), audit (log violations), warn (show warning). Use audit/warn before enforce to catch existing violations.

💡 Apply Restricted to all application namespaces. Exceptions (specific pods needing host access) should be rare and documented.

15What is Sigstore/Cosign and why is image signing important?Hard▼

Image signing provides cryptographic proof that a container image was built by a trusted party and has not been tampered with since signing.

Sigstore is a Linux Foundation project providing free, open-source tooling for signing software artifacts. Cosign is the Sigstore tool for signing container images.

Why important (supply chain security):

Ensures images in your registry are from your CI/CD pipeline, not injected malicious images
Detects tampering — if image is modified after signing, verification fails
Required for software supply chain compliance (SLSA, SSDF, Executive Order 14028)

Verification in Kubernetes:

Policy engines (OPA/Gatekeeper, Kyverno, Sigstore Policy Controller) can require all images to be signed before admission
Reject unsigned images at the cluster level

💡 SolarWinds attack would have been detectable if the tampered update package had a broken signature — image signing is supply chain defense.

16What is an SBOM and why does it matter for supply chain security?Hard▼

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all components, libraries, and dependencies in a software package — like a nutrition label for software.

Formats: SPDX (Linux Foundation), CycloneDX (OWASP)

Why it matters:

Vulnerability response: When Log4Shell dropped, orgs with SBOMs knew within hours if they were affected. Without SBOM, manual discovery took weeks.
Compliance: US Executive Order 14028 requires SBOMs for software sold to the federal government
Supply chain transparency: Know exactly what code is in your product and where it came from
License management: Identify GPL/LGPL dependencies that affect distribution rights

Tools: Syft (Anchore), Trivy, CycloneDX Maven/Gradle plugins, GitHub Dependency Graph.

💡 SBOM + image signing together = strong supply chain assurance: you know what's in the image AND that the image hasn't been tampered with.

17What is OPA/Gatekeeper in Kubernetes?Hard▼

OPA (Open Policy Agent) is a general-purpose policy engine using the Rego language. Gatekeeper is OPA integrated with Kubernetes as an admission controller (ValidatingWebhookConfiguration).

How it works:

Intercepts all API requests to the Kubernetes API server before objects are created/updated
Evaluates requests against Rego policies (ConstraintTemplates + Constraints)
Denies non-compliant requests with informative error messages

Example policies:

Require all containers to have resource limits
Deny privileged containers
Require specific labels on all pods
Block images from untrusted registries
Require pod security contexts

Alternative: Kyverno — Kubernetes-native policy engine using YAML (no Rego needed), simpler for K8s-specific use cases.

💡 OPA is also used beyond K8s — in Terraform (via Sentinel), CI/CD pipelines, Envoy proxies (authorization policies), and API gateways.

18Why are Kubernetes Secrets not truly secret by default?Medium▼

Kubernetes Secrets are stored in etcd (the cluster's key-value store) as base64-encoded data — not encrypted. Base64 is encoding, not encryption; it can be trivially decoded.

Problems:

Any user with get access to Secrets in a namespace can decode them
etcd access (e.g., via backup file or direct API) exposes all secrets in plaintext
Secrets appear in pod specs and can be logged accidentally

Solutions:

Encryption at Rest: Enable etcd encryption in the API server config (EncryptionConfiguration with AES-CBC or AES-GCM) — encrypts secrets before writing to etcd
External Secrets Operator: Sync secrets from AWS Secrets Manager / Azure Key Vault / HashiCorp Vault into K8s Secrets at runtime
Sealed Secrets (Bitnami): Encrypt secrets with a cluster-specific key; store encrypted SealedSecret in git
HashiCorp Vault Agent Injector: Inject secrets directly into pods as files without touching K8s Secrets

💡 This is a very common interview question for K8s security roles. Always propose at least one solution alongside identifying the problem.

19What is a CI/CD pipeline security gate?Medium▼

A pipeline security gate is an automated checkpoint in the CI/CD pipeline that evaluates security criteria and either allows the pipeline to continue or fails the build if thresholds are not met.

Examples:

SAST gate: Fail build if any Critical or High severity code vulnerability is found
Secrets gate: Fail build if any credential pattern is detected in code
SCA gate: Fail build if a dependency has a CVSS score > 7.0
Container scan gate: Fail build if image has critical CVEs unfixed for > 30 days
IaC gate: Fail deployment if Checkov finds Critical misconfigurations

Key principle: gates must be actionable — always provide developers with the specific finding and a path to fix it. Gates that block without explanation cause developer frustration and workaround behavior.

💡 Start with warn-only gates, measure baseline, then gradually tighten to fail-build for critical issues. A gate that fails everything on day one kills developer trust.

20What is a multi-stage Docker build and why is it more secure?Medium▼

A multi-stage Docker build uses multiple FROM statements in a single Dockerfile to separate the build environment from the runtime environment. Only the final stage is included in the produced image.

Security benefits:

Smaller attack surface: Build tools (GCC, Maven, NPM, Go toolchain) are NOT included in the final image — only the compiled binary or artifact
Fewer CVEs: Build tool packages often have vulnerabilities; excluding them reduces the vulnerability surface
No source code in final image: Only compiled artifacts are included
No secrets leakage from build layers: Each stage is isolated

Example pattern:

FROM golang:1.21 AS builder → RUN go build → FROM gcr.io/distroless/static AS runtime → COPY --from=builder /app/binary .

The final distroless image contains only the binary — no shell, no package manager, no unnecessary OS tools.

💡 Combine with non-root user (USER nonroot:nonroot) and read-only filesystem for maximum container hardening.

MCQ Quiz · ~15 min · 25 Questions

Multiple Choice Questions

Select an answer then click Check. Explanations shown after each submission.

Progress:

0 / 25

Simulation 1 · CI/CD Pipeline

CI/CD Security Stage Mapper

Classify each security activity into the correct CI/CD pipeline stage.

Simulation 2 · Docker Security

Container Security Best Practice Checker

For each container configuration, identify whether it is Secure or Insecure.

Simulation 3 · Kubernetes RBAC

Kubernetes RBAC Permission Evaluator

For each K8s RBAC configuration, select whether it is Too Permissive, Appropriate, or Too Restrictive.

Simulation 4 · IaC Security

IaC Misconfiguration Spotter

Review each Terraform snippet and identify the security vulnerability.

🎉

Module 07 Complete!

You've completed DevSecOps & Container Security.
MCQ Score: