ECCouncil 312-97 EC-Council Certified DevSecOps Engineer (ECDE) Exam Practice Test

The secure communication principle focuses on protecting data as it moves between systems, services, and users. This is achieved by establishing and maintainingsecure trust relationships, which include strong authentication mechanisms, encryption, certificate management, and trusted communication channels. Preventing breaches and reducing attack surface are broader security objectives, not specific to communication security. Balancing default configuration settings relates to secure defaults rather than communication. Secure trust relationships ensure that only authenticated and authorized entities can exchange data and that information remains confidential and tamper-proof during transmission. Embedding this principle into DevOps culture ensures that secure communication practices are consistently applied across all stages of the DevSecOps pipeline.

========

By default, Brakeman returns a non-zero exit code when security warnings are detected, which can cause Jenkins builds to fail. The --no-exit-on-warn option modifies this behavior by instructing Brakeman toreturn an exit code of 0 even if warnings are found. This allows the CI pipeline to continue executing while still generating a security report that highlights vulnerabilities. This option is particularly useful when teams are initially integrating SAST tools and want visibility into security issues without immediately blocking builds. During the Build and Test stage, this approach supports gradual adoption of security enforcement, allowing teams to prioritize remediation efforts while maintaining delivery velocity. Over time, organizations can tighten policies by removing this option to enforce stricter build-breaking behavior once security baselines improve.

The DevSec Hardening Framework is commonly implemented usingChef, and it is executed locally using the chef-solo command. The -c flag specifies the configuration file (solo.rb), and the -j flag specifies the JSON attributes file (solo.json). Option A correctly uses both required parameters in the proper format. The other options incorrectly swap or misuse flags that are not supported by Chef-solo. Running this command applies secure configurations, compliance controls, and cryptographic standards to the target system. Executing DevSec Hardening Framework during the Operate and Monitor stage ensures that systems remain secure, compliant, and resilient against misconfiguration-based attacks.

========

Build-time checks are designed to enforce security gates within the CI/CD pipeline. When critical vulnerabilities such as SQL injection and cross-site scripting (XSS) are detected during this stage, the correct and expected behavior is tofail the build. Stopping the build process prevents insecure code from progressing to later stages such as testing, deployment, or production. Ignoring issues or merely sending alerts while continuing the pipeline undermines the purpose of shift-left security. Alerts to SIEM systems and issue trackers are typically supplementary actions, but the primary enforcement mechanism at build time is to block the pipeline when severity thresholds are exceeded. This approach reduces remediation costs, limits exposure, and ensures that only secure artifacts move forward in the DevSecOps lifecycle.

========

To identify the currently running Java binary used by Jenkins, administrators typically inspect the running processes on the Linux system. The command ps -aux | grep Jenkins lists all active processes and filters those related to Jenkins. This output includes details such as the user, process ID, and the full command line used to start Jenkins, which often contains the path to the Java executable. The other options reference invalid or nonexistent commands (pc, as, ac). Locating the Java binary is necessary when installing certificates into the correct Java keystore, which is required for secure communication between Jenkins and tools like Acunetix. Performing this setup during the Build and Test stage ensures that DAST scans can run securely and reliably as part of automated pipelines.

========

Dynamic Application Security Testing (DAST) and fuzz testing require a running application in order to actively probe for vulnerabilities such as injection flaws, authentication bypasses, and improper input handling. These techniques are therefore performed after the application has been built and deployed to a testing environment, categorizing them astest-time checks. Commit-time and build-time checks rely primarily on static analysis and dependency scanning and do not exercise application behavior at runtime. Deploy-time checks focus on configuration validation rather than aggressive attack simulation. Test-time checks are specifically designed to uncover critical and high-severity vulnerabilities by mimicking real-world attack scenarios. Performing DAST and fuzz testing during this stage allows teams to detect exploitable flaws before production release, significantly strengthening application security.

========

The command shown in the pre-build phase explicitly targets a script namedwss_agent.sh. The curl -LJO flags mean: -L follows redirects, -J honors the server-provided filename in the Content-Disposition header (when present), and -O writes output to a local file using the remote name. Since the requested path ends with wss_agent.sh, the downloaded file on the AWS CodeBuild server will be wss_agent.sh. This script is the WhiteSource (now commonly referred to as Mend in many environments) unified agent shell wrapper used to run SCA scans as part of a CI pipeline. Integrating SCA during the Build and Test stage helps detect vulnerable open-source dependencies and licensing/compliance issues early, when fixes are cheapest. The other filenames (ssw_agent.sh, cbs_agent.sh, aws_agent.sh) are distractors; they are not referenced by the provided command and would not be downloaded by that step.

