CCA-F Practice Test

CCA-F Practice Test practice questions, page 4 of 6, with answer review and explanations.

Question 16

You’re implementing the escalation logic for when the agent should call escalate_to_human. Your team proposes four different approaches for triggering escalation. Which approach will most reliably identify cases that genuinely require human intervention?

  1. Implement sentiment analysis that monitors for frustration indicators (negative language, repeated questions, exclamation marks) and trigger escalation when the frustration score exceeds a configured threshold.
  2. Configure the agent to escalate after three consecutive tool calls that fail to resolve the customer’s stated issue, ensuring a reasonable attempt before involving a human.
  3. Instruct the agent to escalate when the customer requests a human, when the issue requires policy exceptions, or when the agent cannot make meaningful progress.
  4. Build a rules engine that maps specific issue types, customer segments, and product categories to escalation decisions, removing the need for model judgment calls.

Question 17

Your order management system requires tools for three distinct operations: issuing refunds (requires amount and reason), canceling orders (requires reason), and requesting reshipments (requires shipping address). Each operation shares an order_id parameter but has different additional requirements. You notice during testing that with your current unified tool design, the agent frequently omits required parameters or includes irrelevant ones. What design change will most effectively improve parameter accuracy?

  1. Keep one unified tool with a nested operation_details object parameter whose internal structure varies by operation type, documented in the tool description.
  2. Keep one unified tool but add JSON Schema if-then-else conditionals to enforce that parameters like amount are required only when the operation type is “refund”.
  3. Split into three separate tools (issue_refund, cancel_order, request_reshipment), each defining only the parameters required for that specific operation.
  4. Keep one unified tool with all parameters marked optional, but add detailed few-shot examples in the system prompt showing correct parameter combinations for each operation type.

Question 18

Your post_content tool requires user confirmation before publishing. The current workflow displays “Ready to post to social media. Confirm?” and analytics show users approve 98% of requests within 2 seconds. Post-mortems reveal incidents where posts went to wrong accounts, were scheduled for wrong times, or contained errors – all confirmed by users without catching the mistakes. How should you redesign the confirmation workflow?

  1. Auto-approve routine posts and only require explicit confirmation for unusual patterns like posting to new accounts or large audiences
  2. Require users to type a confirmation phrase instead of clicking a button
  3. Add a mandatory waiting period before the confirm option becomes available
  4. Include the complete post text, target account, scheduled time, and platform in the confirmation request

Question 19

Your agent uses three tools: get_property_details(property_id) returns data including street address, get_price_history(property_id) returns historical pricing, and get_neighborhood_info(address) returns area statistics. You observe that get_neighborhood_info always requires get_property_details first just to extract the address, even when users specify the property by ID. This creates unnecessary latency and failure coupling – if the first call fails, the neighborhood request also fails. What tool design change best addresses this?

  1. Create a lookup_address(property_id) helper tool for retrieving addresses.
  2. Add retry logic and timeout handling to get_property_details.
  3. Change get_neighborhood_info to accept property_id, resolving the address internally.
  4. Consolidate into a single get_property_with_neighborhood(property_id) tool returning both datasets.

Question 20

Your update_user_profile tool accepts a user_id (required) and an optional fields_to_update object. In testing, Claude frequently omits user_id or passes incorrectly structured data. What is most critical for helping Claude understand what parameter values to provide?

  1. Strict JSON Schema type constraints marking user_id as required and defining fields_to_update as an object type
  2. Verbose parameter names encoding format hints, such as user_id_string_uuid_format
  3. Detailed error responses explaining why invalid parameter values were rejected
  4. Clear parameter descriptions explaining expected format, such as “user_id: UUID of the user to update (required)”