CompTIA PenTest+ Domain 1: Engagement Management

Rules of engagement are the detailed guidelines and constraints on executing the test, established beforehand and giving the team authority to act without additional per-action permissions.

• AA statement of work itemizes the deliverables, hours, and price of the project; it does not set the operational constraints and standing authority for how testing is executed.
• CThe scope statement defines what is to be tested; the question asks for the document governing how testing is conducted and the standing authority, which is a different artifact.
• DA non-disclosure agreement protects confidential information shared between the parties; it neither constrains testing execution nor grants authority to perform the defined activities.

Scope specifically defines what is to be tested; here the enumerated ranges, domains, and CDE perimeter establish precisely which systems are in bounds for the engagement.

• BRules of engagement govern how each aspect of the test is conducted, such as timing and constraints; they do not by themselves enumerate which target systems are in bounds.
• CA master service agreement sets the overarching commercial and legal terms of the relationship; it is not the artifact that lists which specific systems are in scope.
• DPayment terms address billing schedules and amounts; they have nothing to do with identifying which IP ranges, domains, and systems may be tested.

The provider is responsible for protecting the infrastructure that runs its services — hardware, hypervisor, and facilities — the layer described as security of the cloud.

• AThe customer is responsible for security in the cloud — its data, configurations, and workloads — not the underlying physical infrastructure, which falls outside what the tenant controls.
• BThe testing firm assesses systems within an authorized scope; it never owns operational security responsibility for the provider's infrastructure under the shared responsibility model.
• DEnd users consume the application and hold no responsibility for infrastructure security; the shared responsibility split is strictly between the provider and the customer tenant.

Across every cloud deployment model the customer always owns its data and identities, remaining responsible for classifying, protecting, and managing accounts and access.

• BSecuring datacenter facilities, including physical access and environmental controls, is the provider's responsibility in all cloud models, not something the customer retains.
• CThe virtualization layer and physical hosts are managed by the provider; the customer never retains responsibility for the hypervisor or underlying server hardware.
• DThe provider's physical network infrastructure is its responsibility; the customer configures only its own logical network controls, not the provider's backbone.

A penetration test has evaluators mimic real-world attacks to identify ways to exploit and circumvent the security features of systems, exactly as described.

• AA vulnerability scan identifies, ranks, and reports potential weaknesses but does not actively exploit them; the scenario requires exploitation to circumvent security features.
• BA compliance gap audit compares controls against a standard's requirements; it is a documentation and control review, not active exploitation of vulnerabilities.
• DA configuration review inspects settings against a baseline without attacking the system; it cannot demonstrate exploitable paths that defeat security features.

Black-box testing assumes no knowledge of the internal structure and is performed without prior detail of the target, matching the no-information condition described.

• AWhite-box testing assumes explicit and substantial knowledge of the internal structure and implementation; the client here deliberately withholds all such detail.
• CGrey-box testing assumes some knowledge of the internal structure; the scenario provides none at all, so it exceeds the information available to a grey-box tester.
• DA credentialed configuration review depends on supplied access and internal detail; that contradicts the client's refusal to provide any prior information.

White-box testing assumes explicit and substantial knowledge of the internal structure and implementation, which is exactly what the full documentation and source code provide.

• ABlack-box testing assumes no knowledge of the internal structure; the client here supplies complete internal detail, which is the opposite condition.
• BGrey-box testing assumes only some knowledge of the internal structure; the scenario provides full and complete detail, exceeding the grey-box information level.
• CA blind external scan probes from outside with no internal information; that conflicts with the client handing over source code and architecture documentation.

Grey-box testing assumes some knowledge of the internal structure and is performed with partial details of the target, matching the limited information the client supplied.

• BBlack-box testing assumes no knowledge of the internal structure; here the client provided a user account and partial detail, which is more than black-box allows.
• CWhite-box testing assumes explicit and substantial internal knowledge; the client deliberately withheld source code and full documentation, so this exceeds what was given.
• DAn unauthenticated scan uses no credentials and only identifies surface weaknesses; the client supplied an account and partial detail, which describes a knowledge level, not a scan.

