update dynamodb spec

[iheartNathan]

Description

Issue: #883

Fixes: #883

[netlify]

✅ Deploy Preview for crossplane ready!

Name	Link
🔨 Latest commit	a925f60
🔍 Latest deploy log	https://app.netlify.com/sites/crossplane/deploys/67f8f62f85f34e00088c2184
😎 Deploy Preview	https://deploy-preview-916--crossplane.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 81 (🔴 down 1 from production) Accessibility: 90 (🔴 down 2 from production) Best Practices: 83 (no change from production) SEO: 100 (no change from production) PWA: 70 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[negz]

I don't think this is actually necessary. When you omit providerConfigRef, it defaults to using the ProviderConfig named default. So this change is just documenting the default behavior.

#883 may be misleading. It's unclear whether anything actually broke, or whether @wnqueiroz just expected to see a providerConfigRef but didn't.

I could see a case for it being a good practice to show the providerConfigRef in the docs so that folks know what's happening. However I can also see a case for omitting it, to keep the getting started example as simple as possible.

[iheartNathan]

There is no where in the Part 1 and Part 2 of the AWS Quickstart I can see the below mentioned.

When you omit providerConfigRef, it defaults to using the ProviderConfig named default.

In the part 1 of the AWS quickstart the providerConfigRef was provided as part of the bucket yaml file, it's not surprising user might be expecting the same thing in the part 2, atleast for users who are new to crossplane.

For consistency in the docs I think it will be OK to have the providerConfigRef field present in both the s3bucket and dynamodb spec or excluded on both.

[wnqueiroz]

Hey folks!

What I was expecting from a quickstart experience was more of a copy-paste approach — just enough to get the changes applied in my environment and quickly "feel" how the tool works.

I understand the behavior @negz mentioned. Omitting certain fields can definitely make it harder for newcomers to understand how things are wired together under the hood.

If this behavior is something users are expected to be aware of, I believe it would be helpful to make that more explicit in the documentation.

I agree with @iheartNathan — my initial impression wasn’t that the field was optional or that omitting it would default to a specific ProviderConfig. It felt more like something was missing entirely.