This is not generally true.
The ComponentInstance’s "dynamic_attributes" dictionary WILL have the attributes, IF the instance does not use the same default value as in the definition’s "dynamic_attributes" dictionary.
As an example, the definition may have a material attribute set to a default material / color, but if the user changes a DC option to another color choice, the DC engine will recreate the attribute in the instance’s "dynamic_attributes" dictionary with the specific material choice. The original “default” choice remains as it was in the definition’s "dynamic_attributes" dictionary, so that new instances inserted later will still use the “default” attribute value.
The normal pattern is to always first check the DC instance’s "dynamic_attributes" dictionary for an attribute, and if it is nil THEN check the definition’s "dynamic_attributes" dictionary for the attribute.
This is what the DC engine itself does internally.
Note that "dynamic_attributes" for nested groups (inside dynamic components) are always stored on the group instance itself, not on the group’s definition.
Example …
def read_dc_attribute(inst,key)
dydict = 'dynamic_attributes'
val = inst.get_attribute(dydict,key,nil)
return val if !val.nil?
inst.definition.get_attribute(dydict,key,nil)
rescue
return nil
end