Free SAP-C03 practice questions

SQS FIFO ordering is scoped to a message group; parallelism comes from having many groups, and deduplication is by deduplication ID within a five-minute interval.

The requirement mixes three properties: per-merchant order, parallelism across merchants and suppression of retried sends. A FIFO queue with the merchant as the message group gives the first two, because consumers can work on different groups at once while each group is delivered in order. Setting the deduplication ID to the transaction ID gives the third. One fixed group serialises the whole queue, a standard queue does not order, and a random Kinesis partition key breaks the per-merchant order.

1. Identify the ordering scope: per merchant, not global.
2. Map that scope to the FIFO message group ID so groups run in parallel.
3. Map the business identity of a send (the transaction ID) to the deduplication ID.
4. Reject designs that order globally (no scale) or not at all (standard queue, random key).

Exam tip: Order by the narrowest key the business needs: one message group (or partition key) per entity, never one for everything.

IAM Identity Center with an external IdP splits the job: SAML 2.0 authenticates the user, SCIM provisions and deprovisions identities.

Identity Center is the AWS-recommended way to give a workforce single sign-on to many accounts. Choosing Okta as the external identity source over SAML 2.0 handles authentication. Because Identity Center does not create or remove users from SAML assertions, automatic provisioning through SCIM is what makes the HR-driven lifecycle work: a user disabled in Okta is deprovisioned in Identity Center. Per-account IAM SAML providers scale poorly, and Cognito is for application users, not workforce access to AWS accounts.

1. Recognise a workforce, multi-account single sign-on need: IAM Identity Center.
2. Connect the existing directory as the identity source using SAML 2.0 for sign-in.
3. Separate authentication from lifecycle: SCIM pushes user and group changes.
4. Reject Cognito (application users) and per-account IAM SAML providers (no central control).

Exam tip: SAML signs users in; SCIM creates and removes them. Identity Center needs both for an external IdP lifecycle.

Compute Savings Plans trade a smaller discount for the widest flexibility: any EC2 family, size, Region, OS or tenancy, plus Fargate and Lambda.

The stated plan moves usage across instance families, Regions and from EC2 to Fargate and Lambda. Only a Compute Savings Plan keeps applying across all of those changes. EC2 Instance Savings Plans and Reserved Instances give deeper or similar discounts but are bound to EC2 instance families and Regions, and none of them discount Fargate or Lambda.

1. List the changes expected during the term: family, Region, and compute service.
2. Check which commitment covers Fargate and Lambda as well as EC2.
3. Choose the Compute Savings Plan and size it to the steady hourly spend.

Exam tip: When usage will move between families, Regions or from EC2 to Fargate/Lambda, a Compute Savings Plan is the commitment that follows it.

Migration discovery must capture both utilization and network connections, because move groups are built from observed dependencies, not from inventory lists.

The deciding needs are utilization data plus evidence of which servers communicate, for a company new to AWS migration services. The AWS Transform discovery tool runs in the VMware environment and collects performance and network connection data that AWS Transform's planning uses. RVTools is a static configuration export without connection data. Compute Optimizer only analyzes AWS resources. The Agentless Collector of Application Discovery Service did collect connections, but that service is closed to new customers.

1. List what the plan needs: inventory, utilization and server-to-server connections.
2. Check which source actually observes network connections rather than listing servers.
3. Rule out tools that only work on AWS resources or are closed to new customers.

Exam tip: Move groups come from observed connections: collect network dependency data with the AWS Transform discovery tool, not from RVTools or a CMDB alone.

Service-managed StackSets with automatic deployment keep an organization-wide baseline in every current and future member account.

Two requirements decide it: future accounts must receive the baseline automatically, and no per-account deployment roles should be maintained. Service-managed permissions use Organizations trusted access, so CloudFormation creates the roles it needs; automatic deployment deploys stack instances when an account joins a targeted OU. Self-managed StackSets need roles in every account, nested stacks cannot cross accounts, and per-account CDK deployments need bootstrapping and pipeline changes for every new account.

1. List the requirements: every member account, two Regions, future accounts included, no per-account roles.
2. Pick the multi-account deployment mechanism: CloudFormation StackSets.
3. Choose the permission model that needs no roles in each account: service-managed.
4. Turn on automatic deployment so accounts added later receive the stack.

Exam tip: Org-wide baseline for current and future accounts: service-managed StackSet + automatic deployment, targeting OUs or the root.