Application Deployment and Security

Key Concepts

CI/CD Pipeline: Automates code integration, testing, and deployment — reduces manual errors and speeds delivery
Continuous Integration (CI): Developers merge code frequently; automated tests run on each commit
Continuous Delivery (CD): Code is always in a deployable state; deployment to production is manual trigger
Continuous Deployment: Every passing build is automatically deployed to production (no human approval)
Deployment Models: Dev → Test/Staging → Production; never deploy untested code directly to production
Infrastructure as Code (IaC): Define and provision infrastructure via code (Terraform, Ansible, CloudFormation)
Containers vs VMs: Containers share the OS kernel (lightweight, fast); VMs have full OS (isolated, heavier)
Docker: Packages apps + dependencies into portable containers; image → container relationship
Kubernetes (K8s): Orchestrates containers at scale — handles scheduling, scaling, self-healing
Secret Management: Never hardcode credentials; use environment variables, vaults (HashiCorp Vault), or secrets managers
OWASP Top 10: Key web security risks — injection, broken auth, XSS, insecure deserialization, etc.
Shift-Left Security: Integrate security testing early in the pipeline, not just at the end
SAST vs DAST: SAST = static analysis (source code, no running app); DAST = dynamic analysis (tests running app)
TLS/HTTPS: Encrypts data in transit; APIs should always enforce HTTPS
OAuth 2.0 / OIDC: OAuth 2.0 = authorization framework; OIDC = identity layer on top for authentication
API Keys vs Tokens: API keys = static, long-lived (riskier); tokens (JWT) = short-lived, scoped (preferred)

How It Works

CI/CD Flow: 1. Developer pushes code → triggers pipeline 2. Build stage compiles/packages the app 3. Test stage runs unit, integration, security tests 4. Artifact is stored (Docker image, JAR, etc.) 5. Deploy stage pushes to staging → then production

Container Lifecycle: - Write Dockerfile → build image (docker build) → push to registry → pull and run as container

OAuth 2.0 Flow (simplified): - App requests authorization → user approves → auth server issues access token → app uses token to call API

Commands / Syntax / Key Values

Tool/Concept	Key Command / Value
`docker build`	`docker build -t myapp:latest .`
`docker run`	`docker run -p 8080:80 myapp`
`docker push/pull`	Push/pull image to/from registry
`kubectl apply`	`kubectl apply -f deployment.yaml`
`kubectl get pods`	List running pods
HTTP → HTTPS	Port 80 → Port 443
JWT structure	`header.payload.signature` (Base64 encoded)
Environment vars	`os.environ.get('SECRET_KEY')` (Python)
Webhook trigger	HTTP POST sent to CI/CD on code push

Exam Gotchas

Continuous Delivery ≠ Continuous Deployment — Delivery still requires a manual approval step for production; Deployment is fully automated. Exam questions love to swap these.
SAST needs source code; DAST needs a running app — If a question says "no access to source," the answer is DAST, not SAST.
Containers are NOT fully isolated — They share the host OS kernel. VMs are fully isolated with their own OS. Don't confuse security properties.
OAuth 2.0 is NOT authentication — It's an authorization framework. OIDC is what adds authentication on top. Exam may try to call OAuth 2.0 an "authentication protocol."
Hardcoded secrets = automatic wrong answer — Any option that stores credentials, API keys, or passwords directly in source code is always the incorrect/insecure choice.

Quick Summary

Always know the difference between CI, Continuous Delivery, and Continuous Deployment — especially that Delivery still has a manual gate