SY0-701 Question 156
Single answerInfrastructure as code (IaC)A company uses Infrastructure as Code (IaC) templates in a shared Git repository to deploy cloud web servers, security groups, and databases. During a security review, the team discovers that a database administrator hard-coded cloud access keys and a database password directly into an IaC template so the deployment would succeed automatically. The organization wants to reduce the risk of credential exposure while maintaining automated deployments and version control for the infrastructure definitions. Which of the following is the BEST solution?
- A
Store the IaC templates in a separate private repository and continue embedding the credentials in the template files
- B
Replace the hard-coded secrets with references to a centralized secrets manager or secure parameter store and grant the deployment pipeline permission to retrieve them at runtime
- C
Encrypt the entire template file with a symmetric key and commit the encrypted file to the repository along with the decryption key for the build server
- D
Move the credentials into environment variables on each administrator workstation and require admins to run the deployments manually
Show answer and explanation
Correct answer: B
Explanation
The best answer is to remove secrets from the IaC templates and retrieve them securely at deployment time from a centralized secrets management solution. This aligns with widely accepted secure DevOps and cloud security practices: infrastructure definitions should remain in version control, but sensitive values such as API keys, passwords, and tokens should be stored separately in managed secret stores with strict access controls, auditing, and rotation capabilities. In practical terms, the CI/CD pipeline or deployment engine should use an assigned identity with least-privilege permissions to access only the required secrets at runtime. This approach supports automation, limits credential exposure in source control, and reduces long-term risk from repository history leaks. This guidance is consistent with common vendor and industry recommendations, such as using managed secrets services and avoiding hard-coded credentials in code repositories, CI/CD configurations, and IaC templates.
- A. Incorrect.
This is incorrect. Using a private repository reduces exposure compared with a public one, but it does not solve the core problem: secrets are still hard-coded in version-controlled IaC files. Credentials committed to source control can be copied, retained in history, and exposed to anyone with repository access. This is a common but insecure practice.
- B. Correct.
This is correct. A centralized secrets manager or secure parameter store is a standard best practice for IaC and automated deployments. The template can reference the secret at deployment time instead of containing the secret itself. Access can be controlled through IAM roles or service accounts assigned to the CI/CD pipeline, reducing credential sprawl, improving auditability, and supporting secret rotation without editing the template.
- C. Incorrect.
This is incorrect. Encrypting the template file may sound secure, but storing the decryption key for the build process undermines the protection if key management is weak or if the key is accessible to the same systems or users. It also creates operational complexity and still treats the IaC file as a secret container rather than separating code from secrets. Best practice is to keep sensitive values out of the template entirely.
- D. Incorrect.
This is incorrect. Moving credentials to local administrator environment variables avoids storing them in the template, but requiring manual deployments reduces consistency, scalability, and auditability. It also increases the risk of local workstation compromise and configuration drift. The scenario specifically requires maintaining automated deployments, which this option does not support well.