========

Burp Suite’sOut-of-band Application Security Testing (OAST)feature is designed to detect vulnerabilities that do not produce immediate or visible responses during standard scanning. OAST works by triggering interactions such as DNS or HTTP callbacks, which occur outside the normal request-response cycle. This capability enables detection of blind vulnerabilities like blind SQL injection and server-side request forgery. Because findings are based on confirmed external interactions, OAST significantly reduces false positives. The other options listed are not valid Burp Suite features. Integrating OAST during the Build and Test stage improves the accuracy of dynamic security testing and ensures deeper coverage of complex and hard-to-detect vulnerability classes before applications are released.

========

ThreatSpec is a command-line tool that follows standard Unix-style conventions, where commands are lowercase. To generate a threat model report after annotating source code, the correct command is threatspec report. Commands using incorrect casing or capitalization will fail because the CLI is case-sensitive. Options A, B, and C incorrectly capitalize either the command or the subcommand. Generating threat model reports during the Plan stage allows DevSecOps teams to continuously identify, document, and visualize security threats as the code evolves. This practice embeds threat modeling directly into the development lifecycle, enabling early risk identification and more secure system design decisions.

========

To inspect mount propagation modes for Docker containers, Rockmond needs to list all container IDs and then inspect their configuration. The docker ps --quiet --all command outputs container IDs only, which are then passed to docker inspect using xargs. The --format option allows extraction of specific fields, such as mount propagation settings. Option C correctly uses valid flags (--quiet --all) and proper formatting syntax. Options A and D incorrectly use single hyphens, and option B omits the equals sign, which is required to display the propagation value. Inspecting mount propagation during the Operate and Monitor stage helps prevent unintended privilege escalation or data modification by other containers, aligning with container hardening best practices.

========

ThreatModeler’sAcceleratorcapability allows automatic generation of threat models directly from an organization’s live AWS environment. It connects to AWS services, analyzes deployed resources, and converts them into architectural diagrams and threat models without manual input. YAML-based orchestration tools and STRIDE per Element are methodologies used for modeling but do not automatically ingest live cloud configurations. Architect is a design construct, not an automation engine. Using Accelerator during the Plan stage enables proactive, continuous threat modeling, ensuring that evolving cloud infrastructure is always assessed for risk and security gaps.

========

To inspect exposed ports for running Docker containers, the recommended approach is to first retrieve container IDs using docker ps --quiet and then pass them to docker inspect. The --format option allows selective output of container configuration details, including port mappings. The command docker ps --quiet | xargs docker inspect --format ': Ports=' correctly extracts port information for each container. Options that include the --all flag or incorrect formatting are not valid for this inspection use case. Checking exposed ports is an important activity in the Operate and Monitor stage because unnecessary open ports increase the attack surface and may violate container security best practices. Regular inspection helps ensure that only required ports are exposed, supporting secure runtime operations.

========

Git post-commit hooks are executed automatically after a commit is successfully created. To trigger the Jenkins build job configured to respond to commits, Alex must create a valid Git commit using the correct Git command. The standard command to commit changes with a message is git commit -m "commit from terminal". Running this command records the changes in the repository and triggers the post-commit hook, which in turn initiates the Jenkins build. Commands using github commit are invalid because github is not a native Git command-line utility. The -b flag is also not used with git commit. Automating build triggers during the Code stage improves efficiency, reduces manual intervention, and ensures continuous integration is consistently enforced.

========

Bitbucket provides a cloud-based source code management platform that supports collaboration, CI/CD integration, and secure code hosting. One of the key features offered by Bitbucket isfree unlimited private repositories, particularly beneficial for organizations developing proprietary software such as IoT applications. This allows teams to store source code securely without exposing it publicly while still enabling collaboration features like pull requests, issue tracking, and pipeline automation. The term “limited private repositories” is inaccurate because Bitbucket does not restrict the number of private repositories under its free offering; rather, user count limits apply. While Bitbucket also supports public repositories, the option that best represents its value to enterprise and product-based teams is unlimited private repositories. This capability aligns with DevSecOps practices by ensuring confidentiality of source code while enabling integrated planning, testing, and deployment workflows within a single platform.

========

