I am stuck on this task and keep receiving a common validation error: "'devops-priv-vpc/boot/boots.log' not found in bucket 'devops-s3-logs-19048'".
-
Naming Conventions: Strictly followed.
-
Resources: All required infrastructure has been correctly provisioned.
-
Functionality: The entire workflow described in the task works flawlessly.
-
Verification: The log file is successfully uploaded to the S3 bucket; I can physically see the object and interact with it in the AWS Console.
Despite having a fully operational pipeline, the automated validator consistently fails with the error: "'devops-priv-vpc/boot/boots.log' not found in bucket 'devops-s3-logs-19048'".
Anticipating suggestions to look up solutions on GitHub - I have already searched and tried them. They face the exact same issue, and the validator still rejects the solution with that specific error.
Could you please explain the internal logic of the validator for this particular assignment? How exactly does the testing script perform the check, and which specific system users (root vs. ubuntu) are expected to execute the cron jobs?
It is highly demotivating to have a completely functional, working setup on hands that cannot be submitted due to the opaque validation logic or a lack of explicit verification requirements in the task description.
Thank you.
So, it turns out the entire issue was that the task description DID NOT SPECIFY that:
“You’ll need to configure the public vm so that you can log into the root user (this needs a fix in /root/.ssh/authorized_keys) …”
Why is such critical information, which directly affects the validator’s behavior, completely missing from the task description? How are candidates supposed to guess that on a PUBLIC, internet-facing node-contrary to all security best practices and common sense we are required to enable root login?
I might be sounding overly emotional, but due to this oversight in the task description, I wasted 4 hours (and 4 attempts) debugging the validator’s operation. Meanwhile, my actual infrastructure setup was fully functional and working perfectly from the very first try.
@MastDon There is a clue if you read the question carefully
an EC2 instance named nautilus-priv-ec2 (using ubuntu image). This instance uses the SSH key pair nautilus-key.pem already available on the AWS client host at /root/.ssh/ .
So this means that you need to log into the private instance as root. It’s a safe bet in these challenges that you’ll be root on the public instance when you make the connection, so configure the public instance for that.
It also means for lab builders that they don’t particularly need to care what AMI is used (as the current one could get deprecated), and many have different default users, e.g. ec2-user, ubuntu etc. root is always present whatever distro is used. Then the grader can easily hop from root to root to root.
Shocking in real world security though 
There’s also a small side-challenge in setting up root SSH access which you found, and that’s to edit not append to root’s authorized_keys or it doesn’t let you in.
I cannot agree that this is a hint. It is merely a part of the task description, and it can be interpreted in two ways - just as nothing explicitly forbids doing this from the ubuntu user.
At the same time, I remember there was a task where it was explicitly stated that remote login for the root user had to be enabled for the linter check to pass successfully.
I believe that if there is only one attempt to submit the assignment, the description of the task itself - and the fact that the validator will check for this - should be clearly specified to eliminate such mistakes.
I sincerely ask you to pass this on to the developers so they can edit the description. It will save a lot of time for other people. Thank you.