@Md Ashraf Razi Correct Answer: B. Assess the account's access and assign an owner Explanation (CISSP logic): The clues are "AI agent pays invoices", "shared service account", "static password", and "CFO wants it running". A non-human identity that moves money is a privileged account, and this one has no named owner and no visible scope. Identity management starts with knowing what an identity can do and who is accountable for it; until someone owns the account and its entitlements are mapped, every fix is a guess and every failure is an orphan. Assess before you act: understand the access, name the owner, then remediate to the level the risk deserves. Breakdown: A. Rotating and vaulting the password is quick hygiene and it will almost certainly happen. But a vaulted password on an account nobody owns, with entitlements nobody has reviewed, is still a shared privileged identity that can pay anyone anything. B. ✅ Correct. Reviewing the account's entitlements and assigning an accountable owner tells you the blast radius of the agent, whether it is over-privileged for its job, and who signs off on the remediation. Rotation, redesign and the audit response all depend on this picture. C. The strong distractor. Per-workflow managed identities with least privilege are the target architecture and the eventual answer. But rebuilding a payment integration in six weeks without first knowing what the agent actually needs risks breaking finance or recreating the same excess access under a new name. D. A risk acceptance is a legitimate governance tool once the risk is understood. But asking the CFO to accept a risk nobody has measured is not risk management, it is a signature on a blank page, and the auditor will read it that way. Think like a manager: Every identity that can spend money needs an owner and a known scope. Find both before you fix anything.

@Naveen C Correct Answer: C. Perform security due diligence on its environment Explanation (CISSP logic): The clues are "buys a smaller rival", "joined on day one", and "never been reviewed". In an acquisition the buyer inherits every weakness, breach, and compliance gap the target already has, and due diligence is how management learns what it is buying before it owns it. Until the rival's environment has been assessed nobody can say whether day one connection is a reasonable risk or an open door into the corporate cloud. Assess before you act: know the risk you are acquiring, then decide how to connect, insure, or govern it. Breakdown: A. A restrictive firewall is a sensible way to limit a new connection and it may well be part of the final design. But it is a technical control placed around an environment nobody has looked at, so the rules would be guesses, and an existing compromise on the rival's side would ride straight through whatever is allowed. B. The strong distractor. Bringing the rival under corporate policy is a real integration goal and it has to happen. But policy adoption takes months, it says nothing about the state of the environment today, and you cannot write a sensible integration plan until due diligence tells you how far the rival is from the standard. C. ✅ Correct. Due diligence surfaces the rival's existing incidents, unpatched systems, regulatory obligations and contractual liabilities while there is still time to price them into the deal or condition the connection on fixing them. Every other option depends on what it finds. D. Extending insurance is legitimate risk transfer and the board will want it in place. But an insurer will ask for exactly the assessment that has not been done, and transferring a risk you have never measured is not risk management, it is hope with a premium. Think like a manager: You do not just buy a company, you buy its breaches. Look before you connect.

@Broulaye Samake Correct Answer: B. Tabletop the revised plan with the business owners Explanation (CISSP logic): The clues are "rewritten after a cloud migration", "never exercised", and "full production failover as proof". Recovery testing climbs a ladder: read-through, tabletop, walkthrough, simulation, parallel, full interruption, and each rung exists to catch the errors the previous one would turn into an outage. A plan nobody has exercised on paper almost certainly has wrong contacts, wrong dependencies, and recovery objectives the business never agreed to, and the cheapest place to find that out is around a table. Assess before you act: prove the plan is coherent before you bet production on it. Breakdown: A. A full interruption test produces the strongest evidence and the audit clock is real. But running it on an unexercised plan risks a self inflicted outage, and an audit finding for a failed failover is worse than one for an untested plan. B. ✅ Correct. A tabletop costs a few hours, validates roles, sequence, dependencies and recovery targets with the people who own the processes, and produces documented evidence the regulator will accept as the first step of a testing program. Every heavier test builds on it. C. The strong distractor. Restorable backups are the foundation of any recovery and this check belongs early in the testing program. But it validates one technical component in isolation, not whether the plan around it can actually bring the business back, and it is a test the tabletop will schedule anyway. D. Asking for an extension is honest and sometimes necessary. But it is a negotiation, not a control, and 45 days is enough to run the early rungs of the ladder and show the regulator a plan under active testing. Think like a manager: A recovery plan is tested on paper before it is tested on production.