CISA Information Systems Acquisition & Development: Agile and DevOps — Complete Study Guide

Most CISA candidates stumble on Agile and DevOps questions because they try to audit the tools. The exam, however, tests whether you can audit the process. The number one mistake is applying obsolete, waterfall-era change management logic to a modern CI/CD pipeline, a trap that makes you select the wrong control every time.

Key facts

• Exam Domain: Domain 3: Information Systems Acquisition, Development, and Implementation
• Domain Weighting: 18% of the CISA exam
• Key Concepts: CI/CD pipeline, Infrastructure as Code (IaC), containers, microservices, DevSecOps
• Audit Focus: Continuous assurance, automated controls, and governance in rapid-release cycles
• Primary Frameworks: COBIT 2019, ITIL 4, and the NIST Cybersecurity Framework (CSF)
• Official Body: ISACA (Information Systems Audit and Control Association)

The official ISACA CISA Exam Content Outline (effective June 2024) weights Domain 3 at 18% of your total score, making these modern development topics essential for passing.

How Are Agile and DevOps Tested on the CISA Exam?

The CISA exam tests your judgment by placing you in realistic audit scenarios related to Agile and DevOps. Expect questions that require you to identify new risks, assess modern controls, and recommend appropriate audit procedures for fast-paced development environments. Your primary goal isn't to slow down development; it's to provide assurance that governance, security, and compliance are built into the process.

Agile is a mindset guided by values like iterative delivery and responding to change. Frameworks like Scrum and Kanban put these principles into practice through short "sprints" and a focus on working software. DevOps extends Agile by integrating development (Dev) and IT operations (Ops) through a culture of automation. This enables a continuous integration/continuous delivery (CI/CD) pipeline, where code can move from a developer's keyboard to production multiple times a day.

What are the most common traps for candidates?

The number one reason candidates stumble is by applying an old audit mindset to new technology. They mistakenly:

1. Demand waterfall controls: Insisting on a formal change approval board (CAB) sign-off when the modern equivalent is an approved pull request with automated security scan results.
2. Focus on tools over principles: Knowing what Kubernetes is is less important than understanding the audit implications of container orchestration, such as the need for image security and network segmentation.
3. Overlook the "continuous" aspect: Controls in DevOps are not point-in-time checks. They are ongoing processes like automated monitoring and integrated security validation.
4. Ignore governance: Assuming speed eliminates the need for clear product ownership and business requirement validation.

To avoid these traps, shift your focus from manual, periodic checks to automated, continuous assurance. If you're struggling with this mindset shift, VoraPrep's AI tutor, Vory, can provide 24/7 guidance on these complex scenarios. Try VoraPrep's free CISA practice questions to see how you stack up.

How Does Auditing Agile/DevOps Differ from Traditional Auditing?

An auditor's approach must fundamentally change to be effective in an Agile or DevOps environment. You move from being a gatekeeper at the end of a long process to being a consultant embedded within a continuous cycle.

Audit Area	Traditional (Waterfall) Approach	Agile/DevOps Approach
Change Management	Formal, manual change approval board (CAB) meetings.	Automated pipeline with integrated peer reviews (pull requests) and pre-approved, low-risk changes.
Testing	Performed in a distinct, late-stage phase (e.g., UAT).	Continuous, automated testing integrated throughout the pipeline ("shift left").
Documentation	Comprehensive, upfront design documents.	"Just enough" documentation; working software and user stories are primary. The system itself (e.g., IaC scripts) is a form of documentation.
Auditor Involvement	Point-in-time audits at phase gates.	Continuous auditing; auditor acts as a consultant, reviewing the pipeline and controls, not just the final product.
Security	Often a separate, late-stage security review or penetration test.	Security is integrated into the entire lifecycle (DevSecOps), with automated security scanning (SAST, DAST, IAST) in the pipeline.

What Key Technical Concepts Must an Auditor Understand?

Your role is to understand the governance, risk, and compliance (GRC) implications of each concept, aligning with frameworks like COBIT 2019 and ITIL 4.

How Should an Auditor Assess Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) is the practice of managing infrastructure (servers, networks, databases) through machine-readable definition files, like Terraform or CloudFormation scripts. For an auditor, these scripts are a primary source of evidence. Audit & GRC Implications:

