Task 4.4: Prepare logs for audit

• ACloudTrail Insights events for the trail

  Incorrect

  Insights events detect unusual API call or error rates. They say nothing about whether log files were changed.

• BLog file integrity validation for the trail

  Correct

  Integrity validation uses SHA-256 hashing and RSA signing so you can determine whether a log file was modified, deleted or unchanged after delivery.

• CS3 Versioning for the log bucket

  Incorrect

  Versioning keeps earlier versions of objects, but it does not prove whether a delivered file was changed.

• DDefault encryption with SSE-KMS on the log bucket

  Incorrect

  Encryption protects the files at rest. It does not detect or prove modification.

Proof of integrity comes from digest files that CloudTrail signs; storage features such as versioning or encryption do not provide it.

• ARun CloudWatch Logs Insights queries on the bucket that holds the log files

  Incorrect

  Logs Insights analyzes log data that is in CloudWatch Logs. It does not query files in an S3 bucket.

• BCreate an Athena table over the CloudTrail logs in S3 and query it with SQL

  Correct

  Athena queries CloudTrail log files where they are in S3, and the Athena guide documents a table definition for them.

• CLoad the log files into Amazon Redshift with COPY and query the tables

  Incorrect

  COPY loads the data into Redshift tables, which the requirement rules out.

• DTurn on CloudTrail Insights so that it returns the matching events

  Incorrect

  Insights events flag unusual activity rates. They do not run SQL queries over past events.

CloudTrail already writes its logs to S3, so Athena can query them in place and charge only for the data scanned by each audit query.

• AReview the CloudTrail event history for DeleteTable events once a week

  Incorrect

  Event history is a searchable record of management events, but a weekly review is not an alarm within minutes.

• BCloudTrail to CloudWatch Logs, with a metric filter alarm on DeleteTable

  Correct

  A trail can send its events to a CloudWatch Logs log group, where a metric filter and alarm can act on specific API calls.

• CTurn on CloudTrail Insights for the management events that the trail logs

  Incorrect

  Insights flags unusual API call rates or error rates against a baseline, not each individual DeleteTable call.

• DTurn on log file integrity validation for the trail

  Incorrect

  Integrity validation shows whether log files were changed after delivery. It raises no alarms about API calls.

For alerts on specific API calls, route CloudTrail to CloudWatch Logs and alarm on a metric filter; S3 delivery alone is for storage and analysis.

• AA CloudWatch alarm with a fixed threshold

  Incorrect

  A fixed threshold is exactly what the team wants to avoid, and it does not learn what normal looks like.

• BCloudTrail Insights on the trail

  Correct

  Insights learns a baseline of normal API call and error rates and generates Insights events when current rates deviate from it.

• CLog file integrity validation

  Incorrect

  Integrity validation shows whether delivered log files were modified. It does not analyze call rates.

• DS3 server access logging on each bucket

  Incorrect

  Server access logs give detailed records of requests to a bucket, but they do not flag unusual rates.

Insights turns CloudTrail from a record into a detector: it baselines call and error rates and reports deviations.

• ARedshift audit logging for connections

  Incorrect

  Database audit logs record connections and user activity in the database. Traffic rejected before it reaches the database is not there.

• BCloudTrail management events for Redshift

  Incorrect

  CloudTrail records API calls to the Redshift service, not network traffic to the cluster.

• CVPC Flow Logs for the cluster's subnets

  Correct

  Flow logs capture information about IP traffic going to and from network interfaces in the VPC and publish it to CloudWatch Logs, S3, or Firehose.

• DS3 server access logging for the bucket

  Incorrect

  Server access logs record requests made to a bucket, not traffic to the cluster's network interfaces.

Network-level audit questions are answered by VPC Flow Logs; database and API logs only see what reached the database or the service API.

• ABroker log delivery from the cluster to an S3 bucket

  Correct

  MSK can deliver broker logs to CloudWatch Logs, Amazon S3, or Firehose; the destination must exist before you configure delivery.

• BA CloudTrail trail that records the cluster's events

  Incorrect

  CloudTrail logs Amazon MSK API calls, not the brokers' own logs.

• CEnhanced monitoring at the PER_TOPIC_PER_BROKER level

  Incorrect

  Monitoring levels control which CloudWatch metrics MSK publishes. Metrics are not broker logs.

• DA CloudWatch alarm on the cluster's CpuUser metric

  Incorrect

  CpuUser is the brokers' CPU use in user space. An alarm on it keeps no logs.

MSK separates API audit (CloudTrail), metrics (CloudWatch), and broker logs, which you route to CloudWatch Logs, S3, or Firehose.

• AThe AWS Config resource timeline for each of the Data Catalog tables

  Incorrect

  Config records configuration changes and compliance over time, not each request for data access credentials.

• BCloudTrail events named GetDataAccess from lakeformation.amazonaws.com

  Correct

  GetDataAccess is logged whenever a principal or integrated service requests temporary credentials to access data in a location registered with Lake Formation.

• CAWS Glue job run insights for the jobs that read the data

  Incorrect

  Job run insights help debug and optimize jobs. They do not cover Athena or record credential requests.

• DCloudTrail Insights events for the Lake Formation service in the account

  Incorrect

  Insights events flag unusual call or error rates. They are not a record of each data access.

Lake Formation vends credentials for registered locations, and CloudTrail records each vend as a GetDataAccess event, a natural audit trail of reads.