Use GetTraceSummaries to list trace IDs for the time window, then call BatchGetTraces to download the full trace data is correct because it discovers trace IDs within a specified time window and then retrieves the full trace documents required to render complete traces in a custom dashboard.

GetTraceSummaries supports start time and end time filters so you can restrict queries to the last 36 hours and it returns trace identifiers and summary information. After you collect the IDs you call BatchGetTraces with those IDs and it returns the full segment documents and annotations that your custom viewer needs to show end to end trace detail.

Use the GetServiceGraph API to enumerate trace IDs, then fetch the traces with GetTraceSummaries is incorrect because GetServiceGraph produces a service topology and aggregated metrics and it does not provide a list of individual trace IDs. Also GetTraceSummaries returns summaries and not full trace documents so it cannot by itself provide complete trace payloads.

Call BatchGetTraces first to discover trace IDs, then query the traces with GetTraceSummaries is wrong because BatchGetTraces requires trace IDs as input and so it cannot be used to discover IDs. The summary call is what returns IDs and the batch call is what fetches the full traces.

Use the GetGroup API to obtain trace IDs for the app, then retrieve the traces with BatchGetTraces is invalid because GetGroup returns group metadata and the filter expression for a group and it does not produce the individual trace identifiers needed to call BatchGetTraces.

Full AWS Practitioner Certification Question