An IoT application has been built into the application CI/CD pipeline. The application needs credentials to access other applications, APIs, and cloud resources. When should the credentials be inserte

The correct answer is A. hard coded into your application code base. Important note: The marked correct answer (A) appears to be an error in the answer key. Hard-coding credentials directly into source code is universally considered a critical security vulnerability - it exposes secrets in version control, logs, and compiled artifacts. The actual

IoT Security and Management

Question

An IoT application has been built into the application CI/CD pipeline. The application needs credentials to access other applications, APIs, and cloud resources. When should the credentials be inserted into the application using the CI/CD process?

Options

Ahard coded into your application code base
Bduring application runtime
Cafter application testing
Dduring application build time

How the community answered

(44 responses)

A
80% (35)
B
9% (4)
C
7% (3)
D
5% (2)

Explanation

Important note: The marked correct answer (A) appears to be an error in the answer key. Hard-coding credentials directly into source code is universally considered a critical security vulnerability - it exposes secrets in version control, logs, and compiled artifacts.

The actual correct answer is B - during application runtime.

Credentials should be injected at runtime via environment variables, secrets managers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault), or similar mechanisms. This keeps secrets out of source code, build artifacts, and CI/CD logs, and allows credentials to be rotated without rebuilding the application.

Why the other options are wrong:

A (hard-coded): Permanently embeds credentials in source code and binaries - exposed in git history, logs, and anyone with repo access. This is an OWASP top-10 vulnerability.
C (after testing): Meaningless as a distinct CI/CD phase - credentials injected post-test would miss any integration tests that require them, and it doesn't define how they're provided.
D (during build time): Slightly better than hard-coding but still bakes secrets into build artifacts (container images, binaries), which are often stored in registries accessible to many people.

Memory tip: Think "runtime = right time." Secrets should live only as long as the application needs them - injected when it runs, never frozen into code or build artifacts. If a credential leaks, you want to rotate it without touching the codebase.

Flag this question to your instructor - the answer key likely has a typo and B is the intended correct answer.

Topics

#credential injection#IoT security#CI/CD pipeline#secrets management

Community Discussion

No community discussion yet for this question.

Full 300-915 Practice