• Version Control as Audit Trail: IaC scripts must be stored in a version control system like Git. This provides a complete, immutable audit trail of every infrastructure change, including who made the change, when, and why.
• Change Management via Code Review: Changes to IaC must follow a defined review and approval process. A mandatory peer review on a pull request is the modern equivalent of a CAB meeting and helps enforce segregation of duties.
• Policy as Code: Audit for the use of tools that enforce compliance and security rules programmatically (e.g., OPA Gatekeeper). This prevents misconfigurations before they are deployed.
• Secrets Management: Sensitive data like API keys or passwords must never be hardcoded in IaC files. Audit for the use of a secure secrets management solution (e.g., HashiCorp Vault, AWS Secrets Manager).
• Drift Detection: Implement tools to detect "configuration drift"—manual changes made to infrastructure that bypass the IaC process. Drift undermines the control and consistency IaC is meant to provide.

What Are the Key Audit Risks in a Containerized Environment?

Containers (e.g., Docker) package an application and its dependencies into an isolated unit, while Container Orchestration systems (e.g., Kubernetes) automate their management. This creates new layers of abstraction and risk. Audit & GRC Implications:

• Software Supply Chain Security: The audit must verify the container image lifecycle. Are base images from trusted, hardened sources? Are images scanned for known vulnerabilities (CVEs) in the CI/CD pipeline? Is a Software Bill of Materials (SBOM) generated and reviewed?
• Network Segmentation: Review network policies within the orchestrator (e.g., Kubernetes Network Policies) to ensure proper segmentation. This limits the blast radius of a potential compromise.
• Access Control: Audit the role-based access control (RBAC) for the orchestration platform. Who can deploy containers or alter network policies? The principle of least privilege must be strictly enforced.
• Observability: Verify that the system provides robust observability through aggregated logs, metrics, and distributed tracing. This is critical for security monitoring and incident response, aligning with principles in NIST SP 800-137 (Information Security Continuous Monitoring).

How Does a Microservices Architecture Change the Audit Approach?

Microservices is an architecture where an application is composed of small, independently deployable services that communicate via APIs. This distributed nature fundamentally changes the attack surface. Audit & GRC Implications:

• API Security: APIs are the new perimeter. The audit must focus on API security controls: strong authentication, authorization, rate limiting, and input validation, ideally managed by a central API Gateway.
• Data Governance: In a distributed system, an auditor must ask how sensitive data is protected and how compliance with regulations like GDPR is managed when data is spread across multiple services and databases.
• Distributed Monitoring: Centralized logging and distributed tracing are critical for observability. Without them, performing forensic analysis or troubleshooting issues across services is nearly impossible.
• Service Mesh: A service mesh (e.g., Istio) can enforce security policies like mutual TLS (mTLS) for service-to-service communication. Auditors should review its configuration to ensure security is enforced consistently.

What is a "Spike" and Why Does it Matter to Auditors?

In Agile, a spike is a short, time-boxed research activity to reduce uncertainty or a technical risk. An auditor should view spikes as a key control for proactive risk management. They are evidence that the team is identifying and addressing technical uncertainties or security flaws before they become major problems. While informal, the outcomes of a spike should be documented to inform the product backlog.

CISA Worked Example: Auditing a DevOps Environment

Let's walk through a realistic scenario to show you how to think like the examiner.

Scenario: Horizon Bank is developing a new mobile banking app using microservices on a public cloud. They use a full DevOps CI/CD pipeline, with Infrastructure as Code (IaC) and Kubernetes. The IS auditor, Sarah, is reviewing security controls before the Q4 2026 launch.

Sarah discovers:

1. IaC templates in Git are reviewed by only one developer before being automatically deployed.
2. Container images are pulled from public registries and scanned for vulnerabilities only once a month.
3. Microservices communicate via APIs, but there is no central API gateway; individual teams handle their own API security.
4. Container logs are stored locally and are not aggregated.

Question: What is the most critical security concern Sarah should prioritize, and what is the most appropriate recommendation? Step-by-Step Reasoning Process:

1. Understand the Auditor's Objective: Sarah's goal is to identify the highest-impact vulnerability for a mobile banking application before it goes live. Prioritization must be based on potential business impact, such as financial loss, data breach, or reputational damage.
2. Analyze Each Finding:

• Finding 1 (IaC Review): Lack of segregation of duties. A significant control gap.
• Finding 2 (Container Scanning): Infrequent vulnerability scanning. A very high foundational risk.
• Finding 3 (API Security): Decentralized, inconsistent API security. A very high application risk.
• Finding 4 (Logging): No central logging. A critical detective control gap.

1. Prioritize the Most Critical Concern: This is where CISA judgment is crucial. Both Finding 2 and Finding 3 represent critical, preventative control weaknesses.

