ISTQB Specialist (CT-STE v1.0.1) Mock Exam #1 — Questions & Answers
Every question in this mock exam, with the correct answer marked and a written rationale behind each option below — for reading and review, not a timed run.
A hospital records system stores three data sets: the publicly advertised opening hours of each clinic, the internal duty rosters of nursing staff, and the diagnostic histories of individual patients. The organization has classified these three data sets at different asset security levels. How should that classification influence the security testing effort?
The deepest and most rigorous testing should target the diagnostic histories, because the required protection level follows from the sensitivity and value of the asset being protected.
Correct. Chapter 1 derives the required protection level, and hence test rigour, from asset classification; patient diagnostic data is the most sensitive of the three.
The effort should be spread evenly over the three data sets, because all three are reachable through the same application interface and therefore share one exposure surface.
Incorrect. A shared interface does not equalise asset value; the syllabus scales protection and testing to the sensitivity of the data behind the interface.
The effort should follow the record volume of each data set, because a larger data store is a more attractive target for exfiltration than a smaller one.
Incorrect. Volume may raise impact in some cases, but the syllabus bases the required protection level on asset value and sensitivity, not row counts.
The effort should follow the number of user roles able to reach each data set, because the breadth of granted access is what determines the required protection level.
Incorrect. Access breadth is an input to risk analysis, but the asset security level is set by the sensitivity and value of the asset itself.
The required level of protection — and therefore the rigour and depth of security testing — is derived from the sensitivity and value of the asset. The most sensitive asset class attracts the deepest testing.
How does the CT-STE syllabus describe the relationship between security testing and a security audit?
Security testing supplies evidence to the security audit, which is the wider assessment of whether people, processes and technology conform to the defined security policies.
Correct. The audit is the broader conformance assessment; test results are one of its inputs.
A security audit is one of the dynamic test techniques the security test engineer executes against the running system, comparable in scope to a vulnerability scan.
Incorrect. An audit is an assessment of conformance to policy across people, process and technology, not a dynamic test technique.
A security audit assesses conformance to the security policies, and security testing is the follow-up activity that remediates the non-conformances the audit reported.
Incorrect. Remediation is performed by development and operations; testing provides information about weaknesses rather than fixing them.
A security audit covers the technology controls, while security testing covers the people and the process sides of the same set of concerns.
Incorrect. This inverts the scopes: the audit addresses people, process and technology together, while testing is largely technical evidence gathering.
A security audit is the broader assessment of whether people, processes and technology conform to the defined security policies. Security testing is one of the activities that supplies evidence into that assessment.
Which two statements reflect the zero trust paradigm as it is presented in the CT-STE syllabus? (Choose two.)
Every request is authenticated and authorized on its own merits, irrespective of whether it originated inside or outside the corporate network perimeter.
Correct. Removing location-based implicit trust is the core of the zero trust paradigm.
Access rights are granted at the minimum level needed for the specific task and are re-evaluated per request rather than assumed to persist.
Correct. Least privilege plus continuous re-evaluation is the second pillar described in chapter 1.
Traffic that has already passed the perimeter firewall may be treated as trusted, so internal service-to-service calls are exempt from a further authorization check.
Incorrect. This is the traditional perimeter model that zero trust was formulated to replace.
Trust is established once per session at login, after which the requests inside that session inherit the decision taken at authentication time.
Incorrect. Session-scoped trust inheritance is exactly the implicit trust that zero trust removes.
Zero trust removes implicit trust based on network location: every request is authenticated and authorized on its own merits, and access is granted at the minimum level required and re-evaluated rather than assumed to persist.
A payment service reuses a widely adopted open-source authentication library. What consequence does this reuse have for security testing, according to the CT-STE syllabus?
Both the component's published weaknesses and the way it has been integrated into the payment service belong in the test scope, because openly available source code is available to attackers too.
Correct. Chapter 1 treats OSS reuse as an extension of the attack surface that must be covered by testing.
Testing can concentrate on the team's own code, because the open-source project's public review process already addresses defects inside the library itself.
Incorrect. Public review reduces but does not discharge the risk; the syllabus expects the reused component to be in scope.
The library should be examined for licence conformance, since its functional and security defects fall to the maintainers under the project's own governance model.
Incorrect. Licence conformance is a separate concern, and the risk of a defect in a reused component is borne by the organization shipping the product.
The library should be treated as a black box exercised through the payment service's business flows, because its source code is not part of the artifact the organization delivers.
Incorrect. The library is delivered inside the product, and its availability as source is an argument for using it in test design rather than ignoring it.
Reused open-source components bring their published weaknesses into the product, and their source code is available to attackers as well as to defenders. Both the component and the way it has been integrated belong in the test scope.
During a test, an attacker succeeds in changing the delivery address stored against another customer's order, and the change leaves no trace that the system can detect. Which element of the CIA triad has primarily been compromised?
Integrity, because the stored data no longer reflects what the legitimate owner recorded and the unauthorised change went undetected.
Correct. Unauthorised, undetectable modification of data is the definition of an integrity compromise.
Confidentiality, because the attacker was able to reach and read order data belonging to a customer other than themselves.
Incorrect. Reading another customer's data would be a confidentiality issue, but the described harm is the modification of the record.
Availability, because the customer can no longer rely on the order being fulfilled in the way that was originally agreed.
Incorrect. Availability concerns whether the service and data are reachable when needed, not whether stored values are correct.
Non-repudiation of the audit trail, which the syllabus lists as the fourth element of the triad alongside the other three properties.
Incorrect. The triad has exactly three elements — confidentiality, integrity and availability.
Integrity concerns whether data still reflects what the legitimate owner recorded, and whether unauthorised change can be detected. The address was altered undetectably, so integrity is the property at stake.
A logistics company runs sixteen microservices inside one network segment behind a single perimeter firewall. The services call each other over plain HTTP and accept any request that arrives from an address inside that segment; only the public API gateway performs authentication and authorization. The company has just adopted a zero trust security policy, and the test manager asks you to redesign the security tests for the internal services accordingly. Which test approach applies the zero trust paradigm to this situation?
From a host inside the segment, call each internal service directly — with no token, with an expired token, and with a token issued for a different service — and verify that every such request is rejected and recorded in the service's log.
Correct. This tests each service's own enforcement of authentication and authorization, which is what zero trust requires and what the current design lacks.
Exercise the API gateway's authentication and authorization logic exhaustively, then confirm through the gateway that each internal service returns only the data the authenticated caller is entitled to receive.
Incorrect. Testing only through the gateway leaves the implicit trust granted to intra-segment traffic entirely unexercised.
Run a network vulnerability scan across the whole internal segment and confirm that no service exposes an unpatched version banner or an unnecessary listening port.
Incorrect. This is useful hardening verification, but it says nothing about whether a service authorizes each individual request.
Verify that the perimeter firewall permits only the ports the microservices require and that the internal segment is separated from the DMZ by its own rule set.
Incorrect. Strengthening the perimeter and the network zoning is the model zero trust moves away from as the sole line of defence.
Applying zero trust means testing that each service enforces authentication and authorization for itself, so the tests must originate inside the segment and bypass the gateway. Gateway-only testing, network scanning and firewall rule review all leave the implicit intra-segment trust untested.
A security test engineer has been given the application's source code and its deployment configuration, and also executes the running application in order to confirm the findings. How does the CT-STE syllabus classify this combination of test types?
Grey-box and dynamic, since internal knowledge of the implementation is combined with observation of the executing system; the syllabus notes such categories overlap in practice.
Correct. Partial internal knowledge plus execution is the grey-box, dynamic combination.
White-box and static, because the availability of the source code is what fixes the classification and the later execution does not change it.
Incorrect. Execution of the system makes the activity dynamic, and the knowledge is partial rather than complete.
Black-box and dynamic, because the findings are ultimately confirmed against the externally observable behaviour of the running application.
Incorrect. Black-box testing assumes no access to the internal structure, yet here source code and configuration were supplied.
White-box and dynamic, because reviewing the source code and the deployment configuration is the activity that produced the findings in the first place.
Incorrect. The engineer holds source and configuration but not necessarily full internal insight, which the syllabus treats as grey-box.
Access to internal information combined with observation of the running system is grey-box testing. The syllabus explicitly notes that these categories have fuzzy overlaps in practice.
Every quarter an organization compares the user accounts and granted permissions present in a production system against the authoritative HR record of current employees and their roles, and reports every difference. Which security test type does this describe?
Reconciliation testing, which compares the identities and permissions actually present in the system against the authoritative source that should define them.
Correct. Comparing the live access state against the authoritative record is reconciliation testing.
Recertification testing, in which the owners of an application re-confirm at defined intervals that each permission still held is still needed for the holder's work.
Incorrect. Recertification is a re-approval activity performed by owners; here the check is an automated comparison against HR data.
Destructive testing, which examines how the identity management component behaves when it is fed input outside the range that it was designed to accept.
Incorrect. Destructive testing pushes a component beyond its intended operating conditions; no such input is applied here.
Vulnerability scanning, which uses a tool with a signature database to report known weaknesses present in the identity management component.
Incorrect. A scan looks for known weaknesses in the component, not for discrepancies between granted access and the HR record.
Reconciliation testing compares the identities and permissions actually present in a system against the authoritative source that is supposed to define them. Recertification testing is the neighbouring activity in which application owners re-confirm that each remaining permission is still required.
Consider two test cases against a warehouse management system. Test case A signs in with a password that has been revoked and expects the sign-in to fail. Test case B signs in as a valid warehouse clerk and then requests the payroll report, expecting the request to be refused. Which statement correctly assigns these test cases to identity and access management concerns?
A tests authentication, because it checks whether the claimed identity is legitimate; B tests authorization, because it checks what an already established identity is permitted to do.
Correct. This is the distinction the syllabus draws between the two controls.
A tests authorization, because a revoked password is a withdrawn permission; B tests authentication, because the payroll report re-establishes who the caller is.
Incorrect. This inverts the two concepts: credential validity is authentication, resource entitlement is authorization.
Both test authentication, because in each case the system has to decide whether to serve a request coming from the account that presented the credentials.
Incorrect. Deciding whether an authenticated account may reach a particular resource is authorization, not authentication.
Both test authorization, because in each case the system compares the account against the set of permissions that has been stored for that account.
Incorrect. Rejecting a revoked password is a credential check, which is authentication.
Authentication establishes whether the claimed identity is legitimate; authorization establishes what that established identity is permitted to do. A is authentication, B is authorization.
Which two statements about fuzz testing are consistent with the CT-STE syllabus? (Choose two.)
It supplies malformed, unexpected or randomly generated input in order to reveal weaknesses in how the target handles data that it was not designed to accept.
Correct. This is the definition of fuzz testing given in the syllabus keywords.
It can be applied at the network level by sending malformed packets to a listening service, as well as against the API of an individual component.
Correct. Network fuzzing with malformed packets and component-level API fuzzing are both named in the syllabus.
It replays previously captured legitimate traffic at steadily increasing volume in order to establish the point at which the service stops responding to requests.
Incorrect. That describes load or denial-of-service style testing; fuzzing varies the shape of the input rather than its volume.
It compares the input validation rules implemented in the source code against the validation rules stated in the requirements specification.
Incorrect. That is a static review activity; fuzzing is dynamic and executes the target with generated input.
Fuzzing supplies malformed, unexpected or randomly generated input to find weaknesses in how the target handles data it was not designed to accept, and it applies at network level (malformed packets) as well as to a component's API.
How does vulnerability scanning differ from penetration testing?
A vulnerability scan uses a tool and a database of known weaknesses to report what may be exploitable, while a penetration test attempts to exploit findings to demonstrate the impact actually reachable.
Correct. The difference lies in reporting potential weaknesses versus demonstrating exploitability and impact.
A vulnerability scan is run against the source code while a penetration test is run against the executing system, which is why the two are classified as static and dynamic respectively.
Incorrect. Vulnerability scanning is itself performed against running systems and components, so both are dynamic activities.
A vulnerability scan is executed by the development team inside the build pipeline while a penetration test is executed by an auditor, so the difference lies in who performs the activity.
Incorrect. Either activity may be performed by internal or external parties; the distinction is what the activity does, not who runs it.
A vulnerability scan reports weaknesses in the configuration while a penetration test reports weaknesses in the code, so the two address different categories of defect.
Incorrect. Both activities can surface configuration and code weaknesses; the depth of demonstration is what separates them.
A vulnerability scan uses a tool and a database of known weaknesses to report what may be exploitable. A penetration test goes further and attempts to exploit findings in order to demonstrate the impact that is actually reachable.
What role do threat models play in the design of security tests, according to chapter 2 of the CT-STE syllabus?
They are an input that identifies which threats and attack paths matter for this system, so that test conditions and their priority can be derived from them together with the security risk analysis.
Correct. Chapter 2 designs security tests from security risks and threat models.
They are an output produced after test execution, summarising which of the possible attack paths the executed tests turned out to have covered.
Incorrect. Coverage of attack paths is reported after execution, but the threat model itself precedes and drives design.
They describe the security controls the system implements, so they serve as the expected results against which the outcome of each test is compared.
Incorrect. Standards, requirements and best practices act as sources of test oracles; a threat model describes adversary behaviour, not the expected result.
They record the tools and the access rights the test team will require, so they are used when planning the test environment rather than the test conditions.
Incorrect. Tooling and access needs are planning concerns; a threat model addresses which threats to test for.
Threat models are an input to test design: together with the security risk analysis they identify which threats and attack paths matter for this system, from which test conditions and their priority are derived.
A regional bank runs a customer portal. Its security risk analysis rates the following risk highest: the session token issued by the portal is transmitted and stored in a way that would let an attacker on a shared network capture the token and replay it in order to act as the customer. The test team has source code access, a production-like test environment and a scanner licence, and one week of effort. Which test activity most directly addresses this specific risk?
Inspect and exercise the transport and storage of the token: that it travels only over an encrypted channel, that its cookie attributes prevent clear-text transmission and script access, and that a captured token stops working after logout and after expiry.
Correct. Each element of the named risk — capture in transit, capture at rest, and replay — is covered by one of these checks.
Run an authenticated vulnerability scan against the portal's hosts and confirm that the web server and the TLS library carry no missing patches recorded in the scanner's signature database.
Incorrect. Patch level is worth knowing, but a fully patched server can still issue a token with unsafe attributes and no expiry.
Fuzz the portal's login endpoint with malformed and oversized credential values and confirm that the application rejects them without disclosing internal error detail to the caller.
Incorrect. This addresses input handling at the login endpoint, not the confidentiality and lifetime of an issued token.
Review the portal's user administration screens and confirm that an account which has been closed can no longer be granted a new permission by an operator.
Incorrect. This exercises access administration behaviour, which is a different risk from token capture and replay.
The risk is about the confidentiality and lifetime of the session token, so the tests must target its transport and storage: encrypted channel only, cookie attributes that prevent clear-text transmission and script access, and invalidation on logout and expiry.
Which precondition does the CT-STE syllabus place on the start of security testing activities in a production-like environment?
Documented approval from management for the planned testing, because security tests may resemble a real attack and can affect the systems and the data involved.
Correct. The syllabus carries a dedicated objective on obtaining management approval before security testing starts.
A written statement from the tool vendor confirming that the selected tools are permitted in the jurisdiction in which the test environment is hosted.
Incorrect. Tool legality is a genuine consideration in tool selection, but it is not the precondition the process places on starting to test.
Completion of all static analysis activities, so that the dynamic tests are aimed only at the weaknesses that the code review was unable to detect.
Incorrect. Static and dynamic activities complement each other and are not sequenced as a gate in the security test process.
A restore point for the identity store, so that any permission changed during the test run can be reverted by the operations team once testing finishes.
Incorrect. Reverting test data is good practice for the environment, but it is not the stated precondition for beginning security testing.
Security tests can resemble a real attack and can affect systems and data, so documented management approval of the planned testing is required before execution begins.
Which two of the following does the CT-STE syllabus name as inputs to the security test process? (Choose two.)
The threat models available for the system under test, which describe the adversary behaviour the tests have to address.
Correct. Available threat models are an explicit input to the security test process.
The results of the security risk analysis, from which the priority of the individual security tests is derived.
Correct. The risk analysis result drives prioritisation within the process.
The security test completion report from the previous release, which sets the acceptance criteria that the current release has to meet.
Incorrect. Acceptance criteria come from the requirements and stakeholder agreement, not from the previous release's report.
The list of vulnerabilities closed during the previous maintenance cycle, which defines the scope of the new test design.
Incorrect. That list feeds confirmation and regression testing but does not define the scope of the design activity.
The security test process takes available threat models and the results of the security risk analysis as inputs, alongside the security requirements; prioritisation of the tests is derived from them.
Which characteristic of an effective security test environment does the CT-STE syllabus emphasise?
It should mirror the production environment closely, including its configuration, access rights and delegation, because security behaviour depends on exactly those settings.
Correct. A findings-transferable environment has to reproduce production's configuration and access model.
It should be reduced in capacity relative to production, since security findings are independent of deployment scale and a smaller environment is cheaper to maintain.
Incorrect. Reduced capacity is a performance-testing compromise; for security the concern is fidelity of configuration and access rights.
It should be detached from the production identity provider and populated with locally created accounts, so that the permission model under test stays simpler than the production one.
Incorrect. A simplified permission model hides exactly the authorization defects the tests are meant to find.
It should run the same application build as production but with the security controls switched off, so that the tests can reach the application logic directly.
Incorrect. Disabling the controls removes the objects under test; the controls themselves are what security testing evaluates.
Security behaviour depends heavily on configuration, access rights and delegation, so the environment has to mirror production closely if the findings are to transfer to production.
A security test engineer designs fuzz tests against the API of a single component before that component is integrated with the others. At which test level is this activity, and what does the syllabus say characterises the next level up?
Component level; component integration testing then targets the interfaces newly exposed by assembly, designed from a documented risk analysis with realistic threat modelling.
Correct. This matches the level-by-level design guidance in chapter 3.
System level; component integration testing is then the level at which complete end-to-end business processes are used to validate the security requirements.
Incorrect. This swaps the levels: end-to-end validation of security requirements belongs to system and acceptance testing.
Component level; component integration testing then repeats the same fuzz cases against the assembled system in order to confirm that the earlier findings were fixed.
Incorrect. Repeating cases to check fixes is confirmation testing, which is not what defines the integration level.
Component integration level; the next level up is acceptance testing, where a scanner is run against the deployed system in a production-like configuration.
Incorrect. Fuzzing one component's API before assembly is component level, and system testing sits between integration and acceptance.
Fuzzing a component's API is component-level security testing. Component integration testing then addresses the interfaces newly exposed by assembly, designed on the basis of a documented risk analysis with realistic threat modelling.
An insurance company states the following security requirement: "A claims handler may view only the claims of the region they are assigned to; any attempt to view a claim outside that region must be refused and recorded in the audit log." Three systems take part: the customer-facing portal, the claims service, and a regional assignment directory. You have to design a test at system and acceptance level that validates this requirement. Which design matches the syllabus's description of end-to-end security testing at these levels?
Drive the whole business process through the portal with a handler assigned to region North: retrieve a North claim successfully, then request a South claim, and verify the refusal in the portal, the decision taken in the claims service, and the resulting entry in the audit log.
Correct. This validates the requirement end-to-end through the business process across all three systems, including the audit evidence the requirement demands.
Call the claims service API directly with a forged region attribute in the request and verify that the service refuses the call, since the portal only forwards the attributes it receives from the caller.
Incorrect. This is a valuable component-integration test, but it does not validate the requirement through the business process at system level.
Review the data model of the regional assignment directory and confirm that every handler record carries exactly one region value, since the requirement depends on that constraint holding.
Incorrect. This is a static check of one contributing system rather than an executed end-to-end validation.
Fuzz the portal's claim identifier parameter with values that belong to other regions and confirm that no response body returned by the portal contains claim data.
Incorrect. Fuzzing one parameter tests input handling and misses both the decision in the claims service and the required audit log entry.
At system and acceptance level the syllabus expects an end-to-end test that validates the security requirement through the business process, covering all participating systems — including the required audit evidence.
The CT-STE syllabus describes a chain leading from a general class of coding flaw, through a concrete flaw in a shipped product, to the way an adversary exploits it. Which mapping of catalogues to that chain is correct?
CWE describes the weakness type, CVE identifies the concrete vulnerability in a specific product, and CAPEC describes the attack pattern used against it.
Correct. This is the weakness → vulnerability → attack chain of chapter 4.
CVE describes the weakness type, CWE identifies the concrete vulnerability in a specific product, and CAPEC expresses how severe the resulting attack would be.
Incorrect. CWE and CVE are swapped, and severity is expressed by CVSS or CWSS rather than by CAPEC.
CAPEC describes the weakness type, CVE lists the product versions affected by it, and CWE supplies the remediation guidance for each catalogued entry.
Incorrect. CAPEC catalogues attack patterns, and remediation guidance is not the purpose of CWE.
CWE identifies the concrete vulnerability in a specific product, CVSS describes the weakness type behind it, and CAPEC records the exploit code available for it.
Incorrect. CWE is the weakness type catalogue, CVSS is a scoring system, and CAPEC describes patterns rather than storing exploit code.
CWE catalogues weakness types, CVE identifies concrete vulnerabilities in specific products and versions, and CAPEC catalogues the attack patterns used against them.
A static analysis run on a product that is still under development reports 240 potential weaknesses. None of the affected code has been deployed to any environment reachable by users, and the team now has to decide which findings to investigate first. Which scoring approach fits this situation, and for what reason?
CWSS, because it scores weaknesses whose exploitability in a deployed context is not yet established, while CVSS presumes a vulnerability already present in a deployed system.
Correct. This is the distinction the syllabus draws between the two scoring systems.
CVSS, because it produces a single comparable numeric severity for every finding, which is what prioritising a list of 240 items requires above all.
Incorrect. CWSS also produces a comparable score; the deciding factor here is that nothing is deployed yet.
CVSS, because a static analysis tool reports its findings against CVE identifiers and CVSS is the scoring system defined for CVE entries.
Incorrect. Static analysis reports weaknesses in the team's own code, which have no CVE identifier assigned to them.
CWSS, because it is the scoring system defined for findings produced by dynamic analysis, while CVSS is the one defined for findings produced by static analysis.
Incorrect. Neither scoring system is tied to a particular analysis technique; the difference concerns weaknesses versus deployed vulnerabilities.
CWSS scores weaknesses whose exploitability in a deployed context is not yet established, which is exactly the case for code that has not been deployed. CVSS presumes a vulnerability that already exists in a deployed system.
While threat modelling a document management system the team records this threat: a user who holds read access downloads a signed contract, alters the totals in it, and re-uploads it through an endpoint that does not record who last modified the file — so the change appears to have been made by the contract owner. Applying STRIDE, which two categories does this threat fall under? (Choose two.)
Tampering, because the content of a stored contract is modified by someone who is not entitled to change it.
Correct. Unauthorised modification of stored data is the tampering category.
Repudiation, because the system does not record who actually made the change, so the real actor is able to deny having made it.
Correct. Missing attribution of an action is the repudiation category.
Information disclosure, because the user was able to download the full contract document including its financial totals.
Incorrect. The user held read access, so the download itself was authorised and no data was disclosed to an unauthorised party.
Elevation of privilege, because the user obtained the read permission that made the initial download possible.
Incorrect. The read permission was already legitimately assigned; no privilege was gained beyond what was granted.
The contract content is modified without entitlement (tampering) and the system cannot establish who made the change, so the real actor can deny it (repudiation).
A team is about to start security testing on a new public web API. The only documented security requirement is the sentence "the API must be secure". Nothing more specific was agreed with the stakeholders. How can standards and best practices help the team in this situation, according to chapter 4?
They can act as sources of test oracles: a recognised catalogue of common web application risks supplies concrete expected behaviours to test against where documented requirements are missing.
Correct. Chapter 4 explicitly presents standards and best practices as sources of test oracles.
They can be adopted verbatim as the API's security requirements specification, so that the test basis becomes the standard itself rather than the stakeholders' stated needs.
Incorrect. A standard informs and supplements the test basis; it does not displace the stakeholders' requirements.
They can be used to choose the test tools, since each standard prescribes the tool categories needed to demonstrate conformance with it.
Incorrect. Standards describe protections and tests rather than prescribing particular tool categories.
They can be applied after execution to classify the findings by severity, which is the purpose the syllabus assigns to standards and best practices.
Incorrect. Severity classification uses scoring systems such as CVSS or CWSS; the syllabus's stated purpose here is supplying test oracles.
The syllabus names standards and best practices as sources of test oracles. A recognised list of common web application risks supplies concrete expected behaviours to test against when documented requirements are thin.
A retailer's web shop stores the names, addresses and purchase history of EU customers, so the GDPR applies and the organization's security policy has been extended accordingly. Which test activity most directly verifies the effect that the regulation has had on that security policy?
Verify that the controls the policy derives from the regulation actually work: personal data protected in transit and at rest, access to it restricted and logged, and a deletion request removing the data from every store it reached.
Correct. The regulation drives policy, the policy prescribes controls, and the controls are what security testing exercises.
Verify that the web shop displays a consent banner on a visitor's first visit and that no analytics script runs before the visitor has accepted it.
Incorrect. Consent handling is a compliance behaviour of the front end, not the security control set the policy derives from the regulation.
Verify the encryption strength of the payment gateway against the card scheme's requirements, since payment data is the personal data the regulation is chiefly concerned with.
Incorrect. Card data requirements come from the payment card standards; the regulation in question covers personal data far more broadly.
Verify that the retailer's published privacy notice lists every third-party processor, since the completeness of that notice is what a security test is able to check.
Incorrect. Reviewing the notice is a documentation check; it says nothing about whether the technical controls hold.
Regulation shapes the security policy, and the policy prescribes technical controls. Testing the effect of the regulation therefore means testing that those controls — protection in transit and at rest, restricted and logged access, and actual deletion — work.
Company A concentrates all security testing in one central security team that serves twelve product groups. Company B embeds one security tester inside each of its nine product teams and has no central security testing function. Which statement best describes the consequences of these two organizational structures for security testing?
In A the approach and tooling tend to be consistent and specialist skill deep, but the team can become a bottleneck and sit far from product context; in B context and turnaround improve, while consistency of approach and depth of specialist skill have to be actively maintained.
Correct. This is the trade-off chapter 5 draws between centralised and embedded structures.
In A the security testers report to the product owners, which keeps findings close to the business, while in B they report to a central authority that decides the priority of every finding.
Incorrect. The reporting lines are the other way round, and neither structure fixes who prioritises findings.
In A the tests are designed from threat models while in B they are designed from the output of tool scans, because the choice of test basis follows the reporting structure.
Incorrect. The test basis is chosen from risks, threat models and requirements regardless of where the testers sit.
In A security testing can be confined to the system test level while in B it has to cover every test level, because the number of testers determines the level coverage that is achievable.
Incorrect. Level coverage follows from risk and the test approach; headcount affects capacity rather than which levels are in scope.
Centralisation buys consistency of approach and depth of specialist skill at the cost of throughput and product context. Embedding buys context and speed but has to work to keep approach consistent and specialist skills deep.
An investigation reconstructs the following sequence at a manufacturing company. (1) Six weeks before the incident, advanced search-engine operators were used to locate an internal procurement procedure that had been left indexed on the company website; it named the finance director and the approval chain for supplier invoices. (2) The profiles of four finance staff were viewed on a professional networking site. (3) Two weeks later a caller claiming to represent the company's bank telephoned an accounts payable clerk and asked her to confirm the supplier reference format. (4) A week after that the company's public mail server was port-scanned and its operating system fingerprinted. (5) An invoice was then submitted from a spoofed supplier address and paid. Which two conclusions about the information gathering are correct? (Choose two.)
Steps 1 and 2 are passive information gathering, because search-engine operators and a professional networking site leave no trace on the company's own systems or with its staff.
Correct. Passive reconnaissance draws on publicly available sources without contacting the target.
Steps 3 and 4 are active information gathering, because the telephone call is vishing and the port scan with operating system fingerprinting reaches the company's own host, so both are detectable.
Correct. Active reconnaissance interacts with the target's people or systems and can be detected through logs and network intrusion detection.
Steps 1 and 4 are passive because both address publicly reachable resources, while steps 2 and 3 are active because both involve a human being on the company's side.
Incorrect. The distinction is contact with the target, not whether the resource is public: scanning a public server is active, viewing a public profile is passive.
Step 5 is the only step that could have been detected, because none of the earlier steps involved any contact with the company's systems or its staff.
Incorrect. Steps 3 and 4 both made contact and were therefore detectable well before the fraudulent invoice was submitted.
Steps 1 and 2 are passive information gathering — search-engine operators and social media leave no trace on the target's own systems. Steps 3 and 4 are active — the telephone call is vishing and the port scan with OS fingerprinting touches the company's own host, so both are detectable.
A regional water utility's public information portal is defaced overnight with a political slogan. Nothing is exfiltrated, no ransom demand arrives, and no operational system is touched. The logs show a single automated tool run against the portal's content management system, exploiting a publicly documented vulnerability for which a patch had been available for eleven months. The same slogan appeared on the portals of four other utilities the same night. Which two conclusions about the source and motivation of this attack are best supported by the evidence? (Choose two.)
The motivation is political rather than financial: a slogan was published, nothing was taken, and no payment was demanded from any of the five organizations.
Correct. The pattern of coordinated defacement with a message and no financial demand is characteristic of politically motivated attackers.
The technical capability required was low: an off-the-shelf tool exploited a publicly documented vulnerability with a long-available patch, which fits attackers who reuse existing exploits rather than develop their own.
Correct. Reuse of published exploits through ready-made tooling is the profile the syllabus associates with low-capability attackers.
The source is an insider, because knowing which content management system the portal runs on is information not obtainable from outside the organization.
Incorrect. The platform behind a public portal is routinely identifiable from outside through fingerprinting and response headers.
The motivation is financial, because defacing five portals in a single night builds the pressure an extortion demand would need in order to succeed.
Incorrect. No demand was made and nothing was taken, so the evidence does not support a financial motive.
Publishing a slogan while taking nothing and demanding nothing points to a political motivation; using an off-the-shelf tool against a long-patched, publicly documented vulnerability points to attackers who reuse existing exploits rather than develop their own.
How does adopting a DevOps model with integrated security practices change security testing, compared with a sequential lifecycle?
Security activities are distributed across the pipeline and run on every change — static and dependency analysis in the build, dynamic checks in the deployment stages — rather than concentrated into a phase before release.
Correct. Distributing and automating the activities across the pipeline is the shift-left effect the syllabus describes.
Security testing shifts towards production monitoring, because the deployment frequency leaves little room for pipeline activity, so weaknesses are addressed once they appear in the live system.
Incorrect. Production monitoring is added, but the syllabus's emphasis is on moving activity earlier into the pipeline, not later.
Security testing passes from the development team to the operations team, since in a DevOps organization the deployment pipeline is owned and operated by operations.
Incorrect. DevSecOps makes security a shared responsibility across the whole delivery team rather than reassigning it.
Security testing is reduced in scope, because the small size of each individual change means each deployment carries less risk than a sequential release does.
Incorrect. Small changes can still introduce serious weaknesses, and higher deployment frequency raises rather than lowers the need for automated security checks.
In DevSecOps the security activities are distributed across the pipeline and run on every change — static and dependency analysis in the build, dynamic checks in the deployment stages — rather than being concentrated in a phase shortly before release.
A vulnerability found in a live payment module has been fixed and the fix is about to be released. Which combination of testing does the CT-STE syllabus expect during operations and maintenance?
Confirmation testing that the reported vulnerability can no longer be exploited, together with security regression testing that the change has not weakened other controls or reopened previously closed weaknesses.
Correct. Confirmation plus security regression testing after a change is exactly what chapter 6 prescribes.
Confirmation testing that the reported vulnerability can no longer be exploited, followed by a re-run of the functional regression suite, since a localised fix leaves controls outside the payment module untouched.
Incorrect. A localised fix can still weaken shared controls, which is why security regression testing is required alongside functional regression.
A fresh vulnerability scan of the whole deployment, which covers the fixed weakness as well and therefore takes the place of a targeted confirmation test.
Incorrect. A scan reports known weakness signatures and may not exercise the specific attack path that was reported and fixed.
Security regression testing across the whole product, with the confirmation test deferred to the next scheduled release so the fix can be assessed together with the other changes.
Incorrect. Deferring confirmation leaves the organization without evidence that the reported vulnerability has actually been closed.
The syllabus pairs confirmation testing (the reported vulnerability can no longer be exploited) with security regression testing (the change has not weakened other controls or reopened previously closed weaknesses).
A change is deployed to a shared authentication library that is used by three applications: the customer portal, the mobile back end and an internal administration console. The change alters the way password hashes are compared. Which set of tests best fits security regression testing for this change?
Re-run the security tests for login, lockout after repeated failed attempts and password reset in all three consuming applications, together with the tests for weaknesses previously closed in those flows.
Correct. All three consumers use the changed comparison logic, and previously closed weaknesses in those flows are the classic regression risk.
Re-run the complete security test suite for the customer portal alone, because it is the consumer with the largest user base and therefore carries the greatest exposure.
Incorrect. Exposure size does not limit where a change to a shared library can cause a regression; the other two consumers would go unchecked.
Run new fuzz tests against the library's comparison function and treat a passing result as evidence that the three consuming applications remain unaffected.
Incorrect. Component-level evidence does not show how each application uses the library in its own login and reset flows.
Re-run only those tests that failed during the previous release cycle, across all three applications, since those are the areas in which the product has already shown weakness.
Incorrect. Previous failures are one input, but regression selection has to follow the impact of this change rather than last cycle's failure list alone.
Security regression testing after a change to a shared component has to cover every consumer of that component in the flows the change can affect, and has to re-exercise weaknesses previously closed in those flows.
A medical device company ships the same software product in two ways. For regulated hospital customers it follows a sequential lifecycle with a formal release every nine months and documented evidence per phase. As a cloud service it follows an iterative lifecycle with a release every two weeks. The security test engineer has to plan the security testing for both. Which two statements analyse the impact of the two lifecycle models correctly? (Choose two.)
In the sequential delivery the security testing can be planned as identifiable phase activities producing documented evidence and a formal decision point before release, which fits the regulated customer's need for auditable records.
Correct. Sequential models allow phase-bound, documented security test activities and a formal release gate.
In the iterative delivery comparable coverage has to come from automated checks running on every increment plus periodic deeper manual testing, because a two-week cadence cannot absorb a full manual security test each time.
Correct. High-cadence delivery shifts the bulk of security testing into automation, with deeper manual work run on a separate rhythm.
In the sequential delivery the threat modelling can be performed once at the start and carried unchanged through to release, because the requirements are frozen before the security testing phase begins.
Incorrect. Design decisions, third-party components and the threat landscape all change during a nine-month cycle, so the threat model needs revisiting.
In the iterative delivery the manual penetration testing can be dropped in favour of pipeline scanning, since automated tools cover the same attack paths that a manual tester would explore.
Incorrect. Automated tools find known patterns; business-logic and chained attack paths still require exploratory manual work.
The sequential delivery supports planned, phase-bound security activities with auditable evidence and a formal pre-release decision point. The iterative delivery has to reach comparable coverage through automation on every increment plus periodic deeper manual testing, because a two-week cadence cannot absorb a full manual security test each time.
How do the acceptance criteria agreed for security testing influence the work of the security test engineer, according to chapter 7?
They shape the selection of test approaches and techniques, because the criteria state what has to be demonstrated and therefore what evidence the tests need to produce.
Correct. Chapter 7 links acceptance criteria directly to the choice of approaches and techniques.
They determine which findings may be reported, because a weakness falling outside the agreed criteria also falls outside the scope of the engagement.
Incorrect. A weakness discovered outside the criteria is still reported; the criteria govern what must be demonstrated, not what may be disclosed.
They fix the number of test cases to be designed per security requirement, so that the effort can be estimated before test design begins.
Incorrect. Case counts follow from risk and technique choice; acceptance criteria do not prescribe them.
They set the severity thresholds used to score the findings, so that the scoring scheme is agreed with the stakeholders before execution starts.
Incorrect. Severity scoring uses schemes such as CVSS or CWSS; acceptance criteria describe what an acceptable result looks like.
The acceptance criteria state what has to be demonstrated, so they shape which approaches and techniques are selected and what evidence the tests have to produce.
What is the purpose of feeding security test results into an Information Security Management System (ISMS)?
The results become input for actively managing the organization's security risks, so identified weaknesses are tracked and treated inside the management system rather than only in a test report.
Correct. Chapter 7 positions test results as an input to active security risk management within the ISMS.
The results become certification evidence, so the management system can be assessed without the auditor having to examine the tested systems themselves.
Incorrect. Results do support audits, but their stated purpose here is feeding risk management, not substituting for the auditor's own work.
The results take the place of the risk assessment held in the management system, since executed tests give a more current picture than an assessment made earlier.
Incorrect. Test results update and inform the risk assessment; they are not a substitute for it.
The results are used to update the test policy held in the management system, which is the artifact governing how future security testing will be performed.
Incorrect. Lessons learned may influence the policy, but the purpose of the input described in chapter 7 is security risk management.
The results become input for actively managing the organization's security risks: identified weaknesses are tracked and treated inside the management system rather than living only in a test report.
Why does the CT-STE syllabus emphasise measurability and metrics inside an ISMS?
Because managing security risk through the system needs measures whose movement over time can be observed, so improvement or deterioration is recognised and can be acted upon.
Correct. Measurability is what makes the management cycle inside the ISMS work.
Because the management system standard prescribes a fixed catalogue of security metrics that every certified organization reports in an identical form.
Incorrect. The standard requires measurement but leaves the choice of metrics to the organization and its context.
Because metrics let the organization's security testing effort be compared against that of other organizations of similar size in the same sector.
Incorrect. External benchmarking is not the reason the syllabus gives; the point is observing the organization's own trend.
Because attaching a metric to each finding is what allows that finding to be assigned to an owner for remediation.
Incorrect. Assignment of an owner is a defect management step and does not depend on a metric.
Managing security risk through a management system requires measures whose movement over time can be observed, so that improvement or deterioration is recognised and can be acted upon.
For three years an organization's ISMS has received exactly the same security testing evidence: one annual external penetration test of the public website, plus a quarterly network vulnerability scan of the hosting range. In that time the website has become one of eleven internet-facing services, six of which expose public APIs, and the company has moved to a two-week release cadence. Which change to the security testing would most improve the maturity of the ISMS?
Extend the testing to the newly exposed test objects and add approaches matching the release cadence — security tests at API level and dependency analysis on every release — so the evidence reaching the ISMS covers the current attack surface.
Correct. New test objects, new approaches and improved coverage are precisely the three levers the syllabus names for raising ISMS maturity.
Raise the frequency of the existing external penetration test from once to twice a year, so that the interval between two assessments of the website is halved.
Incorrect. More of the same evidence still leaves ten services and six public APIs entirely outside the scope.
Replace the quarterly network scan with a continuous scan of the same hosting range, so the management system receives the same measure without a reporting delay.
Incorrect. Timeliness improves, but the coverage of test objects and the range of approaches stay exactly as they were.
Add a formal management review of the existing penetration test report, so the findings are discussed at senior level before the next annual test is commissioned.
Incorrect. Better discussion of unchanged evidence does not extend coverage to the services and APIs that are now exposed.
Chapter 7 improves ISMS maturity through new test approaches, new test objects and improved coverage. Here the attack surface and the cadence have both changed, so the evidence has to extend to the new objects and to approaches that fit the release rhythm.
Why does the CT-STE syllabus require that security test results be handled with controlled access rather than distributed as widely as ordinary test reports?
Because a weakness found during testing usually exists in production as well, so the report is in effect a map of exploitable paths and should reach only those who need it.
Correct. This is exactly the confidentiality argument the syllabus makes about security test results.
Because the report contains the personal data that was used as test input, which the organization is obliged to protect wherever that data is stored.
Incorrect. Test data protection is a separate obligation; the reason for restricting the report is that it describes live weaknesses.
Because the report is a contractual deliverable of the test provider, whose intellectual property in the test procedures needs to be protected from disclosure.
Incorrect. Commercial confidentiality may apply, but it is not the reason the syllabus gives for restricting security test results.
Because unrestricted access would let developers start correcting the findings before those findings had been formally triaged and prioritised.
Incorrect. Early awareness among developers is generally useful; the concern is disclosure of exploitable weaknesses beyond the need-to-know circle.
A weakness found in a test environment usually exists in production as well, so the report is effectively a map of exploitable paths. Access to it therefore has to be restricted to those who need it.
The table below is an excerpt from a dynamic scanner run against a customer portal. The right-hand column records whether a tester manually confirmed the finding against the running portal. The portal's security risk analysis rates account takeover and session hijacking as its two highest risks, and the team has capacity to close two findings before the release. Which pair should be prioritised, and on what grounds?
Findings 3 and 4, because both were manually confirmed as exploitable and they correspond directly to the two risks the analysis rates highest — account takeover and session hijacking.
Correct. Confirmed exploitability combined with the highest-rated risks is what drives prioritisation here.
Findings 3 and 6, because both carry a High severity label from the scanner and severity is the ranking the report is intended to convey to the reader.
Incorrect. Finding 6's vulnerable function was established as not reachable, so its scanner label overstates the risk in this deployment.
Findings 1 and 5, because the version banner and the directory listing supply the reconnaissance material an attacker needs before any of the other findings can be exploited.
Incorrect. Both are unconfirmed low-impact information leaks, and neither is a precondition for exploiting the confirmed findings.
Findings 2 and 6, because an obsolete protocol version and an obsolete library are the two items that can be closed by upgrading a component rather than by changing application code.
Incorrect. Ease of remediation is a useful input, but it does not outrank confirmed exploitability against the highest-rated risks.
Evaluation of scanner output means combining confirmation of exploitability with the risks that matter for this system. Findings 3 and 4 are the two confirmed ones, and they map directly onto the two highest-rated risks — no lockout enables account takeover, a cookie readable by script enables session hijacking. Finding 6 carries a High label but its vulnerable function is not reachable.
Testing reveals that an administration console is reachable at /admin on a company's public portal and that it accepts the same credentials as the internal-network copy of the same console. Four remediation proposals are put forward. Which of them removes the vulnerability rather than merely hiding it?
Require the console to authenticate through the organization's identity provider with a second factor and restrict its network reachability to the administration segment, then re-test from the internet and from inside that segment.
Correct. This changes the exposure itself rather than the ease of finding it, and the re-test provides the evidence.
Move the console from /admin to a long randomly generated path that is not linked from any page of the portal and is excluded from the published site map.
Incorrect. This hides the console; anyone who learns or discovers the path still reaches a console accepting internal credentials.
Return a 404 response to any request for /admin that does not carry a known administrator cookie, so the console does not appear to exist for other callers.
Incorrect. This conceals the console's presence but leaves the authentication weakness in place for whoever obtains such a cookie.
Remove the /admin path from the scanner's target list and request its removal from the search engine index, so it is neither reported nor discoverable through search.
Incorrect. This suppresses the report and the discoverability while the exposure remains exactly as it was.
The syllabus distinguishes hiding a vulnerability from avoiding or removing it. Obscuring the path, faking a 404 or excluding the path from scans and indexes all leave the console exposed to anyone who finds it. Strengthening authentication and restricting network reachability removes the exposure.
Which mapping of security testing tool categories to what each one examines is correct?
SAST analyses source or binary code without executing it; DAST exercises the running application from the outside; SCA identifies the third-party components in the build and their known weaknesses.
Correct. This is the categorisation given in chapter 9.
SAST exercises the running application from the outside; DAST analyses source code without executing it; SCA measures the code coverage that the security tests achieved.
Incorrect. SAST and DAST are swapped, and SCA analyses composition rather than coverage.
SAST analyses source code without executing it; DAST monitors the application from inside while it runs under test; SCA scans network hosts for open ports and reachable services.
Incorrect. Monitoring from inside a running application describes IAST, and host and port scanning is vulnerability scanning rather than SCA.
SAST identifies the third-party components and their known weaknesses; DAST analyses the deployment configuration; SCA exercises the running application through its public interfaces.
Incorrect. All three categories are misassigned; component identification is SCA and exercising the running application is DAST.
SAST analyses source or binary code without executing it, DAST exercises the running application from the outside, and SCA identifies the third-party components present in the build together with their known weaknesses.
Which two considerations does chapter 9 name when selecting a security testing tool? (Choose two.)
Whether the tool fits the intended use case and its category: the technology under test, the point in the lifecycle at which the tool runs, and the depth of internal knowledge it requires.
Correct. Matching use case to tool category is the central selection consideration in chapter 9.
Whether the vendor maintains the tool frequently enough that its detection content still reflects the current threat landscape.
Correct. Security tools lose value quickly when their detection content is not kept current.
Whether the tool comes from the same vendor as the test management system, so that findings move between the two without an intermediate export step.
Incorrect. Integration is convenient, but single-vendor sourcing is not a selection consideration the syllabus raises.
Whether the tool belongs to the dynamic category, since static tools report weaknesses that cannot be confirmed against a running system.
Incorrect. Static tools have their own value in the categorisation, and their findings can be followed up dynamically.
Tool selection has to match the intended use case and the tool's category — technology under test, point in the lifecycle, depth of internal knowledge required — and has to weigh how frequently the vendor updates the tool so that its detection content stays aligned with current threats.
A team maintains a payment API written in Java. On every merge request they want two separate questions answered automatically: first, whether any dependency newly added to the build carries a publicly documented vulnerability; second, whether the new code the team itself wrote introduces an injection weakness. Which pair of tool categories fits these two needs?
Software composition analysis for the dependency question, and static application security testing for the team's own newly written code.
Correct. SCA inventories third-party components against known vulnerability data; SAST analyses the team's own code for weakness patterns such as injection.
Dynamic application security testing for the dependency question, and interactive application security testing for the team's own newly written code.
Incorrect. Neither category inventories the build's dependencies, and both require a running deployment rather than a merge request.
Host vulnerability scanning for the dependency question, and dynamic application security testing for the team's own newly written code.
Incorrect. Host scanning looks at the platform rather than the application's library set, and DAST needs a deployed application to exercise.
Static application security testing for the dependency question, and software composition analysis for the team's own newly written code.
Incorrect. The two categories are the right ones but assigned the wrong way round.
Publicly documented vulnerabilities in third-party dependencies are the domain of software composition analysis. Injection weaknesses in the team's own newly written code are found by static application security testing of that code.