Your immediate answer predominantly resides here, the official SQL Server Audit documentation. The larger discussions of performance, requirements, actual security issues addressed, threats mitigated, and what-the-hell-is-wrong-with-your-auditors has been alluded to in the comments and isn't a great candidate for Stack Exchange.
For your scenario you could do something like this:
1) Create the Server Audit
CREATE SERVER AUDIT [Audit-GeneralServerAudit]
( FILEPATH = N'\\NetworkStore\AuditLogs'
,MAXSIZE = 1024 MB
,MAX_FILES = 70
,RESERVE_DISK_SPACE = ON
( QUEUE_DELAY = 1000
,ON_FAILURE = SHUTDOWN
ALTER SERVER AUDIT [Audit-GeneralServerAudit]
WITH (STATE = ON);
2) Define the Server Audit (modify events as needed)
CREATE SERVER AUDIT SPECIFICATION [ServerName - Audit]
FOR SERVER AUDIT [Audit-GeneralServerAudit]
WITH (STATE = ON)
3) Create Database Audit(s) as needed. Create additional Server Audits to separate log files for easy use/permissions restrictions and to implement different retention/storage strategies
CREATE DATABASE AUDIT SPECIFICATION [DatabaseAuditSpecification]
FOR SERVER AUDIT [Audit-DB Specific Audit]
ADD (DELETE ON DATABASE::[DBName] BY [public]),
ADD (SELECT ON DATABASE::[DBName] BY [public]),
ADD (UPDATE ON DATABASE::[DBName] BY [public])
WITH (STATE = ON)
SQL Server automatically controls log rollover and space as per your file size and number of file definitions. Or the Windows Log settings control this if you elect for that design. Still a yes though - it absolutely can get out of control in terms of log size and over-writes (loss of audit data) if you don't setup the correct capacities.
If you're auditing a single user, why not audit other users and issues? You know, in-case someone else or another account is performing unwanted behavior.
Even basic log files are probably massive... as stated in comments, auditors need a clear definition of "unusual activity" or a clear methodology to automate finding it.
Intrusion Detection is unlikely to be caught by undefined anomaly detection. An actual audit strategy needs more than just the log files. I haven't seen much in the way of pre-built solutions for SQL Audit log files, but there are a lot of web, network, server log file solutions out there... maybe one is adaptable. Some example reports and setup guides here to get started on very basic reporting.