A DevOps engineer is managing an AEM as a Cloud Service Sites environment. During final testing, a code quality check flags a hard-coded password in a service property. What should the DevOps engineer do?

A DevOps engineer is managing an AEM as a Cloud Service Sites environment. During final testing, a code quality check flags a hard-coded password in a service property. What should the DevOps engineer do?

• A. Bypass the pipeline step in Cloud Manager by contacting support.
• B. Suppress the warning in Cloud Manager using @SuppressWarnings("squid:S2068").
• C. Inform the development team and ask them to remove the password.
• D. Ignore the warning and continue with deployment.

Answer: (C)

Hard-coded credentials are a serious security risk, especially in a deployment pipeline. The test flags a password embedded in a service property to prevent secrets from being exposed in code, configuration files, or build artifacts. The correct course is to involve the development team and have them remove the password from the code and replace it with a secure secret reference. In practice, that means storing the credential in a secret management facility (for example, Cloud Manager secrets or a vault) and configuring the service to read the value at runtime from that secure store, typically via an environment variable or a secure property reference. This approach supports secret rotation, access control, and reduces the chance of leakage across versions and environments. Suppressing the warning or bypassing the check would weaken security and set a bad precedent, and ignoring the warning means the vulnerability would persist into production.

Hard-coded credentials are a serious security risk, especially in a deployment pipeline. The test flags a password embedded in a service property to prevent secrets from being exposed in code, configuration files, or build artifacts. The correct course is to involve the development team and have them remove the password from the code and replace it with a secure secret reference. In practice, that means storing the credential in a secret management facility (for example, Cloud Manager secrets or a vault) and configuring the service to read the value at runtime from that secure store, typically via an environment variable or a secure property reference. This approach supports secret rotation, access control, and reduces the chance of leakage across versions and environments.

Suppressing the warning or bypassing the check would weaken security and set a bad precedent, and ignoring the warning means the vulnerability would persist into production.