@Tayo Olaomi Correct Answer: C. Extend the coding standard and review gates to assistant output Explanation (CISSP logic): The clues are "a third of new code", "payment logic shipping in two weeks" and "the coding standard and review gates never mention assistant output". Domain 8 puts security into the development lifecycle through policy and process, and an AI coding assistant is a new source of code that the lifecycle has not been told about. Code that enters the pipeline outside the standard is ungoverned however good it is, so the management-first move is to bring the assistant inside the existing standard and review gates, which then decide what gets scanned, what gets tagged and whether anything ships in two weeks. Breakdown: A. Running static analysis on the AI-written code is the strong distractor because it finds real flaws in the payment logic before launch and feels like the responsible engineer's move. It is a control chosen before the policy that should require it exists, so it covers this release and nothing after, and nobody has decided what a failing scan means for the ship date. B. Suspending the assistant pending vendor security review treats the tool as the risk and buys time. A third of the firm's code velocity stops, developers route around the ban, and the review answers a question about the vendor rather than the real one, which is how the firm governs code from any source. C. ✅ Correct. Extending the coding standard and review gates to assistant output gives the firm a policy position on AI-written code: it is reviewed, tested and approved like any other code, with the payment logic held to the same gate as everything else. Every later control, including the scan in A, hangs off that decision. D. Requiring developers to tag every assistant-written change creates visibility and helps the reviewers in C know where to look. A tag is a label, not a gate, so without a standard that says what happens to tagged code it records the problem instead of governing it.

@Rajdeep Ajmani Correct Answer: B. Map the applications, data flows and trust boundaries Explanation (CISSP logic): The clues are "board funded zero trust", "deployed this quarter" and "no inventory of applications, data flows or trust boundaries exists". Zero trust is a network security architecture, not a product, and Domain 4 rewards designing the architecture before buying the components. Every policy an access broker enforces is a statement about which identity may reach which application over which path, and the manufacturer cannot write one of those statements because nobody knows what the applications are, how they talk to each other or where the trust boundaries fall. Assess before you act: map the applications, data flows and boundaries, and the broker, the segmentation and the pilot all become design decisions with a basis instead of guesses under a deadline. Breakdown: A. Deploying the access broker for remote users first is the strong distractor because it is the purchase the board funded and it closes the path most ransomware walks in through. A broker enforcing policy against an unknown application estate either blocks flows the plant depends on or allows everything to keep production running, and the second outcome is the old network with a new logo. B. ✅ Correct. Mapping the applications, data flows and trust boundaries produces the inventory every later step consumes: which assets matter, who needs them, which flows are legitimate and where enforcement points belong. It is the design input the quarter's budget should buy first. C. Segmenting the network by department before the rollout reduces blast radius and is a genuine zero trust building block. Department is an org chart, not a data flow, so segments drawn that way split systems that must talk and group ones that should not, and the team rebuilds them once the real flows are known. D. Piloting the access broker on executive devices limits risk and gives the board something to see this quarter. Executives are the least representative users on the network and the pilot still has no flow map to validate against, so it proves the broker installs, not that the architecture works.

@Tayo Olaomi Correct Answer: B. Inventory and classify the data and assign owners Explanation (CISSP logic): The clues are "unclassified data", "acquired a firm", "30 days" and "regulator exam next quarter". Asset Security starts with knowing what you hold: classification and ownership decide how data is labeled, handled, protected and retained, and nothing downstream, migration included, can be done correctly until those exist. The bank cannot say which of those 20 TB are customer records, which are public and which should never have been kept, and no one is accountable for deciding. Assess before you act: inventory and classify the shares and name owners, and the migration, the encryption and the retention purge all become decisions those owners can make and defend to the examiner. Breakdown: A. Migrating under the bank's default classification is the strong distractor because it meets the 30-day deadline and the data lands inside the bank's own controls. A default label is a guess applied to everything at once, so sensitive records end up under-protected and junk gets the full treatment, and the bank now owns 20 TB it still cannot describe to a regulator. B. ✅ Correct. Inventorying and classifying the data and assigning owners turns an unknown pile into assets with a label, a handling rule and an accountable person. Integration can then migrate in order of sensitivity, and the exam has an answer to "what do you hold and who is responsible for it". C. Encrypting the shares in place protects confidentiality while the data sits, and it is a reasonable interim control. It buys time without buying knowledge, the keys become one more unowned asset, and the examiner will still ask what is inside the encrypted volumes. D. Applying the bank's retention schedule and purging first reduces the volume to migrate and the exposure if something leaks. A retention schedule works by data type and owner, and this data has neither, so a purge would delete records nobody has evaluated, possibly under an acquisition hold.

@Joseph Knowles Correct Answer: B. Set a cryptographic standard and assess the design against it Explanation (CISSP logic): The clues are "wrote their own encryption", "passed unit tests" and "no cryptographic standard exists". Domain 3 rewards secure design principles, and the first of them here is that the organization has not said what acceptable cryptography looks like: which algorithms, key lengths, modes and key management it accepts and who approves exceptions. Unit tests prove the code does what the developer intended, not that the design is sound, so the architect's first move is to set the standard and assess the payments design against it. Assess before you act: once the standard exists, the fix, whether a library swap or a redesign, follows from a documented gap rather than from one engineer's opinion. Breakdown: A. Replacing the custom code with a vetted library is the strong distractor because it is almost certainly where this ends up, and never rolling your own crypto is sound advice. It is still an implementation decision made before anyone has defined what the service must meet, so the team could swap in a library with the wrong mode, weak keys or no key management plan and call it done. B. ✅ Correct. Setting a cryptographic standard and assessing the design against it gives the organization a rule it can apply to this launch and the next one, and turns "trust us, the tests pass" into a documented review with a named approver. C. Commissioning a penetration test is useful assurance, and the service should get one. A tester working without a standard can only report what they happened to break, and finding cryptographic design flaws by black-box testing is unreliable, so it is the wrong tool for this gap and the wrong step in the sequence. D. Approving launch with a rewrite planned next quarter respects the deadline and is honest about the debt. Shipping custom cryptography on a payments service is a risk acceptance that belongs to the business owner against a defined standard, not something an architect waves through on a promise, and temporary code has a way of becoming permanent.