Jenkins plugins are distributed and installed as .hpi files. To manually install a plugin, administrators upload the .hpi file through the Jenkins Plugin Manager using the “Upload Plugin” option. This approach is commonly used in environments with restricted internet access or when custom plugin versions are required. .war files are used for deploying the Jenkins application itself, not plugins, while .zip and .conf files are not recognized plugin formats. Installing the InsightAppSec plugin allows Jenkins pipelines to automatically trigger dynamic application security scans during the Build and Test stage. This integration ensures that web applications are continuously evaluated for vulnerabilities before deployment, supporting proactive security testing and risk reduction.

========

When GitHub Code Scanning is enabled using CodeQL, each supported programming language is identified by a specific language key. For C++ code, CodeQL uses the identifiercpp, not “cp.” CodeQL workflows are commonly configured to run during pull request events so that security issues and coding errors can be detected and reviewed before code is merged into the main branch. As a result, the CodeQL analysis entry displayed in GitHub Actions and the Security tab for C++ pull request analysis appears asCodeQL/Analyze (cpp) (pull-request). Options A and B are incorrect because “cp” is not a valid CodeQL language identifier. Option C uses the correct language identifier but references an incorrect event format. Identifying the correct CodeQL analysis entry helps DevSecOps engineers confirm that scans are executing correctly for the intended language during the Code stage and that security feedback is available early in the development lifecycle.

========

Gauntlt is a security testing framework written in Ruby and distributed as a Ruby gem. The correct way to install a Ruby gem is using the gem install command followed by the lowercase gem name. RubyGems are case-sensitive and standardized to lowercase naming conventions, which makes gem install gauntlt the correct command. The gems command does not exist in Ruby’s package management ecosystem, and using uppercase names such as Gauntlt can lead to installation failures. Installing Gauntlt allows DevSecOps teams to write human-readable security tests and integrate them into CI/CD pipelines, enabling automated and collaborative security validation during the Build and Test stage.

========

Git hooks determine success or failure based on the exit code of the executed script. An exit code of0indicates 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.

========

Keywhiz CLI requires authentication before secrets can be added. The correct process involves logging in using the --devTrustStore option and authenticating as an administrator using the --admin flag. Once authenticated, the add secret command is used with input redirection to securely store the secret. Options that use incorrect flag names, incorrect casing, or invalid trust store identifiers do not follow Keywhiz CLI syntax. Adding secrets through Keywhiz instead of embedding them in code supports secure secret distribution and management, which is a fundamental aspect of DevSecOps culture. This approach ensures secrets remain protected, auditable, and available even during outages.

Ubuntu systems use the Advanced Package Tool (APT) for installing and managing software packages. The correct syntax for installing a package is sudo apt-get install . In this case, the OpenSSH server package required for secure remote access is named openssh-server, makingsudo apt-get install openssh-serverthe correct command. Options using apt.get are invalid because the command syntax is incorrect. Options that include the -s flag only simulate the installation process and do not actually install the package. Installing OpenSSH is often required when integrating Docker Bench with Jenkins, as it enables secure communication and remote execution of compliance checks. Performing this setup during the Build and Test stage ensures that container hosts comply with Docker CIS Benchmark recommendations, helping organizations identify misconfigurations and security weaknesses early in the pipeline.

========

The correct installation procedure for the Sqreen PHP microagent involves downloading the installer script and executing it with the organization token and application name. The curl -s option downloads the script silently, while the > redirection operator saves it locally as sqreen-install.sh. The script is then executed using bash, passing the required token and app name as parameters. Options using input redirection (<) are incorrect because they do not save the downloaded script to a file. The -i option includes HTTP headers in the output, which is unnecessary and could corrupt the script. Installing the microagent correctly enables runtime monitoring, attack detection, and automatic blocking, supporting strong runtime security during the Operate and Monitor stage.

========

AWS Inspector is a managed vulnerability assessment service designed specifically to scan workloads running on Amazon EC2 instances and container images for security vulnerabilities and unintended network exposures. It automatically evaluates instances against known vulnerabilities and security best practices, providing detailed findings and risk severity levels. AWS WAF protects web applications from common web exploits but does not perform host-based vulnerability scanning. AWS Config tracks configuration changes and compliance but does not actively scan workloads for vulnerabilities. Amazon CloudWatch focuses on monitoring logs, metrics, and alarms rather than security scanning. For a Spring Boot microservices application deployed on EC2, AWS Inspector is the correct choice to continuously assess security posture during the Build, Deploy, and Operate phases of the DevSecOps pipeline.

========

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.

========

