Application Deployment and Security →hardMultiple Select

200-901 DevSecOps Practice Question

A company is adopting DevSecOps practices. Which THREE practices should be implemented to secure application deployment?

⚠ Common exam trap

200-901 often tests the misconception that committing .env files to git is acceptable for secrets management — candidates must recognize that any secret in version control is compromised.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Dependency scanning with tools like Snyk or Dependabot

Option B is correct because dependency scanning with tools like Snyk or Dependabot automatically detects known vulnerabilities (CVEs) in third-party libraries and generates remediation PRs, which is essential for securing the software supply chain in a DevSecOps pipeline. Option C is correct because enforcing HTTPS (via TLS and HSTS) protects data in transit from eavesdropping and man-in-the-middle attacks, while proper CORS configuration restricts which origins can make cross-origin requests, preventing unauthorized data access. Option D is correct because secure coding practices such as input validation and parameterized queries directly mitigate injection flaws (e.g., SQL injection, XSS) at the source, which is a foundational DevSecOps principle of shifting security left. Option A is not appropriate because committing .env files containing secrets to git exposes credentials in version history; secrets should instead be stored in a dedicated secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager). Option E is clearly wrong because disabling security tools increases risk and contradicts the entire purpose of DevSecOps.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Secrets management using environment variables stored in .env files committed to git
Why it's wrong here
Committing .env files to git exposes credentials in repository history, defeating secret management entirely. Environment variables are a legitimate pattern, but secrets belong in a dedicated vault or CI/CD secret store injected at runtime, never version-controlled alongside source code.
✓
Dependency scanning with tools like Snyk or Dependabot
Why this is correct
Snyk and Dependabot inspect manifest and lock files against vulnerability databases, surfacing known CVEs in third-party libraries and transitive dependencies. This satisfies DevSecOps by shifting dependency risk detection into the build pipeline before deployment, rather than relying on runtime protection alone.
✓
HTTPS enforcement and CORS configuration
Why this is correct
Enforcing HTTPS protects data in transit via TLS, while CORS configuration restricts which origins may call the API from browsers. Together they satisfy DevSecOps deployment security by closing transport interception and cross-origin request abuse paths at the application boundary.
✓
Secure coding practices (input validation, parameterized queries)
Why this is correct
Input validation rejects malformed or malicious data at trust boundaries, and parameterised queries ensure user input is treated as data, not executable SQL. This satisfies DevSecOps by eliminating injection flaws at the source rather than detecting them after deployment.
✗
Disabling all security tools to reduce deployment time
Why it's wrong here
Disabling security tooling removes the scanning and policy gates that DevSecOps depends on, trading detection for speed. Security controls are automated into the pipeline precisely so they add negligible latency; disabling them is only ever considered for isolated, non-production troubleshooting.

Go deeper

200-901 DevSecOps Practice Question

Why each option matters

Option-by-option breakdown

Related to this question