The executive summary is written for leadership overseeing the security program, focusing on business impact and high-level findings while leaving out technical detail.

• AThe technical findings section targets engineers with reproduction steps and remediation detail; it is not the non-technical, business-impact view leadership needs.
• CRules of engagement are a pre-engagement agreement on how testing is conducted; they are not the narrative report section addressed to senior leadership.
• DThe statement of work defines deliverables and hours before testing; it is a contractual artifact, not the report section summarizing findings for executives.

The technical findings section is aimed at the technical team and details each vulnerability with the scope, attack path, impact, and remediation needed to fix it.

• AThe executive summary is the non-technical, business-impact overview for leadership; it intentionally omits the reproduction and remediation detail engineers require.
• BThe scope statement defines what was in bounds for testing; it does not contain the per-vulnerability technical detail, attack path, and remediation guidance.
• DA non-disclosure agreement governs confidentiality of shared information; it is unrelated to documenting and remediating the specific vulnerabilities found.

Root cause analysis after an assessment translates findings into actionable mitigations and surfaces failed processes, addressing organizational weaknesses, not just the symptomatic patch.

• AA business impact analysis estimates the consequences of disruption to processes and assets; it does not trace findings back to the underlying process failures that caused them.
• BRetesting confirms whether findings were remediated; it verifies fixes but does not identify the systemic process weaknesses behind the vulnerabilities.
• CRescoring with CVSS reprioritizes findings by severity; it changes ranking but never reveals the root process failures or translates findings into mitigations.

Performing testing off-hours and on duplicates of production systems is a recommended way to minimize the risk that assessment techniques affect production availability.

• BRunning intrusive tests at peak hours maximizes the chance of disrupting live operations; that raises rather than reduces the risk to production availability.
• CSkipping exploitation altogether would prevent validating real risk; the goal is to manage impact through scheduling and duplicates, not to abandon the test's purpose.
• DChoosing black-box over white-box concerns how much information the tester has, not how testing load affects production; it does not inherently reduce availability impact.

In IaaS the customer manages the guest operating system, including updates and security patches, along with the applications it installs on the instances.

• AIn IaaS the provider secures the underlying infrastructure but not the guest operating system; OS patching of customer instances is not the provider's duty.
• BThe testing firm assesses the systems within scope; it never assumes operational responsibility for patching the client's virtual machines under the shared model.
• DIaaS does not auto-patch guest operating systems; assuming it does leaves instances unpatched, and the responsibility still rests with the customer tenant.

Because the client does not own the hosting infrastructure, the cloud provider must be alerted and must grant permission, often via its own testing policy or request form.

• AThe client cannot speak for its third-party providers; their authorization does not automatically extend to the hosting provider's infrastructure and systems.
• CCloud-hosted assets can be tested once proper permission is obtained; excluding them outright is unnecessary and misstates how third-party authorization works.
• DNotifying the ISP does not satisfy the hosting provider's authorization requirement, and beginning before the provider grants permission risks legal and policy violations.

The fundamental purpose is to identify the business risk associated with attacks and translate findings into risk mitigation that improves security posture.

• AA penetration test should not be a confrontational contest to show the tester can hack; framing it that way undermines the engagement's real, business-focused purpose.
• BTotal compromise is not an end in itself; pursuing it without regard to scope and impact ignores the goal of informing business risk decisions.
• CAssessments are not meant to take the place of implementing and maintaining security controls; a test evaluates controls, it does not replace them.

A good report appeals to both executive management and technical staff, splitting into an executive summary and a detailed findings section for those distinct audiences.

• BLegal counsel may review confidentiality terms, but the report is not written solely for them; it must reach both leadership and the technical remediation team.
• CSOC analysts are one technical audience, but a complete report also has to communicate business impact to executives, so this excludes a required audience.
• DRegulators may consume results for compliance, but the report's two major sections are designed for management and technical staff, not auditors alone.