An administrator wants to let the finance group reach a new internal web application through Secure Private Access, but cannot select the application as a destination when writing the private access rule. What was skipped?
Select an answer to reveal the explanation.
Short Explanation
You can't send a guest to a room that isn't on the hotel map yet. In Secure Access, a private access rule points at private resources, so you have to define the app first — address or FQDN, ports and how it's reached. The trap is an internet access rule; private apps live in a different rule type.
Full Explanation
In Cisco Secure Access, private access rules reference private resources as their destinations. A private resource definition describes the internal application: its internal address, range or fully qualified domain name, the protocols and ports it uses, and the access methods allowed, such as client-based or browser-based zero trust access or VPN. Only after the resource exists can the administrator select it in a private access rule and pair it with identities such as the finance group. Because the application cannot be selected, the missing step is defining it as a private resource. An internet access rule governs traffic to internet destinations; an internal application reached through private access is not an internet destination, and exposing it on a public IP address would defeat the purpose. A do-not-decrypt list affects HTTPS inspection of internet traffic and has nothing to do with whether a private resource can be selected in a rule. AI guardrails inspect prompts and responses exchanged with AI applications as part of DLP policy and are unrelated to private application access. Exam caveat: private resources also need a path, usually resource connectors or a network tunnel, so that Secure Access can reach the application after the rule permits it. Operational check: create the private resource, confirm it appears in the private access rule destination list, and test access as a finance user.