StackToIT Migration Intelligence Workspace

1 unit: module.vpc.module.vpc.aws_route_table.private · owner role Network Architect · required by phase: not stated · 1 step rests on it

Options and trade-off

none listed: the knowledge base has no options for this kind of decision, so none is invented and a person states the answer in the decisions file

Applications touched

none: no applications file was given and no suggested group holds an affected unit

Wave

not stated: none of its units is a member of a wave (a unit that does not exist, exists only when OpenTofu plans, or is refused for a missing input is in none) · steps in foundation

Approval

not approved: no decisions file was given with this run

What the draft does

Decide the outbound (egress) rules of the security group: The draft does not carry the setting on module.vpc.module.vpc.aws_route_table.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_route_table.private/open-settings). In the estates checked when this entry was written, the draft does not carry these settings: what it writes instead (a variable, a "not carried" line in the Terraform comments, or nothing) is stated per unit in the generated Terraform. Where the critical-settings record of a run names a step that carries a setting (with the evidence of the value), a person confirms that value instead. Review the NAT fixed egress address setting: The draft does not carry the setting on module.vpc.module.vpc.aws_route_table.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_route_table.private/open-settings). Confirm that the project is the boundary of one network: The draft does not carry the setting on module.vpc.module.vpc.aws_route_table.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_route_table.private/open-settings). Confirm the destinations of the routes: The draft does not carry the setting on module.vpc.module.vpc.aws_route_table.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_route_table.private/open-settings). A table whose routes all go to an internet gateway is replaced by STACKIT's default routing and no table is drafted, with the precondition that the project is created outside a Network Area (the plan's statement that no routing table is drafted). A custom table is drafted as a stackit_routing_table of a Network Area with the routes it can carry; every other route is named "not carried" in the Terraform comments. Confirm the targets of the routes: The draft does not carry the setting on module.vpc.module.vpc.aws_route_table.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_route_table.private/open-settings). Re-create the routes with STACKIT next hops: The draft does not carry the setting on module.vpc.module.vpc.aws_route_table.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_route_table.private/open-settings). Confirm what each route table is associated with: The draft does not carry the setting on module.vpc.module.vpc.aws_route_table.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_route_table.private/open-settings). Confirm the network of the route table: The draft does not carry the setting on module.vpc.module.vpc.aws_route_table.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_route_table.private/open-settings). With one VPC the project stands for it and the default routing applies (nothing drafted); a custom table is drafted at Network Area scope.

Still open

