Application Deployment and Security
Study cheat sheet · DEVASC
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