EC-Council Certified DevSecOps Engineer ECDE 312-97 Exam Questions

Answer : A

Git hooks determine success or failure based on the exit code of the executed script. An exit code of 0 indicates successful execution, while any non-zero value signals failure and causes Git to abort the commit. In Jordon's setup, a Bash shell calls a PowerShell script to perform pre-commit checks. If the PowerShell script exits with code 0, Git interprets this as a successful hook execution and allows the commit to proceed. Exit codes such as 1, 2, or 3 indicate errors or policy violations and will block the commit. This mechanism ensures that security or quality checks enforced by the pre-commit hook must pass before code is committed. Using exit codes in this way is a standard and reliable approach in cross-platform DevSecOps automation during the Code stage.

Answer : D

Conjur policies define access controls, authentication rules, and secret variables, and they must be loaded into the correct policy branch. The conjur policy load command uses the -b flag to specify the policy branch and the -f flag to specify the policy file. To load a policy into the root branch, the correct command is conjur policy load -b root -f <file-name>. Options that reverse or misuse these flags are invalid and would either fail or load the policy incorrectly. Loading policies correctly during the Build and Test stage ensures that Jenkins pipelines can securely access secrets at runtime, enforcing centralized secret management, least-privilege access, and compliance with security requirements.

Answer : D

The CentOS operating system uses the yum package manager to install software packages. Inside a CentOS-based Docker container, the correct way to install the Apache HTTP Server is by running yum install httpd. Containers typically run as the root user by default, making the use of sudo unnecessary. Commands such as install-httpd are invalid because yum requires the install keyword followed by the package name separated by a space. Installing required packages inside containers should be done carefully to avoid bloating images and increasing the attack surface. During the Operate and Monitor stage, DevSecOps teams must balance functionality with container hardening best practices by installing only necessary components.

Answer : D

Jenkins automatically assigns a unique identifier to each build using the environment variable BUILD_ID. When integrating OWASP ZAP with Jenkins, appending ${BUILD_ID} to output filenames or reports ensures that every scan result corresponds to a specific build execution. This avoids overwriting previous reports and allows traceability between build artifacts and security findings. Variables such as ${ZAPROXY_HOME} refer to installation paths, not build uniqueness, while ${Profile_ID} and ${zap_scan} are not standard Jenkins variables for uniquely identifying builds. Using ${BUILD_ID} supports better auditing, historical analysis, and correlation between detected vulnerabilities and the exact build in which they were found, which is critical during the Build and Test stage of a DevSecOps pipeline.

Answer : D

Sqreen provides runtime application self-protection (RASP) capabilities that allow teams to detect and respond to security threats in real time. Sqreen uses a structured automation mechanism called a playbook to define how security events are handled. A playbook consists of three key components: a trigger that detects suspicious or malicious behavior, a security response that defines what action Sqreen should take (such as blocking a request or flagging an attack), and a notification that sends alerts to external systems like Slack. The term ''cookbook'' is not used in Sqreen's alerting and response model, making options A and B incorrect. Option C incorrectly uses the phrase ''Alert a response'' instead of ''security response,'' which does not accurately describe Sqreen's configuration model. By using playbooks, Sqreen enables automated detection, response, and team notification during the Operate and Monitor stage, ensuring rapid awareness and collaboration when security incidents occur.

Answer : A

Deploy-time checks are designed to identify vulnerabilities that may not surface during earlier stages such as commit-time, build-time, or test-time checks. These checks analyze applications in environments that closely resemble or are part of production, making it possible to detect configuration issues, runtime vulnerabilities, and environment-specific weaknesses. Pre-production testing often cannot fully replicate production conditions, so deploy-time checks act as an additional safety net. Commit-time and build-time checks focus on code quality and static analysis, while test-time checks validate application behavior in controlled environments. Deploy-time checks therefore help Victor uncover vulnerabilities missed earlier, improving overall security assurance before or during deployment.

Answer : A

AWS CodeCommit is a fully managed, AWS-hosted source control service that allows teams to store and manage source code, binaries, and other digital assets securely in the cloud. It supports Git-based repositories and integrates seamlessly with other AWS DevOps services such as CodeBuild, CodePipeline, and CodeDeploy. CodePipeline orchestrates CI/CD workflows, CodeBuild performs build and test operations, and CodeDeploy automates application deployment---but none of these are version control systems. For organizations migrating from on-prem to AWS, CodeCommit provides fine-grained access control using IAM, encryption at rest and in transit, and high availability without the need to manage infrastructure. Using CodeCommit during the Code stage supports secure collaboration, version tracking, and centralized source control aligned with DevSecOps best practices.