Can you make sure this is coerced to an actual boolean value? It's confusing that the default value is False but when you check if it's enabled you compare with == "true" instead of is True.

I actually followed the same approach as for disable_api_termination:

• https://github.com/anisaoshafi/moto/blob/9e8bc74f3610ed390e7fad4bb90af574b68dd1f1/moto/ec2/models/instances.py#L126
• https://github.com/anisaoshafi/moto/blob/9e8bc74f3610ed390e7fad4bb90af574b68dd1f1/moto/ec2/models/instances.py#L778 with if instance.disable_api_termination == "true":

for some reason when I coerce disable_api_stop to bool with _convert_to_bool(), the test starts failing even though it should be straightforward 🤔
unless I'm doing sth wrong in the test or elsewhere. Could you please help me figure out if I'm missing sth?

This attribute is always coerced to a string, if supplied. If we want Moto to always handle this as a boolean, we need to make changes in quite a few places:

1. run_instances() - that's the easiest one, as it can use _get_bool_param
2. modify_instance_attribute(Attribute="disableApiStop", Value="false") - more difficult, as we currently treat all attributes (strings and booleans) the same
3. modify_instance_attribute(DisableApiStop={"Value": True}) - same logic, different code path
4. describe_instance_attribute - the response needs custom logic to convert True to 'true' and False to 'false' iff we're describing a boolean attribute

The last point was why you we're getting an error @anisaoshafi. boto3 expects a lower-case true in the responses, so if Moto returns <value>True</value>, boto3 interprets that as a False-value.

Now, ideally, if we're going to handle this attribute as a boolean, we should handle all boolean attributes as such. The other ones are: SourceDestCheck, DisableApiTermination, EbsOptimized, EnaSupport.

Which leads to another change:
5. Change describe_instances(filters=[{"Name": "source-dest-check", "Values": ["false"]}]) (and other boolean filters like it) to convert the incoming values

So in short - should it be a boolean? Yes absolutely. Do we want to do it as part of this PR? Probably not, because the list of changes is quite large, and I'm not sure if we have the test coverage for all corner cases. So I vote to merge this as-is for now, and classify this as techdebt.

I've pushed a commit with a few more assertions, just to verify all possible scenarios currently pass. This should come in handy if/when we tackle this techdebt.

Thanks a lot for the very thorough clarification, @bblommers. This seems like an interesting problem, and agree that it's out of the scope of this PR.

I really appreciate that you added the extra assertions 🙏🏼 hope all the checks pass, otherwise I can handle the needed adjustments 🤞🏼