Decide the outbound (egress) rules of the security group: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Review the NAT fixed egress address setting: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Confirm that the project is the boundary of one network: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Confirm the destinations of the routes: That the target networks reach what the source routes reached and nothing more: the default routing of a Network Area was never read, and the equivalence outside an area was observed in one STACKIT test project only. Confirm the targets of the routes: That the target networks reach what the source routes reached and nothing more: the default routing of a Network Area was never read, and the equivalence outside an area was observed in one STACKIT test project only. Re-create the routes with STACKIT next hops: That the target networks reach what the source routes reached and nothing more: the default routing of a Network Area was never read, and the equivalence outside an area was observed in one STACKIT test project only. Confirm what each route table is associated with: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Confirm the network of the route table: Which STACKIT networks the routing rules govern. Decide the outbound (egress) rules of the security group: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. The restriction of egress to the NAT gateway (the only way out of a private subnet) is carried on STACKIT by the egress rules of the security groups, not by a route (the test of 2026-10-10: with egress rules for one /32 only that destination was reachable, with none nothing left). Whether the source restricts egress that way, and whether the draft carries those rules for the servers of this table's subnets, is not something this contract can read, so it is REVIEW and never PRESERVED: a person confirms that the servers of the private subnets keep a restricting egress rule set. Review the NAT fixed egress address setting: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. NOT CARRIED, an observed loss (the test of 2026-10-10): the NAT gateway's fixed egress address. Confirm that the project is the boundary of one network: A check of the knowledge base (topology vpc unproven) fired on this unit and leaves the setting to a person: the target does not settle it by itself (a finding of this unit describes it). Several VPCs, a VPC count that is not visible, or a unit of the estate that names a VPC, or is placed in a subnet, the scan cannot prove is the estate's, leave the architecture to the architect for every unit of the topology, this route table included: STACKIT has no VPC container in its stable model, the project is the boundary of its networks, so the draft cannot keep several VPCs apart in one project. Confirm the destinations of the routes: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. Destinations are read by value: every route of a default-only table sends 0.0.0.0/0 to an internet or NAT gateway — STACKIT's default network routing, observed equivalent for a draft outside a Network Area (the test of 2026-10-10) and REVIEW all the same. Confirm the targets of the routes: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. The next hop of each route of the table: a route whose target is anything but an internet or NAT gateway, or that names none, makes the table a custom routing table. Re-create the routes with STACKIT next hops: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. Custom routes map to stackit_routing_table_route, an experimental resource (experiment routing-tables); next hops that name AWS gateways are chosen anew. Confirm what each route table is associated with: A check of the knowledge base (rt private subnet association) fired on this unit and leaves the setting to a person: the target does not settle it by itself (a finding of this unit describes it). The setting states which subnet uses this route table, for the associations the draft does not attach. Confirm the network of the route table: A check of the knowledge base (topology vpc unproven) fired on this unit and leaves the setting to a person: the target does not settle it by itself (a finding of this unit describes it). aws_route_table.vpc_id: The VPC whose subnets this route table's rules apply to; a route table's entries only make sense, and only affect reachability, within this one VPC, so losing or mismapping it silently changes which network the routing rules govern. A custom table is REVIEW whatever the estate: the draft's stackit_routing_table is organisation and Network Area scoped (organization_id, network_area_id, pinned provider), not a resource of the project that is the VPC's boundary (the experimental stackit_vpc_routing_table, pinned provider: project_id, vpc_id, is a VPC-scoped table that the draft does not write and that nothing establishes as the counterpart of an AWS route table), so which networks the table governs is decided by the Network Area the person puts the project in and the routing_table_id each network is given. A table the draft does not make (count or for_each) and one left to the architect are REVIEW. Several VPCs, a VPC count that is not visible, or a vpc_id (this table's or another unit's) that is a literal, a variable, a data source or an expression the scan cannot reduce to the estate's VPC: which routing domain the table belongs to is the architect's decision — REVIEW. Held CRITICAL: it decides which networks, clients or endpoints reach the resource or what it reaches.

Ways out

