UiPath-ADAv1 Logging Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use the Add Log Fields activity to add a custom field containing the customer's full name for easy identification in logs.

  Why it's wrong here

  Adding PII such as a full name as a custom log field directly violates the requirement to avoid logging sensitive data. Custom fields are included in every subsequent log entry and are visible in Orchestrator, so this would expose PII. Instead, non-sensitive identifiers like a hashed customer ID should be used.

• ✗

  Set the robot's logging level to Verbose to capture all details, then manually redact sensitive information from the logs before sharing them.

  Why it's wrong here

  Setting the level to Verbose increases the risk of logging sensitive data because more detailed messages are captured. Manual redaction is error-prone and does not prevent PII from being stored in Orchestrator. The goal is to avoid logging PII in the first place, not to redact after the fact.

• ✓

  Replace direct logging of sensitive values with references to non-sensitive identifiers, such as a hashed customer ID or a queue item reference.

  Why this is correct

  Using non-sensitive identifiers allows the developer to correlate log entries with specific customers or transactions without exposing PII. A hashed ID or queue reference provides traceability for troubleshooting while ensuring that the actual sensitive data is never written to logs, satisfying both security and diagnostic needs.

• ✓

  Configure the automation to log only non-sensitive metadata, such as timestamps, status codes, and transaction outcomes, for each processing step.

  Why this is correct

  Logging only non-sensitive metadata provides a record of the automation's execution without exposing PII. Timestamps, status codes, and outcomes are sufficient for troubleshooting and auditing while ensuring compliance with data protection policies. This approach minimizes the risk of accidental PII exposure in logs.

• ✗

  Use the Log Message activity with Level set to Error to log the full customer record when an exception occurs, ensuring that support can see the data.

  Why it's wrong here

  Logging the full customer record, even at Error level, still writes PII to the logs. Error-level entries are not automatically encrypted or restricted, and they persist in Orchestrator. This action would violate the requirement to avoid logging sensitive data, regardless of the severity level used.