Check file permissions and OS log-rotation compatibility with the CloudWatch Logs agent
Troubleshoot logging solutions.
AnswerCorrect answer: A, B — check that file permissions still let the agent read the logs and that OS log-rotation rules are compatible with the agent's streaming config.
Amazon CloudWatch Logs agent is successfully delivering logs to the CloudWatch Logs service. However, logs stop being delivered after the associated log stream has been active for a specific number of hours. What steps are necessary to identify the cause of this phenomenon? (Choose two.)
Ensure that file permissions for monitored files that allow the CloudWatch Logs agent to read the file have not been modified. Correct Answer
Verify that the OS Log rotation rules are compatible with the configuration requirements for agent streaming. Correct Answer
Configure an Amazon Kinesis producer to first put the logs into Amazon Kinesis Streams.
Create a CloudWatch Logs metric to isolate a value that changes at least once during the period before logging stops.
Use AWS CloudFormation to dynamically create and maintain the configuration file for the CloudWatch Logs agent.
Community Votes
AB
75%
BE
25%
75% of anonymous learners picked answer AB.
Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
When logs stop after a fixed active period, log rotation is the usual culprit: rotation can alter file permissions (A) or rename/rotate the file the agent is tailing, and if rotation rules are incompatible with the agent's file-read configuration the stream stalls (B). Kinesis (C) and metric creation (D) are unrelated; CloudFormation (E) is a fix, not a cause-identification step. A and B are the diagnostic pair.
CloudWatch Logs stops after the stream has been active for a set number of hours. To identify the cause, confirm the monitored files' permissions still let the agent read them (log rotation can change ownership/mode) and confirm the OS log-rotation rules are compatible with the agent's streaming config (rotation can break the file handle the agent follows). Both A and B target the 'identify the cause' ask; E is a remediation, not a diagnosis step.
Adding a Kinesis producer (C)—unrelated to why the agent stops streaming. Creating a metric (D)—does not explain the stoppage. Using CloudFormation to manage the config (E)—that could remediate but the question asks to identify the cause, and E was flagged by commenters as a fix rather than a diagnostic step. A and B diagnose.
Community Discussion (4 comments)
AWSLoverLoverLoverLoverLover👍 1Selected: AB
✅ A. File permissions issue – If the file permissions change (e.g., log rotation modifies ownership or access rights), the CloudWatch Logs agent may lose access to the logs and stop forwarding them. ✅ B. Log rotation issue – Many operating systems use log rotation mechanisms (e.g., logrotate in Linux). If a log file is rotated and the CloudWatch Logs agent is not configured to handle rotation correctly, it may lose track of the log stream and stop sending logs.
Bachhu👍 2Selected: AB
AB E is not the step to identify the cause but can potentially solve the issue.
nznzwell👍 1
The question asks "What steps are necessary to identify the cause of this phenomenon? ". E is not a step to identify the cause, but an action to potentially solve the issue. So, should be A, B. For A, file permissions CAN change to prevent the Cloudwatch agent from reading it.
IPLogic👍 1Selected: BE
To identify the cause of logs stopping after a certain number of hours, you should: B. Verify that the OS Log rotation rules are compatible with the configuration requirements for agent streaming. E. Use AWS CloudFormation to dynamically create and maintain the configuration file for the CloudWatch Logs agent. These steps will help ensure that the log rotation process isn't interfering with the CloudWatch Logs agent and that the configuration is properly maintained
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Log in to comment, report an error, or add a note about this question.
Expert Analysis
Why the Answer Is Correct
A log stream that halts after being active for a specific duration points to file-handling changes, typically from OS log rotation. Verifying file permissions still permit the agent to read the monitored files (A) catches rotation-induced ownership/mode changes, and verifying the OS log-rotation rules are compatible with the agent's streaming configuration (B) catches rotation breaking the file the agent tails. Both directly identify the cause.
Why the Other Options Are Wrong
C (Kinesis producer) is unrelated to the agent's streaming stoppage. D (a metric) observes but does not explain the cause. E (CloudFormation-managed config) is a potential remediation, not a step to identify the cause, as commenters noted. A and B are the correct diagnostic steps.
Community Comment Notes
Community voted A,B (75), with a B,E minority (25). Commenters explained A (rotation changing file permissions) and B (rotation rule compatibility) as the cause-identification steps, and noted E is a fix rather than a diagnostic action. A,B confirmed.