1. Decide the outbound (egress) rules of the security group: Verify what the knowledge base's note asks to confirm; needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: A person checks the setting on the STACKIT target (or against the source, the clients and the tooling that depend on it) and records the result; nothing in the draft changes.; regeneration: not stated — treated as required; risk: A setting confirmed from the draft alone, without the check, can still differ at runtime.; the draft is generated again with it
2. Review the NAT fixed egress address setting: Accept the documented difference; needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: The owner records that the target does not reproduce the setting and that the workload accepts it; nothing in the draft changes.; regeneration: not stated — treated as required; risk: What the setting protected on the source (data, access, availability) is not protected on the target in the same way.; the draft is generated again with it
3. Confirm that the project is the boundary of one network: Verify what the knowledge base's note asks to confirm; needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: A person checks the setting on the STACKIT target (or against the source, the clients and the tooling that depend on it) and records the result; nothing in the draft changes.; regeneration: not stated — treated as required; risk: A setting confirmed from the draft alone, without the check, can still differ at runtime.; the draft is generated again with it
4. Confirm the destinations of the routes: Keep STACKIT's default routing in a project outside a Network Area; needs every route of the table sends traffic to an internet gateway (a default-only table), the target project is created outside a Network Area; effect: No routing table is written; every network reaches the internet through source NAT and the networks of the project reach each other.; risk: A server without a public IP gains outbound internet through the network's shared address, which the source's internet gateway did not give it.
5. Confirm the destinations of the routes: Place the workload in a Network Area and carry the routes in a routing table; needs a Network Area for the target project (an organisation-level decision; whether a project can join an area after creation is not stated in the sources read), the complete route set, with a STACKIT next hop for each route; effect: A stackit_routing_table with stackit_routing_table_route resources (IPv4 CIDR destinations only) is assigned to the routed networks.; risk: The resource is experimental and may change; IPv6 routes and routes to NAT, transit or peering targets have no counterpart.; the draft is generated again with it
6. Confirm the targets of the routes: Keep STACKIT's default routing in a project outside a Network Area; needs every route of the table sends traffic to an internet gateway (a default-only table), the target project is created outside a Network Area; effect: No routing table is written; every network reaches the internet through source NAT and the networks of the project reach each other.; risk: A server without a public IP gains outbound internet through the network's shared address, which the source's internet gateway did not give it.
7. Confirm the targets of the routes: Place the workload in a Network Area and carry the routes in a routing table; needs a Network Area for the target project (an organisation-level decision; whether a project can join an area after creation is not stated in the sources read), the complete route set, with a STACKIT next hop for each route; effect: A stackit_routing_table with stackit_routing_table_route resources (IPv4 CIDR destinations only) is assigned to the routed networks.; risk: The resource is experimental and may change; IPv6 routes and routes to NAT, transit or peering targets have no counterpart.; the draft is generated again with it
8. Re-create the routes with STACKIT next hops: Keep STACKIT's default routing in a project outside a Network Area; needs every route of the table sends traffic to an internet gateway (a default-only table), the target project is created outside a Network Area; effect: No routing table is written; every network reaches the internet through source NAT and the networks of the project reach each other.; risk: A server without a public IP gains outbound internet through the network's shared address, which the source's internet gateway did not give it.
9. Re-create the routes with STACKIT next hops: Place the workload in a Network Area and carry the routes in a routing table; needs a Network Area for the target project (an organisation-level decision; whether a project can join an area after creation is not stated in the sources read), the complete route set, with a STACKIT next hop for each route; effect: A stackit_routing_table with stackit_routing_table_route resources (IPv4 CIDR destinations only) is assigned to the routed networks.; risk: The resource is experimental and may change; IPv6 routes and routes to NAT, transit or peering targets have no counterpart.; the draft is generated again with it
10. Confirm what each route table is associated with: Take the decision the knowledge base's note names and carry it out (alternatives: not stated in the knowledge base); needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: A person takes the decision the closing condition names and carries it out; where it changes what the draft writes, the draft is regenerated or changed by hand.; regeneration: not stated — treated as required; risk: The knowledge base states no evidenced alternatives to choose from; a decision taken without the source context the note names can change what the workload reaches, stores or exposes.; the draft is generated again with it
11. Confirm the network of the route table: Keep one project per VPC with STACKIT's default routing; needs one VPC in the estate, the project created outside a Network Area; effect: The project's networks are the VPC's subnets; no table is written.; risk: As for the routes of the table: the default routing is observed equivalent only outside a Network Area.
12. Confirm the network of the route table: Assign the routing table to the networks of the Network Area it should govern; needs the Network Area the project joins, the networks that take the table; effect: Each network that takes the table carries its id; a table is assigned per network, there is no per-subnet association.; risk: A network left without the table follows the area's default table.; the draft is generated again with it

What closes it