Grype is a vulnerability scanning tool used to analyze container images and file systems for known vulnerabilities across operating system and application dependencies. The most effective way to perform a comprehensive scan is by running the grype --scope all-layers command. This ensures that vulnerabilities are detected acrossall layersof the container image, not just the final runtime layer. Containers often inherit vulnerabilities from base images or intermediate layers, making full-layer scanning essential. The packages subcommand is used for listing detected packages rather than performing vulnerability analysis. Running Grype during the Build and Test stage allows DevSecOps teams to identify vulnerable base images and dependencies early, reducing the risk of deploying insecure containers into production and supporting secure container lifecycle management.

========

The BDD Security framework is executed through Gradle wrapper commands, and the correct wrapper script on Unix-like systems is ./gradlew (dot-slash indicates “run the wrapper from the current directory”). Options using /gradlew or /gradlev imply an absolute path at filesystem root and are typically incorrect for a cloned project. Also, the wrapper name isgradlew, notgradlev. For executing only the authentication feature (or scenarios tagged for authentication), Cucumber tag expressions are used through the -Dcucumber.options system property. The command must include --tags @authentication to select authentication-tagged scenarios. To skip scenarios tagged “skip,” the exclusion operator is used as --tags ~@skip (meaning “exclude @skip”). Options A and B incorrectly include --tags @skip which wouldincludeskipped tests rather than exclude them. Therefore, ./gradlew -Dcucumber.options="--tags @authentication --tags ~@skip" is the correct choice to run authentication scenarios while excluding anything marked to skip.

========

Git requires developers to configure their identity using two specific configuration keys:user.nameanduser.email. These values are embedded into every commit and are essential for accountability, auditing, and collaboration. The correct configuration syntax uses dot-separated key names (user.name and user.email) and the --global flag to apply the settings across all repositories on the system. Among the provided options, only optionBuses the correct configuration keys. The other options use invalid key names such as user-name, user_name, or incorrect command structure. Although the options display a minor command typo (“get config” instead of git config), the question is clearly testing knowledge of the correct Git configuration keys. Configuring Git identity in the Code stage ensures accurate commit history and supports traceability across the DevSecOps pipeline.

Chef InSpec provides a command-line interface for creating and executing compliance profiles. To initialize a new profile with the required directory structure, metadata file, and example controls, the correct command is inspec init profile . In Jeremy’s case, running inspec init profile jyren-azureTests creates a new folder with all required artifacts needed to write and run Azure compliance tests. Options using prof are invalid abbreviations, and prefixing the command with chef is incorrect when using the InSpec CLI directly. Creating a structured InSpec profile during the Build and Test stage enables automated validation of infrastructure against architectural standards and security policies, supporting Infrastructure as Code security and continuous compliance practices.

========

In Conjur secret management, variables are first declared in policy files and then populated with actual secret values using the Conjur CLI. The correct command to assign a value to a variable is conjur variable set, where the -i option specifies the fully qualifiedpolicy path of the variable name, and the -v option specifies thesecret valueto be stored securely. This command writes the secret into Conjur’s encrypted vault and associates it with the declared variable so that Jenkins jobs can retrieve it securely at runtime. The other options misuse flags or reverse their meanings, which would result in invalid commands or incorrect secret handling. Integrating Conjur with Jenkins during the Build and Test stage ensures that sensitive credentials such as passwords, API keys, and tokens are never hard-coded in pipeline scripts or source code. Instead, secrets are dynamically fetched when required, supporting least-privilege access, auditability, and compliance requirements—critical for financial-sector applications.

========

Jira usesAtlassian Query Language, commonly referred to as JQL, to search, filter, and manage issues. This query language allows users to create advanced searches using fields such as project, status, assignee, priority, and custom attributes. Although often informally called Jira Query Language, the official name among the given options is Atlassian Query Language. SQL and Java query language are unrelated and not used for issue searching in Jira. Using JQL during the Code stage improves traceability between source code commits, builds, and tracked issues, enabling teams to monitor progress, validate deployment status, and maintain alignment between development and delivery activities.

========

To identify the version of a service running on a target system, Nmap uses the -sV option, which enables service version detection. The -sS flag specifies a TCP SYN scan, which is a common and efficient scanning method. Combining these two flags allows Nmap to discover open ports and accurately identify the service versions running on those ports, such as Jenkins. Options A and B reference invalid scan types (-sJ) and do not enable version detection. Option C includes the correct flags but places them in a less conventional order; however, the commonly accepted and documented usage is -sV -sS. Running this scan during the Operate and Monitor stage helps security teams understand exposed services and assess potential attack surfaces.

========