interview_flashcards

Question 1

What is environment parameterization in Connect flows?

Answer 1

Using the Connect instance ARN to detect which environment (dev/QA/UAT/prod) the flow is running in, then setting all resource ARNs to match. Same flow works everywhere - no changes needed per environment.

Question 2

Why did L set 112 contact attributes with ARNs at the start of the flow?

Answer 2

So every Lambda, Lex bot, and DynamoDB table referenced downstream points to the correct environment. Flow detects its own Connect instance ARN → sets all resource ARNs for that environment → every block downstream uses those attributes instead of hardcoded values.

Question 3

What’s the FIRST thing the flow does to figure out which environment it’s in?

Answer 3

It reads its own Connect instance ARN. Each environment (dev, QA, UAT, prod) has a different Connect instance with a different ARN. The ARN tells the flow where it is.

Question 4

After the flow knows which environment it’s in what does it do next?

Answer 4

Sets 100+ contact attributes pointing to the correct resource ARNs - the right Lambda ARNs, Lex bot ARNs, DynamoDB table names. Everything downstream references these attributes.

Question 5

Why NOT just hardcode Lambda ARNs directly in each flow block?

Answer 5

You’d need separate flow versions for dev, QA, UAT, and prod. Every update means updating 4 flows. With parameterization one flow works everywhere - DevOps deploys the same thing to every environment.

Question 6

How does environment parameterization help the DevOps pipeline?

Answer 6

Pipeline stays simple - deploy the same flow to every Connect instance. No environment-specific flow versions. No risk of deploying a dev Lambda ARN to prod. The flow figures out the right resources on its own.

Question 7

What’s the Lambda equivalent of environment parameterization?

Answer 7

Environment variables. Instead of hardcoding a DynamoDB table name in code, store it in TABLE_NAME env var. Same Lambda code runs in dev and prod - only the env var value changes per environment.

Question 8

What’s the CDK equivalent of environment parameterization?

Answer 8

CDK parameterization with environment-specific configs. Pass different values (account ID, region, table names) per environment. Same CDK code, different configs for dev/staging/prod.

Question 9

What does a Connect instance ARN look like?

Answer 9

arn:aws:connect:us-east-1:123456789012:instance/abc-def-123. The account ID and instance ID are unique per environment - that’s how the flow knows if it’s in dev, QA, UAT, or prod.

Question 10

If you deploy the same flow to dev and prod how do the Lambda calls go to different functions?

Answer 10

Flow reads its Connect ARN → detects it’s in prod → sets contact attributes with prod Lambda ARNs → every Invoke Lambda block references those attributes. In dev, same flow reads a different ARN → sets dev Lambda ARNs instead.

Question 11

What’s the config-driven approach and how does it connect to parameterization?

Answer 11

Same idea - changes are config updates, not code changes. Update a DynamoDB table or environment variable instead of rewriting and redeploying. Parameterization, env vars, and DynamoDB configs are all config-driven patterns.

Question 12

Phone number disconnecting 100% of calls - what’s Step 1?

Answer 12

Phone Numbers page → find the number → confirm it’s mapped to a flow. If it’s not mapped to anything, that’s your problem right there.

Question 13

Phone number is mapped to a flow - what’s Step 2?

Answer 13

Open that flow → read it block by block from the entry point. Understand what the flow is SUPPOSED to do before you start looking at logs.

Question 14

You’re reading the flow and see a Lambda invoke - what’s Step 3?

Answer 14

Identify where the flow could fail. Lambda timeout? Missing DynamoDB data? Bad error handling? Look at what the Lambda should return and where the error branch goes.

Question 15

You suspect the prompt Lambda is the issue - what’s Step 4?

Answer 15

Go to Lambda console → find that specific function → read the code. Look at index.js (handler) and the services folder (business logic). Understand what it does before checking logs.

Question 16

How do you find which DynamoDB table a Lambda is querying?

Answer 16

Lambda console → Configuration tab → Environment Variables → look for TABLE_NAME or DYNAMODB_TABLE. That’s your table. Then go to DynamoDB console and pull it up.

Question 17

What does a missing prompt look like in production?

Answer 17

Lambda queries DynamoDB for a prompt key → gets nothing back → returns empty or null → flow tries to play empty prompt → caller hears silence → disconnect. Fix: add the missing prompt entry to DynamoDB.

Question 18

When do you check CloudWatch Logs in troubleshooting?

Answer 18

AFTER you understand the flow, the Lambda code, and the DynamoDB data. Logs confirm what you suspect - don’t go there first because you won’t know what to look for yet.

Question 19

What’s the full troubleshooting order?

Answer 19

Phone number → flow → specific block → Lambda console → Lambda code → env vars → DynamoDB → THEN CloudWatch logs and metrics. Follow the call path.

Question 20

What does Set Logging Behavior do at the start of a flow?

Answer 20

Enables CloudWatch logging for this contact. Every block the call hits gets logged so you can trace it later.

Question 21

What does Set Recording/Analytics Behavior do?

Answer 21

Controls call recording (agent side, customer side, or both) and enables Contact Lens for transcription and sentiment analysis.

Question 22

Why set a voice like Joanna near the start of the flow?

Answer 22

Sets the Amazon Polly TTS voice for Play Prompt blocks using text-to-speech. Joanna is default English. Set a second voice for Spanish if the flow supports it.

Question 23

What should you ask when navigating 100+ flows in someone else’s environment?

Answer 23

Ask about their naming convention first. Likewize used ‘wise connect’ as a prefix. Knowing the pattern saves you from scrolling through 100 flows guessing.

Question 24

What’s in the index.js file of a Lambda?

Answer 24

The handler - entry point that listens for triggers. Receives the event, calls service functions, returns the response. It’s the front door, not where the real work happens.

Question 25

What's in the services/ folder of a Lambda?

Answer 25

The business logic. DynamoDB queries, API calls, data transformations happen here. The handler calls these functions. This is where you look to understand what the Lambda actually does.

Question 26

You see a Lambda with index.js and a services/ folder - where do you look first?

Answer 26

index.js first to understand what triggers it and what it returns. Then services/ to see the actual logic - DynamoDB queries, external API calls, data processing.

Question 27

How do dynamic prompts work in Connect with DynamoDB?

Answer 27

Flow invokes Lambda → Lambda queries DynamoDB using LOB + prompt key → DynamoDB returns prompt text with SSML tags → Lambda passes it back as contact attribute → flow plays it in Play Prompt block.

Question 28

Why store prompts in DynamoDB instead of directly in the flow?

Answer 28

Centralized management. Update a DynamoDB entry to change what callers hear - no flow changes, no redeployment. Same flow handles multiple LOBs with different prompt keys. Non-technical staff can update prompts.

Question 29

What's SSML and why is it used in prompts?

Answer 29

Speech Synthesis Markup Language. Tags that control how Polly reads text - pauses, emphasis, speed, pronunciation. Stored in DynamoDB with prompt text so output sounds natural, not robotic.

Question 30

How does the prompt Lambda know which prompts to pull?

Answer 30

The flow passes the line of business and prompt key as parameters. Lambda uses those to query DynamoDB for the right prompt entries. Different LOBs get different prompts from the same Lambda and table.