Decide the outbound (egress) rules of the security group: A person confirms that the servers of the private subnets keep a restricting egress rule set in their security groups, because on STACKIT the restriction of egress is carried by egress rules, not by a route. Review the NAT fixed egress address setting: A person accepts the project's shared egress address, which can change and cannot be set, or gives each server a STACKIT public IP when a third party allow-lists the old address. Confirm that the project is the boundary of one network: The knowledge base states no closing condition for this setting; the run closes it when a person decides it as the open check asks and that check's closing evidence or decision is recorded. Confirm that the project is the boundary of one network: A person decides it as that finding asks, and the finding's closing evidence or decision is recorded. Confirm the destinations of the routes: A person confirms every route destination that is not the default route to an internet or NAT gateway (a CIDR, a prefix list, any IPv6 route): the draft carries none, and a specific destination needs a stackit_routing_table_route, which takes IPv4 CIDR destinations only. Confirm the targets of the routes: A person decides the next hop of each route on STACKIT: an internet gateway becomes the next hop internet, an appliance (a network interface or an instance) a next hop of type ipv4. A NAT gateway, a transit gateway or a VPC peering has no STACKIT counterpart, so the connectivity design is the person's. Re-create the routes with STACKIT next hops: A person creates the routes on the STACKIT routing table (stackit_routing_table_route, experimental) and chooses the next hops anew, because they name AWS gateways. Confirm what each route table is associated with: A person decides which networks of the Network Area take the routing table and sets routing_table_id on them: STACKIT attaches a routing table to a whole network (stackit_network.routing_table_id), there is no per-subnet association, and routing tables apply only to routed Layer 3 networks in a Network Area. Confirm what each route table is associated with: A person decides it as that finding asks, and the finding's closing evidence or decision is recorded. A person decides which networks of the Network Area take the routing table and sets routing_table_id on them: STACKIT attaches a routing table to a whole network (stackit_network.routing_table_id), there is no per-subnet association, and routing tables apply only to routed Layer 3 networks in a Network Area. Confirm the network of the route table: A person decides which STACKIT networks the routing table governs: the draft's custom table is organisation and Network Area scoped, so the Network Area the project joins and the routing table each network is given decide it. Confirm the network of the route table: A person decides it as that finding asks, and the finding's closing evidence or decision is recorded. A person decides which STACKIT networks the routing table governs: the draft's custom table is organisation and Network Area scoped, so the Network Area the project joins and the routing table each network is given decide it. Verification: Decide the outbound (egress) rules of the security group: the check, proof or closing evidence is recorded with its result; Confirm that the project is the boundary of one network: the check, proof or closing evidence is recorded with its result; Confirm the destinations of the routes: reachability observed on the target: the internet, the other networks, and nothing the source did not reach; Confirm the targets of the routes: reachability observed on the target: the internet, the other networks, and nothing the source did not reach; Re-create the routes with STACKIT next hops: reachability observed on the target: the internet, the other networks, and nothing the source did not reach; Confirm what each route table is associated with: the decision or the manual work is done and recorded (who, when, what was configured and why); Confirm the network of the route table: the routing of each target network observed on the target.

Next action

Review the NAT fixed egress address setting: Review the NAT fixed egress address setting for module.vpc.module.vpc.aws_route_table.private, and record the answer for this record in the decisions file given with --decisions (decisions-template.yaml).

1 unit: module.vpc.module.vpc.aws_eip.nat · owner role Network Architect · required by phase: not stated · 1 step rests on it

Options and trade-off

none listed: the knowledge base has no options for this kind of decision, so none is invented and a person states the answer in the decisions file

Applications touched

none: no applications file was given and no suggested group holds an affected unit

Wave

wave 1 · steps in foundation

Approval

not approved: no decisions file was given with this run

What the draft does

Review the public address setting: The draft does not carry the setting on module.vpc.module.vpc.aws_eip.nat; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_eip.nat/public-address). In the estates checked when this entry was written, the draft does not carry these settings: what it writes instead (a variable, a "not carried" line in the Terraform comments, or nothing) is stated per unit in the generated Terraform. Where the critical-settings record of a run names a step that carries a setting (with the evidence of the value), a person confirms that value instead.

Still open

Review the public address setting: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Review the public address setting: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. The address changes. An Elastic IP of a NAT gateway is its fixed egress address, an open question on STACKIT (fixed egress ip of the NAT gateway rule).

Ways out

