NetworkLinks Object

When Truto actually read this object from the provider, in UTC ISO 8601 with the offset present. Not when the request was made and not a provider timestamp. Drives consumer staleness rules.

Truto's stable unified identifier for this object. Opaque; use provider_ref to address the object in the provider's own console or API.

The provider's own identifier for the link.

What kind of connection this is.

The network on this side of the link.

The provider's own type string, unmodified -- for example 'AWS::S3::Bucket', 'aws_iam_role', 'Microsoft.Sql/servers'. Used for display and drill-down.

Which cloud this object was read from.

The provider's own unbroken identifier, passed through verbatim -- a full ARN, resource id or self-link. Never truncated, prefixed or normalised. This is the customer-facing key used to find the object in the console.

The account owning the far side. Essential: the risk this object exists to surface is a link crossing an account boundary. Links are oriented by account rather than by which side initiated, because initiator is not a security property.

The provider's own state string for the link, verbatim.

Whether traffic can transit through this link to a third network. Structurally always false for AWS VPC peering, which does not support transitive peering at all. For transit gateways it is NOT on the attachment -- the attachment carries an association but propagations are absent entirely -- so reachability is computed from associations and propagations together, and attachments that look identical can have completely different blast radii.

For transit gateways, whether attachments are associated with the default route table automatically. Together with default_route_table_propagation this is the highest-signal finding on the object: both enabled is the flat-mesh default where every network reaches every other network.

For transit gateways, whether attachment routes propagate into the default route table automatically.

Where the object is. A compliance answer in its own right, not metadata. The literal string 'global' is emitted for genuinely global resources (for example IAM, or a GCP VPC network) rather than guessing a region. Never invented: where the provider does not return a location and none can be derived, the collector's queried region is used and that substitution is recorded in unreadable_fields.

The network on the far side of the link.

Raw data returned from the remote API call.

The region on the far side of the link.

Route exchange configuration, where the provider has one. AWS VPC peering has no equivalent: the only surviving option concerns DNS resolution rather than routing, and the other two are deprecated. Null with not_supported_by_provider there.

Whether routes actually exist for this link. Load-bearing: an active peering exchanges no routes automatically -- an administrator must add them by hand -- so an active state alone does not mean the two networks are connected. Cross-checked against the route tables.

Key-value pairs exactly as the customer set them: no case folding, no key or value normalisation, no merging of separate provider concepts. Present on every object because tags are the primary input for environment classification. An empty object means the object carries no tags; tags that could not be read are recorded in unreadable_fields instead.

Per-object list of the fields that could not be read, and why -- the brief section 8.4 answer, chosen over per-field sentinel values. Each entry is an object with 'field' (the property name on this resource), 'reason' (a reason code) and an optional human-readable 'detail'. Reason codes: not_supported_by_provider, not_configured, permission_denied, not_collected, collection_error, partially_collected. An empty array means every property on this object was read successfully. A property absent from this array and null in the payload means the provider genuinely returned no value, which is different from 'we could not look'.