Free DEVSECOPS Practice Test

A standard naming convention's primary benefit is enhancing readability and understandability for developers and operators. Consistent names for variables, functions, files, or infrastructure resources make the system's purpose and structure self-evident. This clarity reduces cognitive load, simplifies maintenance, and accelerates debugging and onboarding of new team members. While other benefits like sortability may arise from specific naming patterns, readability is the most fundamental and universal advantage that underpins overall code and system quality.

A. Sortability is a benefit of specific naming schemes (e.g., using date prefixes), but it is not the universal primary benefit of all standard naming conventions.
B. Abstraction is a design principle for hiding complexity; while good naming supports it, the convention's main goal is clarity, not abstraction itself.
C. Indexation, or making items easy to find, is a positive outcome of good naming, but it is a secondary benefit derived from the primary goal of readability.

1. Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. Chapter 2, "Meaningful Names," extensively discusses how the primary purpose of naming is to reveal intent and improve readability.

2. MIT OpenCourseWare. (2016). 6.031: Software Construction. Lecture 2: "Designing for Readability." This course material emphasizes that a key goal of coding style, including naming conventions, is to make code readable for other humans. (ocw.mit.edu/courses/6-031-software-construction-spring-2016/).

3. McConnell, S. (2004). Code Complete (2nd ed.). Microsoft Press. Chapter 11, "The Power of Variable Names," states that a good variable name's primary goal is to provide clarity and understanding, which is synonymous with readability.

The IT security learning continuum is often described by the Awareness, Training, and Education (ATE) model. Awareness is the foundational level, designed to establish a baseline of security literacy across an organization. Its goal is to make everyone conscious of security policies, common threats, and their role in safeguarding information. This level focuses on the "what" (what are the policies, what are the risks) rather than the "how" (training) or the "why" (education), making it the correct answer for covering "security basics and literacy."

A. Education is the most advanced level, focusing on in-depth knowledge and critical thinking (the "why") to solve complex and novel security problems.
C. Immersion is not a standard category in the widely accepted ATE security learning model. It typically refers to a hands-on learning method, not a level.
D. Training is the intermediate level that builds specific skills and teaches individuals "how" to perform their job functions securely according to procedures.

1. Wilson, M., & Hash, J. (2003). NIST Special Publication 800-50, Building an Information Technology Security Awareness and Training Program. National Institute of Standards and Technology. Section 2.2, "Differentiating Among Awareness, Training, and Education," defines awareness as the level that establishes a common baseline of understanding for all users.

2. Schweitzer, D. (2013). A layered approach to security education, training, and awareness. In Proceedings of the 2013 on InfoSecCD '13: Information Security Curriculum Development Conference. ACM, New York, NY, USA, 110–115. https://doi.org/10.1145/2508337.2508356. (This paper explicitly details the ATE model, defining awareness as the foundation for establishing a security-conscious culture).

A key principle and primary benefit of a peer code review is the early identification of defects, security vulnerabilities, and logic errors. By having another developer examine the code before it is merged into the main branch, issues can be caught and fixed when the cost of remediation is lowest. This practice aligns with the "shift left" security principle in DevSecOps, where quality and security checks are integrated as early as possible in the software development lifecycle. It also promotes knowledge sharing and adherence to coding standards across the team.

B. Peer code reviews are typically an integral part of a formal change process, providing a crucial quality gate and audit trail, not a way to bypass it.
C. While code reviews require focused work, "task speculation" is not a standard term or goal. The focus is on the quality and correctness of the submitted code.
D. Code reviews empower teams with quality ownership, but they do not replace management's responsibility for overall quality assurance; they are a tool to help achieve it.

1. McConnell, S. (2004). Code Complete (2nd ed.). Microsoft Press. Chapter 21, "Collaborative Construction," details how reviews are one of the most effective ways to find defects early.

2. Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. Proceedings of the 35th International Conference on Software Engineering (ICSE '13), 712–721. https://doi.org/10.1109/ICSE.2013.6606629. This academic study identifies "finding defects" as a primary expected outcome of code reviews (Table 1, p. 714).

3. Siy, H., & Votta, L. (2005). Does the modern code inspection have value? Journal of Systems and Software, 74(2), 159-166. https://doi.org/10.1016/j.jss.2004.02.027. The research confirms the continued value of code inspections (a formal type of review) for defect detection.

Checking source code for programmatic and stylistic errors using tools like linters is a universal software development best practice for maintaining code quality and consistency. It is not a security requirement that is unique to mobile applications; it applies equally to web, desktop, and backend development. In contrast, securing on-device secrets for backend calls, designing for operation on untrusted public networks, and preventing data leakage between sandboxed applications are all security challenges that are particularly prominent and specific to the mobile application environment.

B. Securely storing secrets (e.g., API keys, tokens) on a user-controlled device is a critical and specific challenge for mobile security.
C. Mobile applications are inherently designed to run outside a secure corporate perimeter on untrusted networks, a primary security design constraint.
D. Preventing data leakage between applications through mechanisms like insecure storage or clipboard access is a core security concern for mobile OS platforms.

1. OWASP. (2016). Mobile Top 10 Security Risks. M1: Improper Platform Usage, M2: Insecure Data Storage, M4: Insecure Authentication. These risks highlight security concerns specific to the mobile context, such as handling secrets, data, and network connections on the device. Checking for stylistic errors is a general coding standard, not a unique mobile security risk.

2. Enck, W. (2014). CSC 495/591: Mobile and Cloud Security. North Carolina State University. Lecture 2: Android Security Architecture. Discusses application sandboxing and inter-component communication as a core, mobile-specific security design.

This option provides the most complete and logical sequence for a modern software development lifecycle incorporating CI/CD. It begins with the pre-development 'Design' phase. The CI/CD pipeline proper starts with 'Develop', 'Build', and 'Test'. 'Provision' prepares the necessary infrastructure. The sequence 'Deploy' then 'Release' reflects the modern best practice of decoupling deployment (placing code in production) from release (making features available to users), which enhances control and reduces risk.

A. This option contains a typo ("lest" for "test") and presents a less common sequence of release/deploy compared to the modern decoupled approach.
C. This option omits the critical 'Design' phase, making it a less complete description of the overall process from concept to delivery.
D. This option places 'release' before 'deploy'. While valid in a traditional sense (creating a release artifact), it doesn't reflect the modern, risk-reducing pattern of decoupling.

1. Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional. (Chapter 1 introduces the core concepts, and later chapters on deployment patterns discuss the separation of deploying code from releasing features to users).

2. Fowler, M. (2017). Feature Toggles (aka Feature Flags). martinfowler.com. (This article, from a highly reputable source in software engineering, explicitly details the practice of deploying code to production behind a toggle and then "releasing" it to users separately, supporting the 'deploy' then 'release' order).

Risk management in DevSecOps focuses on identifying, assessing, and mitigating risks within the software delivery lifecycle and for specific applications. Managing major events (incident response) is a direct component of risk management, as it deals with the realization and containment of identified or unidentified risks. Informing business decisions and ensuring compliance are also core functions. However, assessing the effectiveness of the entire cybersecurity program is a broader, strategic governance and audit function that sits above the operational risk management performed within DevSecOps. While related, it is generally considered outside the direct scope.

B. Informing business risk decisions is a primary output and purpose of risk management, providing data for stakeholders to accept, mitigate, or transfer risk.
C. Assessing the effectiveness of the cybersecurity program is a higher-level governance or audit function, not a direct part of operational risk management within DevSecOps.
D. Ensuring the ability to meet compliance controls is a key driver for risk management; managing the risk of non-compliance is a critical, in-scope activity.

1. National Institute of Standards and Technology (NIST). (2011). Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and Information System View. Section 2.2, "The Tiers of Risk Management," distinguishes between organizational (Tier 1), mission/business process (Tier 2), and information system (Tier 3) levels. Assessing the entire program is a Tier 1 activity, while DevSecOps risk management is primarily Tier 2 and 3.

2. Myrbakken, H., & Røstad, L. (2017). DevSecOps: A Case Study of the Practice in a Financial Technology Company. Norwegian University of Science and Technology. Page 11 discusses how risk assessments are integrated into the pipeline to "provide decision support."

The statement describes a container that has broken its isolation and gained read-write access to the host's filesystem. This is a critical security vulnerability and a primary risk associated with running a container in "privileged" mode. Privileged containers are granted capabilities that effectively disable the security boundaries between the container and the host, allowing for such dangerous access. This scenario represents a failure of container security, not a requirement or benefit.

B. Container credentials are for authenticating to external services (like a database or cloud API), not for accessing the host filesystem.
C. This is the direct opposite of the described situation. Container isolation is the security mechanism designed to prevent a container from accessing the host's disks.
D. Container immutability is a best practice to prevent changes to running containers, but it is a separate concept from the container's access privileges to the host system.

1. National Institute of Standards and Technology (NIST). (2017). NIST Special Publication 800-190: Application Container Security Guide. https://doi.org/10.6028/NIST.SP.800-190 (Section 3.2, "Risks Associated with the Use of Containers," explicitly lists container breakout to the host as a major risk, often enabled by excessive privileges).

2. Docker Documentation. (n.d.). Runtime privilege and Linux capabilities. Docker Inc. (The official documentation warns that the --privileged flag gives a container "all capabilities" and access to all devices on the host, and advises against its use due to the significant security risks).

Firewalls are broadly categorised as network-based (appliance) or host/ computer-based. A computer-based firewall runs on an individual host OS, filtering traffic entering or leaving that specific machine.

B. “System-based” is not a standard firewall class in NIST/ISO literature.
C. Firewalls enforce policy at host or network level, not per user.
D. Cloud-based firewalls describe a deployment model (FWaaS), not a distinct canonical type.

1. NIST SP 800-41 rev1, §5.2 “Host-Based (Personal) Firewalls”.

2. ISO/IEC 27033-4:2014, §8.3 “Host Firewall Implementations”.

3. MIT OCW 6.858, “Network Security” lecture notes, slide 21 (“Host vs. Network Firewalls”).

The most effective role for security experts in a DevSecOps environment is to evolve from traditional gatekeepers into enablers. By becoming coaches and "tool smiths," they empower development teams with the knowledge and automated tools needed to build security into the software development lifecycle (SDLC) from the start. This approach scales security expertise across the organization, fosters a culture of shared responsibility, and aligns with the core DevSecOps principle of integrating security seamlessly into workflows rather than adding it as a final, separate step. This transformation is fundamental to achieving speed and security simultaneously.

B. This is too late. DevSecOps requires security involvement from the earliest stages of the SDLC (e.g., requirements, design), not just sometime before going live.
C. While important for personal development, attending training is an input to being effective, not the direct act of supporting the organization's DevSecOps adoption.
D. This describes a traditional, siloed security function. While assessments are still valuable, the best support involves enabling teams, not just auditing their work after the fact.

1. PEOPLECERT. (2021). PEOPLECERT DevSecOps Qualification Syllabus (Version 1.1). Section 3.3.1, "The DevSecOps professional must be able to explain the importance of culture in a DevSecOps environment," emphasizes the cultural shift where security becomes a shared responsibility, facilitated by security experts acting as champions and enablers.

2. Myrbakken, H., & Colomo-Palacios, R. (2017). DevSecOps: A Multivocal Literature Review. In Software Process Improvement and Capability Determination (pp. 17-29). Springer, Cham. This academic review discusses the role change of security personnel to become advisors and facilitators within development teams. (DOI: https://doi.org/10.1007/978-3-319-69341-92)

3. MIT OpenCourseWare. (2016). 6.857 Computer and Network Security, Fall 2016. The principles taught often highlight the need for usable security and integrating security thinking into the design phase, which aligns with the coaching and tool smith role.

DevOps emerged from the convergence of two major movements. The first is Agile software development, which emphasizes iterative progress, customer collaboration, and rapid response to change. The second is Lean thinking, derived from manufacturing principles, which focuses on optimizing the flow of value to the customer by eliminating waste. DevOps applies these combined principles to the entire software delivery lifecycle, breaking down silos between development (Agile) and operations (Lean-inspired system thinking) to create a more efficient, holistic process.

B. ITIL is a framework for IT Service Management. While it can be integrated with DevOps, it was not a foundational principle that led to DevOps.
C. SAFe (Scaled Agile Framework) is a framework that incorporates DevOps principles to apply Agile at an enterprise scale; it is a consumer of DevOps, not a precursor.
D. SAFe is a framework that came after the establishment of DevOps principles and seeks to implement them at scale, not a foundational source.

1. Ebert, C., Gallardo, G., Hernantes, J., & Serrano, N. (2016). DevOps. IEEE Software, 33(3), 94-100. https://doi.org/10.1109/MS.2016.68. (Page 96 explicitly states, "DevOps has its roots in agile and lean approaches").

2. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. IT Revolution Press. Chapter 2, "The Three Ways: The Principles Underpinning DevOps," directly links the principles to Lean manufacturing and the Agile Manifesto. (While a commercial book, its authors are foundational to the DevOps movement and it is widely cited in academic literature).