1. Review the public address setting: Take the decision the knowledge base's note names and carry it out (alternatives: not stated in the knowledge base); needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: A person takes the decision the closing condition names and carries it out; where it changes what the draft writes, the draft is regenerated or changed by hand.; regeneration: not stated — treated as required; risk: The knowledge base states no evidenced alternatives to choose from; a decision taken without the source context the note names can change what the workload reaches, stores or exposes.; the draft is generated again with it

What closes it

Review the public address setting: A person decides how peers that allow-list the Elastic IP are served: STACKIT egress uses the project's shared address, which differs from the Elastic IP, cannot be set and can change; a STACKIT public IP per server keeps its address. Verification: Review the public address setting: the decision or the manual work is done and recorded (who, when, what was configured and why).

Next action

Review the public address setting: Carry out the manual work the plan names for module.vpc.module.vpc.aws_eip.nat outside the draft; the plan states no title for it.

1 unit: module.vpc.module.vpc.aws_nat_gateway.this · owner role Network Architect · required by phase: not stated · 1 step rests on it

Options and trade-off

none listed: the knowledge base has no options for this kind of decision, so none is invented and a person states the answer in the decisions file

Applications touched

none: no applications file was given and no suggested group holds an affected unit

Wave

wave 2 · steps in foundation

Approval

not approved: no decisions file was given with this run

What the draft does

Decide the fixed outbound IP address: The draft does not carry the setting on module.vpc.module.vpc.aws_nat_gateway.this; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_nat_gateway.this/open-settings). In the estates checked when this entry was written, the draft does not carry these settings: what it writes instead (a variable, a "not carried" line in the Terraform comments, or nothing) is stated per unit in the generated Terraform. Where the critical-settings record of a run names a step that carries a setting (with the evidence of the value), a person confirms that value instead. Review the NAT placement setting: The draft does not carry the setting on module.vpc.module.vpc.aws_nat_gateway.this; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_nat_gateway.this/open-settings). Confirm that the project is the boundary of one network: The draft does not carry the setting on module.vpc.module.vpc.aws_nat_gateway.this; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_nat_gateway.this/open-settings).

Still open

Decide the fixed outbound IP address: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Review the NAT placement setting: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Confirm that the project is the boundary of one network: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Decide the fixed outbound IP address: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. A stable egress IP on STACKIT is an open question (no source in this repository answers it; the per-network SNAT address is computed and cannot be chosen or kept). Review the NAT placement setting: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. A zonal NAT gateway (subnet_id) is placed in one AZ; a regional one lists its per-AZ egress in availability_zone_address(es).availability_zone. STACKIT has no NAT gateway resource, and its documentation does not state whether the implicit outbound path is zone-scoped: REVIEW. Confirm that the project is the boundary of one network: A check of the knowledge base (topology vpc unproven) fired on this unit and leaves the setting to a person: the target does not settle it by itself (a finding of this unit describes it). Several VPCs, a VPC count that is not visible, or a unit of the estate that names a VPC, or is placed in a subnet, the scan cannot prove is the estate's, leave the architecture to the architect for every unit of the topology, this NAT gateway included: STACKIT has no VPC container in its stable model, the project is the boundary of its networks, so the draft cannot keep several VPCs apart in one project.

Ways out

1. Decide the fixed outbound IP address: Take the decision the knowledge base's note names and carry it out (alternatives: not stated in the knowledge base); needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: A person takes the decision the closing condition names and carries it out; where it changes what the draft writes, the draft is regenerated or changed by hand.; regeneration: not stated — treated as required; risk: The knowledge base states no evidenced alternatives to choose from; a decision taken without the source context the note names can change what the workload reaches, stores or exposes.; the draft is generated again with it
2. Review the NAT placement setting: Take the decision the knowledge base's note names and carry it out (alternatives: not stated in the knowledge base); needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: A person takes the decision the closing condition names and carries it out; where it changes what the draft writes, the draft is regenerated or changed by hand.; regeneration: not stated — treated as required; risk: The knowledge base states no evidenced alternatives to choose from; a decision taken without the source context the note names can change what the workload reaches, stores or exposes.; the draft is generated again with it
3. Confirm that the project is the boundary of one network: Bring the closing evidence the finding names, or record the decision it asks for; needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: A person reads the finding the critical-settings record of the run names for the setting (its message holds the closing evidence), brings that evidence or records the decision, and the record keeps it.; regeneration: not stated — treated as required; risk: A decision recorded without the evidence the finding names leaves the difference the finding describes in place.; the draft is generated again with it

