Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 458 discussion

I would go with A. In May 2021 they introduced the ability to specify upto 3 dimensions. 'For example, you can use this feature to extract fields from webserver access logs allowing you to measure the bytes transferred per event type' https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-cloudwatch-logs-announces-dimension-support-for-metric-filters/

Metric Filters only provide simple pattern counting functionality and cannot handle duplicate users.

Both A and B are workable. A is the simplest and has no code development effort

With https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html the documentation states that CloudWatch Logs metric filters can extract and publish metrics based on log data, but the dimensions for these metrics are limited to the following: LogGroupName LogStreamName Namespace (optional) There is no mention of the ability to use custom dimensions like user name or client name with CloudWatch Logs metric filters. Given this limitation, the solution that would provide the required information with the least change to the application is: D. Configure an AWS Lambda function to consume an Amazon CloudWatch Logs stream of the application logs. Additionally, configure the Lambda function to increment a custom metric in CloudWatch that uses the user name and client name as dimensions for the metric.

Option A involves configuring a CloudWatch Logs metric filter to extract login metrics from log files. This approach can provide the required KPIs with minimal changes to the application, as it does not require modifying the application code or adding additional services. The solution also uses dimensions to capture user name and client name information, which will help identify unique users for each client on a daily, weekly, and monthly basis.

Answer seems to be option D. Metric Filters can only count the occurrence of a pattern in the log, they cannot extract specific data fields like user name or client name. Metric Filters do not automatically create custom metrics in CloudWatch. They only send the counted values to an existing metric.

was at first for A but then for D.. ChatGPT is also for D: D: This option provides the most flexibility and capability for processing data. AWS Lambda can process the incoming log stream to apply more complex logic, such as checking for and ignoring duplicate entries within a set time frame (daily, weekly, monthly) before incrementing the metrics. This allows for the implementation of logic to ensure that users are only counted once per period, effectively tracking unique logins. Conclusion: Among the given options, Option D using an AWS Lambda function is best equipped to handle the requirement of counting unique user logins accurately over specified periods. Lambda functions offer the flexibility to implement any necessary logic to filter duplicates and manage counts over time, aligning with the need to track unique users on a daily, weekly, and monthly basis.

A is not because Metric filters can't directly solve the problem of counting unique users across different time periods. They can count how many logins happened, but not how many distinct users logged in during those time periods.

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html

With existing logs, we don't have to make changes to the application.

I would go for A https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringPolicyExamples.html

Answer is C.

A is the correct answer: it has the least changes to the application. C and D are rubbish.

No app code change by configuring the agent to extract & save successful login metrics as custom metrics with user name and client name dimensions. #A and #B requires app changes. #D needs additional lamba infra and increase complexity