A game studio has web and app EPGs in the same ACI VRF. Web servers cannot open a single required port to the app servers, and no contract exists between the EPGs. Which change permits only that port?
Select an answer to reveal the explanation.
Short Explanation
ACI is a guest list, not an open lobby. You write a contract for the one port, let the app EPG provide it, and let the web EPG consume it. Preferred group would swing the doors open between the members, which is much more than this studio asked for.
Full Explanation
Between EPGs, ACI is a whitelist. With no contract, web endpoints are not allowed to reach app endpoints even though both EPGs sit in the same VRF. The specific fix is a contract whose filter names the required protocol and port, provided by the app EPG and consumed by the web EPG, because the web tier is the side opening the connection. Preferred group on the VRF permits a wide set of communication among EPGs that are marked as members. It does not limit traffic to one port, so it fails the requirement even though traffic would start to flow. Hardware proxy is a forwarding choice for unknown unicast. The spine COOP lookup does not insert a permit entry between EPGs. Merging web and app into one EPG uses the default intra-EPG allow, which opens communication and also drops the ability to filter that one port at the contract layer. Caveat: the filter has to match the real protocol and port, and a taboo or a higher-priority deny still wins if one is already in the tenant. Operational check: after the contract is applied, verify the two EPGs show the provide and consume relationship and test only the intended port from a web host.