• The Case for API Security (Finding 3): For a banking app, APIs are the front door to the application's business logic and data. They directly expose functions for transferring funds, viewing balances, and accessing personal information. Inconsistent security across these APIs creates a wide, unpredictable attack surface directly tied to the bank's core function and sensitive data.
• The Case for Container Scanning (Finding 2): A severe vulnerability in a container's underlying software could allow an attacker to bypass application-level controls entirely. This is a foundational, systemic risk.

The CISA exam requires you to choose the most critical issue based on business context. While a container vulnerability is a severe technical risk, a compromised API in a banking app represents a direct, immediate threat to financial transactions and customer data integrity. Therefore, the decentralized API security (Finding 3) is the most critical business risk.

1. Formulate the Recommendation: The recommendation must directly address the prioritized finding and be actionable.

Conclusion:

The most critical security concern is the lack of a centralized API gateway and inconsistent API security policies across microservices (Finding 3).

The most appropriate recommendation is for Horizon Bank to implement a centralized API gateway to enforce consistent security policies—including authentication, authorization, and input validation—across all microservices APIs.

The Tempting Wrong Answer and Why It's Wrong

A very tempting wrong answer is to prioritize the infrequent container scanning (Finding 2). It's a severe risk. However, for a mobile banking application built on microservices, the API layer is the direct interface to sensitive data and financial functions. Securing this layer with a consistent, centrally managed control (an API gateway) addresses the most immediate and probable threat vector related to the application's purpose. The exam expects you to connect the technical risk to the business context.

Study Tips and Exam-Day Strategy

• Time Allocation: Expect to see these topics in 5-8 questions. Don't rush them. Identify the practice (IaC, CI/CD), the auditor's goal, and the control principle being tested.
• Connect to Other Domains: These concepts link across the CISA blueprint. The security controls relate directly to Domain 5. For a quick refresher, use our CISA Protection of Information Assets Cheat Sheet (2026).
• Final Week Review: Don't just re-read textbooks. Focus on the "why." Review your incorrect practice questions on VoraPrep to understand your judgment gaps. Our CISA IS Acquisition, Development & Implementation Cheat Sheet (2026) is perfect for a rapid review of key terms and their audit implications.

Frequently asked questions

How many questions on Agile and DevOps appear on the CISA exam? Expect 5-8 scenario-based questions. These concepts are a core part of Domain 3, which constitutes 18% of the exam. What's the best way to study Agile and DevOps for CISA? Focus on audit judgment, not tool definitions. Use realistic practice questions, like those in the VoraPrep CISA question bank, to learn how to apply control principles to automated pipelines. Is Agile and DevOps tested in simulations or only multiple-choice questions? The CISA exam consists entirely of multiple-choice questions (MCQs). All questions on these topics are presented as MCQs, typically within detailed audit scenarios. How long should I spend studying Agile and DevOps? Dedicate at least 15-20 hours of your Domain 3 study time to these topics. This should include learning the concepts and practicing numerous scenario questions. To fit this into a busy schedule, check out our guide on how to pass the CISA while working full time.

--- Ready to Pass Your CISA Exam? Don't let modern development practices catch you off guard. VoraPrep provides 2,300+ practice questions with detailed explanations, an adaptive learning engine that targets your weak areas, and a 24/7 AI tutor (Vory) to ensure you're fully prepared.

Visit voraprep.com to get started.

Start Your Free 14-Day Trial at voraprep.com →

---

Related Resources

• CISA Salary Guide 2026: How Much Do CISAs Earn? — Understand the financial rewards of certification and how your skills translate to market value.
• CISA Pass Rates 2026: What to Expect — Get a realistic view of the exam's difficulty and what it takes to succeed.
• 15 Tips to Pass the CISA Exam in 2026 — Actionable advice to improve your study efficiency and exam-day performance.
• CISA Exam Changes 2026: What Candidates Need to Know — Stay current on the latest updates to the CISA exam content outline.
• 90-Day CISA Study Plan (2026): Daily Schedule for Busy Candidates — A structured plan to guide your preparation from start to finish.
• CISA CISA1 Risk-Based Audit Planning: Common Mistakes and How to Avoid Them (2026) — Connect DevOps audit concepts back to the foundational principles of risk-based auditing.

Official resources and references

• ISACA CISA Certification Page — The official source for CISA exam details, the candidate guide, and the exam content outline.
• COBIT Framework — The ISACA framework for the governance and management of enterprise IT, which provides context for CISA audit objectives.
• NIST Special Publication 800 Series — Authoritative U.S. government guidance on information security topics relevant to CISA domains.
• U.S. Bureau of Labor Statistics - Information Security Analysts — Provides salary and job outlook information for roles related to the CISA certification.