What closes it

Decide the fixed outbound IP address: A person decides how peers that allow-list the Elastic IP are served: a routed STACKIT network leaves by the project's shared egress address, which cannot be set and can change, so the allow-list follows it or each server gets a STACKIT public IP. Review the NAT placement setting: A person decides whether the egress path must stay in one zone or per zone, because the STACKIT documentation does not state whether the implicit outbound path is scoped to a zone. Confirm that the project is the boundary of one network: The knowledge base states no closing condition for this setting; the run closes it when a person decides it as the open check asks and that check's closing evidence or decision is recorded. Confirm that the project is the boundary of one network: A person decides it as that finding asks, and the finding's closing evidence or decision is recorded. Verification: Decide the fixed outbound IP address: the decision or the manual work is done and recorded (who, when, what was configured and why); Review the NAT placement setting: the decision or the manual work is done and recorded (who, when, what was configured and why); Confirm that the project is the boundary of one network: the check, proof or closing evidence is recorded with its result.

Next action

Decide the fixed outbound IP address: Carry out the manual work the plan names for module.vpc.module.vpc.aws_nat_gateway.this outside the draft; the plan states no title for it.

1 unit: module.vpc.module.vpc.aws_vpc.this · owner role Platform Architect · required by phase: not stated · 1 step rests on it

Options and trade-off

none listed: the knowledge base has no options for this kind of decision, so none is invented and a person states the answer in the decisions file

Applications touched

none: no applications file was given and no suggested group holds an affected unit

Wave

wave 1 · steps in foundation

Approval

not approved: no decisions file was given with this run

What the draft does

Confirm how names resolve for the servers of the migrated networks: The draft does not carry the setting on module.vpc.module.vpc.aws_vpc.this; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_vpc.this/dns-settings). In the estates checked when this entry was written, the draft does not carry these settings: what it writes instead (a variable, a "not carried" line in the Terraform comments, or nothing) is stated per unit in the generated Terraform. Where the critical-settings record of a run names a step that carries a setting (with the evidence of the value), a person confirms that value instead.

Still open

Confirm how names resolve for the servers of the migrated networks: That the STACKIT target reproduces each setting, or that the difference is acceptable for the workload: nothing in the knowledge base proves either. Confirm how names resolve for the servers of the migrated networks: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. enable_dns_support and enable_dns_hostnames of the VPC decide how names resolve for what runs in it; STACKIT has no VPC object (each subnet becomes a stackit_network).

Ways out

1. Confirm how names resolve for the servers of the migrated networks: Verify what the knowledge base's note asks to confirm; needs the knowledge base's note on each setting (cited in this entry) and the unit's open entry in the critical-settings record of the run; effect: A person checks the setting on the STACKIT target (or against the source, the clients and the tooling that depend on it) and records the result; nothing in the draft changes.; regeneration: not stated — treated as required; risk: A setting confirmed from the draft alone, without the check, can still differ at runtime.; the draft is generated again with it

What closes it

Confirm how names resolve for the servers of the migrated networks: A person confirms how names resolve for the servers of the migrated networks. Verification: Confirm how names resolve for the servers of the migrated networks: the check, proof or closing evidence is recorded with its result.

Next action

Confirm how names resolve for the servers of the migrated networks: Verify on the target for module.vpc.module.vpc.aws_vpc.this: the check, proof or closing evidence is recorded with its result.