Trifectapp · original learning companion · version 1
PBQ reasoning workbook — worked solutions
The original guide’s explanations are shown below. Compare the reasoning and limitations, not only the final choice. All solution disclosures are expanded for printing.
Practice example 1: order a firewall rule set
Scenario: A training company hosts an internal web application at 10.20.20.20. Staff use 10.20.10.0/24; guests use 10.20.30.0/24. The administrator’s workstation is 10.20.99.10. All addresses are private examples for this exercise.
The firewall checks rules from top to bottom and stops at the first match. Evaluate only new inbound TCP connections to the application server; established return traffic is already handled. Staff require HTTPS on port 443. Only the administrator requires SSH on port 22. Everything else must be denied.
| Rule | Source | Destination | TCP port | Action |
|---|---|---|---|---|
| A | Any | 10.20.20.20 | Any | Deny |
| B | 10.20.10.0/24 | 10.20.20.20 | 443 | Allow |
| C | 10.20.99.10 | 10.20.20.20 | 22 | Allow |
| D | Any | 10.20.20.20 | 443 | Allow |
Your task: Select the necessary rules, place them in order and predict the outcome for staff HTTPS, guest HTTPS, administrator SSH and staff SSH.
Show the explanation
Use B, C, A. C, B, A also works because the two allow rules do not overlap. Remove D: it would permit guests and every other source to reach HTTPS.
Staff HTTPS matches B and is allowed. Administrator SSH matches C and is allowed. Guest HTTPS and staff SSH reach A and are denied. Putting A first would block every request before an allow rule could be considered.
Notice the two kinds of verification: required traffic succeeds, and prohibited traffic fails. Testing only the staff website connection would miss an overly broad rule. Write both positive and negative tests whenever you practice access controls.
Practice example 2: correct excessive permissions
Scenario: An invoice application combines permissions from all assigned roles. There are no inherited roles, direct grants or explicit deny rules. Company policy says the same person must not both edit and approve invoices.
| Role | Permissions |
|---|---|
| InvoiceEditor | Read, create and edit invoices |
| InvoiceApprover | Read and approve invoices |
| InvoiceReader | Read invoices only |
Maya prepares invoices and currently has InvoiceEditor. Leo approves them and currently has both InvoiceApprover and InvoiceEditor. An external auditor needs read-only access until 17:00 UTC on November 20, 2026, and currently has no role.
Your task: Give each person the smallest role assignment that meets their work requirements. Identify one temporary-access control and two tests that would expose a permissions mistake.
Show the explanation
Keep Maya as InvoiceEditor. Keep Leo as InvoiceApprover and remove InvoiceEditor. Assign InvoiceReader to the auditor and configure the temporary assignment to expire at the specified time.
Verify that Maya can create an invoice but cannot approve it. Verify that Leo can approve an invoice but cannot change its contents. Also test that the auditor can read records but cannot edit or approve them. Confirm the expiry configuration and verify that access ends afterward; in a lab, use a short test interval.
Adding a read-only role to Leo would not cancel his existing edit permission. Under this scenario’s additive model, the excessive grant must be removed. On real platforms, inspect effective access because group nesting, direct grants and deny behavior can change the result.
Practice example 3: build a timeline from synthetic logs
Scenario: The following invented records use UTC. The account riley normally accesses the invoice application from a managed workstation. There is no approved role-change ticket. The external addresses are documentation examples.
09:10:00 AUTH user=riley source=198.51.100.77 result=fail
09:10:04 AUTH user=riley source=198.51.100.77 result=fail
09:10:09 AUTH user=riley source=198.51.100.77 result=success session=S17
09:10:10 MFA session=S17 result=not_required policy=legacy_exception
09:11:02 APP session=S17 action=add_role role=InvoiceApprover result=success
09:12:15 APP session=S17 action=export records=2400 result=successYour task: Identify the session that deserves investigation, summarize its sequence in one sentence and name two additional evidence sources. State one conclusion these logs do not establish.
Show the explanation
S17 warrants investigation: repeated authentication failures were followed by a successful login without an MFA requirement, a role addition and a large export.
Review identity-provider records for the account and exception policy, then application audit records for the role change, export destination and authorization context. Device records or confirmation from the user through a trusted channel could add context.
The log states that MFA was not required; it does not show an attacker defeating an MFA challenge. It also does not identify a human attacker or prove where exported data ultimately went. Treat the sequence as suspected account misuse requiring investigation under the response procedure.
A good answer separates observations from hypotheses. Preserve the original records, timestamps and session identifiers so another analyst can reproduce the sequence. Avoid replacing the evidence with a vague note such as “suspicious login.”
Practice example 4: prioritize three security events
Scenario: You are the first available analyst. The response playbook allows immediate network isolation of ordinary employee endpoints using EDR while preserving the management channel. None of the affected devices supports a safety-critical process.
| Event | Current evidence |
|---|---|
| A | EDR confirms active encryption on a connected laptop; its user can write to shared files |
| B | A phishing email was quarantined before delivery; no recipient interaction occurred |
| C | A critical vulnerability is confirmed on an internet-facing VPN; no exploitation evidence is currently known |
Your task: Choose the first event to address, the first containment action and the next investigation priority. Explain why a vulnerability severity label alone does not settle the order.
Show the explanation
Address A first. Use the authorized EDR isolation action to limit continued spread, notify the incident lead and assess affected shared resources. Network isolation may not stop encryption already running locally, so follow the playbook for further containment and eradication. Preserve evidence and document the action; wiping the laptop immediately would make investigation harder.
Escalate C next for urgent exposure assessment and mitigation planning with the VPN owner. Investigate scope, vendor guidance and available protections rather than treating “no evidence” as proof that exploitation has not occurred. Review B to confirm the quarantine and look for related messages.
The proposed order is A, C, B because of the specific evidence and impact here. It is not a universal ranking for every incident. A critical vulnerability on a different asset, evidence of exploitation or a safety dependency could change the decision.
Practice example 5: validate a security change
Scenario: A team deploys a security update to an internal application during an approved window. The change plan authorizes restoring the previous application release if two consecutive checkout health checks fail. A tested rollback package is available; the update does not change the database schema.
| Acceptance check | Observed result |
|---|---|
| HTTPS endpoint responds with the expected page | Pass |
| Standard user can complete a test checkout | Fail twice: application error |
| Standard user cannot open the administration page | Pass |
| Required audit events reach the monitoring system | Pass |
Your task: Decide whether to close the change as successful. Select the next action and list what you would verify afterward.
Show the explanation
Do not close the change as successful. The defined rollback condition has been met. Record the failed checks and relevant error evidence, notify the change owner and execute the approved restoration procedure within its authorization.
Afterward, repeat all acceptance checks: expected page, checkout, access restriction and audit delivery. Confirm the restored release and document the service status. Successful HTTPS connectivity alone does not prove that the application works.
Restoring the previous version also restores its prior security risk. Record that risk, maintain any approved compensating controls and plan a corrected deployment. Rollback is a controlled recovery step, not a permanent substitute for remediation.
Original Trifectapp practice, not official CompTIA exam questions. This workbook does not predict an exam score. Source: the published guide. Companion prepared November 7, 2026. The saved exercises retain the guide’s existing objective labels; this companion does not independently certify exam coverage.